Discussion :

[oxyaxion]

Bonjour,

Voilà j'ai quelques questions qui vont paraître bêtes à certains d'entre vous, mais je n'arrive pas à obtenir l'information précise.
Ma question est simple est-il possible de faire de la programmation système (linux/unix) au même niveau d'abstraction (cad en étant aussi proche du système avec l'un que l'autre) avec C++.
En effet lorsque je recherche des cours de dev système Unix tous les cours proposés sont uniquement liés à C.
L'une des évolutions majeurs (en plus de toute la sur-couche POO) du C++ par rapport au C et de ne plus faire utiliser de pointeurs (ou du moins de les cacher dans un autre mécanisme c'est exact ?!)

Or dans des cas précis comme la prog sys par exemple, utiliser les pointeurs pour manipuler les adresses n'est-il pas au contraire un outil supplémentaire permettant d'être plus proche du système ?

Enfin voilà puis-je obtenir le même niveau "d'embrassement" avec le C comme avec le C++ ?.

Merci pour les compléments d'informations.

[Astraya]

Tu peux tout à fait obtenir le même niveau en C et C++. Des mauvaises langues diront toujours que C++ est plus lourd que C ou d'autres idées dans le genre fausses mais répandu.
Beaucoup de drivers sont fait en C++.

L'une des évolutions majeurs (en plus de toute la sur-couche POO) du C++ par rapport au C et de ne plus faire utiliser de pointeurs (ou du moins de les cacher dans un autre mécanisme c'est exact ?!)

Du moins les cacher dans un mécanisme de sécurisation serais plus correct.

Or dans des cas précis comme la prog sys par exemple, utiliser les pointeurs pour manipuler les adresses n'est-il pas au contraire un outil supplémentaire permettant d'être plus proche du système ?

En C++, void* + reinterpret_cast et tu est a même le hardware si tu le désires.

[Goten]

C'est "culturel" si j'ose dire, le language de l'opensource à toujours été le C pour ce genre de chose. Et tu les en fera pas démordre. (balance le mot clef C++ sur une ML linux / *BSD etc et tu verras).
Et pourtant je plussoie mon voisin du dessus qui dis que ce sont de fausses idée répandue .. (code bloat, complexité (quoique))

[oxyaxion]

Donc vous confirmez il est tout à fait possible de développer au niveau de la couche noyau (voir même plus bas) avec C++ ?!

Hormis quelques points comme un compilateur peut-être moins universels pour l'embarqué par exemple, ou quelques petits % de perfs en moins, le vrai fond du problème est qu'en fait utiliser du C++ avec ses nouvelles fonctionnalités et outils dans un environnement 100% C à la base, ça fait tâche et ça rend tout rouge les puristes qui voient des éléments impurs (issus de ce nouveau paradigme qu'est la POO ) se hisser dans leur bel algo impératif tout propre qui fait tourner Unix depuis le début ...
Et c'est tout ?!! Mais c'est un pas un peu refracto/sectaire ça ?!!!

Admettons, j'ai nécessité d'utiliser un pointeur dans un programme c++ pour x ou y raison particulière, je ne risque pas de me faire taper dessus par les collègues et me faire traiter d'incompétent car produisant une bouillie C/C++ ?!

[Astraya]

Donc vous confirmez il est tout à fait possible de développer au niveau de la couche noyau (voir même plus bas) avec C++ ?!

Oui.

ou quelques petits % de perfs en moins

ça c'est entièrement faux. je peux faire un code C plus lent que le C++ et inversement, le mauvais codeur te sortiras l'argument des performances.

le vrai fond du problème est qu'en fait utiliser du C++ avec ses nouvelles fonctionnalités et outils dans un environnement 100% C à la base, ça fait tâche et ça rend tout rouge les puristes qui voient des éléments impurs (issus de ce nouveau paradigme qu'est la POO ) se hisser dans leur bel algo impératif tout propre qui fait tourner Unix depuis le début ...

Si tu n'es pas le seul à travailler la dessus, tu n'auras pas le choix. Si tu as la possibilité de faire une DLL personne ne verra si c'est du C ou C++.

Admettons, j'ai nécessité d'utiliser un pointeur dans un programme c++ pour x ou y raison particulière, je ne risque pas de me faire taper dessus par les collègues et me faire traiter d'incompétent car produisant une bouillie C/C++ ?!

Et bien ça vas dépendre de tes collègues . Le mélange C/C++ n'est pas vraiment une bonne chose, pas pour des questions de performance ou autres. Mais plus pour des questions d'unicité du code.

[guillaume07]

Oui.
ça c'est entièrement faux. je peux faire un code C plus lent que le C++ et inversement, le mauvais codeur te sortiras l'argument des performances.

modulo que si tu te sers des features C++ comma la STL les exceptions, alors oui le C++ sera "plus lent"

[koala01]

Salut,

Le problème n'est, à l'extrême limite, pas l'utilisation de pointeurs, car, bien que l'on tende à les éviter au maximum, il y a malgré tout des situations dans lesquelles il n'est, purement et simplement, pas possible de faire autrement.

Il n'y a donc, a priori, aucune raison pour que l'on te lance des pierres pour la seule raison que tu utilise des pointeurs, si, du moins, tu les utilise à bon escient.

De plus, la programmation hardware / kernel est un domaine tout à fait à part, où les performances revêtent un aspect tout à fait primordial.

Même les puristes devraient donc être en mesure de comprendre que l'approche "moderne" du C++ n'est pas forcément adaptée, au vu de certaines possibilités qui présentent des performances dégradées.

Je pense entre autres à l'utilisation des flux qui, il faut l'avouer, sont globalement beaucoup moins performantes que les solutions issues du C

Mais, si les performances d'une possibilité particulière peuvent servir de prétexte à l'écartement de celle-ci, ce n'est, malgré tout, pas une raison pour virer bébé avec l'eau du bain...

Pour autant que tu soies en mesure de justifier valablement ta décision d'utiliser un des mécanismes issus du C au lieu du mécanisme équivalent issu du C++, il n'y aura, sans doute, pas grand chose à dire une fois que tu auras fait part de cette justification

Si, par contre, tu fais effectivement une "infâme bouillie" de C / C++ sans que cela ne soit justifié ni justifiable, il n'est pas exclu que tu obtienne quelques remarques bien senties et au demeurant justifiées

Il est cependant difficile de donner des règles générales sur le sujet, car la réaction des uns et des autres dépendra fortement du contexte dans lequel ils se situeront

Mais, quoi qu'il en soit, que risques tu réellement à présenter un code qui *risque* d'être considéré comme incorrect par les puristes, à par de te donner l'occasion d'obtenir un code plus sécurisant et tout aussi efficace

[Luc Hermitte]

modulo que si tu te sers des features C++ comma la STL les exceptions, alors oui le C++ sera "plus lent"

Modulo que std::sort est généralement plus rapide que qsort.
Modulo que les derniers compilos font du très bon boulot pour les chemins nominaux en cas d'exception -- avec que le code C sera totalement bloated de if pour propager l'erreur (ou alors non robuste, c'est un choix, que celui d'aller vite sans air bag).

Donc vous confirmez il est tout à fait possible de développer au niveau de la couche noyau (voir même plus bas) avec C++ ?!

http://wiki.osdev.org/Main_Page
http://wiki.osdev.org/C%2B%2B

[guillaume07]

Modulo que std::sort est généralement plus rapide que qsort.
Modulo que les derniers compilos font du très bon boulot pour les chemins nominaux en cas d'exception -- avec que le code C sera totalement bloated de if pour propager l'erreur (ou alors non robuste, c'est un choix, que celui d'aller vite sans air bag).


http://wiki.osdev.org/Main_Page
http://wiki.osdev.org/C%2B%2B

je pensais aussi tout bêtement à std::string versus char*

[3DArchi]

Admettons, j'ai nécessité d'utiliser un pointeur dans un programme c++ pour x ou y raison particulière, je ne risque pas de me faire taper dessus par les collègues et me faire traiter d'incompétent car produisant une bouillie C/C++ ?!

En développement embarqué ou système, on utilise souvent des pointeurs en pensant ne pas avoir le choix. Si cela peut être vrai, il y a aussi de nombreux cas où on oublie l'utilité des références :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
typedef uint32_t volatile device_register;
device_register &device = *reinterpret_cast<device_register*>(0xFFFF1000);
//
device = DEVICE_CMD_1;
//
status = device&DEVICE_MSK;
// etc...

cf par expl Memory-mapped devices as C++ classes