Discussion :

[yan]

ATTENTION c'est sérieux...
Bonjour,
aprés plusieurs fois mettre fait envoyer ...bip.. (a juste titre parfois ) a cause de la différence entre ces deux langages. Je voudrai faire un point.

Personnellement, je pense que d'affirmer que c'est deux langage sont distinct est une utopie lors que l'on est développeur :
Il y as trop de projet, de lib et de fonction surpuissante ... qui sont en C (sscanf, glib, GTS, Opencv, OpenGL ...) et utiliser avec du C++. Ainsi que la simplicité de passer des objets C++ au format C : comme les string qui fournisse la méthode cstr() pour reccuperer du char *.

Je ne pense avoir spécialement raison bien sur (d'ou ce topic). Mais j'aimerai savoir si dans votre travaille vous arrivez réellement as séparer ces deux langages, et dans le cas positif, comment faite vous, et aussi qu'es qui est a bannir pour être un vrai développeur C++. exemple le char *.

merci

[Alp]

Pour la plupart des bibliothèques C les plus utilisées, il existe des binding C++.

Ensuite, bien que je ne développe pas pour une entreprise mais simplement à titre personnel pour le moment, j'ai banni les char*. Et lorsque je dois donner un char* à une fonction, je sais que std::string me le permet.

Des exemples de bibliothèques C remplaçables ou bindées en C++ :
pthread -> boost.thread, Loki, wxThread (wxWidgets), QThread (Qt), ...
sockets posix -> boost.asio, socket++, wxSocket (wxWidgets), QSocketClient/Server (Qt), ...

Tu veux d'autres équivalents ?

[yan]

Pour la plupart des bibliothèques C les plus utilisées, il existe des binding C++.

Ensuite, bien que je ne développe pas pour une entreprise mais simplement à titre personnel pour le moment, j'ai banni les char*. Et lorsque je dois donner un char* à une fonction, je sais que std::string me le permet.

Des exemples de bibliothèques C remplaçables ou bindées en C++ :
pthread -> boost.thread, Loki, wxThread (wxWidgets), QThread (Qt), ...
sockets posix -> boost.asio, socket++, wxSocket (wxWidgets), QSocketClient/Server (Qt), ...

Tu veux d'autres équivalents ?

Malheureusement, ce n'est pas le développeur qui décide...

C'est surtout professionnellement que je demande (les travaux personnel en C++ c'est sans aucun problème).
Comment faire pour faire réellement abstraction du C dans des projets.
Ce n'est surtout pas pour troller. Je suis d'accord de bien faire comprendre que C et C++ ne sont pas les même langage, mais pas sur le fait de les distinguer. Car, par exemple, un jeune développeur qui va commencer a travailler va avoir de bonne base de C++ et/ou as qui ont n'as jamais expliqué comment les différencier, va se retrouver avec des projet C/C++. Si il ne sait pas faire la différences, il est mal barré (un peu mon cas au début, mais j'y travail ). Et va commencer à mélanger les deux.

Personnellement je ne vois pas comment pour faire à tous les coups, un projet totalement C++.
Par exemple GTS, il n'y as le choix que de traîner des morceaux en C (en plus c'est du "C objet"), faire un binder C++ prendrai trop de temps.

Aprés je veut bien croit que se soit ma méthode de travail qui faudrait revoir, mais dans ces cas j'aimerai que l'on m'explique, et avoir des conseil. Perso je ne pense pas être le seule avec ce problème, et de fermer toutes discutions sur ce thème ne fait pas avancer les choses.

[nikko34]

Ce n'est pas difficile de faire un projet C++. C'est juste de trouver des gens compétents qui est peut être plus dur, mais si quelqu'un qui s'y connait peut expliquer clairement ce qu'il faut faire et ne pas faire, ça passe tout seul.

[Laurent Gomila]

Ce n'est pas une question de mélanger C et C++, ici tu parles juste d'utiliser des bibliothèques ayant une interface C. Et je ne vois pas de problème à le faire, ça ne te fait qu'appeler des fonctions avec éventuellement des char* ou des void*, mais ça ne te fait pas coder en C.

[yan]

Ce n'est pas une question de mélanger C et C++, ici tu parles juste d'utiliser des bibliothèques ayant une interface C. Et je ne vois pas de problème à le faire, ça ne te fait qu'appeler des fonctions avec éventuellement des char* ou des void*, mais ça ne te fait pas coder en C.

C'est des exemples, je peut rajouter les callback, cela n'as pas l'aire trés C++ comme fonction. Utiliser des FILE, des sscanf , .... parfois on n'as pas le choix. C'est pas du C++. Y as plein d'exemple, NULL n'est pas C++ mais C ...

Aprés peut être que je ne suis pas claire. Le but est de savoir comment se débrouille les gens et répertorier ce qui serait bien de bannir du C++ (professionnellement parlant). En gros c'est pour savoir comment bien séparer ces deux langage (dans la limite du possible) et reprendre de bonne habitude comme :
- plus de char *
- plus de tableau mais des vector (ça je ne suis pas encore vraiment d'accord)
...(la je sais pas)

[Laurent Gomila]

Ce que je voulais dire c'est que quelque soit l'interface de la bibliothèque C que tu utilises, tu pourras très vite revenir à du C++ correct, tu n'auras pas à te trimballer du code C un peu partout.

Le but est de savoir comment se débrouille les gens

C'est simple, moi je n'utilise du C que lorsque je ne peux pas faire autrement. J'utilise actuellement des bibliothèques pour un projet perso, toutes sont en C, ça ne me pose aucun problème elles s'intègrent parfaitement. Elles auraient eu une interface C++ ça n'aurait pas changé grand chose, si ce n'est la syntaxe des appels de fonction ("x.f(y)" au lieu de "f(&x, y)").

répertorier ce qui serait bien de bannir du C++

Si tu en es là ça veut dire que tu as mal démarré ton apprentissage, et que tu as déjà assimilé des choses à éviter ?

- plus de tableau mais des vector (ça je ne suis pas encore vraiment d'accord)

Moi non plus, il y a bien d'autres conteneurs qui peuvent être plus adaptés que std::vector. Par contre il y aura toujours quelque chose qui sera mieux qu'un bête tableau brut.

[yan]

En faite jusqu' a maintenant j'ai essayer de différencier le moins possible c'est deux langages. Justement a cause de leur ressemblance. De plus on m'empeché presque d'utiliser la STL, les templates... Et donc on me demandé de faire du C dans du C++. Ce qui as un coté positif malgrés tout. Maintenant j'essaye de me remettre a niveau par rapport a tout ça.

En faite j'aimerai surtout comprendre si il est réellement possible de ne pas tenir compte du C. ET de savoir ce qui est C et ce qui est C++. Par exemple les cast brut, les operateur binaire de décalage .... je ne sait pas ou les rangé

Justement le problème est que d'incruté du C dans du C++, il n'y as pas de problème. J'essaie donc de me remettre a plat tout cela

[Alp]

En exagérant, autant comparer C et PHP ...

Le C++, merci pour la compatibilité, possède un sous-ensemble permettant d'accepter dans de grandes mesures du code C. Ce n'est pas pour autant que programmer en C++ c'est savoir utiliser ce sous-ensemble.

Programmer en _C++_, c'est utiliser ses fonctionnalités.
On doit intéragir avec du code C ? Pas de problème, le C++ permet de s'en servir. On peut alors interfacer ce code C par du C++ sans problèmes.

Il n'y a pas à lister les différences. Ce sont deux langages différents que l'on ne doit pas mélanger. Ce n'est pas comme Php et Html, par exemple. Le C++ n'a pas besoin du C, il permet de s'en servir dans du code C++.

Les différences sont tellement énormes. A force d'écrire du code C++ au sens "C++-only", tu te rendras compte des différences.

Je pense que le mieux pour toi est de consulter un peu les généralités sur la FAQ, essayer d'écrire du code C++ pur avec la STL, les templates, les exceptions, la POO, ...

[yan]

c'est cool d'avoir plusieurs point de vue merci

Ce n'est pas pour autant que programmer en C++ c'est savoir utiliser ce sous-ensemble.

Tu verra (ou pas je te le souhaite) quand tu bossera

Les différences sont tellement énormes. A force d'écrire du code C++ au sens "C++-only", tu te rendras compte des différences.

Je pense que le mieux pour toi est de consulter un peu les généralités sur la FAQ, essayer d'écrire du code C++ pur avec la STL, les templates, les exceptions, la POO, ...

je ne suis pas non plus débutant. Mais j'avoue que la STL je l'avait toujours considéré comme non optimisé, mal faite ... (maintenant je la trouve très intéressante). Je pense que si je m'arrête a cela je n'irait pas plus loin. Il y as tellement plus comme les templates, la metaprog. Je trouve que la puissance du C++ est trés peu connue. Et que c'est pour cette raison qu'il faut le différencier du C (qui est aussi trés puissant mais pas de la même manière).

Le problème est vraiment de réussir a savoir où sont les différences.

[Mat007]

Salut,

Je ne vois pas bien pourquoi le fait d'être dans un environnement de production change les choses, je fais le même C++ (et le même java) chez moi qu'au boulot.
J'utilise les mêmes bibliothèques externes (jamais des faites pour du C) et je vois mal comment on peut se passer de la STL (des conteneurs et des flux en tous cas).
En fait ça fait tellement de temps que j'ai pas fait de C (FILE* ?! sscanf ?!) que ça me fait toujours un choc quand j'en vois des bouts de code

Cela dit si on t'empêche d'utiliser la STL et les templates au boulot ça doit pas être évident déjà...

MAT.

[Ksempac]

Mouais, les templates c'est bien joli, ca fait type calé techniquement, mais ca s'utilise pas tous les jours non plus.

En revanche l'utilisation de std::string, de la STL, des flux (cin, cout, ofstream...) c'est quelquechose de permanent qui distingue radicalement le C++ du C. On arrete de se prendre la tete avec des histoires de depassement de buffers, de tableaux dynamiques a allouer, etc...
Deplus, si la POO en C est quelquechose d'assez delicat a mettre en oeuvre, c'est quelquechose de fondamental en C++. Du C++ sans POO, ca n'est, a mon sens pas du C++. Et développer un programme orienté objet ca modifie completement la facon de penser l'application...

Compare un peu les questions des forums C et C++, tu verras que ca n'a rien a voir. Dans le forum C, les problemes de gestions de chaine de caracteres, d'ouverture de fichiers, reviennent en permanence. Dans le forum C++, ca parle surtout POO et STL.

[yan]

Salut,

Je ne vois pas bien pourquoi le fait d'être dans un environnement de production change les choses, je fais le même C++ (et le même java) chez moi qu'au boulot.
J'utilise les mêmes bibliothèques externes (jamais des faites pour du C) et je vois mal comment on peut se passer de la STL (des conteneurs et des flux en tous cas).
En fait ça fait tellement de temps que j'ai pas fait de C (FILE* ?! sscanf ?!) que ça me fait toujours un choc quand j'en vois des bouts de code

Cela dit si on t'empêche d'utiliser la STL et les templates au boulot ça doit pas être évident déjà...

MAT.

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

[nikko34]

Mouais, les templates c'est bien joli, ca fait type calé techniquement, mais ca s'utilise pas tous les jours non plus..

en fait si, tous les jours, ne serait ce que dans les classes de la STL...

Après en faire toi..c'est un peu comme si tu disais "le polymorphisme, ça fait joli, mais on s'en sert pas tous les jours.."

[yan]

Mouais, les templates c'est bien joli, ca fait type calé techniquement, mais ca s'utilise pas tous les jours non plus.

T'es sur, pourtant la STL est uniquement faite en templates.
Par contre c'est claire que la POO en C++ n'est pas la même en C (si on peut considéré le"C objet" comme de la POO)

[r0d]

Je ne vois pas bien pourquoi le fait d'être dans un environnement de production change les choses, je fais le même C++ (et le même java) chez moi qu'au boulot.

Ce qui change (je parle pour moi) c'est qu'au boulot, je ne choisis pas toujours (pas souvent même) les technos que j'utilise. Je me retrouve donc souvent à interfacer différents types de langages, donc souvent du C. C'est un point de vue trés personnel, mais lorsque que j'ai le choix de la techno, j'essaie autant que faire se peut d'en trouver une en C++, même si elle n'a pas fait autant ses preuves que son équivalent dans d'autres langages.

En revanche l'utilisation de std::string, de la STL, des flux (cin, cout, ofstream...)

la classe string ainsi que les flux ne font pas partie de la STL, mais de la SL.

On arrete de se prendre la tete avec des histoires de depassement de buffers, de tableaux dynamiques a allouer, etc...

Les conteneurs aussi permettent cela. Surtout eux d'ailleurs, et ils font partie de la STL.

[JolyLoic]

Mouais, les templates c'est bien joli, ca fait type calé techniquement, mais ca s'utilise pas tous les jours non plus.

Je pense que je fais mes propres templates (par opposition à simplement en utiliser des tous faits, je pense que c'est là ce que tu voulais dire) très régulièrement. A peu près aussi souvent que je fais une fonction virtuelle.

Après, ce ne sont en général pas des templates hyper sophistiqués, reconfigurables à fond, dans une bibliothèque générique à large usage, mais plutôt des templates qui devront pouvoir s'instance sur 2/3 types que je maitrise aussi. Derniers exemples en date :
- Une fonction de manipulation de chaîne de caractères qui peut travailler avec les différentes chaînes de notre application (std::string, std::wstring, une wstring case-insensitive et Glib::ustring).
- Des fonctions de sérialisation pour boost
- Un algorithme de synchronisation de deux map<string, T>, que j'utilise pour 3/4 T différents
- ...

[millie]

Des exemples de bibliothèques C remplaçables ou bindées en C++ :
pthread -> boost.thread, Loki, wxThread (wxWidgets), QThread (Qt), ...
sockets posix -> boost.asio, socket++, wxSocket (wxWidgets), QSocketClient/Server (Qt), ...

Ca, c'est effectivement pratique si tu as les bibliothèques sous la main et compilés. Mais ce n'est pas toujours le cas sur des systèmes particulier et ça devient parfois la croix et la bannière à les compiler.

Même si tu n'as pas cité cela (et que c'est une bibliothèque C), afin d'avoir une bibliothèque réseau multiplateforme (notamment Windows, linux, mac, Solaris). J'avais voulu utilisé SDL_net. Ce qui impliquait d'utiliser SDL. J'ai réussi à faire compiler SDL sans trop trop de problème sous Solaris, mais je n'ai jamais réussi pour SDL_net ce qui fait que j'ai dû choisir une autre solution Je crois que j'aurais le même type de problème avec d'autres bibliothèques sur des systèmes vieux, "particuliers" et avec très peu de bibliothèques dessus

[Ksempac]

la classe string ainsi que les flux ne font pas partie de la STL, mais de la SL.

Est ce que j'ai pretendu le contraire ?

Les conteneurs aussi permettent cela. Surtout eux d'ailleurs, et ils font partie de la STL.

C'est justement ce que je disais : 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.

Montgolois, nikko34 > je sais je suis au courant que STL, ca signifie Standard TEMPLATE Library.
Merci a JolyLoic d'avoir compris ce que je disais. Merci aussi pour les exemples d'utilisation des templates.

[koala01]

Salut,

Je crois qu'il ne faut déjà pas confondre ce qui vient du C, et qui a été gardé tel quel en C++ - pointeurs, enum, struct (même si elles ont évolué), opérateurs de décalages de bits, simplement le nom des types primitifs, et tant d'autres choses - et ce qui est pur C, qui est fournis sous une autre optique en C++ mais qui a été gardé pour des raisons de compatibilité -*scanf,*printf, FILE et tant d'autres choses...

Il est clair que si tu décides de bannir tout ce qui vient du C et pour quoi on n'a pas créé d'équivalent... il ne restera pas grand chose au C++ standard à part les références, les classes, les templates et la S(T)L :

• Les structures de contrôle
• Les boucles
• les énumération
• les types primitifs
• les pointeurs
• la signature des fonctions
• les directives préprocesseur
• la grosse majorité des mots clé
• le nom de la fonction principale
• les opérateurs logiques, mathématiques ou d'(in)égalité
• pleins de choses auxquelles je n'aurais pas pensé de prime abord

sont autant de choses dont tu pourrais estimer, vu que cela vient du C et qu'il n'y a pas d'équivalent "pur C++", que leur emploi te fait coder en C et non en C++

Le problème vient du fait qu'il y a une grande filiation entre le C++ et le C...

Un peu comme il y a une grande filiation entre toi et ton père

L'astuce, c'est qu'on ne pourra jamais dire que ton père c'est toi, ou que tu es ton père

Et pourtant, d'après selon l'héridité, tu es composé pour 50% du patrimoine de ton père...

C'est exactement la même chose pour ce qui est du C et du C++:

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

Simplement parce que le C et... le "père" du C++.

A ce titre, l'"hérédité" a fait que le C++ dispose d'une grande partie de ce qui fait le C

Et cela va même plus loin en te permettant d'interfacer du C dans du code C++...

Mais toute la différence tient dans ce mot: interfacer Ce n'est pas parce que tu décide d'appeler des fonctions fournies par des bibliothèques écrites en C que, d'office, tu te met à écrire du code C

Par contre, si *vraiment* tu veux essayer d'écrire du code "pur C++" (si tant est que rentre dans ta définition du mot pur ), les conseils sont simples:

• Si une alternative C++ existe, utilise la (cin/cout par préférence à *scanf/printf, *fstream par préférence à FILE et autres f*(), ...)
• Utilise de préférence ce qui est décrit dans la norme (la S(T)L, prochainement au moins une partie de boos...)
• Pour ce qui n'est pas décrit dans la norme, préfères les bibliothèques "C++"
• refuse (si tant est qu'une alternative existe) d'utiliser des bibliothèques "C"
• Quoi qu'il en soit, si tu dois utiliser des bibliothèques C, limites les parties réellement écrites en C à leur stricte minimum