Type int par defaut... Ca me gonfle

Bonjour,

aujourd'hui, mauvais copier coller (probleme entre la chaise et le clavier... bref)
et je me retrouve avec une fonction qui devrait retourner void mais que c'est
pas marqué. Le compilo, lui, considere que du coup c'est int et rale parceque
je retourne rien et j'en passe...

BRef, je comprends pas comment il peut y avoir un trou aussi enorme
dans la norme : ne rien mettre = int... C'est d'ailleurs aussi vrai pour
une variable inconnue qui prendra defacto, le type int...

Ca faisait longtemps que ca m'etais pas arrivé ca, et perso, je croyais
dur comme fer que c'etait lie au C mais qu'en C++ on pouvait pas
ne pas mettre de type...

Bref, une question pour les pro de la norme et ma culture générale :
- mon compilo (VC) ne respecte pas la norme ?
- la norme autorise-t-elle une syntaxe a trou ?

En plus, c'est pas coherent avec les parametres d'une fonction.
Si on mets rien, il considere pas qu'on veut apsser un int !

Merci de vos lumieres. Doms.

Salut,

A l'origine, C++ s'appelait "C with classes", ce qui montre mieux que
ce langage a été créé avec dans l'idée qu'un compilateur C++ devait
pouvoir compiler du C. D'où la "syntaxe à trous".
VC ne respecte pas la norme (bien que ça s'améliore avec les versions),
mais ça n'a pas de rapport avec ta question.
Si tu es perdu, relis la parole du prophète :
http://www.research.att.com/~bs/
http://www.research.att.com/~bs/3rd.html

Mathieu

Dominique Vaufreydaz wrote:

aujourd'hui, mauvais copier coller (probleme entre la
chaise et le clavier... bref) et je me retrouve avec une
fonction qui devrait retourner void mais que c'est pas
marqué. Le compilo, lui, considere que du coup c'est int
et rale parceque je retourne rien et j'en passe...

Le compilateur n'est pas conforme. Ça fait maintenant une
éternité que l'« implicit int » n'existe plus.

BRef, je comprends pas comment il peut y avoir un trou
aussi enorme dans la norme : ne rien mettre = int...

Le trou n'est pas dans la norme, mais dans ton compilateur, qui
n'implémente pas la norme.

C'est d'ailleurs aussi vrai pour une variable inconnue qui
prendra defacto, le type int...

Ça a été vrai pour les tous premiers C. Il y a très longtemps.
Je crois que ça n'a jamais été vrai pour le C++, et C lui-même
l'a abandonné il y a déjà un moment.

Ca faisait longtemps que ca m'etais pas arrivé ca, et
perso, je croyais dur comme fer que c'etait lie au C mais
qu'en C++ on pouvait pas ne pas mettre de type...

Bref, une question pour les pro de la norme et ma culture
générale :
- mon compilo (VC) ne respecte pas la norme ?
- la norme autorise-t-elle une syntaxe a trou ?

Non et non.

Reste que tous mes compilateurs C l'accepte, sauf gcc, si je
précise -std=c89. (Curieusement, si je précise -std=c89, j'ai
une erreur sur la fonction, tandis qu'avec -std=c99, ce n'est
qu'un avertissement. Comme sur la variable, dans les deux case.)

Parmi les compilateurs C++, Sun CC l'accepte (et pour la
fonction, et pour la variable -- alors que C90 l'interdisait
déjà pour la variable), g++ le rejette.

N'avoir même pas un avertissement est, à mon avis, une erreur
dans le compilateur.

En plus, c'est pas coherent avec les parametres d'une
fonction. Si on mets rien, il considere pas qu'on veut
passer un int !

En C++. En C, si (ou au moins, c'était le cas quand j'ai appris
le C).

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Bonjour,

Le compilateur n'est pas conforme. Ça fait maintenant une
éternité que l'« implicit int » n'existe plus.

ahmen !

Le trou n'est pas dans la norme, mais dans ton compilateur, qui
n'implémente pas la norme.

euh, gcc sous linux fait pareil...

Reste que tous mes compilateurs C l'accepte, sauf gcc, si je
précise -stdÈ9. (Curieusement, si je précise -stdÈ9, j'ai
une erreur sur la fonction, tandis qu'avec -stdÉ9, ce n'est
qu'un avertissement. Comme sur la variable, dans les deux case.)

FAut que j'essaye ca, je compile en -pedantic et -Wall
et -Werror mais pas sur que ca rajoute pas si je mets
-std™...

Parmi les compilateurs C++, Sun CC l'accepte (et pour la
fonction, et pour la variable -- alors que C90 l'interdisait
déjà pour la variable), g++ le rejette.

N'avoir même pas un avertissement est, à mon avis, une erreur
dans le compilateur.

J'ai -Werror, donc pour moi c'est fatal !

Merci. Doms.

Bonjour,

A l'origine, C++ s'appelait "C with classes", ce qui montre mieux que
ce langage a été créé avec dans l'idée qu'un compilateur C++ devait
pouvoir compiler du C. D'où la "syntaxe à trous".
VC ne respecte pas la norme (bien que ça s'améliore avec les
versions), mais ça n'a pas de rapport avec ta question.
Si tu es perdu, relis la parole du prophète :
http://www.research.att.com/~bs/
http://www.research.att.com/~bs/3rd.html

Merci pour ces liens. Doms.

Le compilateur n'est pas conforme.

Qu'est-ce que vous racontez là ? (certes le posteur initiale ne précise
pas la version de son VC).
Le VC 2005 est tout à fait conforme.

mafonction()
{
return 1;
}

int main(int argc, char* argv[])
{
mafonction();
return 0;
}

Echoue avec:

Error 1 error C4430: missing type specifier - int assumed. Note: C++
does not support default-int

Ça a été vrai pour les tous premiers C. Il y a très longtemps.
Je crois que ça n'a jamais été vrai pour le C++, et C lui-même
l'a abandonné il y a déjà un moment.

James tu m'étonnes. Si j'étais taquin comme toi, je dirais volontiers
que "Je vois que tu n'as pas beaucoup d'expérience dans le domaine" LOL ;-)

La norme dit:

7.1 Specifiers [dcl.spec]
1 The specifiers that can be used in a declaration are
decl-specifier:
storage-class-specifier
type-specifier
function-specifier
friend
typedef

The “implicit int” rule of C is no longer supported.


"No longer supported" sous entend que c'était supporté à un moment
précédent.
En fait il me semble me souvenir que la la règle était supportée
jusqu'en 1996. En 1995 une proposition avait été faite pour retirer le
support.

On trouve encorfe de straces de ça sur le Net. Je viens de regarder en
même temps que j'écrivais ce post et j'ai tropuvé par exemple

http://corfield.org/index.cfm/event/cplusplus.section/section/cast9503


--
Alain

Bonjour,

Qu'est-ce que vous racontez là ? (certes le posteur initiale ne
précise pas la version de son VC).
Le VC 2005 est tout à fait conforme.

2003/2005, mais c'est vrai que le probleme m'etais apparu sous 2003.

On trouve encorfe de straces de ça sur le Net. Je viens de regarder en
même temps que j'écrivais ce post et j'ai tropuvé par exemple
http://corfield.org/index.cfm/event/cplusplus.section/section/cast9503

Merci. Doms.

Dominique Vaufreydaz wrote:

[...]

Le trou n'est pas dans la norme, mais dans ton compilateur,
qui n'implémente pas la norme.

euh, gcc sous linux fait pareil...

Est-ce que tu lui l'a démandé, ou non ? Comme tous les autres
compilateurs, g++ implémente par défaut un langage qui ressemble
un peu à C++, mais qui n'est pas C++. Quand j'invoque g++
-std=c++98 chez moi (sur Sparc, g++ 4.1.0), j'ai bien les
erreurs.

Reste que tous mes compilateurs C l'accepte, sauf gcc, si je
précise -std=c89. (Curieusement, si je précise -std=c89,
j'ai une erreur sur la fonction, tandis qu'avec -std=c99, ce
n'est qu'un avertissement. Comme sur la variable, dans les
deux case.)

FAut que j'essaye ca, je compile en -pedantic et -Wall
et -Werror mais pas sur que ca rajoute pas si je mets
-std=99...

Si tu ne lui dis pas à quelle norme il doit se conformer,
comment peut-il le savoir ? Il y en a tellement:-).

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Alain Gaillard wrote:

Le compilateur n'est pas conforme.

Qu'est-ce que vous racontez là ?

Qu'un compilateur qui accepte l'int implicit n'est pas conforme.

(certes le posteur initiale ne précise pas la version de son
VC). Le VC 2005 est tout à fait conforme.

Ça ne m'étonne pas outre-mesure, mais je suis actuellement sur
un Sparc sous Solaris, ce qui en rend la vérification assez
difficile.

[...]

Ça a été vrai pour les tous premiers C. Il y a très
longtemps. Je crois que ça n'a jamais été vrai pour le C++,
et C lui-même l'a abandonné il y a déjà un moment.

James tu m'étonnes. Si j'étais taquin comme toi, je dirais
volontiers que "Je vois que tu n'as pas beaucoup d'expérience
dans le domaine" LOL ;-)

La norme dit:

7.1 Specifiers [dcl.spec]
1 The specifiers that can be used in a declaration are
decl-specifier:
storage-class-specifier
type-specifier
function-specifier
friend
typedef

The ?implicit int? rule of C is no longer supported.

"No longer supported" sous entend que c'était supporté à un
moment précédent.

à un moment précédent, il a été supporté. La question est :
quel moment ? (Et quand est-ce que ce texte a été écrit ?)

En fait il me semble me souvenir que la la règle était
supportée jusqu'en 1996. En 1995 une proposition avait été
faite pour retirer le support.

Je n'ai pas accès à des documents pour vérifier. Il faut dire
que dans la mesure où je ne m'en servais pas, même en C, je n'y
prêté pas attention. C'est donc bien possible qu'il a perduré
plus longtemps que je ne le croyais. (En ce qui me concerne, il
n'a jamais existé, même en C. Mais mon avis sur la bonne façon
d'écrire le C ou le C++ n'est pas la norme.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Qu'est-ce que vous racontez là ?

Qu'un compilateur qui accepte l'int implicit n'est pas conforme.

LOL :-)
"Qu'est-ce que vous racontez là ? est une façon de parler qui veut dire
: "Ce que vous dites est un tantinet bizarre". :-)

(En ce qui me concerne, il
n'a jamais existé, même en C. Mais mon avis sur la bonne façon
d'écrire le C ou le C++ n'est pas la norme.)

Ca c'est encore une autre débat :-)

Je vois où tu veux en venir et je peux partager ton avis en partie.
Même actuellement je ne trouve pas pertinent par exemple que unsigned
soit synonyme de unsigned int. J'écris toujours unsigned int
personnellement.

--
Alain

Bonjour,

Est-ce que tu lui l'a démandé, ou non ? Comme tous les autres
compilateurs, g++ implémente par défaut un langage qui ressemble
un peu à C++, mais qui n'est pas C++. Quand j'invoque g++
-std=c++98 chez moi (sur Sparc, g++ 4.1.0), j'ai bien les
erreurs.

Dans la doc gcc, j'ai :
std c++98 : norme...

gnuc++98 = c++98 + GNU extensions.
C'est le defaut lors de la compilation.

Et comme ca coince dans ce mode la (le mode
par defaut), c'est donc qu'une des GNU extensions,
c'est d'autoriser le int comme type par defaut.

Si tu ne lui dis pas à quelle norme il doit se conformer,
comment peut-il le savoir ? Il y en a tellement:-).

Disons que j'aurais eu tendance a croire qu'il
pendrait ca par defaut.

Doms.