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.

Salut,

Citation:

---

Envoyé par oxyaxion

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.

---

Rien ne t'empêche de faire du noyau en C++. Tu peux appuyer ton apprentissage de l'OO non pas en pratiquant avec des applis IHM mais en t'essayant à des applis plus orientés systèmes : gestionnaire mémoire, scheduler, E/S, etc. Bref, avec un peu d'imagination, tu devrais trouver de quoi t'amuser ;)

Citation:

---

Envoyé par oxyaxion

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:

---

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

Citation:

---

Envoyé par Luc Hermitte

Ce n'est pas parce que l'on manipule des abstractions que c'est nécessairement plus lent.

---

tu as un exemple en C++ pour étayer stp ?

Quelques exemples, écrits avec string, je te propose d'écrire les équivalents les plus directs avec char*, voire un peu moins directs, puis on comparera :

Code:

---

1 2 3 4 5 6 7 8 9

string s; char g(int i); // Fonction fournie par l'utilisateur, dont on ne sait rien a priori   char c = g(rand()); while (c != 0) { s += c; // Ici, l'abstraction est une croissance géométrique, permettant un temps amorti constant }

---

Code:

---

1 2 3 4 5

void f(string const &s) { string s2 = s; // Ici, l'abstraction est que si s fait 1 ou 2 caractères, il n'y a pas d'allocation dynamique // On travaille avec s2, le modifiant }

---

Ici je trouve que les string sont bien adapté typiquement

Peux-tu donc à ton tour donner un exemple où tu penses que l'abstraction apportée par les strings pose problème ?

Citation:

---

Envoyé par JolyLoic

Peux-tu donc à ton tour donner un exemple où tu penses que l'abstraction apportée par les strings pose problème ?

---

une application qui reçoit en entrée un flux de chaine de caractère via une socket à un rytme parfois important 100.000 trame / s de chaine 100 caractères en moyenne et qui doit détecter la fin d'une trame pour la passer à une fonction de traitement. Plus le pre-processing est rapide mieux c'est.

Code:

---

1 2 3

tag=value;tag2=value2;END;tag=value;...;END;tag=value;... où tag=value;tag2=value2;END représente une trame

---

on reçoit ça dans un buffer via la socket il n'y a donc pas d'allocation dynamique , un tableau statique est déclarer en amont pour recevoir le buffer, il n'y a pas non plus de concaténation, cas où il est vrai string est pratique

Citation:

---

Envoyé par 3DArchi

Salut,
Rien ne t'empêche de faire du noyau en C++. Tu peux appuyer ton apprentissage de l'OO non pas en pratiquant avec des applis IHM mais en t'essayant à des applis plus orientés systèmes : gestionnaire mémoire, scheduler, E/S, etc. Bref, avec un peu d'imagination, tu devrais trouver de quoi t'amuser ;)

---

C'est tout à fait ce que je cherche à faire, apprendre les mécanismes POO qui possèdent, j'en suis persuadé, d'énormes possibilités disons "créatives" (bon c'est un peu bancal comme terme), qui ne sont pas possible avec le raisonnement impératif qui peut devenir vite compliqué, (parce qu'au fond ce ne sont que deux raisonnement différents) et ceux à tout les niveaux. Pas en l'exploitant vers le haut (ihme) mais plutôt en descendant (système).

C'est fort dommage d'ailleurs que les exemples donnés pour l'apprentissage C++ ne concernent souvent que le développement applicatif.

Je ne donnerai pas mon avis de novice entre string et char*.
Mais pour "défendre" le fait que dans de nombreux cas l'abstraction est utile, rapide et plus performante que de reconstruire la roue je donnerai un exemple bête de mon niveau sous shell.

Je veux lister le contenu de mon répertoire.
A - J'utilise la commande ls qui fonctionne très bien, qui est quasi universelle est qui a été algorithmiquement rodée et optimisée par tout les grands gurus à barbes du C, qui maîtrisent mieux l'environnement que je ne le maitriserai jamais.
B - Je n'en suis pas content et je développe ma propre commande (en C de par exemple tiens). Quelles sont les probabilités que "l'ersatz" pourtant réalisée à la main de A à Z, fasse mieux que l'original en terme de performance pure ?
C'est un exemple bête mais je vois ça comme ça (n'hésitez pas à me corriger si j'vous parais hors sujet). Si des biblio performantes et au p'tits oignons existent en C\++ pour réaliser des tâches complexes pourquoi devrais-je les refaire à la main ? Et cela pour le dev de haut niveau comme pour du dev plus axé système ! Ensuite si j'ai le choix et bien là c'est encore mieux.

Attention je parle bien d'encapsuler des mécanismes complexes et difficiles ou long à cadrer, pas d'encapsuler un mécanisme "simple" qui en plus d'être simple justement offre l'avantage de donner plus d'accès à la machine,dans un tel cas l'encapsulation n'a plus pour effet de faciliter la tâche mais seulement de masquer et de poser un voile sur la méthode et là j'aime moins.

Voilà navré si j'ai été un peu hors sujet sur la fin, merci pour les liens je vais aller voir ça de plus près et vous m'avez convaincus, je vais me lancer avec ++ à la façon OO, pour commencer à jouer un peu avec les E/S et la mémoire par exemple ;)

Citation:

---

Envoyé par guillaume07

on reçoit ça dans un buffer via la socket il n'y a donc pas d'allocation dynamique , un tableau statique est déclarer en amont pour recevoir le buffer, il n'y a pas non plus de concaténation, cas où il est vrai string est pratique

---

Dans ce cas, un string n'apporte probablement pas grand'chose, en effet. Mais une autre abstraction permettrait probablement une meilleure utilisation que l'accès brut à la zone mémoire du buffer. Pas tellement en perfs, mais en simplicité (gestion des dépassements, notion de buffer tournant avec une partie à traitée, une partie recyclable, gestion des locks pour les accès multithreads à ce buffer...).

Citation:

---

Envoyé par JolyLoic

Dans ce cas, un string n'apporte probablement pas grand'chose, en effet. Mais une autre abstraction permettrait probablement une meilleure utilisation que l'accès brut à la zone mémoire du buffer. Pas tellement en perfs, mais en simplicité (gestion des dépassements, notion de buffer tournant avec une partie à traitée, une partie recyclable, gestion des locks pour les accès multithreads à ce buffer...).

---

Pour le dépassement il suffit de créer un tableau d'une taille supérieur ou égal au buffer max qu'une socket peut lire en une passe.

Dans ce style d'application généralement un thread est dédié à la socket, donc pas de mutex à gérer.

Pour le buffer tournant, je ne te suis pas trop ici.

Citation:

---

Envoyé par guillaume07

tu as un exemple en C++ pour étayer stp ?

---

cf les benchmarks de Mr stepanov (lui même) "abstraction penalty benchmark".

Citation:

---

Envoyé par Goten

cf les benchmarks de Mr stepanov (lui même) "abstraction penalty benchmark".

---

ok merci