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.

[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