Discussion :

[r0d]

Est ce que j'ai pretendu le contraire ?

C'est justement ce que je disais

En effet, j'avais mal compris.

[yan]

On ne peut pas dire que le C soit du C++

oula je peut pas faire ce sacrilège, ce sens n'est pas "possible"

on ne peut pas dire que le C++ soit du C...

ben en partie... C'est la raison que l'on peut codé du C dans du code C++

Sinon t'as bien résumé le problème.

Ce que je n'arrive pas a comprendre totalement est la raison de vouloir absolument tout enlever du C dans le C++. En premier, vu les réponses, on fait du C avec du C++ (même minime). Le C fournie de super méthode qui ne sont pas en C++, comme le sscanf exemple

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
std::string s("path : c:/bal blabla/azeazaze/");
char path[1024];
ssacnf(s.c_str()," %*s %*s %[\t]",path);

va recopier correctement avec les espaces le path. Je suis bien sur d'accord sur le fait que se n'ai pas securisé. je n'ai pas trop d'équivalence en C++

autre exemple sprintf

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
char ligne[1024];
int a=1;
float b[5] = {1.f,5.f,8.f,9.f,2.f};
sprintf(ligne,"% 5d %f % 5.3f %05.6f %f%f",a,b[0],b[1],b[2],b[3],b[4]);

par touvé mieux pour formaté des ligne d'un fichier

autre exemple, interfacé des code fortran avec du c++, on utilisera plustot en premier lieu du C.

[Laurent Gomila]

Les sscanf et sprintf sont avantageusement remplacés par les flux stringstream. Tu as aussi boost.format, qui fournit un équivalent plus typé à sprintf.

[yan]

En C, faire un tableau dynamique demande un certain nombre de manipulations et des precautions, alors qu'en C++, les conteneurs font le travail a notre place.

Pas toujour vrai.
Par exemple le vector, l'operateut [] n'est absolument pas obligé de faire de vérification (dans VC2005 il ont décidé que oui...). Justement pour être proche des performance d'un tableau dynamic en C. La aussi faut savoir ce que l'on fait.

[yan]

Les sscanf et sprintf sont avantageusement remplacés par les flux stringstream. Tu as aussi boost.format, qui fournit un équivalent plus typé à sprintf.

stringstream : j'ai pas trouve de super equivalence avec kes flux
boost.format : faut vraiment que je me mette a boost. Ils ont l'aire d'avoir fait plein de super chose

[Alp]

Les stringstream (cf la FAQ) permettent de manipuler des chaînes par le biais de ... flux

C'est plus pratique encore que sscanf/sprintf. Et de plus ça utilise le modèle de flux très pratique et très répandu désormais dans les bibliothèques C++.

boost.format est une excellente bibliothèque qui permet à la *printf-like de formater des chaînes.

Oui, vraiment, vas jeter un coup d'oeil à boost

[Laurent Gomila]

stringstream : j'ai pas trouve de super equivalence avec kes flux

Tu aurais un exemple que tu as du mal à transposer avec les flux ?

boost.format : faut vraiment que je me mette a boost. Ils ont l'aire d'avoir fait plein de super chose

L'utilisation de boost devient de plus en plus inévitable

Par exemple le vector, l'operateut [] n'est absolument pas obligé de faire de vérification (dans VC2005 il ont décidé que oui...). Justement pour être proche des performance d'un tableau dynamic en C. La aussi faut savoir ce que l'on fait.

std::vector ne fait pas systématiquement ce genre de vérifications, tout comme le programmeur ne les ferait pas avec un tableau brut. Par contre il permet de les faire si nécessaire (via la fonction at()).
Par contre, std::vector implémente correctement les différentes opérations que tu auras à faire sur un tableau, opérations qui seraient inévitablement buggées si tu devais les gérer toi-même avec un tableau brut.

[Alp]

De plus, étant encapsulé dans une classe, on peut éviter les débordements et compagnie grâce au "catching" d'exceptions (out_of_range, ...).

On peut donc contrôler ce que l'on fait, éviter (ou du moins limiter) les erreurs, sans se soucier de redimensionner le tableau etc, tout en s'en servant comme un tableau brut. Que vois-tu comme ombre au tableau ?

[yan]

std::vector ne fait pas systématiquement ce genre de vérifications

Ben dans visual 2005 si (c'etait un autre post). j'ai reussi a les viré avec les option de compilation, mais je trouve pas sa propre.
Sinon c'est ce que je voulais dire un contenaire (comme vector) n'est pas forcement obligé de tout faire. Donc faut faire attention

[Laurent Gomila]

Ben dans visual 2005 si (c'etait un autre post)

C'est une spécificité de la STL de Visual C++ 8 en mode debug. Dans la norme, il est indiqué que [] ne fait pas de vérif, et que at() le fait.

Sinon c'est ce que je voulais dire un contenaire (comme vector) n'est pas forcement obligé de tout faire. Donc faut faire attention

Ce qu'il ne fait pas c'est ce que tu n'aurais de toute façon pas fait non plus avec un tableau brut. Donc faut pas plus faire attention qu'avec ce dernier.

[yan]

C'est une spécificité de la STL de Visual C++ 8 en mode debug. Dans la norme, il est indiqué que [] ne fait pas de vérif, et que at() le fait.

Fait quand meme une verif en release pour l'enlever faut mettre _SECURE_SCL=0 dans les options du préprocesseur.

Ce qu'il ne fait pas c'est ce que tu n'aurais de toute façon pas fait non plus avec un tableau brut. Donc faut pas plus faire attention qu'avec ce dernier.

Exactement, c'était juste pour présicer

[Laurent Gomila]

Fait quand meme une verif en release pour l'enlever faut mettre _SECURE_SCL=0 dans les options du préprocesseur

On dirait bien que tu as raison. C'est tout de même étonnant, je me demande même si ce n'est pas en contradiction avec la norme.

[Jean-Marc.Bourguet]

On dirait bien que tu as raison. C'est tout de même étonnant, je me demande même si ce n'est pas en contradiction avec la norme.

Pourquoi? Ca m'a l'air de ne changer le comportement que pour des comportements indefinis.

[Alp]

A ce que je sais ça l'est. La norme spécifie que seule la fonction at() doit vérifier, et pas []. Je vais vérifier.

[yan]

A ce que je sais ça l'est. La norme spécifie que seule la fonction at() doit vérifier, et pas []. Je vais vérifier.

En faite la norme ne spécifie rien sur le fonctionnement de [], mais par principe d'efficacité elle devrait ne rien faire "Exceptional C++ Style 40 New Engineering Puzzles, Programming Problems, and Solutions" chapitre 1 "Uses and Abuses of vector"

[Gandalf]

C'est vrai que professionnellement, les choix sont ceux d'une équipe, voire même ceux de l'entreprise. Evidement quand on travaille sur un logiciel propriétaire (il faut bien vivre) il n'est pas possible d'incorporer des élément en GPL dedans.

Ensuite certain choix sont simplement des contraintes techniques, on a rarement la chance de travailler sur un projet 'from scratch' et alors il faut gérer l'existant, et donc oui on fait du C++ ou l'utilisation de la STL est interdit par exemple... sachant qu'en plus ca passe très mal de Dll en Dll...

[Matthieu Brucher]

Ben quand ton chef comprend pas tout ou qu'il veut tel lib parcequ'elle est gratuite et surtout pas GPL, ou que tu reprend un vieux projet mal pensé, mal développer ... ben tu souffre. Aprés en java c'est pas le même problème, un projet en java que tu reprendrai est déja en java

Le C++ est du C++, je ne vois pas la différence d'avec les n versions de Java...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

C'est la raison que l'on peut codé du C dans du code C++

Faux. D'ailleurs, même les compilateurs usuels ne sont pas forcément capables de compiler le C99 (j'ai eu un souci comme ça où je devais compiler une bibliothèque avec ICC en mode c99, mais je ne pouvais pas ajouter l'option --std=c99)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Par exemple le vector, l'operateut [] n'est absolument pas obligé de faire de vérification (dans VC2005 il ont décidé que oui...). Justement pour être proche des performance d'un tableau dynamic en C. La aussi faut savoir ce que l'on fait.

Si mes souvenirs sont bons, c'est désactivable. Tu as /GS enclenché ?

[JolyLoic]

C'est une spécificité de la STL de Visual C++ 8 en mode debug. Dans la norme, il est indiqué que [] ne fait pas de vérif, et que at() le fait.

Pas tout à fait. Dans la norme, il est dit que mal utiliser [] est un comportement indéfini. Qu'un compilateur a donc le droit droit de définir comme il le veut. Par exemple en le définissant comme faisant une validation dans des contextes où les performances ne sont pas primordiales. Et définir intelligemment des comportements indéfinis est un critère important de la qualité d'implémentation d'un compilateur.

Par contre, le comportement quand on utilise at incorrectement est défini.

[JolyLoic]

Pour ma part, je dirais que ce que j'évite principalement, c'est d'utiliser la bibliothèque standard du C quand des remplaçants C++ existent (soit en standard, soit en C++), ainsi que tout système d'allocation de ressource non géré par une classe (en particulier la mémoire, ce qui fait que j'ai assez peu d'utilisation directe de pointeurs).
Autre point que j'évite : Les macros, dans les cas où elles peuvent se remplacer par des constantes ou des fonctions (éventuellement inline).

[yan]

Le C++ est du C++, je ne vois pas la différence d'avec les n versions de Java...

java est du java c'est pas la même chose pour le C++, C++ et un peu du C; Même si il ne faudrait pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

C'est la raison que l'on peut codé du C dans du code C++

Faux. D'ailleurs, même les compilateurs usuels ne sont pas forcément capables de compiler le C99 (j'ai eu un souci comme ça où je devais compiler une bibliothèque avec ICC en mode c99, mais je ne pouvais pas ajouter l'option --std=c99)

Y as bien sur une limite a tout cela. C++ n'est qu'en patie du C. Mais dire qu'ils sont totalement différent et un peu trop rapide. Je suis d'accord qu'il faut au maximum les séparer. Ce qui n'est pas toujours facile. Par exemple les struct peuvent être aligné en C++ et non en C(du moins il me semble) ce qui peut poser de grave problème d'interfacage entre du C et du C++...

Si je voulais allez plus loin je pourrai presque dire que la STL est la pour comblé cette ensemble existant entre le C et le C++, mais ca peut partir loin.

Je pense que l'histoire est trop proche entre le C++ et le C pour que ces deux langage soit totalement distinct. Ce qui pose les problème de ce post. Maintenant, une prochaine version du C++ est en cours, et a l'air de remettre à plat pas mal de ces problèmes et c'est pour cette raison que j'essaie de me remettre à niveau; Pour ne pas être largué. Je trouve que la conception du C++ as beaucoup évolué.