Discussion :

[ProgrammeurDuGrenier]

Bonjour a tous, j'ai une petite question depuis longtemps et dont je n'ai pas trouvé la réponse :
Pourquoi devoir choisir entre le C et le C++ dans un projet en C++ alors que le C++ compile très bien un mélange des deux ?
On ne peut pas faire tout simplement un mélange des deux ?
Merci d'avance !

[ternel]

Si, on peut, mais ce sera du C++.
Mais ce n'est pas une bonne idée, en général, les deux langages n'ayant pas les mêmes objectifs.

Une fois que tu commences à te servir correctement du C++ (RAII, références, etc), c'est à dire que tu as accepté d'en payer le coût à la compilation, pourquoi ne pas le faire partout?

Dans les détails, il y a des divergences entre les deux langages (notamment la conversion implicite depuis/vers void*)

[chrtophe]

Dans les détails, il y a des divergences entre les deux langages (notamment la conversion implicite depuis/vers void*)

Peux-tu m'expliquer ce que ça veut dire leternel ?

Je ne suis pas développeur de métier.

[jo_link_noir]

Ce que veut dire @leternel, c'est qu'il existe des comportements différents entre le C et le C++, notamment parce que le C++ est plus strict. De ce fait, une allocation mémoire typique du C (cf: T * x = malloc(sizeof(T))) ne compile pas en C++ sans ajouter un cast (cf: T * x = static_cast<T*>(malloc(sizeof(T))) ou un cast style-C) ce qui revient à faire un mélange bâtard entre C et C++ alors que ce dernier offre une syntaxe beaucoup plus simple et sûr: T * x = new T; ou éventuellement T * x = new(std::nothrow) T; qui permet en plus d’initialiser l'objet, et non pas simplement réserver de la mémoire.

De plus, une allocation demande une libération manuelle et le C++ permet de s'en affranchir en utilisant le RAII. Dans un système qui lance des exceptions, le faire manuellement est quelque chose d’extrêmement compliqué et verbeux. Autant dire qu'utiliser du C dans ces conditions relève du suicide, d'autant plus qu'il n'y a pas la possibilité d'attraper les exceptions en C.

Finalement, mélanger les 2 langages et le bon moyen de restreintes les possibilités de chacun, car on va tendre sur l'utilisation du socle commun.

[chrtophe]

[Médinoc]

Il faut savoir toutefois, que le C et le C++ supportent tous deux la "compilation séparée", et que le C++ supporte d'exporter ses fonctions libres comme si c'étaient des fonctions C. Cela permet d'avoir, dans un même projet, des fichiers sources C et C++ qui cohabitent, chacun compilé avec le bon compilateur, et que le produit de leur compilation soit ensuite mis ensemble lors de l'édition de liens.

J'ai ici un exemple pédagogique de codes C et C++ liés ensemble, utilisables en depuis un code C ou depuis un code C++.

[Astraya]

L'utilisation du C en C++ est possible mais il faut savoir ce que tu fais et avoir une certaine expérience pour le faire bien.
Le but d'utiliser du C en C++ est généralement de "singer" une fonctionnalité C++ standard et de le faire "à ta sauce" apportant des optimisations mémoires ( Gestion, Log, Tracabilité, etc...), et autre ( container custom, ...)

Je vais reprendre un exemple que j'ai vu plus haut du malloc, tu peux surcharger un new, dans ce cas tu utiliseras malloc qui est du C. Mais tu "surchargeras" de-facto la fonctionnalité "new" du C++. Dans certains cas, tu veux juste allouer un nombre de bit et ne pas te soucier de ce que c'est ( Custom Allocator ); Tu peux le faire avec le new standard ou le faire en malloc, je résultat est le même, mais la syntaxe différente ( La version C sera plus lisible et plus courte, mais c'est mon avis);

C++ utilise le C. Donc tu peux utiliser le C dans C++, mais en sachant ce que tu fais et bien le faire.

[Ehonn]

Tu peux le faire avec le new standard ou le faire en malloc, je résultat est le même, mais la syntaxe différente ( La version C sera plus lisible et plus courte, mais c'est mon avis)

Plus courte ? Tu compares malloc de C et malloc avec cast en C++ ? Et non malloc de C avec new de C++ comme ton message le laisse penser (auquel cas, l'utilisation de new est probablement plus courte) ? (Sinon, je veux bien un exemple.)

[Astraya]

Plus courte ? Tu compares malloc de C et malloc avec cast en C++ ? Et non malloc de C avec new de C++ comme ton message le laisse penser (auquel cas, l'utilisation de new est probablement plus courte) ? (Sinon, je veux bien un exemple.)

Je veux parler de malloc<->malloc oui. Avec le new, autant l'utiliser quand on peut, mais dans le cas ou l'on ne veux pas appeler le constructeur la syntaxe C est plus lisible je trouve. Mais c'est un avis personnel.

[ternel]

A part dans des cas extrèmement spéciaux, qui finissent par l'appel du "placement new", quand veux-tu allouer de la mémoire sans appeler un constructeur?

[jblecanard]

Je connais au moins deux cas : le malloc aligné. On ne l'a pas dans le new C++ et pourtant on peut en avoir besoin (ok normalement il finit avec un placement new). Et aussi, allocation d'une stack pour switch de contexte. Là pas de de placement new.

[Bousk]

Il existe un nombre incroyable d'API C, donc intégrer du C dans du code C++ est loin d'être rare.
On n'écrit pas du C pour autant, c'est juste la syntaxe, un simple appel de fonction en général, qui est identique.

[jo_link_noir]

le malloc aligné. On ne l'a pas dans le new C++.

Si, en C++17. D'ailleurs, aligned_alloc n'arrive aussi quand C++17. Je suppose que c'est une conséquence de mettre C11 par défaut pour extern "C". Avant C++17, utiliser un projet C11 dans un code C++ est simplement impossible.

[Astraya]

Exactement, malloc aligné donc allocateur custom.

Pour ce qui est de C++ 11/17, je ne connais aucune entreprise qui l'utilise, c'est beau sur papier mais dans les fait les boites n'y sont pas passé. Peut-être avec le temps, mais il ne faut pas compté sur C++11 dans la majorité des entreprises même aujourd'hui malheureusement.

[ternel]

Détrompe-toi, il y en a: mon projet est en cours de migration, il sera officiellement en C++11 d'ici fin 2017.

Bon, ca en fait une, reste à en trouver d'autres

[jblecanard]

Si, en C++17. D'ailleurs, aligned_alloc n'arrive aussi quand C++17. Je suppose que c'est une conséquence de mettre C11 par défaut pour extern "C". Avant C++17, utiliser un projet C11 dans un code C++ est simplement impossible.

Ho non très mauvaise nouvelle pour moi je comptais l'utiliser prochainement sur un projet C++14 .

Pour ce qui est de C++ 11/17, je ne connais aucune entreprise qui l'utilise, c'est beau sur papier mais dans les fait les boites n'y sont pas passé. Peut-être avec le temps, mais il ne faut pas compté sur C++11 dans la majorité des entreprises même aujourd'hui malheureusement.

17, non. 11 ça vient. Ma précédente boîte l'utilise depuis 2 ans et le client chez qui je suis est en 11/14.

[Matt_Houston]

C++14 ici.

[jo_link_noir]

Ho non très mauvaise nouvelle pour moi je comptais l'utiliser prochainement sur un projet C++14 .

Tu peux pour aligned_malloc, elle existe avec clang et gcc (sous linux en tout cas), et sous le nom de _aligned_alloc pour vc++. Mon propos concerne plus certains mots clefs (_Noreturn, _Generic, etc).
Je viens de refaire un test avec _Generic, cela fonctionne avec clang (même en c++03), mais pas avec gcc ni vc++, je ne sais pas quoi penser :/.

Chez nous c'est c++11, bientôt 14.

[LittleWhite]

Il faut aussi trouver les développeurs qui se sont intéresser aux évolutions du langage.

[nikko34]

Maintenant dans ma boite pour tous les nouveaux process j'essaie d'être en C++14 si possible.

J'ai aussi fait du C++11 embarqué (avr-gcc) il y a deux ans, très intéressant.