Discussion :

[elekis]

bonjour,
voila, dans mon cursus, nous avons un cours d'archi, qui est surtout de la programmation system en c.(socket , semaphore, etc..etc...)

j'aurais voulu savor, c'est system call sont il les memes en c++ , et si oui pourquoi en programmation system, on n'utilise quasi jamais le c++)

et sinon, par apres, en general, faut il toujours utiliser le c pour le bas niveau (socket, and autre) et pour la couches superieurs, utiliser de l'objet??

merci

a++

[piff62]

Perso, je pense que ce choix est plus un choix de "gout"
Y'en a qui prefere le C (plus bas nivau) car c'est eux qui gere presque tout alors qu'il y en a qui prefere C++ (plus haut niveau) afin d'eviter toutes betises

Les gouts et les couleurs ne se discutent pas

[Luc Hermitte]

Tradition ? Méconnaissance ? Abscence de compilo C++ ? Abscence d'ABI C++ ?
http://www.objectmentor.com/resource...tillUsingC.pdf

Sinon, voir les "débats" à droite à gauche sur le sujet.

[blackhorus]

si on part sur ce constat :

langage machine (0,1 puerement) -->assembleur --> C --> C++ --> C oméga... (ou je sais pas)

plus on s'éloigne de langage machine, et plus on se facilite la vie par des concepts plus abstrait et plus proche de notre entourage ( quoique..)

on choisit généralement, le C sur l'assembler, un compromis entre vitesse et taille du langage généré, mais avec les vitesse des processeurs, et l'optimisation des compilteurs, ce constat tend à disparaitre...

mais, certain reste sur leur acquis, et veulent pas trop s'emmerder avec des nouveaux concepts (polymorphisme, et cie), leur productivité en C leur suffit amplement.. et dans le domaine de la programmtion système, on trouve du C avec de l'assembleur, un parfait mariage, mais dans d'autre domaine le C n'est plus accepté et l'orienté objet oblige à programmer avec du C++, ...

[JolyLoic]

Sans savoir ce que signifie le symbole "-->", on ne peut pas trop confirmer ou infirmer ce classement...

Par contre, je relève quelques imprécisions dans le reste du message : Tout d'abord, j'ai l'impression d'y lire que le C++ est plus lent que le C, ce qui n'est pas vrai dans le cas général.

Ensuite, j'y lis que la POO implique l'usage du C++, alors que les plus gros programmes en C dont j'ai entendu parler sont programmés orientés objet, même sans support direct du langage.

Pour ce qui est de la question initiale, je dirais que comme C++ est une langage plus difficile à maîtriser (pas plus difficile à utiliser, hein, je n'ai jamais dit ça), un professeur peut légitimement préférer utiliser le C pour apprendre des concepts qui n'ont rien à voir avec le langage, afin de ne pas perdre l'étudiant. De plus, bien qu'utilisable en C++, on pourrait dire des appels systèmes classiques qu'il sont très mal conçus s'ils étaient conçus pour être utilisés en C++ (par exemple, un mutex qui n'utilise pas du RAII est une hérésie), donc autant préciser qu'il s'agit d'interface en C, afin de ne pas donner de mauvaises excuses à un étudiant qui ferait pareil en C++.

[SKZ81]

c'est system call sont il les memes en c++ , et si oui pourquoi en programmation system, on n'utilise quasi jamais le c++)

Oui ce sont les même.
Pourquoi les appels systèmes sont-ils des fonctions C ?
Parceque qui peut le plus peut le moins, donc il n'y a aucun problème technique au fait d'appeler une fonction C dans un programme C++. Par contre, comme l'inverse est impossible, les concepteurs des fonctions les écrivent en C, pour qu'elles puissent être utilisées dans les deux languages.

et sinon, par apres, en general, faut il toujours utiliser le c pour le bas niveau (socket, and autre) et pour la couches superieurs, utiliser de l'objet??

Quand c'est toi qui programme, tu a le choix. Comme je disais avant, pas de soucis pour appeler une fonction C dans u code C++. Si tu fais ce choix, par contre, il est mieux de faire en sorte que la classe qui utilise les appels systèmes encapsule correctement le C (c'est à dire en dehors de la classe, on a pas conscience qu'elle utilise des pointeurs etc...)
Même si rien n'est obligatoire à ce niveau (sinon ça ne compilerais pas) c'est très recommandé.

Pour conclure, ce qui détermine que tu va programmer en C ou en C++, c'est pas les fonctions que tu utilise, c'est ce que tu veux faire. Juste une simple fonction ? => C.
Un gros programme avec une belle architecture orientée objet ? => C++.

NB : On peut tout à fait faire du C avec un compilateur C++ !!

NB2 : On peut tout à fait interfacer du C++ avec de l'assembleur (linverse est beaucoup moins évident, cf le mangling)

[blackhorus]

Sans savoir ce que signifie le symbole "-->", on ne peut pas trop confirmer ou infirmer ce classement...

je sais pas trop, des couches d'abstractions, des niveau de difficultés...

Par contre, je relève quelques imprécisions dans le reste du message : Tout d'abord, j'ai l'impression d'y lire que le C++ est plus lent que le C, ce qui n'est pas vrai dans le cas général.

je voulais insister sur la taille du code généré, du fait de l'utilisation des classes, et des concepts inhérent au paradigme OO. quand à la vitesse j'ai conclu qu'avec les machines actuelles, la question de la vitesse ne se posais même pas...

Ensuite, j'y lis que la POO implique l'usage du C++, alors que les plus gros programmes en C dont j'ai entendu parler sont programmés orientés objet, même sans support direct du langage.

même avec l'assembleur on peut faire de l'orienté objet, et si on pousse un peu notre raisonement, même avec du langage machine... par mes propos, je voulais dire que le C++ etait inventé d'un côté pour faciliter la conception OO.

[Aurelien.Regat-Barrel]

Je pense que le fait que le système est écrit en C est un des principaux facteurs. Ca revient à reporter le débat pourquoi ne pas utiliser C++ pour le kernel ? Y'a un débat là dessus, les principaux arhuments:
- au début de Linux y'avait pas de compilateur C++ digne de ce nom
- le C n'empêche pas de faire de l'objet, certaines partie du kernel sont conçues de manière objet
- réécrire le kernel en C++ est un gaspillage d'énergie
- y'a plus de programmeurs C que de programmeurs C++ / C est plus simple

[JolyLoic]

- y'a plus de programmeurs C que de programmeurs C++ / C est plus simple

Sachant que là, ça se mord un peu la queue... Comme le kernel est en C, les autre programmes, on les développe en C (ça fait partie des recommendations de certains ténors de GNU et de Linux), histoire de pas avoir de surprises, donc il y a beaucoup de développeurs C, donc on écrit en ...

A une époque il y avait eu pas mal de frictions côté gcc parce que des gens voulaient écrire (la partie C++ / le compilateur) en C++, et il y avait eu un certain barrage.

[elekis]

merci, ma lanterne est eclairée,

mais juste un truc.

- réécrire le kernel en C++ est un gaspillage d'énergie

y a pas besoin de reecrire tout le kernel, suffit juste de changer les makefiles (en fait changer de compilateur) avec le temps, ca se fera tout doucement.

merci a tous

a++

[Aurelien.Regat-Barrel]

y a pas besoin de reecrire tout le kernel, suffit juste de changer les makefiles (en fait changer de compilateur) avec le temps, ca se fera tout doucement.

C'est + détaillé sur la FAQ. Mais soit en est en C++, soit en C. Mélanger les 2 c'est pas bon, et de toutes façons ce genre de manip ça se fait pas simplement.
Après c'est leurs arguments. Je suis pas spécielement d'accord. L'OS en C ok, mais s'il est conçu objet, rien n'empêche d'avoir un wrapper C++ à mon avis.