Qui peut le ++ peut le -- , non ?!

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.

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++.

Citation:

---

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.

Citation:

---

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.

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))

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++ ?!

Citation:

---

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.

Citation:

---

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.

Citation:

---

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++.

Citation:

---

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 :aie:. 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.

Citation:

---

Envoyé par Astraya

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"

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 :aie:

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 :question:

Citation:

---

Envoyé par guillaume07

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).

Citation:

---

Envoyé par 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++ ?!

---

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

Citation:

---

Envoyé par Luc Hermitte

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*

Qui n'a jamais fait parti de la STL :P (mais ... utilise-t-on tant que ça des chaines de caractères dans des noyaux ? [Je n'ai pas la réponse, mais je tendrais à dire: "très peu"])

J'ai réagis car le message généralisait trop.

NB: ce côté de lenteur des std::string sera à reconsidérer avec l'arrivée de C++11. Sans parler des implémentations non conformes comme celle de STLport qui implémente les concaténations avec une double passe qui extrait d'abord la longueur de la chaine finale à allouer.

je suis surpris ici il semble que STD::string fasse partie de la STL

http://www.cplusplus.com/reference/

La STL est une appellation historique pour une lib dont une partie a fini par rejoindre la SL de ce qui devint le C++ 98.
C'est avant tout ça: http://www.sgi.com/tech/stl/ (bien que je crois bien qu'il était chez HP à l'époque)
std::string c'est seulement dans la SL, plus universellement appelée stdlib.

(comment ça je pinaille?)

Citation:

---

comment ça je pinaille?

---

Moi ce que j'ai entendu c'est : "et bla et bla et bla"... :aie: :mouarf:


On ne peut pas vraiment dire que std::string est toujours plus mauvais que char*.

Si je fais un std::string et 100000 copie non modifier, ça sera plus éfficace que de faire 100001 char*.

Si l'on doit réaliser des traitements sur une std::string, les algorithmes standards sont très performant. En faisant un algo maison avec char *, tu pourras atteindre au mieux les performances des algorithmes de la STL.

Et puis des fois c'est bien, des fois c'est pas bien :aie:

Ce ne sont pas des choses à prendre en étant cartésien :roll:

Citation:

---

Envoyé par Luc Hermitte

La STL est une appellation historique pour une lib dont une partie a fini par rejoindre la SL de ce qui devint le C++ 98.
C'est avant tout ça: http://www.sgi.com/tech/stl/ (bien que je crois bien qu'il était chez HP à l'époque)
std::string c'est seulement dans la SL, plus universellement appelée stdlib.

(comment ça je pinaille?)

---

euh..c'est clair, aujourd'hui la STL = toute la SL, plus personne ne parle de SL.
Merci d'avoir émis cette remarque ô combien pertinente.

Citation:

---

Envoyé par Astraya

Moi ce que j'ai entendu c'est : "et bla et bla et bla"... :aie: :mouarf:


On ne peut pas vraiment dire que std::string est toujours plus mauvais que char*.

Si je fais un std::string et 100000 copie non modifier, ça sera plus éfficace que de faire 100001 char*.

Si l'on doit réaliser des traitements sur une std::string, les algorithmes standards sont très performant. En faisant un algo maison avec char *, tu pourras atteindre au mieux les performances des algorithmes de la STL.

Et puis des fois c'est bien, des fois c'est pas bien :aie:

Ce ne sont pas des choses à prendre en étant cartésien :roll:

---

fait des benchmarks toi même et tu verras que char* est plus rapide que std::string et ceci pour des raisons on ne peut plus simples :) :
std::string encapsule un char* et rajoute de la gestion autour l=>overhead.

j'ai l'exemple très simple d'un applicatif qui doit être capable de traiter 100K trame/s, trame qui ont la forme de chaine de caractère, l'emploi de std:string plutôt que de char* change considérablement la donne

Hé bien je vous remercie pour vos réponses très précises (désolé d'avoir sans le vouloir soulevé quelques trolls sur la performance de telle ou telle librairie ce n'était pas mon but) simplement j'étais vraiment dans le brouillard à ce sujet.

En fait j'ai déjà les bases C (algo, prog impérative, pointeur etc ...) posée par mes études et j'ai connaissances d'autres langages impératifs aussi, et j'aurai souhaité évoluer (me forcer à apprendre) la POO. (ça je n'ai jamais vu lors de ma formation initiale).
J'ai essayé en commençant par apprendre avec un livre JAVA, mais j'ai laissé tomber à mi chemin (en fait dés que j'ai découvert pour une récupérer une saisie au clavier il y avait moyen de faire ça par deux bibliothèques extérieurs différentes et que ça prenait 2 à 3 lignes ... mais qu'est ce que c'est que ce langage ... Oo), je ne sais pas mais je n'aime pas ça fait trop "mastondotesque" et le niveau d'abstraction à l'air trop haut pour moi, j'aime lorsqu'on a possibilité de tripoter une peu la machine en fait ... (bon peut être qu'on peut aussi en java mais j'suis pas allé plus loin que les concepts de bases ...).
Le problème est que j'essaie de me spécialiser dans le système informatique disons les "premières couches unix/linux" là où le C (simple) semble Roi.
Enfin c'est la partie qui m'intéresse le plus dans ce domaine qu'est l'informatique (mon entourage dans ce domaine ne cesse de me répéter qu'il est important de se "spécialiser"), mais je me rends bien compte de la puissance d'un paradigme qu'est la POO est j'aimerais en saisir les mécanismes avec un langage qui me permettrait si besoin de revenir en mode algo impératif à l'ancienne, comme le c++. (J'aime le système et j'ai envie d'aimer la POO également mais je n'ai pas envie de faire un p'tit logiciel avec Qt .. mais plutôt mettre les mains dans le noyau ;) )

Donc en fait tout n'est pas si simple ... Et j'ai l'impression qu'il manque un petit frère à C, C++ .. a Quand D ?! Pour remettre tout les puristes C/++ d'accord et enfin repartir sur des bases de développement avec POO / impératifs "saines" une refonte des noyaux en D etc etc ... bon on peut toujours rêver ..
Merci pour toutes vos réponses éclairées.

Citation:

---

Envoyé par guillaume07

euh..c'est clair, aujourd'hui la STL = toute la SL, plus personne ne parle de SL.
Merci d'avoir émis cette remarque ô combien pertinente.

---

Ce n'est pas très template memcpy. Cela fait pourtant de la bibliothèque standard du C++...
EDIT: BTW, relis mon message initial, le pertinent, ce n'est pas ce qui précède le ... smiley.

Citation:

---

Envoyé par guillaume07

fait des benchmarks toi même et tu verras que char* est plus rapide que std::string et ceci pour des raisons on ne peut plus simples :) :
std::string encapsule un char* et rajoute de la gestion autour l=>overhead

---

Cela dépend comment cela sera utilisé. Un naïf strcat (qui aura perdu la longueur de la chaine pourtant connue par ailleurs) sera ainsi plus lent que string::operator+.
Ce n'est pas la gestion autour qui est problématique. C'est le COW et les copies, et les implémentations qui préfèrent les boucles à la main quand on dispose de mieux.

Pour certains use cases, la small string optimisation peut aussi donner avantage aux string sur les char*. Après, il est certain qu'avec des efforts héroïques, on peut obtenir avec des char * aussi bien qu'avec des strings. Pour des efforts de développement raisonnables, c'est autre chose.

Citation:

---

Envoyé par JolyLoic

Après, il est certain qu'avec des efforts héroïques, on peut obtenir avec des char * aussi bien qu'avec des strings. Pour des efforts de développement raisonnables, c'est autre chose.

---

c'est là ou je comprends pas qu'on puisse chipoter, un cas d’utilisation très simple à savoir le parsing d'une chaine de caractère de la forme tag=value;tag2=value2;...;findetrame; est fatalement plus performante avec des char* que des string pour un surcoup de développement ridicule

C'EST DU CONCRET PAS UNE VISION PHILOSOPHIQUE DE CE QUE DEVRAIT ETRE LA PROG , L'ABSTRACTION LE HAUT NIVEAU OU JE SAIS PAS QUOI D'AUTRE

D'où ce genre d'initiatives: http://stlab.adobe.com/group__abi__string.html (et cf aussi le parser SAX 0-copies)
Ce n'est pas parce que l'on manipule des abstractions que c'est nécessairement plus lent.
Le cas général peut l'être par rapport à une utilisation spécifique après, c'est sûr.