C et C++ mythe et realité

Version imprimable

Voir 40 message(s) de cette discussion en une page

08/08/2007, 09h18
r0d

Citation:

Envoyé par Ksempac

Est ce que j'ai pretendu le contraire ?

C'est justement ce que je disais

En effet, j'avais mal compris. :oops:
08/08/2007, 09h21
yan
Citation:

Envoyé par koala01

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"

Citation:

Envoyé par koala01

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:

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:

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.
08/08/2007, 09h26
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.
08/08/2007, 09h26
yan

Citation:

Envoyé par Ksempac

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.
08/08/2007, 09h28
yan

Citation:

Envoyé par 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.

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
08/08/2007, 09h32
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 ;)
08/08/2007, 09h32
Laurent Gomila

Citation:

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

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

Citation:

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 ;)

Citation:

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.
08/08/2007, 09h35
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 ?
08/08/2007, 09h40
yan

Citation:

Envoyé par Laurent Gomila

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

Ben dans visual 2005 si :cry: (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
08/08/2007, 09h55
Laurent Gomila

Citation:

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.

Citation:

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.
08/08/2007, 10h15
yan

Citation:

Envoyé par Laurent Gomila

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 :cry: pour l'enlever faut mettre _SECURE_SCL=0 dans les options du préprocesseur.

Citation:

Envoyé par Laurent Gomila

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 :lol:
08/08/2007, 10h23
Laurent Gomila

Citation:

Fait quand meme une verif en release :cry: 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.
08/08/2007, 10h24
Jean-Marc.Bourguet

Citation:

Envoyé par Laurent Gomila

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.
08/08/2007, 10h25
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.
08/08/2007, 10h35
yan

Citation:

Envoyé par 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.

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"
08/08/2007, 11h35
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...
08/08/2007, 12h32
Matthieu Brucher

Citation:

Envoyé par Mongaulois

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:

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:

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é ?
08/08/2007, 13h32
JolyLoic

Citation:

Envoyé par Laurent Gomila

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.
08/08/2007, 13h36
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).
08/08/2007, 14h21
yan

Citation:

Envoyé par Miles

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

Citation:

Envoyé par Miles

Code:

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 :D 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é.

Voir 40 message(s) de cette discussion en une page