Marc Boyer writes:
| > Dans ce cas, tu enfonces une porte ouverte -- voir les écrits de BS
| > à ce sujet.
|
| Lesquels ?
celles que tu viens d'enfoncer :-)
| >| > (je choix des unsigned dans la STL est beacuoup plus compliqué que
| >| > le simple constat le suggèrerait.)
| >|
| >| Je suis preneur de tout pointeur, toute information, sur ce choix.
| >
| > Pointeurs vers des discussions orales ou internes du comité C++ ?
|
| S'il y en a, bien sûr.
|
| > Par contre, tu peux lire TC++PL3 pour voir ce qu'en pense l'auteur.
|
| Je ne trouve pas grand chose (mais je cherche peut-être mal).
| 16.3.4 dit juste des choses genre "ça permet une plus grande plage de
| valeur, mais ça peut provoquer des surprises".
quelle édition, quelle printing ?
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| > Dans ce cas, tu enfonces une porte ouverte -- voir les écrits de BS
| > à ce sujet.
|
| Lesquels ?
celles que tu viens d'enfoncer :-)
| >| > (je choix des unsigned dans la STL est beacuoup plus compliqué que
| >| > le simple constat le suggèrerait.)
| >|
| >| Je suis preneur de tout pointeur, toute information, sur ce choix.
| >
| > Pointeurs vers des discussions orales ou internes du comité C++ ?
|
| S'il y en a, bien sûr.
|
| > Par contre, tu peux lire TC++PL3 pour voir ce qu'en pense l'auteur.
|
| Je ne trouve pas grand chose (mais je cherche peut-être mal).
| 16.3.4 dit juste des choses genre "ça permet une plus grande plage de
| valeur, mais ça peut provoquer des surprises".
quelle édition, quelle printing ?
Marc Boyer writes:
| > Dans ce cas, tu enfonces une porte ouverte -- voir les écrits de BS
| > à ce sujet.
|
| Lesquels ?
celles que tu viens d'enfoncer :-)
| >| > (je choix des unsigned dans la STL est beacuoup plus compliqué que
| >| > le simple constat le suggèrerait.)
| >|
| >| Je suis preneur de tout pointeur, toute information, sur ce choix.
| >
| > Pointeurs vers des discussions orales ou internes du comité C++ ?
|
| S'il y en a, bien sûr.
|
| > Par contre, tu peux lire TC++PL3 pour voir ce qu'en pense l'auteur.
|
| Je ne trouve pas grand chose (mais je cherche peut-être mal).
| 16.3.4 dit juste des choses genre "ça permet une plus grande plage de
| valeur, mais ça peut provoquer des surprises".
quelle édition, quelle printing ?
Marc Boyer writes:
| Ton séjour aux US semble néfaste à ta vigilance grammaticale:
Touché. Mais, serais-tu en train d'illustrer l'idée que rester cloîtré
dans l'hexagone peut se revéler tout aussi atrophiant pour le cerveau ?
| Version française, dite "quatrième édition".
VO, page 73 :
The /unsigned/ integer types are ideal for uses that treat storage
as a bit array. Using /unsigned/ instead of an /int/ to gain one
more bit to represent positive integers is almost never a good idea.
Attempts to ensure that some values are positive by declaring
variables /unsigned/ will typically be defeated by the implicit
conversion rules [...]
page 448 :
[...] This allows a greater range of vector sizes on some
architecture. However, it can also lead to surprises. [...]
In the call f(-1), -1 is converted into a (rather large) positive
integer (§C.6.3). If we are lucky, the compiler will find a way of
complaining.
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| Ton séjour aux US semble néfaste à ta vigilance grammaticale:
Touché. Mais, serais-tu en train d'illustrer l'idée que rester cloîtré
dans l'hexagone peut se revéler tout aussi atrophiant pour le cerveau ?
| Version française, dite "quatrième édition".
VO, page 73 :
The /unsigned/ integer types are ideal for uses that treat storage
as a bit array. Using /unsigned/ instead of an /int/ to gain one
more bit to represent positive integers is almost never a good idea.
Attempts to ensure that some values are positive by declaring
variables /unsigned/ will typically be defeated by the implicit
conversion rules [...]
page 448 :
[...] This allows a greater range of vector sizes on some
architecture. However, it can also lead to surprises. [...]
In the call f(-1), -1 is converted into a (rather large) positive
integer (§C.6.3). If we are lucky, the compiler will find a way of
complaining.
Marc Boyer writes:
| Ton séjour aux US semble néfaste à ta vigilance grammaticale:
Touché. Mais, serais-tu en train d'illustrer l'idée que rester cloîtré
dans l'hexagone peut se revéler tout aussi atrophiant pour le cerveau ?
| Version française, dite "quatrième édition".
VO, page 73 :
The /unsigned/ integer types are ideal for uses that treat storage
as a bit array. Using /unsigned/ instead of an /int/ to gain one
more bit to represent positive integers is almost never a good idea.
Attempts to ensure that some values are positive by declaring
variables /unsigned/ will typically be defeated by the implicit
conversion rules [...]
page 448 :
[...] This allows a greater range of vector sizes on some
architecture. However, it can also lead to surprises. [...]
In the call f(-1), -1 is converted into a (rather large) positive
integer (§C.6.3). If we are lucky, the compiler will find a way of
complaining.
Marc Boyer writes:
| Le 29-10-2010, Gabriel Dos Reis a écrit :
| > Marc Boyer writes:
| >
| >| Ton séjour aux US semble néfaste à ta vigilance grammaticale:
| >
| > Touché. Mais, serais-tu en train d'illustrer l'idée que rester cloîtré
| > dans l'hexagone peut se revéler tout aussi atrophiant pour le cerveau ?
|
| Il ne me semble pas que l'état de mon cerveau soit pire qu'il y a
| quelques années.
Je présume que c'est ici que je devrais dire « I rest my case » :-)
Je ne me prononçais pas sur l'état de ton cerveau, mais je soupçonne qu'en
passant à côté de ce que je disais, tu apportes de l'eau à mon moulin.
| > page 448 :
| > [...] This allows a greater range of vector sizes on some
| > architecture. However, it can also lead to surprises. [...]
| > In the call f(-1), -1 is converted into a (rather large) positive
| > integer (§C.6.3). If we are lucky, the compiler will find a way of
| > complaining.
|
| Oui, c'est ce que j'avais trouvé dans la version française.
|
| Reste un point à discuter: à partir du moment où la bibliothèque standard
| (les familles str* et *alloc en C, les size_type en C++) utilisent
| des non-signés, quelle stratégie d'usage dans le code utilisateur ?
Personnellement, j'utilise un entier signé -- je passe à un entier
non-signé uniquement si c'est requis par le code ou la circonstance
(e.g. mon manager dit que c'est qu'on doit faire, ou les règles locales
disent que c'est ce qu'on doit faire pour le projet.)
| Et historiquement, pourquoi les non-signés dans la STL ?
parce que la comité a voté ainsi.
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| Le 29-10-2010, Gabriel Dos Reis <gdr@cse.tamu.edu> a écrit :
| > Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| >
| >| Ton séjour aux US semble néfaste à ta vigilance grammaticale:
| >
| > Touché. Mais, serais-tu en train d'illustrer l'idée que rester cloîtré
| > dans l'hexagone peut se revéler tout aussi atrophiant pour le cerveau ?
|
| Il ne me semble pas que l'état de mon cerveau soit pire qu'il y a
| quelques années.
Je présume que c'est ici que je devrais dire « I rest my case » :-)
Je ne me prononçais pas sur l'état de ton cerveau, mais je soupçonne qu'en
passant à côté de ce que je disais, tu apportes de l'eau à mon moulin.
| > page 448 :
| > [...] This allows a greater range of vector sizes on some
| > architecture. However, it can also lead to surprises. [...]
| > In the call f(-1), -1 is converted into a (rather large) positive
| > integer (§C.6.3). If we are lucky, the compiler will find a way of
| > complaining.
|
| Oui, c'est ce que j'avais trouvé dans la version française.
|
| Reste un point à discuter: à partir du moment où la bibliothèque standard
| (les familles str* et *alloc en C, les size_type en C++) utilisent
| des non-signés, quelle stratégie d'usage dans le code utilisateur ?
Personnellement, j'utilise un entier signé -- je passe à un entier
non-signé uniquement si c'est requis par le code ou la circonstance
(e.g. mon manager dit que c'est qu'on doit faire, ou les règles locales
disent que c'est ce qu'on doit faire pour le projet.)
| Et historiquement, pourquoi les non-signés dans la STL ?
parce que la comité a voté ainsi.
Marc Boyer writes:
| Le 29-10-2010, Gabriel Dos Reis a écrit :
| > Marc Boyer writes:
| >
| >| Ton séjour aux US semble néfaste à ta vigilance grammaticale:
| >
| > Touché. Mais, serais-tu en train d'illustrer l'idée que rester cloîtré
| > dans l'hexagone peut se revéler tout aussi atrophiant pour le cerveau ?
|
| Il ne me semble pas que l'état de mon cerveau soit pire qu'il y a
| quelques années.
Je présume que c'est ici que je devrais dire « I rest my case » :-)
Je ne me prononçais pas sur l'état de ton cerveau, mais je soupçonne qu'en
passant à côté de ce que je disais, tu apportes de l'eau à mon moulin.
| > page 448 :
| > [...] This allows a greater range of vector sizes on some
| > architecture. However, it can also lead to surprises. [...]
| > In the call f(-1), -1 is converted into a (rather large) positive
| > integer (§C.6.3). If we are lucky, the compiler will find a way of
| > complaining.
|
| Oui, c'est ce que j'avais trouvé dans la version française.
|
| Reste un point à discuter: à partir du moment où la bibliothèque standard
| (les familles str* et *alloc en C, les size_type en C++) utilisent
| des non-signés, quelle stratégie d'usage dans le code utilisateur ?
Personnellement, j'utilise un entier signé -- je passe à un entier
non-signé uniquement si c'est requis par le code ou la circonstance
(e.g. mon manager dit que c'est qu'on doit faire, ou les règles locales
disent que c'est ce qu'on doit faire pour le projet.)
| Et historiquement, pourquoi les non-signés dans la STL ?
parce que la comité a voté ainsi.
| >| Et historiquement, pourquoi les non-signés dans la STL ?
| >
| > parce que la comité a voté ainsi.
|
| Affirmation vraie, mais d'un intérêt limité.
Tu aurais préférée soit fausse ?
| Tu m'avais alléché avec deux phrases
| "voir les écris de BS à ce sujet." ("ce" se rapportant à l'usage de non
| signés dans les tailles de conteneur) et "je choix des unsigned dans la
| STL est beaucoup plus compliqué que le simple constat le suggèrerait".
|
| Au final, tu m'a montrés deux passages du TC++PL d'où il ressort que BS
| juge qu'en général, il ne faut pas utiliser les non signés pour autre
| chose que des champs de bit, et une autre où il signale les dangers
| liés au choix de non signés pour vector::size_t, qu'on pourrait lire en
| creux comme une critique de ce choix.
Ceux qui connaisent les écrits de BS et la façon dont il s'exprime
ne liront pas en creux.
| >| Et historiquement, pourquoi les non-signés dans la STL ?
| >
| > parce que la comité a voté ainsi.
|
| Affirmation vraie, mais d'un intérêt limité.
Tu aurais préférée soit fausse ?
| Tu m'avais alléché avec deux phrases
| "voir les écris de BS à ce sujet." ("ce" se rapportant à l'usage de non
| signés dans les tailles de conteneur) et "je choix des unsigned dans la
| STL est beaucoup plus compliqué que le simple constat le suggèrerait".
|
| Au final, tu m'a montrés deux passages du TC++PL d'où il ressort que BS
| juge qu'en général, il ne faut pas utiliser les non signés pour autre
| chose que des champs de bit, et une autre où il signale les dangers
| liés au choix de non signés pour vector::size_t, qu'on pourrait lire en
| creux comme une critique de ce choix.
Ceux qui connaisent les écrits de BS et la façon dont il s'exprime
ne liront pas en creux.
| >| Et historiquement, pourquoi les non-signés dans la STL ?
| >
| > parce que la comité a voté ainsi.
|
| Affirmation vraie, mais d'un intérêt limité.
Tu aurais préférée soit fausse ?
| Tu m'avais alléché avec deux phrases
| "voir les écris de BS à ce sujet." ("ce" se rapportant à l'usage de non
| signés dans les tailles de conteneur) et "je choix des unsigned dans la
| STL est beaucoup plus compliqué que le simple constat le suggèrerait".
|
| Au final, tu m'a montrés deux passages du TC++PL d'où il ressort que BS
| juge qu'en général, il ne faut pas utiliser les non signés pour autre
| chose que des champs de bit, et une autre où il signale les dangers
| liés au choix de non signés pour vector::size_t, qu'on pourrait lire en
| creux comme une critique de ce choix.
Ceux qui connaisent les écrits de BS et la façon dont il s'exprime
ne liront pas en creux.
Marc Boyer writes:
| >| Tu m'avais alléché avec deux phrases
| >| "voir les écris de BS à ce sujet." ("ce" se rapportant à l'usage de non
| >| signés dans les tailles de conteneur) et "je choix des unsigned dans la
| >| STL est beaucoup plus compliqué que le simple constat le suggèrerait".
| >|
| >| Au final, tu m'a montrés deux passages du TC++PL d'où il ressort que BS
| >| juge qu'en général, il ne faut pas utiliser les non signés pour autre
| >| chose que des champs de bit, et une autre où il signale les dangers
| >| liés au choix de non signés pour vector::size_t, qu'on pourrait lire en
| >| creux comme une critique de ce choix.
| >
| > Ceux qui connaisent les écrits de BS et la façon dont il s'exprime
| > ne liront pas en creux.
|
| D'ailleurs, en général, je viens sur fclc et fclc++ pour apprendre.
|
| Donc, maintenant que tu as suggéré que BS n'appréciait pas
Ce n'est pas just de la suggestion.
| le choix des non-signés pour vectore::size_t,
De plus il les a banni des règles JSF++.
| as-tu des informations
| à donner qui permettent d'éclairer ton "je choix des unsigned dans la
| STL est beaucoup plus compliqué que le simple constat le suggèrerait" ?
La plupart des discussions ont eu lieu dans des meetings face-à-face.
À ta place, je ne regarderais pas le fait que BS se croit obligé de dire
aux gens d'éviter les unsigned et de les bannir de JSF++ comme juste du bruit.
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| >| Tu m'avais alléché avec deux phrases
| >| "voir les écris de BS à ce sujet." ("ce" se rapportant à l'usage de non
| >| signés dans les tailles de conteneur) et "je choix des unsigned dans la
| >| STL est beaucoup plus compliqué que le simple constat le suggèrerait".
| >|
| >| Au final, tu m'a montrés deux passages du TC++PL d'où il ressort que BS
| >| juge qu'en général, il ne faut pas utiliser les non signés pour autre
| >| chose que des champs de bit, et une autre où il signale les dangers
| >| liés au choix de non signés pour vector::size_t, qu'on pourrait lire en
| >| creux comme une critique de ce choix.
| >
| > Ceux qui connaisent les écrits de BS et la façon dont il s'exprime
| > ne liront pas en creux.
|
| D'ailleurs, en général, je viens sur fclc et fclc++ pour apprendre.
|
| Donc, maintenant que tu as suggéré que BS n'appréciait pas
Ce n'est pas just de la suggestion.
| le choix des non-signés pour vectore::size_t,
De plus il les a banni des règles JSF++.
| as-tu des informations
| à donner qui permettent d'éclairer ton "je choix des unsigned dans la
| STL est beaucoup plus compliqué que le simple constat le suggèrerait" ?
La plupart des discussions ont eu lieu dans des meetings face-à-face.
À ta place, je ne regarderais pas le fait que BS se croit obligé de dire
aux gens d'éviter les unsigned et de les bannir de JSF++ comme juste du bruit.
Marc Boyer writes:
| >| Tu m'avais alléché avec deux phrases
| >| "voir les écris de BS à ce sujet." ("ce" se rapportant à l'usage de non
| >| signés dans les tailles de conteneur) et "je choix des unsigned dans la
| >| STL est beaucoup plus compliqué que le simple constat le suggèrerait".
| >|
| >| Au final, tu m'a montrés deux passages du TC++PL d'où il ressort que BS
| >| juge qu'en général, il ne faut pas utiliser les non signés pour autre
| >| chose que des champs de bit, et une autre où il signale les dangers
| >| liés au choix de non signés pour vector::size_t, qu'on pourrait lire en
| >| creux comme une critique de ce choix.
| >
| > Ceux qui connaisent les écrits de BS et la façon dont il s'exprime
| > ne liront pas en creux.
|
| D'ailleurs, en général, je viens sur fclc et fclc++ pour apprendre.
|
| Donc, maintenant que tu as suggéré que BS n'appréciait pas
Ce n'est pas just de la suggestion.
| le choix des non-signés pour vectore::size_t,
De plus il les a banni des règles JSF++.
| as-tu des informations
| à donner qui permettent d'éclairer ton "je choix des unsigned dans la
| STL est beaucoup plus compliqué que le simple constat le suggèrerait" ?
La plupart des discussions ont eu lieu dans des meetings face-à-face.
À ta place, je ne regarderais pas le fait que BS se croit obligé de dire
aux gens d'éviter les unsigned et de les bannir de JSF++ comme juste du bruit.