respects de la norme C++

Version imprimable

05/12/2011, 16h32
Kaamui

respects de la norme C++
Bonjour,

je voudrais savoir si les instructions suivantes respectent le standard C++ ou s'il elles sont juste tolérées (d'ailleurs, doit-on considérer que ce qui est toléré par un compilateur et un EDI qui respecte le standard C++ respecte le standard C++ ou que ce dernier ne fait que le tolérer, même s'il ne respecte pas le standard ?)

exemples :
-

Code:

const char* = 0;

-
Code:

1 2 3 4 typedef struct toto { [...] }titi;
(alors qu'en C++ la définition de type d'un type structuré est inutile)

-un réflexe de C-ien (utilisation de malloc au lieu de new par exemple)

-des conversions implicites qui passent à la compilation, genre :
Code:

1 2 unsigned short i=0; short j=i;
-des déclarations sans définition :

Code:

int i;

je suis en train de lire le standard ici mais j'ai un peu de mal à digérer. Sinon, est-ce une source fiable?

Merci d'avance pour vos éclaircissements.

Cordialement,
05/12/2011, 20h39
3DArchi
Salut,

Citation:

Envoyé par Kaamui

je voudrais savoir si les instructions suivantes respectent le standard C++ ou s'il elles sont juste tolérées (d'ailleurs, doit-on considérer que ce qui est toléré par un compilateur et un EDI qui respecte le standard C++ respecte le standard C++ ou que ce dernier ne fait que le tolérer, même s'il ne respecte pas le standard ?)

Le standard est le standard. Qu'un ou plusieurs compilateurs très présents sur le marché proposent des extensions ou soient tolérantes à des constructions ne doit pas être un prétexte à violer le standard.

Citation:

Envoyé par Kaamui

-

Code:

const char* = 0;

Je n'ai pas vérifié, je ne peux te répondre pour cet exemple.
Citation:
Envoyé par Kaamui

-

Code:

1 2 3 4 typedef struct toto { [...] }titi;

(alors qu'en C++ la définition de type d'un type structuré est inutile)
Disons que le typedef en C++ n'est plus nécessaire pour pouvoir utiliser le nom de la structure (ou de l'énumération ou de l'union). Mais la construction reste valide pour créer un synonyme au type. On trouve encore beaucoup de typedef dans du code très C++.
Exemple :
Code:

1 2 3 4 5 template<class T> struct some_container { typedef T type; typedef T& reference; };
Citation:

Envoyé par Kaamui

-un réflexe de C-ien (utilisation de malloc au lieu de new par exemple)

Ici, pareil que précédemment. Rien ne t'interdit d'utiliser malloc dans ton code. C'est une construction valide du point de vue du standard. En revanche, il faut bien comprendre que cela ne risque pas du tout de faire ce que tu crois. new (peut) alloue de la mémoire MAIS SURTOUT DOIT appeller un constructeur. malloc ne fait que de l'allocation. malloc sur une classe donnera donc un comportement indéfini (je n'ai pas vérifié pour l'UD, mais je pense. En tout état de cause, quelque chose d'invalide).
Citation:
Envoyé par Kaamui

-des conversions implicites qui passent à la compilation, genre :

Code:

1 2 unsigned short i=0; short j=i;

-des déclarations sans définition :

Code:

int i;
Attention. Certaines conversions sont tout à fait valides. L'exemple que tu donnes est dans ce cas : la conversion d'un unsigned vers un signed est valide dès lors que le type signé peut contenir la valeur effective de ta variable non signée. Ce serait plus problématique si tu avais (pour un short sur 2 octets):
Code:

1 2 unsigned short i = 32768; short j = i;
Citation:

Envoyé par Kaamui

je suis en train de lire le standard ici mais j'ai un peu de mal à digérer. Sinon, est-ce une source fiable?

Il m'a l'air de dater un peu.
06/12/2011, 08h44
Kaamui

Merci énormément pour tes réponses, ça me permet d'y voir plus clair ;)

Encore merci d'avoir pris le temps de me répondre, c'est ce qu'on appelle l'altruisme il me semble :D

Aurais-tu un conseil de lecture (gratuite) d'un standard plus fiable ou plus récent ? Si non, merci déjà pour les réponses que tu m'as déjà apporté.

Cordialement,
06/12/2011, 09h02
ManusDei

Pour compiler le C avec gcc tu as les options -ansi, -pedantic, -std qui permettent (dans une certaines limite) de choisir ton standard.

Regarde si il n'existe pas d'équivalent pour ton compilateur C++.
06/12/2011, 09h15
Kaamui

Bonjour,

oui je connais ces options, mais je n'ai pas de problème de compilation ou de choix de standard, c'était purement informatif, je cherche à "apprendre" le véritable standard C++, donc je me demandais si toutes les instructions tolérables étaient respectueuse du standard ou non.

Mais merci quand même pour les infos je ne connaissais pas l'option ansi.

Saurais-tu où je peux trouver un exemplaire du standard (gratuit et en ligne) ?

Cordialement,
06/12/2011, 12h31
3DArchi

Citation:

Envoyé par Kaamui

Saurais-tu où je peux trouver un exemplaire du standard (gratuit et en ligne) ?

Le standard est payant. Donc en tapant sur google 'C++ standard pdf' tu n'obtiendras que des ressources piratées violant le droit de propriété et susceptibles de t'attirer des ennuis.
Maintenant, sur le site http://www.open-std.org/jtc1/sc22/wg21/ tu peux trouver le dernier draft publique de C++11. Il date de février 2011, donc il y a des choses qui ont changées depuis. Mais il devrait plus ressembler à la mouture finale que celui de 2005.
06/12/2011, 14h05
Kaamui

En fait je m'intéresse au standard C++03 (j'aurais du préciser) car je bosse sur des applications qui auraient déjà bien besoin d'être aux normes avec celui-ci. :mouarf:

Vu la taille du projet en question, il n'est pas envisageable de le porter aux normes plus récentes comme C++TR1 ou C++11 (trop d'impact sur le code)

A propos du C++11 : n'est-il pas trop tôt vu que sa publication date du 12 aout pour essayer de respecter ce standard ? je me trompe peut-être mais est-ce que les compilateurs comme gcc (ou g++) et les EDI comme Visual C++ 2010 sont déjà prêt pour ce standard (intuitivement je pensais que non) ?

Edit : dernière question qui n'a rien à voir (et après je mets en résolu) : est-ce que les casting comme static_cast<exp>, dynamic_cast<exp>, etc sont censés remplacé le mot-clé cast où est-ce que cela n'a rien à voir avec ceci ?
07/12/2011, 01h10
JolyLoic
Citation:

Envoyé par Kaamui

-

Code:

const char* = 0;

Ce n'est pas du code valide (il manque un nom de variable). Avec un nom de variable, il le serait.
Citation:
Envoyé par Kaamui

-

Code:

1 2 3 4 typedef struct toto { [...] }titi;

(alors qu'en C++ la définition de type d'un type structuré est inutile)
Ca reste du code valide.

Citation:

Envoyé par Kaamui

-un réflexe de C-ien (utilisation de malloc au lieu de new par exemple)

Ca a toutes les chances de conduire à du code invalide, en C++03, on a le droit d'utiliser malloc uniquement avec les types qui sont des POD. Cette notion a été pas mal affinée en C++0x pour permettre d'autres types, mais je ne sais plus les détails.
Citation:
Envoyé par Kaamui

-des conversions implicites qui passent à la compilation, genre :

Code:

1 2 unsigned short i=0; short j=i;
Ce code est valide.

Citation:

Envoyé par Kaamui

-des déclarations sans définition :

Code:

int i;

Ce code est valide. De plus, il s'agit bien d'une définition de la variable i. une déclaration sans définition de i serait : extern int i;

Citation:

Envoyé par Kaamui

je suis en train de lire le standard ici mais j'ai un peu de mal à digérer. Sinon, est-ce une source fiable?

C'est une source un peu datée, mais fiable

Citation:

Envoyé par Kaamui

En fait je m'intéresse au standard C++03 (j'aurais du préciser) car je bosse sur des applications qui auraient déjà bien besoin d'être aux normes avec celui-ci. :mouarf:

C++98 et C++03, c'est quasiment identique, seuls quelques bugs ont été corrigés

Citation:

Envoyé par Kaamui

Vu la taille du projet en question, il n'est pas envisageable de le porter aux normes plus récentes comme C++TR1 ou C++11 (trop d'impact sur le code)

C++11 est globalement compatible avec C++98, les exceptions étant clairement indiquées. Par contre, je trouve la démarche assez étrange : Habituellement, on l'a pas pour objectif de porter du code vers tel ou tel standard, mais plutôt vers tel ou tel groupe de compilateurs, qui respectent tous plus ou moins un ou plusieurs standards.

Citation:

Envoyé par Kaamui

A propos du C++11 : n'est-il pas trop tôt vu que sa publication date du 12 aout pour essayer de respecter ce standard ? je me trompe peut-être mais est-ce que les compilateurs comme gcc (ou g++) et les EDI comme Visual C++ 2010 sont déjà prêt pour ce standard (intuitivement je pensais que non) ?

Ils incluent tous deux des nouvelles fonctions liées à ce standard. Aucun des deux ne le respecte dans sa totalité actuellement, mais ça n'empêche pas de bénéficier déjà de ces nouveautés (surtout celles implémentées des deux côtés, comme les bases de la move semantic, les lambdas, auto...).

Citation:

Envoyé par Kaamui

Edit : dernière question qui n'a rien à voir (et après je mets en résolu) : est-ce que les casting comme static_cast<exp>, dynamic_cast<exp>, etc sont censés remplacé le mot-clé cast où est-ce que cela n'a rien à voir avec ceci ?

Il n'y a pas de mot clef cast. Il sont sensé remplacer les casts C-style, qui s'exprimaient sans mot clef, comme int i = (int)3.14; et offrant les avantages d'être plus visible, et de préciser l'objectif du cast. De plus, dynamic_cast fourni des fonctions hors de portée d'un cast C-style.
07/12/2011, 09h33
Kaamui

Citation:

Envoyé par JolyLoic

Ca a toutes les chances de conduire à du code invalide, en C++03, on a le droit d'utiliser malloc uniquement avec les types qui sont des POD. Cette notion a été pas mal affinée en C++0x pour permettre d'autres types, mais je ne sais plus les détails.

C'est quoi un type POD ? (et POD est l'acronyme de ... ?)

Citation:

Envoyé par JolyLoic

Ce code est valide. De plus, il s'agit bien d'une définition de la variable i. une déclaration sans définition de i serait : extern int i;

D'accord, c'est noté.

Citation:

Envoyé par JolyLoic

Par contre, je trouve la démarche assez étrange : Habituellement, on l'a pas pour objectif de porter du code vers tel ou tel standard, mais plutôt vers tel ou tel groupe de compilateurs, qui respectent tous plus ou moins un ou plusieurs standards.

le problème est que le code en question a été écrit sous VC++ 2003 et aucun standard n'a été respecté :aie:

En tout cas merci pour toutes tes réponses.
07/12/2011, 10h52
JolyLoic

POD = Plain'Old Data = un type identique à un type du C : Pas de constructeur, de fonction virtuelle, de classe de base, toutes les données membre étant elles aussi des POD...
07/12/2011, 11h20
Kaamui

Merci de votre aide.

Cordialement,
07/12/2011, 17h03
Emmanuel Deloget

Citation:

Envoyé par Kaamui

le problème est que le code en question a été écrit sous VC++ 2003 et aucun standard n'a été respecté :aie:

VC++2003 est l'un des premiers compilateurs MS qui respecte presque totalement le standard C++98. Les seules points problématiques concernent des comportements à la marge sur l'instanciation des templates et autres joyeusetés du même genre.
07/12/2011, 17h32
Kaamui

Tout d'abord bonjour,

D'accord il respectait un standard mais celui de 98, la belle affaire.

Donc si je comprend bien le standard de 98 autorisait les utilisations des classes des librairies standard hors du scope de leur namespace ? et une variable créée dans une boucle while continuait d'exister en dehors du scope de cette boucle ? ben heureusement qu'on arrête pas le progrès...

De toute façon je n'ai jamais dit qu'il n'était pas bien à son époque, mais maintenant Visual 2003 est obsolète pour coder du C++, il respecte même pas le standard 2003 alors j'imagine pas pour TR1 ou 0x.
07/12/2011, 19h40
Emmanuel Deloget

Citation:

Envoyé par Kaamui

Tout d'abord bonjour,

D'accord il respectait un standard mais celui de 98, la belle affaire.

:)

Aurais tu souhaité qu'il respecte celui de 2003 (non sorti au moment ou le compilateur a été releasé) ? Quel autre, sinon ?

Citation:

Envoyé par Kaamui

Donc si je comprend bien le standard de 98 autorisait les utilisations des classes des librairies standard hors du scope de leur namespace ? et une variable créée dans une boucle while continuait d'exister en dehors du scope de cette boucle ? ben heureusement qu'on arrête pas le progrès...

Tu confonds avec VC6 (sorti en 1998, donc pré-norme). VC++2003 ne permet pas de faire aucune des choses que tu cites - à moins peut-être d'utiliser un flag de compilation spécifique (mais j'en doute ; pour avoir fait la migration d'un million de lignes de VC6 à VC++2003, je pense que j'aurais noté si un flag de compilation m'avait permis de réduire mon travail).

Il me semble que tu n'es pas très au point sur cette question. Jusqu'à quelques semaines, il n'existait qu'un seul standard - celui de 98 amendé par un corrigendum en 2003. La version 2003 n'est pas différente de la version de 98 - quelques bugs ici et là, mais en fait la plupart des implémentations avait déjà corrigé ces bugs (par exemple, push_back() prenait un T en paramètre et pas un const T& ; au niveau du code client, aucun changement n'est perceptible entre C++98 et C++03 ; au niveau de la librairie standard, il y a quelques petits changements, mais rien de bien important). Du coup, même g++ ne se targue pas de supporter C++03, parce ce standard est strictement équivalent à C++98. Encore aujourd'hui, VC++2008 (sans service pack) ne fait pas mieux que VC++2003, sauf à la marge extrème (c'est à dire dans les features qui ne sont utilisées que par des concepteurs de librairie).

VC++2010 rajoute une toute petite partie du support C++11 - manque quand même le support correct des listes d'initialisation et des variadic templates pour être vraiment considéré comme un compilateur C++11.

Citation:

Envoyé par Kaamui

De toute façon je n'ai jamais dit qu'il n'était pas bien à son époque, mais maintenant Visual 2003 est obsolète pour coder du C++, il respecte même pas le standard 2003 alors j'imagine pas pour TR1 ou 0x.

Le TR1 a été ajouté avec un service pack à VC++2008. Ce n'est toutefois qu'une librairie (les types traits pouvant nécessiter des intrinsics du compilateur). Ceci dit, je ne connais aucun programme qui utilises le TR1 - principalement parce que le support du TR1 sur VC++2008 est différent de celui de g++ ; du coup, personne ne l'a utilisé vraiment, sauf cas particulier. Si besoin, VC++2003 compile très bien les librairies boost (celles qui sont sorties après sa release), qui contiennent une partie pseudo-TR1 (c'est nettement plus portable que le TR1 lui-même).

Quand au support C++11, je vois mal comment un compilateur sorti en 2003 pourrait le supporter.

VC++2003 n'est pas, loin s'en faut, obsolète ; il est tout à fait équivalent à VC++2005 (encore très utilisé) ou VC++2008 (sans service pack). Il compile du code C++ moderne sans coup férir. En fait, si tu as un doute et que tu penses avoir du code standard (avanc C++11, bien évidemment ; aucun compilateur ne supporte C++11 correctement de toute manière) qui ne compile pas, n'hésite pas à nous le faire partager.
09/12/2011, 16h39
Kaamui
Citation:

Envoyé par Emmanuel Deloget

Aurais tu souhaité qu'il respecte celui de 2003 (non sorti au moment ou le compilateur a été releasé) ? Quel autre, sinon ?

Non, je n'ai jamais dit cela, je prenais pour acquis votre remarque disant que le standard de 98 était respecté. J'ai dit personnellement que j'aurais voulu qu'il respecte UN standard C++. Entre parenthèse j'ai du mal à croire que le standard de 98 et celui de 2003 soient si peu différentiable, mais pour en revenir à votre remarque, je ne fais que constater que, peu importe quel standard il "respectait" (98 ou 2003, ou 2030), il le respectait très mal, pour ne pas dire pas.

Citation:

Envoyé par Emmanuel Deloget

Quand au support C++11, je vois mal comment un compilateur sorti en 2003 pourrait le supporter.

Je ne disais pas ça.

Citation:

VC++2003 n'est pas, loin s'en faut, obsolète ; il est tout à fait équivalent à VC++2005 (encore très utilisé) ou VC++2008 (sans service pack). Il compile du code C++ moderne sans coup férir. En fait, si tu as un doute et que tu penses avoir du code standard (avanc C++11, bien évidemment ; aucun compilateur ne supporte C++11 correctement de toute manière) qui ne compile pas, n'hésite pas à nous le faire partager.

Alors je résume, et vous me direz ce que vous en pensez ensuite car là il y a un peu de malcompréhension entre nous :

Premièrement, je ne peux pas vous montrer de bout de code à cause de la clause de confidentialité à laquelle me lie mon contrat.

Deuxièmement, pour expliquer mon raisonnement, et surtout pour que vous, le compreniez : il s'agit d'une étude que j'ai réalisé dans le cadre d'un portage d'une solution de Microsoft Visual .NET 2003 vers Microsoft Visual .NET 2010, solution d'un peu moins d'un million de lignes (et alors ?). J'ai alors constaté, que pour un code à la fois très vieux et très très très bien écris, certaines erreurs surprenantes (voire paradoxale, surement lié à de nombreuses TMA) ne posaient aucun problème à la compilation et au bon fonctionnement du programme. Pour exemple, des variables définies dans des boucles for comme suit ...
Code:

1 2 for (int i = 0; ...)
...avaient une portée supérieure au scope de la boucle, contrairement à ce que stipule apparemment le standard (6.5 Iteration statements (§1 à §3)).
Des utilisations des fonctionnalités des librairies standards en dehors du scope de leur namespace (3.4.3.2 Namespace members (§1)), des inclusions manquantes, non-problématiques à la compilation, des comparaisons et initialistations étranges (pour moi) comme suit :
Code:

1 2 3 somthing::iterator it = 0; if (it!=0)
Toutes ces erreurs ont été détecté à la compilation sous Microsoft Visual .NET 2010, mais pas sous Microsoft Visual .NET 2003. Suite à cela, j'ai eu le retour d'une personne très significativement plus expérimentée que moi qui m'a affirmé (et je lui fais entièrement confiance) :

Citation:

2003 souffrait de non-conformités au standard assez flagrantes. Aucune classe ou fonction standard n'est censée se trouver en dehors du namespace std.

Il ne faut jamais prendre pour argent comptant tout ce qu'on compilo peut compiler sans erreur.

Il s'agit d'une réponse de Laurent Gomila, que vous connaissez surement.

Maintenant, je suis prêt à entendre vos remarques si elles me permettent d'élargir mes compétences, mais même si je ne suis pas un expert, contrairement à vous ou à Mr Gomila, je penses que mon raisonnement se tient, concernant la non-conformité au standard C++ de Microsoft Visual .NET 2003.

Cordialement,
09/12/2011, 18h40
JolyLoic

Disons qu'il y a deux catégories de non conformités :
- Un compilateur qui ne compile pas (ou mal) du code qui est standard.
- Un compilateur qui compile (parfois très bien) du code qui n'est pas standard (ce qu'on nomme parfois une extension).

Visual C++2003 n'est pas si mal placé dans la première catégorie, mais est très laxiste et permet plein de choses hors standard (Visual C++2010 aussi d'ailleurs, mais pas les mêmes).

Pour le scope des variables déclarées dans le for, il un flag permet en 2010 de retrouver le comportement non standard précédent, ce qui peut (ou pas) faciliter la transition. /Zc:forScope (Force Conformance in for Loop Scope)