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.
| > GCC 3.2... | > | | Pour exemple, ce code passe pas a la compilation et génère un | " invalid operands to binary - "
comme cela se doit.
Il se trouve juste qu'il y a sur ce groupe quelques herétiques qui utilisent des armes de distraction massive pour qu'on ne s'aperçoive pas qu'ils ne comprennent pas le C.
[#3] For subtraction, one of the following shall hold:
-- both operands have arithmetic type;
-- both operands are pointers to qualified or unqualified versions of compatible object types; or
-- the left operand is a pointer to an object type and the right operand has integer type.
(Decrementing is equivalent to subtracting 1.)
[...]
35)CHAR_MIN, defined in <limits.h>, will have one of the values 0 or SCHAR_MIN, and this can be used to distinguish the two options. Irrespective of the choice made, char is a separate type from the other two and is not compatible with either.
Je ne vois pas écrit qu'il faille un diagnostic et arréter la compilation si un opérande est signé et l'autre non. Mais toi qui a une meilleure vue que moi, tu va me dire où c'est écrit.
Par contre, as-tu bien compris le sens du message émis par gcc? Ne serait-ce pas un bug par hasard? Tout est possible...
" invalid operands to binary - "
on dirait que c'est un bug de l'assembleur, non? Ou carrément le code binaire produit est faux. Bref, avant d'accuser les autres d'incompétance, voyons si la dernière version gcc n'est pas en faute. (Parce qu'on a déjà 2 contre- exemples, VC++6 et BC++3.1 qui ne signalent qu'un warning, comme je l'avais indiqué).
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| > GCC 3.2...
| >
|
| Pour exemple, ce code passe pas a la compilation et génère un
| " invalid operands to binary - "
comme cela se doit.
Il se trouve juste qu'il y a sur ce groupe quelques herétiques qui
utilisent des armes de distraction massive pour qu'on ne
s'aperçoive pas qu'ils ne comprennent pas le C.
[#3] For subtraction, one of the following shall hold:
-- both operands have arithmetic type;
-- both operands are pointers to qualified or unqualified
versions of compatible object types; or
-- the left operand is a pointer to an object type and the
right operand has integer type.
(Decrementing is equivalent to subtracting 1.)
[...]
35)CHAR_MIN, defined in <limits.h>, will have one of the
values 0 or SCHAR_MIN, and this can be used to
distinguish the two options. Irrespective of the choice
made, char is a separate type from the other two and is
not compatible with either.
Je ne vois pas écrit qu'il faille un diagnostic et arréter la compilation si
un opérande est signé et l'autre non. Mais toi qui a une meilleure vue que
moi, tu va me dire où c'est écrit.
Par contre, as-tu bien compris le sens du message émis par gcc? Ne serait-ce
pas un bug par hasard? Tout est possible...
" invalid operands to binary - "
on dirait que c'est un bug de l'assembleur, non? Ou carrément le code binaire
produit est faux. Bref, avant d'accuser les autres d'incompétance, voyons si
la dernière version gcc n'est pas en faute. (Parce qu'on a déjà 2 contre-
exemples, VC++6 et BC++3.1 qui ne signalent qu'un warning, comme je l'avais
indiqué).
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
| > GCC 3.2... | > | | Pour exemple, ce code passe pas a la compilation et génère un | " invalid operands to binary - "
comme cela se doit.
Il se trouve juste qu'il y a sur ce groupe quelques herétiques qui utilisent des armes de distraction massive pour qu'on ne s'aperçoive pas qu'ils ne comprennent pas le C.
[#3] For subtraction, one of the following shall hold:
-- both operands have arithmetic type;
-- both operands are pointers to qualified or unqualified versions of compatible object types; or
-- the left operand is a pointer to an object type and the right operand has integer type.
(Decrementing is equivalent to subtracting 1.)
[...]
35)CHAR_MIN, defined in <limits.h>, will have one of the values 0 or SCHAR_MIN, and this can be used to distinguish the two options. Irrespective of the choice made, char is a separate type from the other two and is not compatible with either.
Je ne vois pas écrit qu'il faille un diagnostic et arréter la compilation si un opérande est signé et l'autre non. Mais toi qui a une meilleure vue que moi, tu va me dire où c'est écrit.
Par contre, as-tu bien compris le sens du message émis par gcc? Ne serait-ce pas un bug par hasard? Tout est possible...
" invalid operands to binary - "
on dirait que c'est un bug de l'assembleur, non? Ou carrément le code binaire produit est faux. Bref, avant d'accuser les autres d'incompétance, voyons si la dernière version gcc n'est pas en faute. (Parce qu'on a déjà 2 contre- exemples, VC++6 et BC++3.1 qui ne signalent qu'un warning, comme je l'avais indiqué).
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Benoit.Breholee
DINH Viêt Hoà writes:
Comme d'autre compilateurs C/C++, GCC permet de compiler en mode stricte ANSI C.
Tu feras attention. Lorsque tu parles de compilateurs C/C++, il paraît dans un premier temps évident à tout le monde que tu penses que le C++ n'est qu'un ajout de mots-clefs par rapport au C et que tout code C passerait dans un compilateur qu'il soit C++ ou C.
Dans un cas aussi flagrant que « compilateurs C/C++ » (avec en plus l'exemple de GCC), c'est vraiment *vouloir* considérer que l'auteur fait cette faute. Ou alors c'est à force d'avoir vu cette erreur, mais j'ai l'impression qu'on la relève plus souvent à tort qu'à raison.
DINH Viêt Hoà <dinh.viet.hoa@free.fr> writes:
Comme d'autre compilateurs C/C++, GCC permet de compiler
en mode stricte ANSI C.
Tu feras attention. Lorsque tu parles de compilateurs C/C++, il paraît
dans un premier temps évident à tout le monde que tu penses que le C++
n'est qu'un ajout de mots-clefs par rapport au C et que tout code C
passerait dans un compilateur qu'il soit C++ ou C.
Dans un cas aussi flagrant que « compilateurs C/C++ » (avec en plus
l'exemple de GCC), c'est vraiment *vouloir* considérer que l'auteur
fait cette faute. Ou alors c'est à force d'avoir vu cette erreur, mais
j'ai l'impression qu'on la relève plus souvent à tort qu'à raison.
Comme d'autre compilateurs C/C++, GCC permet de compiler en mode stricte ANSI C.
Tu feras attention. Lorsque tu parles de compilateurs C/C++, il paraît dans un premier temps évident à tout le monde que tu penses que le C++ n'est qu'un ajout de mots-clefs par rapport au C et que tout code C passerait dans un compilateur qu'il soit C++ ou C.
Dans un cas aussi flagrant que « compilateurs C/C++ » (avec en plus l'exemple de GCC), c'est vraiment *vouloir* considérer que l'auteur fait cette faute. Ou alors c'est à force d'avoir vu cette erreur, mais j'ai l'impression qu'on la relève plus souvent à tort qu'à raison.
Richard Delorme
Richard Delorme écrivait :
D'après la norme signed char et unsigned char ne sont pas des types compatibles. Or la norme n'autorise la soustraction que de pointeur vers des types compatibles. Ton compilateur a donc raison si char est signé.
Et mêm si char est non signé d'ailleurs.
En effet, char, signed char et unsigned char sont trois types différents.
-- Richard
Richard Delorme <abulmo@nospam.fr> écrivait :
D'après la norme signed char et unsigned char ne sont pas des types
compatibles. Or la norme n'autorise la soustraction que de pointeur vers
des types compatibles. Ton compilateur a donc raison si char est signé.
Et mêm si char est non signé d'ailleurs.
En effet, char, signed char et unsigned char sont trois types différents.
D'après la norme signed char et unsigned char ne sont pas des types compatibles. Or la norme n'autorise la soustraction que de pointeur vers des types compatibles. Ton compilateur a donc raison si char est signé.
Et mêm si char est non signé d'ailleurs.
En effet, char, signed char et unsigned char sont trois types différents.
-- Richard
Vincent Lefevre
Dans l'article , Emmanuel Delahaye écrit:
Je ne vois pas écrit qu'il faille un diagnostic et arréter la compilation si un opérande est signé et l'autre non. Mais toi qui a une meilleure vue que moi, tu va me dire où c'est écrit.
En tout cas, c'est au moins du comportement indéfini. Dans ce cas, il peut très bien y avoir un diagnostic et un arrêt de la compilation.
Par contre, as-tu bien compris le sens du message émis par gcc? Ne serait-ce pas un bug par hasard? Tout est possible...
" invalid operands to binary - "
on dirait que c'est un bug de l'assembleur, non? Ou carrément le code binaire produit est faux.
Quel est le rapport avec de l'assembleur ou du binaire?
Il s'agit simplement d'opérandes invalides pour l'opération - à deux opérandes.
-- 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 <Xns93CEB5878EA7Dhsnoservernet@130.133.1.4>,
Emmanuel Delahaye <emdelYOURBRA@noos.fr> écrit:
Je ne vois pas écrit qu'il faille un diagnostic et arréter la
compilation si un opérande est signé et l'autre non. Mais toi qui a
une meilleure vue que moi, tu va me dire où c'est écrit.
En tout cas, c'est au moins du comportement indéfini. Dans ce cas,
il peut très bien y avoir un diagnostic et un arrêt de la compilation.
Par contre, as-tu bien compris le sens du message émis par gcc? Ne
serait-ce pas un bug par hasard? Tout est possible...
" invalid operands to binary - "
on dirait que c'est un bug de l'assembleur, non? Ou carrément le
code binaire produit est faux.
Quel est le rapport avec de l'assembleur ou du binaire?
Il s'agit simplement d'opérandes invalides pour l'opération - à
deux opérandes.
--
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
Je ne vois pas écrit qu'il faille un diagnostic et arréter la compilation si un opérande est signé et l'autre non. Mais toi qui a une meilleure vue que moi, tu va me dire où c'est écrit.
En tout cas, c'est au moins du comportement indéfini. Dans ce cas, il peut très bien y avoir un diagnostic et un arrêt de la compilation.
Par contre, as-tu bien compris le sens du message émis par gcc? Ne serait-ce pas un bug par hasard? Tout est possible...
" invalid operands to binary - "
on dirait que c'est un bug de l'assembleur, non? Ou carrément le code binaire produit est faux.
Quel est le rapport avec de l'assembleur ou du binaire?
Il s'agit simplement d'opérandes invalides pour l'opération - à deux opérandes.
-- 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
Emmanuel Delahaye
In 'fr.comp.lang.c', "Ivan Vecerina" wrote:
| > Comme d'autre compilateurs C/C++, GCC permet de compiler | > en mode stricte ANSI C.
J'avais hesite a preciser d'emblee que, en plus du C++ et du C, dans diverses versions de ce dernier, GCC compile egalement l'Objective-C, le Java, et plus encore...
GCC n'y est pour rien. Ce n'est un sélecteur qui va appeler le bon compilateur (cc1 pour C, gpp ou g++ pour C++ etc) en fonction de l'extension (ou d'options de la ligne de commande)
Les compilateurs C et C++ sont physiquement des exécutables séparés.
Pour les compilateurs egalement, la synergie entre certains languages est evidente. Surtout entre le C et le C++.
Il n'y a aucune synergie entre ces langages. Au contraire, la dernière version du C montre des divergences plus nettes. Le seul point commun est le préprocesseur.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', "Ivan Vecerina" <ivec@myrealbox.com> wrote:
| > Comme d'autre compilateurs C/C++, GCC permet de compiler
| > en mode stricte ANSI C.
J'avais hesite a preciser d'emblee que, en plus du C++ et du C,
dans diverses versions de ce dernier, GCC compile egalement
l'Objective-C, le Java, et plus encore...
GCC n'y est pour rien. Ce n'est un sélecteur qui va appeler le bon
compilateur (cc1 pour C, gpp ou g++ pour C++ etc) en fonction de l'extension
(ou d'options de la ligne de commande)
Les compilateurs C et C++ sont physiquement des exécutables séparés.
Pour les compilateurs egalement, la synergie entre certains languages
est evidente. Surtout entre le C et le C++.
Il n'y a aucune synergie entre ces langages. Au contraire, la dernière
version du C montre des divergences plus nettes. Le seul point commun est le
préprocesseur.
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
| > Comme d'autre compilateurs C/C++, GCC permet de compiler | > en mode stricte ANSI C.
J'avais hesite a preciser d'emblee que, en plus du C++ et du C, dans diverses versions de ce dernier, GCC compile egalement l'Objective-C, le Java, et plus encore...
GCC n'y est pour rien. Ce n'est un sélecteur qui va appeler le bon compilateur (cc1 pour C, gpp ou g++ pour C++ etc) en fonction de l'extension (ou d'options de la ligne de commande)
Les compilateurs C et C++ sont physiquement des exécutables séparés.
Pour les compilateurs egalement, la synergie entre certains languages est evidente. Surtout entre le C et le C++.
Il n'y a aucune synergie entre ces langages. Au contraire, la dernière version du C montre des divergences plus nettes. Le seul point commun est le préprocesseur.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Ivan Vecerina
"Emmanuel Delahaye" wrote in message news: | In 'fr.comp.lang.c', "Ivan Vecerina" wrote: | | > Au contraire, j'ai affirmé qu'il était superflu de s'imposer | > l'ajout de lignes de code du genre: | > | > #ifdef __cplusplus | > #error Please use a C-compiler | > #endif | > | > Car la personne qui a recommandé leur usage semble encore vivre | > à l'époque du K&R C, et confondre l'ISO C avec du C++ ... | | Et moi, je dis que tu racontes n'importe quoi.
Vraiment? Dans ce cas, je t'invite à m'indiquer le passage d'un standard ANSI C (version de ton choix) qui définit que les types char et unsigned char sont équivalents. La version du standard C99 que j'ai sous la main indique le contraire (Par 6.5.6/3 et 6.2.5).
Car j'espère que ta seule référence du C n'est pas l'implémentation du language fournie par Microsoft. Car c'est loin d'être la meilleure, (pire encore lorsque le mode ANSI strict n'est pas activé). Je te suggère à la place: http://www.comeaucomputing.com/tryitout/
Bon, je suis fatigué. Je rentre emmener mes gamins a la piscine, assez perdu de temps.
Ivan -- http://www.post1.com/~ivec
"Emmanuel Delahaye" <emdelYOURBRA@noos.fr> wrote in message
news:Xns93CEB424A4869hsnoservernet@130.133.1.4...
| In 'fr.comp.lang.c', "Ivan Vecerina" <ivec@myrealbox.com> wrote:
|
| > Au contraire, j'ai affirmé qu'il était superflu de s'imposer
| > l'ajout de lignes de code du genre:
| >
| > #ifdef __cplusplus
| > #error Please use a C-compiler
| > #endif
| >
| > Car la personne qui a recommandé leur usage semble encore vivre
| > à l'époque du K&R C, et confondre l'ISO C avec du C++ ...
|
| Et moi, je dis que tu racontes n'importe quoi.
Vraiment?
Dans ce cas, je t'invite à m'indiquer le passage d'un standard
ANSI C (version de ton choix) qui définit que les types char
et unsigned char sont équivalents. La version du standard C99
que j'ai sous la main indique le contraire (Par 6.5.6/3 et 6.2.5).
Car j'espère que ta seule référence du C n'est pas l'implémentation
du language fournie par Microsoft. Car c'est loin d'être la meilleure,
(pire encore lorsque le mode ANSI strict n'est pas activé).
Je te suggère à la place:
http://www.comeaucomputing.com/tryitout/
Bon, je suis fatigué.
Je rentre emmener mes gamins a la piscine, assez perdu de temps.
"Emmanuel Delahaye" wrote in message news: | In 'fr.comp.lang.c', "Ivan Vecerina" wrote: | | > Au contraire, j'ai affirmé qu'il était superflu de s'imposer | > l'ajout de lignes de code du genre: | > | > #ifdef __cplusplus | > #error Please use a C-compiler | > #endif | > | > Car la personne qui a recommandé leur usage semble encore vivre | > à l'époque du K&R C, et confondre l'ISO C avec du C++ ... | | Et moi, je dis que tu racontes n'importe quoi.
Vraiment? Dans ce cas, je t'invite à m'indiquer le passage d'un standard ANSI C (version de ton choix) qui définit que les types char et unsigned char sont équivalents. La version du standard C99 que j'ai sous la main indique le contraire (Par 6.5.6/3 et 6.2.5).
Car j'espère que ta seule référence du C n'est pas l'implémentation du language fournie par Microsoft. Car c'est loin d'être la meilleure, (pire encore lorsque le mode ANSI strict n'est pas activé). Je te suggère à la place: http://www.comeaucomputing.com/tryitout/
Bon, je suis fatigué. Je rentre emmener mes gamins a la piscine, assez perdu de temps.
Ivan -- http://www.post1.com/~ivec
Gabriel Dos Reis
Serge Paccalin writes:
| Le mardi 5 août 2003 à 15:31, Gabriel Dos Reis a écrit dans | fr.comp.lang.c : | | >| est-tu sûr que tu utilises un compilateur C et non C++? | | > qu'est-ce que ça change en ce qui concerne unsigned char* et char* ? | | Avec Visual Studio 6.0, ça change ça :
Je ne sais pas si tu as bien suivi la disussion mais il s'agissait de savoir si p - q est bien formé sachant que p est de type 'unsigned char*' et q de type 'char*'. Le fait que ton compilo l'accepte ou le rejete suivant le flag que tu mets n'est pas une preuve que c'est bien formé.
| Le mardi 5 août 2003 à 15:31, Gabriel Dos Reis a écrit dans
| fr.comp.lang.c :
|
| >| est-tu sûr que tu utilises un compilateur C et non C++?
|
| > qu'est-ce que ça change en ce qui concerne unsigned char* et char* ?
|
| Avec Visual Studio 6.0, ça change ça :
Je ne sais pas si tu as bien suivi la disussion mais il s'agissait de
savoir si p - q est bien formé sachant que p est de type 'unsigned
char*' et q de type 'char*'.
Le fait que ton compilo l'accepte ou le rejete suivant le flag que tu
mets n'est pas une preuve que c'est bien formé.
| Le mardi 5 août 2003 à 15:31, Gabriel Dos Reis a écrit dans | fr.comp.lang.c : | | >| est-tu sûr que tu utilises un compilateur C et non C++? | | > qu'est-ce que ça change en ce qui concerne unsigned char* et char* ? | | Avec Visual Studio 6.0, ça change ça :
Je ne sais pas si tu as bien suivi la disussion mais il s'agissait de savoir si p - q est bien formé sachant que p est de type 'unsigned char*' et q de type 'char*'. Le fait que ton compilo l'accepte ou le rejete suivant le flag que tu mets n'est pas une preuve que c'est bien formé.
-- Gaby
Ivan Vecerina
"Emmanuel Delahaye" wrote in message news: | > Pour les compilateurs egalement, la synergie entre certains languages | > est evidente. Surtout entre le C et le C++. | | Il n'y a aucune synergie entre ces langages. Au contraire, la dernière | version du C montre des divergences plus nettes. Le seul point commun est le | préprocesseur.
Aucune synergie ??
Pourrais-tu m'indiquer une seule implémentation de la librairie standard du C++ qui ne contienne pas également une implémentation de la librairie standard C ? Qui ne réutilise pas celle-ci ?
Même le C99 a fait des efforts pour intégrer des fonctionalités du C++ d'une manière compatible. Voir par exemple <stdbool.h>.
Quelle incluture :(
"Emmanuel Delahaye" <emdelYOURBRA@noos.fr> wrote in message
news:Xns93CEB6DEE5D06hsnoservernet@130.133.1.4...
| > Pour les compilateurs egalement, la synergie entre certains languages
| > est evidente. Surtout entre le C et le C++.
|
| Il n'y a aucune synergie entre ces langages. Au contraire, la dernière
| version du C montre des divergences plus nettes. Le seul point commun est
le
| préprocesseur.
Aucune synergie ??
Pourrais-tu m'indiquer une seule implémentation de la librairie standard
du C++ qui ne contienne pas également une implémentation de la librairie
standard C ? Qui ne réutilise pas celle-ci ?
Même le C99 a fait des efforts pour intégrer des fonctionalités du C++
d'une manière compatible. Voir par exemple <stdbool.h>.
"Emmanuel Delahaye" wrote in message news: | > Pour les compilateurs egalement, la synergie entre certains languages | > est evidente. Surtout entre le C et le C++. | | Il n'y a aucune synergie entre ces langages. Au contraire, la dernière | version du C montre des divergences plus nettes. Le seul point commun est le | préprocesseur.
Aucune synergie ??
Pourrais-tu m'indiquer une seule implémentation de la librairie standard du C++ qui ne contienne pas également une implémentation de la librairie standard C ? Qui ne réutilise pas celle-ci ?
Même le C99 a fait des efforts pour intégrer des fonctionalités du C++ d'une manière compatible. Voir par exemple <stdbool.h>.
Quelle incluture :(
Gabriel Dos Reis
Emmanuel Delahaye writes:
| In 'fr.comp.lang.c', Serge Paccalin wrote: | | >>| est-tu sûr que tu utilises un compilateur C et non C++? | > | >> qu'est-ce que ça change en ce qui concerne unsigned char* et char* ? | > | > SPN>cl -nologo -W4 charuchar.c | > charuchar.c | > charuchar.c(8) : warning C4057: '-' : 'char *' differs in indirection to | > slightly different base types from 'unsigned char *' | > | > SPN>cl -nologo -W4 charuchar.cpp | > charuchar.cpp | > charuchar.cpp(7) : error C2230: '-' : indirection to different types | | Tout à fait. Mais certains visiblement ne savent pas encore faire la | différence entre C et C++.
En plus de lire et comprendre la définition de C, tu devrais aussi apprendre à distinguer le comportement d'un compilateur de ce qui est bien formé ou non. Quand tu aurais fini, reviens nous voir. -- Gaby
Emmanuel Delahaye <emdelYOURBRA@noos.fr> writes:
| In 'fr.comp.lang.c', Serge Paccalin <sp@mailclub.no.spam.net.invalid> wrote:
|
| >>| est-tu sûr que tu utilises un compilateur C et non C++?
| >
| >> qu'est-ce que ça change en ce qui concerne unsigned char* et char* ?
| >
| > SPN>cl -nologo -W4 charuchar.c
| > charuchar.c
| > charuchar.c(8) : warning C4057: '-' : 'char *' differs in indirection to
| > slightly different base types from 'unsigned char *'
| >
| > SPN>cl -nologo -W4 charuchar.cpp
| > charuchar.cpp
| > charuchar.cpp(7) : error C2230: '-' : indirection to different types
|
| Tout à fait. Mais certains visiblement ne savent pas encore faire la
| différence entre C et C++.
En plus de lire et comprendre la définition de C, tu devrais aussi
apprendre à distinguer le comportement d'un compilateur de ce qui est
bien formé ou non. Quand tu aurais fini, reviens nous voir.
-- Gaby
| In 'fr.comp.lang.c', Serge Paccalin wrote: | | >>| est-tu sûr que tu utilises un compilateur C et non C++? | > | >> qu'est-ce que ça change en ce qui concerne unsigned char* et char* ? | > | > SPN>cl -nologo -W4 charuchar.c | > charuchar.c | > charuchar.c(8) : warning C4057: '-' : 'char *' differs in indirection to | > slightly different base types from 'unsigned char *' | > | > SPN>cl -nologo -W4 charuchar.cpp | > charuchar.cpp | > charuchar.cpp(7) : error C2230: '-' : indirection to different types | | Tout à fait. Mais certains visiblement ne savent pas encore faire la | différence entre C et C++.
En plus de lire et comprendre la définition de C, tu devrais aussi apprendre à distinguer le comportement d'un compilateur de ce qui est bien formé ou non. Quand tu aurais fini, reviens nous voir. -- Gaby
Erwan David
"Ivan Vecerina" écrivait :
Aucune synergie ??
Pourrais-tu m'indiquer une seule implémentation de la librairie standard du C++ qui ne contienne pas également une implémentation de la librairie standard C ? Qui ne réutilise pas celle-ci ?
Je ne vois pas ce que ça a à voir avec l'exigence que les programmeurs C se limitent à l'intersection de C et C++.
-- Monde de merde
"Ivan Vecerina" <ivec@myrealbox.com> écrivait :
Aucune synergie ??
Pourrais-tu m'indiquer une seule implémentation de la librairie standard
du C++ qui ne contienne pas également une implémentation de la librairie
standard C ? Qui ne réutilise pas celle-ci ?
Je ne vois pas ce que ça a à voir avec l'exigence que les programmeurs
C se limitent à l'intersection de C et C++.
Pourrais-tu m'indiquer une seule implémentation de la librairie standard du C++ qui ne contienne pas également une implémentation de la librairie standard C ? Qui ne réutilise pas celle-ci ?
Je ne vois pas ce que ça a à voir avec l'exigence que les programmeurs C se limitent à l'intersection de C et C++.
