Discussion :

[3DArchi]

Salut,

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

[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

[guillaume07]

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 ?

[JolyLoic]

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 :

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

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 :

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

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
}

[guillaume07]

Ici je trouve que les string sont bien adapté typiquement

[JolyLoic]

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

[guillaume07]

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 :

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

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

[oxyaxion]

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

[JolyLoic]

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

[guillaume07]

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.

[Goten]

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

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

[guillaume07]

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

ok merci