Je cherche un moyen de connaitre la position d'une occurence dans une chaine
J'ai essayé :
temp = strstr(bufferspace, "truc");
taille = temp-bufferspace;
Ne fonctionne pas car temp peut prendre la valeur NULL et donc le
compilateur refuse.
Etant dans l'espace noyau, je n'ai accès qu'a des fonctions sortant un
pointeur, et non la position.
| Dommage que cette sémantique n'ait pas été étendue au typedef...
j'ai peur de ne pas bien saisir la dernière phrase. Pourrais-tu en dire plus ?
si je fais typedef int mon_type; alors int et mon_type sont interchangeables. typedef défini un alias. J'aimerais souvent pouvoir définir un type en disant c'est représenté comme int mais ce n'est pas interchangeable avec un int.
-- Monde de merde
Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait :
Erwan David <erwan@rail.eu.org> writes:
[...]
| Dommage que cette sémantique n'ait pas été étendue au typedef...
j'ai peur de ne pas bien saisir la dernière phrase. Pourrais-tu en
dire plus ?
si je fais typedef int mon_type;
alors int et mon_type sont interchangeables. typedef défini un
alias. J'aimerais souvent pouvoir définir un type en disant c'est
représenté comme int mais ce n'est pas interchangeable avec un int.
| Dommage que cette sémantique n'ait pas été étendue au typedef...
j'ai peur de ne pas bien saisir la dernière phrase. Pourrais-tu en dire plus ?
si je fais typedef int mon_type; alors int et mon_type sont interchangeables. typedef défini un alias. J'aimerais souvent pouvoir définir un type en disant c'est représenté comme int mais ce n'est pas interchangeable avec un int.
-- Monde de merde
Laurent Deniau
Erwan David wrote:
Gabriel Dos Reis écrivait :
Erwan David writes:
[...]
| Dommage que cette sémantique n'ait pas été étendue au typedef...
j'ai peur de ne pas bien saisir la dernière phrase. Pourrais-tu en dire plus ?
si je fais typedef int mon_type; alors int et mon_type sont interchangeables. typedef défini un alias. J'aimerais souvent pouvoir définir un type en disant c'est représenté comme int mais ce n'est pas interchangeable avec un int.
typedef struct { int a; } mon_type1;
convient? de plus il n'est pas interchangeable avec mon_type2 meme si on a:
typedef struct { int a; } mon_type2;
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
Erwan David wrote:
Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait :
Erwan David <erwan@rail.eu.org> writes:
[...]
| Dommage que cette sémantique n'ait pas été étendue au typedef...
j'ai peur de ne pas bien saisir la dernière phrase. Pourrais-tu en
dire plus ?
si je fais typedef int mon_type;
alors int et mon_type sont interchangeables. typedef défini un
alias. J'aimerais souvent pouvoir définir un type en disant c'est
représenté comme int mais ce n'est pas interchangeable avec un int.
typedef struct { int a; } mon_type1;
convient? de plus il n'est pas interchangeable avec mon_type2 meme si on a:
typedef struct { int a; } mon_type2;
a+, ld.
--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]
| Dommage que cette sémantique n'ait pas été étendue au typedef...
j'ai peur de ne pas bien saisir la dernière phrase. Pourrais-tu en dire plus ?
si je fais typedef int mon_type; alors int et mon_type sont interchangeables. typedef défini un alias. J'aimerais souvent pouvoir définir un type en disant c'est représenté comme int mais ce n'est pas interchangeable avec un int.
typedef struct { int a; } mon_type1;
convient? de plus il n'est pas interchangeable avec mon_type2 meme si on a:
typedef struct { int a; } mon_type2;
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
Laurent Deniau
Gabriel Dos Reis wrote:
Laurent Deniau writes:
[...]
| > | - mais char a le meme comportement que soit signed char soit unsigned char | > Non. La norme ne dit pas ça. | | malheureusement si...
il n'y a pas de malheureusement; et j'ai mal lu ta phrase. Je l'ai comprise comme si elle voulait dire que char doit être pareil que soit 'signed char' ou 'unsigned char'.
| 6.2.5-15 | | The three types char, signed char, and unsigned char are collectively | called the character types. The implementation shall define char to | have the same range, representation, and behavior as either signed | char or unsigned char.32)
et en même temps, char doit être un type distinct.
Ce que la norme veut dire ici, c'est juste la formulation de ce qui se passe concretement sur une architrecture 32-bits ou int et long font 32 bits (disons un solaris-2.[567] sur un SPARC 32-bit par exemple).
Les deux types vont avoir alors les mêmes représentations, mais ils resteront néanmoins distincts et incompatibles. Ce n'est pas contradictoire. C'est simplement que la sémantique C (et C++ dans une certaine mesure) est orientée « token » et non « bits »
Ils peuvent avoir les memes representations et la meme taille, mais la norme ne l'exige pas donc il est normal qu'ils soient incompatibles.
Pour les chars, la norme l'exige et va meme plus loin. Voila pourquoi concretement et meme en allant jusqu'au bits, si 6.2.5-15 est respectee, je ne vois pas comment char n'est pas compatible avec un des deux autres. D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un souhait soujacent mais non exprime que char et signed char soit comptatible, peut-etre par coherence avec int et signed int, etc...
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
Gabriel Dos Reis wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
[...]
| > | - mais char a le meme comportement que soit signed char soit unsigned char
| > Non. La norme ne dit pas ça.
|
| malheureusement si...
il n'y a pas de malheureusement; et j'ai mal lu ta phrase.
Je l'ai comprise comme si elle voulait dire que char doit être pareil
que soit 'signed char' ou 'unsigned char'.
| 6.2.5-15
|
| The three types char, signed char, and unsigned char are collectively
| called the character types. The implementation shall define char to
| have the same range, representation, and behavior as either signed
| char or unsigned char.32)
et en même temps, char doit être un type distinct.
Ce que la norme veut dire ici, c'est juste la formulation de ce qui se
passe concretement sur une architrecture 32-bits ou int et long font
32 bits (disons un solaris-2.[567] sur un SPARC 32-bit par exemple).
Les deux types vont avoir alors les mêmes représentations, mais ils
resteront néanmoins distincts et incompatibles. Ce n'est pas
contradictoire. C'est simplement que la sémantique C (et C++ dans une
certaine mesure) est orientée « token » et non « bits »
Ils peuvent avoir les memes representations et la meme taille, mais la norme ne
l'exige pas donc il est normal qu'ils soient incompatibles.
Pour les chars, la norme l'exige et va meme plus loin. Voila pourquoi
concretement et meme en allant jusqu'au bits, si 6.2.5-15 est respectee, je ne
vois pas comment char n'est pas compatible avec un des deux autres. D'ailleurs a
plusieurs endroit dans la norme on sent qu'il y ait un souhait soujacent mais
non exprime que char et signed char soit comptatible, peut-etre par coherence
avec int et signed int, etc...
a+, ld.
--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]
| > | - mais char a le meme comportement que soit signed char soit unsigned char | > Non. La norme ne dit pas ça. | | malheureusement si...
il n'y a pas de malheureusement; et j'ai mal lu ta phrase. Je l'ai comprise comme si elle voulait dire que char doit être pareil que soit 'signed char' ou 'unsigned char'.
| 6.2.5-15 | | The three types char, signed char, and unsigned char are collectively | called the character types. The implementation shall define char to | have the same range, representation, and behavior as either signed | char or unsigned char.32)
et en même temps, char doit être un type distinct.
Ce que la norme veut dire ici, c'est juste la formulation de ce qui se passe concretement sur une architrecture 32-bits ou int et long font 32 bits (disons un solaris-2.[567] sur un SPARC 32-bit par exemple).
Les deux types vont avoir alors les mêmes représentations, mais ils resteront néanmoins distincts et incompatibles. Ce n'est pas contradictoire. C'est simplement que la sémantique C (et C++ dans une certaine mesure) est orientée « token » et non « bits »
Ils peuvent avoir les memes representations et la meme taille, mais la norme ne l'exige pas donc il est normal qu'ils soient incompatibles.
Pour les chars, la norme l'exige et va meme plus loin. Voila pourquoi concretement et meme en allant jusqu'au bits, si 6.2.5-15 est respectee, je ne vois pas comment char n'est pas compatible avec un des deux autres. D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un souhait soujacent mais non exprime que char et signed char soit comptatible, peut-etre par coherence avec int et signed int, etc...
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
Erwan David
Laurent Deniau écrivait :
Erwan David wrote:
Gabriel Dos Reis écrivait :
Erwan David writes:
[...]
| Dommage que cette sémantique n'ait pas été étendue au typedef...
j'ai peur de ne pas bien saisir la dernière phrase. Pourrais-tu en dire plus ?
si je fais typedef int mon_type; alors int et mon_type sont interchangeables. typedef défini un alias. J'aimerais souvent pouvoir définir un type en disant c'est représenté comme int mais ce n'est pas interchangeable avec un int.
typedef struct { int a; } mon_type1;
convient? de plus il n'est pas interchangeable avec mon_type2 meme si on a:
typedef struct { int a; } mon_type2;
mais l'accès va être nettement plus complexe.
Et là c'est parceque tu utilises des struct anonymes.
Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait :
Erwan David <erwan@rail.eu.org> writes:
[...]
| Dommage que cette sémantique n'ait pas été étendue au typedef...
j'ai peur de ne pas bien saisir la dernière phrase. Pourrais-tu en
dire plus ?
si je fais typedef int mon_type;
alors int et mon_type sont interchangeables. typedef défini un
alias. J'aimerais souvent pouvoir définir un type en disant c'est
représenté comme int mais ce n'est pas interchangeable avec un int.
typedef struct { int a; } mon_type1;
convient? de plus il n'est pas interchangeable avec mon_type2 meme si on a:
typedef struct { int a; } mon_type2;
mais l'accès va être nettement plus complexe.
Et là c'est parceque tu utilises des struct anonymes.
| Dommage que cette sémantique n'ait pas été étendue au typedef...
j'ai peur de ne pas bien saisir la dernière phrase. Pourrais-tu en dire plus ?
si je fais typedef int mon_type; alors int et mon_type sont interchangeables. typedef défini un alias. J'aimerais souvent pouvoir définir un type en disant c'est représenté comme int mais ce n'est pas interchangeable avec un int.
typedef struct { int a; } mon_type1;
convient? de plus il n'est pas interchangeable avec mon_type2 meme si on a:
typedef struct { int a; } mon_type2;
mais l'accès va être nettement plus complexe.
Et là c'est parceque tu utilises des struct anonymes.
-- Monde de merde
Vincent Lefevre
Dans l'article , Laurent Deniau écrit:
D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un souhait soujacent mais non exprime que char et signed char soit comptatible, peut-etre par coherence avec int et signed int, etc...
Où ça?
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <3F32213D.6050106@cern.ch>,
Laurent Deniau <Laurent.Deniau@cern.ch> écrit:
D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un
souhait soujacent mais non exprime que char et signed char soit
comptatible, peut-etre par coherence avec int et signed int, etc...
Où ça?
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un souhait soujacent mais non exprime que char et signed char soit comptatible, peut-etre par coherence avec int et signed int, etc...
Où ça?
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
| si je fais typedef int mon_type; | alors int et mon_type sont interchangeables. typedef défini un | alias. J'aimerais souvent pouvoir définir un type en disant c'est | représenté comme int mais ce n'est pas interchangeable avec un int.
C'est un désir qu eje vois souvent émis en C++ (où avec les surcharges et les templates, le « besoin » semble encore plus fort).
Le problème fondamental que je vois avec cette formulation, c'est de définir assez précisément ce que cela veut dire d'être comme mais sans être interchageable. I.e. qu'est-ce qui va différentier ?
| si je fais typedef int mon_type;
| alors int et mon_type sont interchangeables. typedef défini un
| alias. J'aimerais souvent pouvoir définir un type en disant c'est
| représenté comme int mais ce n'est pas interchangeable avec un int.
C'est un désir qu eje vois souvent émis en C++ (où avec les surcharges
et les templates, le « besoin » semble encore plus fort).
Le problème fondamental que je vois avec cette formulation, c'est de
définir assez précisément ce que cela veut dire d'être comme mais sans
être interchageable. I.e. qu'est-ce qui va différentier ?
| si je fais typedef int mon_type; | alors int et mon_type sont interchangeables. typedef défini un | alias. J'aimerais souvent pouvoir définir un type en disant c'est | représenté comme int mais ce n'est pas interchangeable avec un int.
C'est un désir qu eje vois souvent émis en C++ (où avec les surcharges et les templates, le « besoin » semble encore plus fort).
Le problème fondamental que je vois avec cette formulation, c'est de définir assez précisément ce que cela veut dire d'être comme mais sans être interchageable. I.e. qu'est-ce qui va différentier ?
-- Gaby
--=-=-=--
Gabriel Dos Reis
Laurent Deniau writes:
[...]
| > Les deux types vont avoir alors les mêmes représentations, mais ils | > resteront néanmoins distincts et incompatibles. Ce n'est pas | > contradictoire. C'est simplement que la sémantique C (et C++ dans une | > certaine mesure) est orientée « token » et non « bits » | | Ils peuvent avoir les memes representations et la meme taille, mais la norme ne | l'exige pas donc il est normal qu'ils soient incompatibles. | Pour les chars, la norme l'exige et va meme plus loin. Voila pourquoi | concretement et meme en allant jusqu'au bits, si 6.2.5-15 est | respectee, je ne vois pas comment char n'est pas compatible avec un | des deux autres.
Parce que la norme le dit. Ce que veut dire être compatible a une signification précise dans la norme. Par exmple, les types définis par
struct A { int i; }; struct B { int i; };
ne sont pas compatibles. Tu as l'air d'utiliser une autre définition de compatible.
| D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un | souhait soujacent mais non exprime que char et signed char soit | comptatible,
ah bon ? où ? Parce que ailleurs, le texte dit explicitement qu'ils ne sont pas compatibles. Comment le contraire peut être sousjacent ?
-- Gaby
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
[...]
| > Les deux types vont avoir alors les mêmes représentations, mais ils
| > resteront néanmoins distincts et incompatibles. Ce n'est pas
| > contradictoire. C'est simplement que la sémantique C (et C++ dans une
| > certaine mesure) est orientée « token » et non « bits »
|
| Ils peuvent avoir les memes representations et la meme taille, mais la norme ne
| l'exige pas donc il est normal qu'ils soient incompatibles.
| Pour les chars, la norme l'exige et va meme plus loin. Voila pourquoi
| concretement et meme en allant jusqu'au bits, si 6.2.5-15 est
| respectee, je ne vois pas comment char n'est pas compatible avec un
| des deux autres.
Parce que la norme le dit. Ce que veut dire être compatible a une
signification précise dans la norme. Par exmple, les types définis par
struct A { int i; };
struct B { int i; };
ne sont pas compatibles. Tu as l'air d'utiliser une autre définition
de compatible.
| D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un
| souhait soujacent mais non exprime que char et signed char soit
| comptatible,
ah bon ? où ? Parce que ailleurs, le texte dit explicitement qu'ils ne
sont pas compatibles. Comment le contraire peut être sousjacent ?
| > Les deux types vont avoir alors les mêmes représentations, mais ils | > resteront néanmoins distincts et incompatibles. Ce n'est pas | > contradictoire. C'est simplement que la sémantique C (et C++ dans une | > certaine mesure) est orientée « token » et non « bits » | | Ils peuvent avoir les memes representations et la meme taille, mais la norme ne | l'exige pas donc il est normal qu'ils soient incompatibles. | Pour les chars, la norme l'exige et va meme plus loin. Voila pourquoi | concretement et meme en allant jusqu'au bits, si 6.2.5-15 est | respectee, je ne vois pas comment char n'est pas compatible avec un | des deux autres.
Parce que la norme le dit. Ce que veut dire être compatible a une signification précise dans la norme. Par exmple, les types définis par
struct A { int i; }; struct B { int i; };
ne sont pas compatibles. Tu as l'air d'utiliser une autre définition de compatible.
| D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un | souhait soujacent mais non exprime que char et signed char soit | comptatible,
ah bon ? où ? Parce que ailleurs, le texte dit explicitement qu'ils ne sont pas compatibles. Comment le contraire peut être sousjacent ?
-- Gaby
Erwan David
Gabriel Dos Reis écrivait :
Erwan David writes:
| si je fais typedef int mon_type; | alors int et mon_type sont interchangeables. typedef défini un | alias. J'aimerais souvent pouvoir définir un type en disant c'est | représenté comme int mais ce n'est pas interchangeable avec un int.
C'est un désir qu eje vois souvent émis en C++ (où avec les surcharges et les templates, le « besoin » semble encore plus fort).
Le problème fondamental que je vois avec cette formulation, c'est de définir assez précisément ce que cela veut dire d'être comme mais sans être interchageable. I.e. qu'est-ce qui va différentier ?
EN fait il faudrait à la fois la sémantique actuelle de typedef (sinon on casserait 90 % du code actuel) et autre chose qui dise mon type truc est représenté par un int, mais ce n'est pas un int.
Donc on ne peux pas assigner un *truc à un *int et réciproquement. (par exemple).
-- Monde de merde
Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait :
Erwan David <erwan@rail.eu.org> writes:
| si je fais typedef int mon_type;
| alors int et mon_type sont interchangeables. typedef défini un
| alias. J'aimerais souvent pouvoir définir un type en disant c'est
| représenté comme int mais ce n'est pas interchangeable avec un int.
C'est un désir qu eje vois souvent émis en C++ (où avec les surcharges
et les templates, le « besoin » semble encore plus fort).
Le problème fondamental que je vois avec cette formulation, c'est de
définir assez précisément ce que cela veut dire d'être comme mais sans
être interchageable. I.e. qu'est-ce qui va différentier ?
EN fait il faudrait à la fois la sémantique actuelle de typedef (sinon
on casserait 90 % du code actuel) et autre chose qui dise mon type
truc est représenté par un int, mais ce n'est pas un int.
Donc on ne peux pas assigner un *truc à un *int et
réciproquement. (par exemple).
| si je fais typedef int mon_type; | alors int et mon_type sont interchangeables. typedef défini un | alias. J'aimerais souvent pouvoir définir un type en disant c'est | représenté comme int mais ce n'est pas interchangeable avec un int.
C'est un désir qu eje vois souvent émis en C++ (où avec les surcharges et les templates, le « besoin » semble encore plus fort).
Le problème fondamental que je vois avec cette formulation, c'est de définir assez précisément ce que cela veut dire d'être comme mais sans être interchageable. I.e. qu'est-ce qui va différentier ?
EN fait il faudrait à la fois la sémantique actuelle de typedef (sinon on casserait 90 % du code actuel) et autre chose qui dise mon type truc est représenté par un int, mais ce n'est pas un int.
Donc on ne peux pas assigner un *truc à un *int et réciproquement. (par exemple).
-- Monde de merde
Laurent Deniau
Gabriel Dos Reis wrote:
Laurent Deniau writes:
[...]
| > Les deux types vont avoir alors les mêmes représentations, mais ils | > resteront néanmoins distincts et incompatibles. Ce n'est pas | > contradictoire. C'est simplement que la sémantique C (et C++ dans une | > certaine mesure) est orientée « token » et non « bits » | | Ils peuvent avoir les memes representations et la meme taille, mais la norme ne | l'exige pas donc il est normal qu'ils soient incompatibles. | Pour les chars, la norme l'exige et va meme plus loin. Voila pourquoi | concretement et meme en allant jusqu'au bits, si 6.2.5-15 est | respectee, je ne vois pas comment char n'est pas compatible avec un | des deux autres.
Parce que la norme le dit. Ce que veut dire être compatible a une signification précise dans la norme. Par exmple, les types définis par
struct A { int i; }; struct B { int i; };
ne sont pas compatibles. Tu as l'air d'utiliser une autre définition de compatible.
Non. J'utilise la definition de la norme qui dit que deux types sont compatibles s'ils sont les memes. struct A et struct B sont clairement deux types differents. int et signed int sont clairement deux types identiques.
Ce que je trouve contradictoire, non sur la forme qui peut etre decretee comme telle mais sur le fond (c-a-d pour quelle raison), c'est que:
- char a meme taille, meme representation et meme comportement que soit signed char, soit unsigned char
- mais char est incompatible avec les deux. Meme sans preciser avec lequel, il aurait ete plus simple de le considerer compatible avec l'un des deux et d'utiliser SCHAR_MIN pour savoir avec lequel.
| D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un | souhait soujacent mais non exprime que char et signed char soit | comptatible,
ah bon ? où ? Parce que ailleurs, le texte dit explicitement qu'ils ne sont pas compatibles. Comment le contraire peut être sousjacent ?
Je me suis mal exprime, je voulais dire:
D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un souhait soujacent mais non exprime que char soit compatible avec soit signed char, soit unsigned char.
exemple, l'alinea 32)
a quoi cela sert-il de pouvoir savoir si char a meme taille, meme representation et meme comportement que signed char ou unsigned char si ensuite on decrete quand meme qu'ils sont incompatibles...
je pense que de toute facon la norme n'est pas parfaite et que beaucoup de choses peuvent etre discutees pendant des lustres suivant l'experience et le point de vue de chacun.
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
Gabriel Dos Reis wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
[...]
| > Les deux types vont avoir alors les mêmes représentations, mais ils
| > resteront néanmoins distincts et incompatibles. Ce n'est pas
| > contradictoire. C'est simplement que la sémantique C (et C++ dans une
| > certaine mesure) est orientée « token » et non « bits »
|
| Ils peuvent avoir les memes representations et la meme taille, mais la norme ne
| l'exige pas donc il est normal qu'ils soient incompatibles.
| Pour les chars, la norme l'exige et va meme plus loin. Voila pourquoi
| concretement et meme en allant jusqu'au bits, si 6.2.5-15 est
| respectee, je ne vois pas comment char n'est pas compatible avec un
| des deux autres.
Parce que la norme le dit. Ce que veut dire être compatible a une
signification précise dans la norme. Par exmple, les types définis par
struct A { int i; };
struct B { int i; };
ne sont pas compatibles. Tu as l'air d'utiliser une autre définition
de compatible.
Non. J'utilise la definition de la norme qui dit que deux types sont compatibles
s'ils sont les memes. struct A et struct B sont clairement deux types
differents. int et signed int sont clairement deux types identiques.
Ce que je trouve contradictoire, non sur la forme qui peut etre decretee comme
telle mais sur le fond (c-a-d pour quelle raison), c'est que:
- char a meme taille, meme representation et meme comportement que soit signed
char, soit unsigned char
- mais char est incompatible avec les deux. Meme sans preciser avec lequel, il
aurait ete plus simple de le considerer compatible avec l'un des deux et
d'utiliser SCHAR_MIN pour savoir avec lequel.
| D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un
| souhait soujacent mais non exprime que char et signed char soit
| comptatible,
ah bon ? où ? Parce que ailleurs, le texte dit explicitement qu'ils ne
sont pas compatibles. Comment le contraire peut être sousjacent ?
Je me suis mal exprime, je voulais dire:
D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un
souhait soujacent mais non exprime que char soit compatible avec soit signed
char, soit unsigned char.
exemple, l'alinea 32)
a quoi cela sert-il de pouvoir savoir si char a meme taille, meme representation
et meme comportement que signed char ou unsigned char si ensuite on decrete
quand meme qu'ils sont incompatibles...
je pense que de toute facon la norme n'est pas parfaite et que beaucoup de
choses peuvent etre discutees pendant des lustres suivant l'experience et le
point de vue de chacun.
a+, ld.
--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]
| > Les deux types vont avoir alors les mêmes représentations, mais ils | > resteront néanmoins distincts et incompatibles. Ce n'est pas | > contradictoire. C'est simplement que la sémantique C (et C++ dans une | > certaine mesure) est orientée « token » et non « bits » | | Ils peuvent avoir les memes representations et la meme taille, mais la norme ne | l'exige pas donc il est normal qu'ils soient incompatibles. | Pour les chars, la norme l'exige et va meme plus loin. Voila pourquoi | concretement et meme en allant jusqu'au bits, si 6.2.5-15 est | respectee, je ne vois pas comment char n'est pas compatible avec un | des deux autres.
Parce que la norme le dit. Ce que veut dire être compatible a une signification précise dans la norme. Par exmple, les types définis par
struct A { int i; }; struct B { int i; };
ne sont pas compatibles. Tu as l'air d'utiliser une autre définition de compatible.
Non. J'utilise la definition de la norme qui dit que deux types sont compatibles s'ils sont les memes. struct A et struct B sont clairement deux types differents. int et signed int sont clairement deux types identiques.
Ce que je trouve contradictoire, non sur la forme qui peut etre decretee comme telle mais sur le fond (c-a-d pour quelle raison), c'est que:
- char a meme taille, meme representation et meme comportement que soit signed char, soit unsigned char
- mais char est incompatible avec les deux. Meme sans preciser avec lequel, il aurait ete plus simple de le considerer compatible avec l'un des deux et d'utiliser SCHAR_MIN pour savoir avec lequel.
| D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un | souhait soujacent mais non exprime que char et signed char soit | comptatible,
ah bon ? où ? Parce que ailleurs, le texte dit explicitement qu'ils ne sont pas compatibles. Comment le contraire peut être sousjacent ?
Je me suis mal exprime, je voulais dire:
D'ailleurs a plusieurs endroit dans la norme on sent qu'il y ait un souhait soujacent mais non exprime que char soit compatible avec soit signed char, soit unsigned char.
exemple, l'alinea 32)
a quoi cela sert-il de pouvoir savoir si char a meme taille, meme representation et meme comportement que signed char ou unsigned char si ensuite on decrete quand meme qu'ils sont incompatibles...
je pense que de toute facon la norme n'est pas parfaite et que beaucoup de choses peuvent etre discutees pendant des lustres suivant l'experience et le point de vue de chacun.
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
| > Le problème fondamental que je vois avec cette formulation, c'est de | > définir assez précisément ce que cela veut dire d'être comme ma is sans | > être interchageable. I.e. qu'est-ce qui va différentier ? | | EN fait il faudrait à la fois la sémantique actuelle de typedef (sinon | on casserait 90 % du code actuel) et autre chose qui dise mon type | truc est représenté par un int, mais ce n'est pas un int. | | Donc on ne peux pas assigner un *truc à un *int et | réciproquement. (par exemple).
| > Le problème fondamental que je vois avec cette formulation, c'est de
| > définir assez précisément ce que cela veut dire d'être comme ma is sans
| > être interchageable. I.e. qu'est-ce qui va différentier ?
|
| EN fait il faudrait à la fois la sémantique actuelle de typedef (sinon
| on casserait 90 % du code actuel) et autre chose qui dise mon type
| truc est représenté par un int, mais ce n'est pas un int.
|
| Donc on ne peux pas assigner un *truc à un *int et
| réciproquement. (par exemple).
| > Le problème fondamental que je vois avec cette formulation, c'est de | > définir assez précisément ce que cela veut dire d'être comme ma is sans | > être interchageable. I.e. qu'est-ce qui va différentier ? | | EN fait il faudrait à la fois la sémantique actuelle de typedef (sinon | on casserait 90 % du code actuel) et autre chose qui dise mon type | truc est représenté par un int, mais ce n'est pas un int. | | Donc on ne peux pas assigner un *truc à un *int et | réciproquement. (par exemple).
