Discussion :

[rafat]

Bonjour,
Je viens de poster une question à laquelle Mayti4 a eu la gentillesse de répondre (merci encore), et après réflexion et une remise à l'étrier depuis quelques jours, je m'en pose une autre.

En tant qu'étudiant, nos profs nous avaient présenté le Pascal, Fortran et Latex comme des outils de création classique. Par là je veut dire des présentation comme "bon, ce problème est à résoudre pour la semaine prochaine, le compilateur xxxx est sur votre compte vax (ou autre)".
Ensuite la création, bien que laborieuse au début, se faisait via quelques docs épars (internet n'en n'était qu'à ses débuts fin 80 début 90), mais le gros du travail restait le bon fonctionnement du résultat à atteindre. L'apprentissage ne représentait que 20-30% tu temps et de l'effort. Comme je faisais des maths le but n'était pas de faire de la programmation, mais de créer des algorithmes, la programmation en suivait naturellement.

Quelques années plus tard j'ai été confronté à l'Objet, pas en tant que
défi, mais en tant qu'une nouvelle (et plus simple / logique) approche au développement. D'abord via VB, que j'ai trouvé excessivement simple à utiliser, créant un prog de maths facilement (en tant que contexte de formation perso) et appréciant la facilité de créer des interfaces graphiques.

Dans la foulée j'ai approché les MFC, sachant que c'était la façon C++ de faire des IHM. J'en ai été très rapidement dégoûté, constatant qu'il fallait beaucoup d'effort pour faire des choses simples (plusieurs 100aines de Ko pour une fenêtre, code créé par VS afin de "simplifier" les choses ).

Le C a été relativement simple, les struct étant assez logiques, les pointeurs un peu moins. Je comprend à peu près leur utilité dans le concept de la gestion dynamique de l'information, mais n'en n'ai jamais réellement eu besoin.

Puis est venu le C++.
Là je dois dire que je ne comprends plus. Autant la nature atomique de l'assembleur me paraît un mal nécessaire puisque nous faisons appel au langage "mathématique" de base du proc, autant la difficulté d'apprentissage du C++ me paraît absurde.

Je m'explique : le concept de l'objet, les classes et leur puissance, ok, je vois en quoi cela est utile pour de gros codes : par expérience faire un prog de plusieurs 1000ers ou 10aines/100aines de milliers de lignes (typique pour les codes de calculs scientifiques - mon domaine) devient très lourd à gérer. La structure de gestion de l'information fournie par le C++ me paraît alors bonne et intelligente (je ne suis pas paternaliste ou arrogant ici), cependant même en lisant des livres sur le C++, comme LE PROGRAMMEUR ou le Soustrup, je ne vois pas ni comment ni pourquoi associer un nom de string - ligne - à c_str(). Je comprends que c_str() est une fonction de la classe string appelée ligne (je crois que c'est çà) mais comment puis-je le savoir ? Où puis-je trouver une liste / description des classes et leur fonctions associées?

Mon problème n'est pas tant d'ecrire un algo, çà je sais le faire depuis belle lurette, mais quels sont les outils / fonctions/ mots-clés disponibles et comment fonctionnent-ils?

Sous VB les "dépendances" sont fournies quand on écrit le code, où puis-je trouver ces éléments ? Passer 3 jours pour lire un texte et l'utiliser comme nom de fichier en C++ est hallucinant.

Je sais maintenant que ligne.c_str() fait le job, mais je ne sais toujours pas pourquoi, c'est-à-dire ce que fait c_str(), ni qu'elles sont les autres fonctions associées à ligne ni comment les utiliser.

Et je dois dire que lire 1600 pages avant de pouvoir commencer est décourageant (j'exagère bien sûr). Dans tous les autres languages, pour chaque tâche il était possible de trouver quelques lignes de code qui donne en deux temps trois mouvements la façon de faire les choses. Dans ces 1600 pages je n'ai trouvé que de la théorie qui renvoyait à d'autre méthodes théoriques qui renvoyaient à .....

Je sais que le C++ est un langage difficile, mais je pense que c'est surtout dû au changement de paradigme de programmation, on ne peut plus coder linéairement, mais réfléchir aux liens abstraits entre les différents éléments d'information et d'autres affaires de gestion de mémoire etc, mais ceci n'a rien à voir avec savoir quels sont les outils et comment les utiliser afin de coder suivant ce paradigme.

Pour ma part ce n'est pas - en tout cas je ne pense pas que ce le soit - la façon de réflechir à la codification, mais comment j'utilise quoi pour le faire.

Ex : en fortran pour lire le contenu d'un fichier on utilise open, puis on donne le nom du fichier, puis on lui attribue un chiffre de référence. Ensuite pour ecrite ou lire on utilise read ou write puis le chiffre, puis un autre chiffre de référence de format (si on veut) puis la variable contenant l'info.
en C++ il faut ouvrir, ce qui est l'apprentissage d'une autre syntaxe, ifstream, mais ensuite il faut savoir que c_str() existe et comment on l'utilise.

Alors j'obtiens des réponse du style : lit stl, ou : tout çà c'est dans la bibliothèque, etc ...

Je comprend que pour être pro il faille 3 ans, mais pour faire des choses simples, quelques jours devraient suffire non ? Surtout si on a plusieurs années de dev derrière soi.

Donc voilà, ce que je cherche et espérais trouver dans ces bouquins est non seulement la théorie (que je trouve très utile), mais aussi des "recettes" pour faire des choses simples afin d'apprendre rapidement. La compréhension de fond des choses arrivera plus tard, une fois le fonctionnement maitrisé.
On n'apprends pas une langue (humaine) en ouvrant un livre, mais en le baragouinant au départ et en étant soumis à nombre d'exemples, en testant, en se plantant, mais en comprenant grosso modo comment çà marche. L'autonomie çà vient après.

Un exemple de mon état de frustration (pour ceux qui connaissent): une personne demande comment on peu prévoir la météo, je réponds : apprends les EDP.
Je comprendrais parfaitement que sa réponse soit du genre : pourquoi? Quel rapport? Et qu'est-ce ?
Et bien c'est truc machin chouette.
Ok, et alors ??
etc ...
Autrement dit je lui demande de comprendre, plutôt que de donner l'info mathématique en disant comment l'utiliser. Une fois que çà "tourne" il pourra, si çà lui chante, approfondir.

Bon j'arrète là. Je remercie encore celles et ceux qui participent et fournissent de l'info à des pauvre âmes un peu paumées comme moi, et j'espère devenir assez compétent rapidement pour faire de même, comme je le fais dans d'autres domaines.

Commentaires appréciés.

[Matthieu Brucher]

Pas tout compris...

L'orienté objet sert principalement à la modularité et donc à la réutilisabilité. Ensuite, le C++ n'est pas compliqué à apprendre, même s'il est vrai que certains fichiers d'en-tête peuvent être obscur, mais en général, on trouve rapidement sur Internet un site qui explique l'un ou l'autre en-tête - chez G++, il y a une doc sur tout ce que contiennent leurs en-têtes -, et ensuite si on ne comprend pas pourquoi on appelle une méthode plutôt qu'une fonction libre, c'est au comité de standardisation qu'il faut poser la question

[DaZumba]

En tant qu'étudiant, nos profs nous avaient présenté le Pascal, Fortran et Latex comme des outils de création classique.

Si tu etais etudiant en mathematiques (en sciences, plus generalement), c'est normal. Mais cela ne s'applique pas a d'autres domaines.

L'apprentissage ne représentait que 20-30% tu temps et de l'effort. Comme je faisais des maths le but n'était pas de faire de la programmation, mais de créer des algorithmes, la programmation en suivait naturellement.

Le Fortran a justement ete cree pour faciliter la traduction des formules mathematiques et physiques en programme informatique. Il a donc ete concu pour ne pas etre surprenant et ne pas laisser trop de liberte au programmeur. Le C et le C++ ont des objectifs differents.

Quelques années plus tard j'ai été confronté à l'Objet, pas en tant que
défi, mais en tant qu'une nouvelle (et plus simple / logique) approche au développement.

Personnellement, en tant que chercheur, je ne suis pas convaincu que l'orientation objet s'applique si bien que cela aux sciences. Mon domaine est la climatologie (ou un modele fait environ 700.000 lignes de code effectives, en Fortran et en C). Je vois mal un modele de climat comme un groupe d'objets qui s'envoient des messages. Par contre, une suite de processus physiques intervenant les uns apres les autres, ca d'accord. L'approche procedurale est donc tout a fait d'actualite (note que cela n'exclut pas le C++, qui ne force pas l'orientation objet). Cela depend des applications, evidemment : je comprend qu'un developpeur de jeux video utilise une approche orientee objet, car cela est tres adapte a son probleme.

Dans la foulée j'ai approché les MFC, sachant que c'était la façon C++ de faire des IHM.

MFC signifie Microsoft Foundation Classes. Elles sont la pour faciliter l'interaction avec l'API Windows, mais n'ont rien a voir avec le C++ standard.

Le C a été relativement simple, les struct étant assez logiques, les pointeurs un peu moins. Je comprend à peu près leur utilité dans le concept de la gestion dynamique de l'information, mais n'en n'ai jamais réellement eu besoin.

C'est etonnant. Tu n'as jamais ecrit une fonction C qui modifie les arguments qu'elle recoit? Car les pointeurs sont indispensables dans un tel cas.

Puis est venu le C++.

C'est la que je ne suis plus. Tu as l'air de faire une hierarchie entre les langages, passant du Fortran, au VB, au C, puis au C++. Pourquoi? Je programme en Fortran et en C mais je ne fais pas la meme chose avec ces deux langages. Le Fortran est le langage naturel de programmation scientifique, les compilateurs sont excellents et les bibliotheques disponibles sont bonnes. Le C est meilleur pour les operations I/O, la gestion de la memoire et (s'il est besoin), les interfaces graphiques et les appels systemes. Un melange des deux est donc tres adapte a mon application. Je ne vais pas aller voir ailleurs pour le plaisir de me compliquer la vie (dans mon travail, s'entend - pour les loisirs, c'est different).

Mon problème n'est pas tant d'ecrire un algo, çà je sais le faire depuis belle lurette, mais quels sont les outils / fonctions/ mots-clés disponibles et comment fonctionnent-ils?

Ca c'est typiquement de l'apprentissage d'un langage nouveau. Ca ne s'improvise pas et il faut mettre le pied a l'etrier. Le C prend au moins de six mois de travail avant de pouvoir faire quelque chose de serieux avec. Le C++, qui est un langage plus gros et plus complexe, demande plus de travail. Je pense que tu as oublie le travail que tu as du faire pour apprendre le Fortran (et notamment le standard 77!).
Ensuite, tu cites le VB. C'est tout different. C'est un langage plus simple (c'est tout de meme base sur le Basic) qui a pour but d'etre facile et rapide a maitriser. Mais il n'est pas adapte a toutes les applications.

[rafat]

Le Fortran a justement ete cree pour faciliter la traduction des formules mathematiques et physiques en programme informatique. Il a donc ete concu pour ne pas etre surprenant et ne pas laisser trop de liberte au programmeur. Le C et le C++ ont des objectifs differents.

Je ne parlais pas de "traduction" de formules - c'était juste le contexte - mais de la programmation per se. Une boucle for ou un while, ou des sous-routines sont aussi surprenantes dans n'importe quel language et pour n'importe quel contexte pour un non-programmeur, ce que nous étions. Mais ce n'est pas parce que nous étions étudiant en maths que cela (la programmation) nous était "facilité".
D'ailleurs, bien que la quasi totalité des codes scientifiques soient en fortran, le c/c++ devient de plus en plus présent en sciences.

Quand aux objectifs du C C++, en tant que langages "génériques" se doivent d'être aussi "valables" et sont d'ailleurs plus choisis, que les fortrans. Dans le domaine de la Défense par ex, le c est choisi pour sa rapidité de calcul.
Honnètement je ne vois que le c(++) ou dérivés pour tous les domaines : banque, finance, sciences, industrie,...

En quoi les objectifs du c(++) sont-ils différents ?

Personnellement, en tant que chercheur, je ne suis pas convaincu que l'orientation objet s'applique si bien que cela aux sciences. Mon domaine est la climatologie (ou un modele fait environ 700.000 lignes de code effectives, en Fortran et en C). Je vois mal un modele de climat comme un groupe d'objets qui s'envoient des messages. Par contre, une suite de processus physiques intervenant les uns apres les autres, ca d'accord. L'approche procedurale est donc tout a fait d'actualite (note que cela n'exclut pas le C++, qui ne force pas l'orientation objet). Cela depend des applications, evidemment : je comprend qu'un developpeur de jeux video utilise une approche orientee objet, car cela est tres adapte a son probleme.

Personnellement, je dirais que l'approche Object ne présente rien qui l'empêcherait de faire ce que le fortran fait, sur un point de vue de principe.
Je ne dit pas que cela donnerait un avantage quelconque, mais cela ne présenterait pas d'incompatibilité. En revanche cela imposerait une contrainte "d'organisation" de développement pour les scientifiques pour qui le but est de résoudre un problème, pas de gérer la fluidité du transfert d'info.

MFC signifie Microsoft Foundation Classes. Elles sont la pour faciliter l'interaction avec l'API Windows, mais n'ont rien a voir avec le C++ standard.

Je sais, c'est pour cela qu'elles n'existent pas sous linux par exemple (ce qui serait ironique . Cela n'empêche pas que si VB permet des constructions d'IHM facilement (Delphi aussi d'ailleurs), pourquoi pas C++? Jamais compris çà.

C'est etonnant. Tu n'as jamais ecrit une fonction C qui modifie les arguments qu'elle recoit? Car les pointeurs sont indispensables dans un tel cas.

Si, mais je ne pense pas avoir une idée très claires là-dessus. Je pense que dans la majorité des cas, j'ai le réflexe de faire autre chose sans utiliser les pointeurs, mais qui revient à faire ce qu'ils font. C'est sans doute du temps perdu mais cela m'est plus naturel.
J'utilise les pointeurs si c'est vraiment nécessaire pour la syntaxe, comme ouvrir un fichier.
J'avoue devoir travailler ce point(eur) .

C'est la que je ne suis plus. Tu as l'air de faire une hierarchie entre les langages, passant du Fortran, au VB, au C, puis au C++. Pourquoi?

Aucune. Il s'avère que je les ai rencontré dans cet ordre chronologique.
Si tu veux aller dans cette direction, j'ai commencé par Basic, assembleur, pascal ...

Je programme en Fortran et en C mais je ne fais pas la meme chose avec ces deux langages. Le Fortran est le langage naturel de programmation scientifique, les compilateurs sont excellents et les bibliotheques disponibles sont bonnes.

D'accord avec toi. Je ne comprends d'ailleurs pas pourquoi Linux Mandriva 2006 ne l'inclut plus dans gcc. Très bête.

Le C est meilleur pour les operations I/O, la gestion de la memoire et (s'il est besoin), les interfaces graphiques et les appels systemes. Un melange des deux est donc tres adapte a mon application. Je ne vais pas aller voir ailleurs pour le plaisir de me compliquer la vie (dans mon travail, s'entend - pour les loisirs, c'est different).

Pour les IHM, d'accord, le fortran n'est pas "pas bon", il ne sait tout simplement pas faire. Pour le reste il ne m'a jamais posé de problème. Pour ma part travailler avec plusieurs langages aurait tendance à me compliquer la vie, sauf pour les IHM (et je n'ai pas encore résolu le problème de faire un prog fortran avec IHM).

Ca c'est typiquement de l'apprentissage d'un langage nouveau. Ca ne s'improvise pas et il faut mettre le pied a l'etrier. Le C prend au moins de six mois de travail avant de pouvoir faire quelque chose de serieux avec. Le C++, qui est un langage plus gros et plus complexe, demande plus de travail. Je pense que tu as oublie le travail que tu as du faire pour apprendre le Fortran (et notamment le standard 77!).

Ce n'est pas la même chose, je crois. Avec le Fortran on doit bosser pour l'apprendre, c'est clair, cependant il est plus simple d'approche. D'une part par sa sémantique et syntaxe : il n'y a pas 36 façons de faire les choses et celles-ci sont en "anglais", alors que pour le c(++) tu peux écrire 10 lignes en une seule ce qui rend le code illisible, et d'autre part il n'y a pas de dépendances sauf si tu les crées. Tu es au contrôle car tu as tout défini.
Le c(++) possède tout un arsenal de dépendances que l'on doit apprendre à connaitre avant de coder. Et c'est un peu mon problême.

Enfin, comme je l'ai dit : bien qu'ayant déjà touché à la chose je connais la théorie mais pêche beaucoup par la pratique.

Ensuite, tu cites le VB. C'est tout different. C'est un langage plus simple (c'est tout de meme base sur le Basic) qui a pour but d'etre facile et rapide a maitriser. Mais il n'est pas adapte a toutes les applications.

Mais le basic n'est qu'un "jeu" de mots, moins étendu que d'autres langage, mais son apprentissage n'a été facile que parceque l'interface VS fournit toute l'info. Je n'irais pas écrire un code de calcul en VB pas parcequ'il ne possède pas de pointeurs ou de polymorphisme etc ... mais parcequ'il est lent et peu précis entre autres.

Le C++ impose une pente d'apprentissage initiale très forte : il faut beaucoup de théorie avant de faire quoi que ce soit.

Dans LE PROGRAMMEUR C++, on commence à toucher au c++ au chapitre 5, page 122.
Tu dois faire plus de 100 pages de programmation de base avant de voir les surcharges de fonctions.

Pour le moment je dois pouvoir extraire d'un string des mots qui sont entre des virgules. D'entrée de jeu je ne sais pas comment faire çà. Il va donc falloir que je me plonge dans comment je dois savoir quoi pour faire ce que je veux, Plutôt que ok j'ai la commande ou la logique, maintenant utilisons çà pour le faire (après multiples essais de plantage bien sûr).

Donc ma question reste : comment sait-on quelles sont les fonctions disponibles, à quoi elles servent, comment on s'en sert et quelles sont leurs dépendances?

[DaZumba]

En quoi les objectifs du c(++) sont-ils différents ?

Ils sont fait pour etre performants (une notion un peu floue, il faut l'admettre), portables (au niveau source, pas au niveau binaire), permettre des constructions de haut et de bas niveau, et generalistes.

Personnellement, je dirais que l'approche Object ne présente rien qui l'empêcherait de faire ce que le fortran fait, sur un point de vue de principe.

Le Fortran 90 et 95 incluent maintenant des facilites pour l'orientation objet. Mais si on considere que l'approche objet n'apporte pas d'avantage a un projet scientifique, sachant que, comme tu le notes, cela demande une reorganisation profonde du code et de la facon de penser l'architecture en general, je me demande si cela en vaut la peine.

Cela n'empêche pas que si VB permet des constructions d'IHM facilement (Delphi aussi d'ailleurs), pourquoi pas C++? Jamais compris çà.

Parce qu'une interface depend du systeme sur lequel elle tourne. On n'ouvre pas une fenetre de la meme facon sous Linux et Windows. Comme C et C++ ont choisit d'etre portables, ils n'ont pas inclus les capacites qui les feraient dependre d'une plateforme particuliere (apres tout, un programme C standard doit pouvoir tourner sur une machine a laver ou un supercalculateur, ou la notion d'interface est tres differente de celle d'un ordinateur personnel). Mais des bibliotheques tierces, comme Qt ou GTK, par exemple, permettent de faciliter l'interaction avec le systeme en ajoutant une couche d'abstraction supplementaire entre toi et l'API. Elle se veulent generalistes, cependant, donc l'abstraction ne sera pas aussi elevee que des langages de tres haut niveau. Il va falloir faire plus de choses soi-meme, ou utiliser les bibliotheques faites par des gens qui ont rencontre les memes problemes que toi.

Donc ma question reste : comment sait-on quelles sont les fonctions disponibles, à quoi elles servent, comment on s'en sert et quelles sont leurs dépendances?

Un livre de C++ regroupe en general les fonctions de reference, sinon il y a les man pages, MSDN dans une certaine mesure, les tutorials, ... et les reponses des contributeurs de developpez.com!

[Pragmateek]

Il y a plusieurs sites qui références les différentes classes avec leurs données membres et méthodes comme par exemple:
http://www.cppreference.com/

Pour le moment je dois pouvoir extraire d'un string des mots qui sont entre des virgules.

Il n'y a pas à priori de méthode de la classe "std::string" qui fasse cela automatiquement.
Par exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
size_t split(std::string s,char c,std::vector<std::string>& v)
{
	size_t i=0,j=0,nbr=0;
 
	while((j=s.find(c,i))!=std::string::npos){
		v.push_back(s.substr(i,j-i));
		i=j+1;
		nbr++;
	}
 
	nbr++;
	v.push_back(s.substr(i));
 
	return nbr;
}

[Matthieu Brucher]

Mais si on considere que l'approche objet n'apporte pas d'avantage a un projet scientifique, sachant que, comme tu le notes, cela demande une reorganisation profonde du code et de la facon de penser l'architecture en general, je me demande si cela en vaut la peine.

Oui, oui, et oui, ça en vaut la peine car la réutilisabilité est largement plus importente.

[rafat]

Il y a plusieurs sites qui références les différentes classes avec leurs données membres et méthodes comme par exemple:
http://www.cppreference.com/

merci

Il n'y a pas à priori de méthode de la classe "std::string" qui fasse cela automatiquement.
Par exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
size_t split(std::string s,char c,std::vector<std::string>& v)
{
	size_t i=0,j=0,nbr=0;
 
	while((j=s.find(c,i))!=std::string::npos){
		v.push_back(s.substr(i,j-i)); 
		i=j+1;
		nbr++;
	}
 
	nbr++;
	v.push_back(s.substr(i));
 
	return nbr;
}

ooooookkkkkééééééé!!!!!!!!!!!!!
Je ne pensais pas qu'il existe une façon pré-établie de le faire.
Je te remercie pour le code. Je vais voir si je peux l'adapter à mon cas où
j'ai tout simplement un string Ligne qui contient le texte.
Merci

[rafat]

Oui, oui, et oui, ça en vaut la peine car la réutilisabilité est largement plus importente.

Sur un point de vue technique oui.
Maintenant, en ce qui concerne celui ou celle qui va signer le chèque .... faut déjà prouver que le code est important. J'ai déjà vu des sociétés sacrifier des projets de ce style dits "important" parceque cela coûtait moins cher de ne pas savoir faire quelque chose de façon efficace.
Mais c'est un autre débat.

[Matthieu Brucher]

C'est surtout très con pour l'avenir, parce que du code écrit dans un projet peut être réutilisé dans un autre, d'où gain de temps et donc d'argent, sans compter moins de bugs, ...

[DaZumba]

C'est surtout très con pour l'avenir, parce que du code écrit dans un projet peut être réutilisé dans un autre, d'où gain de temps et donc d'argent, sans compter moins de bugs, ...

Une fonction en programmation procedurale peut etre re-utilisable facilement si elle ne depend pas du contexte. Mais j'admet que l'orientation objet pousse le concept plus loin. Ceci dit, le changement d'architecture du code est important, et je persiste a penser que l'orientation objet n'est pas applicable a tous les problemes. Une programmation procedurale est parfois superieure. Mais c'est un autre debat, en effet.

Edit: et j'arrete de polluer le forum C++, promis !

[Matthieu Brucher]

Une fonction en programmation procedurale peut etre re-utilisable facilement si elle ne depend pas du contexte. Mais j'admet que l'orientation objet pousse le concept plus loin. Ceci dit, le changement d'architecture du code est important, et je persiste a penser que l'orientation objet n'est pas applicable a tous les problemes. Une programmation procedurale est parfois superieure. Mais c'est un autre debat, en effet.

Je suis partisan des 2 car les fonctions, à partir du moment où elles sont génériques, peuvent étendre les capacités d'un module.
En revanche, l'orienté objet apporte des possibilités que le procédural ne peut proposer sans implémenter un ersatz d'orienté objet - tout ce qui concerne l'héritage, par exemple -

[Pragmateek]

Sinon pour trouver les sous chaines dans une string il y a aussi cette méthode:
http://c.developpez.com/faq/cpp/?pag...#STRING_tokens

[rafat]

[QUOTE=seriousme]Il y a plusieurs sites qui références les différentes classes avec leurs données membres et méthodes comme par exemple:
http://www.cppreference.com/

J'ai oublié de dire MERCI . C'est exactement ce que je cherchais, en tout cas pour le moment.

[koala01]

Salut,

A vrai dire, l'orienté objet n'a vraiment que pour but de permettre de conceptualiser quelque chose d'aussi abstrait qu'un programme comme ce qui se passe dans la vie de tous les jours...

Quand tu regardes autour de toi, tu es entouré d'objets (disons même de "choses" pour inclure le domaine vivant) dont les informations et l'utilité/utilisation sont intimement liées.

Tout comme il ne te viendrait pas à l'idée d'utiliser une tasse pour enfoncer un clou, et encore moins la tete de ta femme (quoi, que... en y réfléchissant bien... heu, bon, je m'écarte du sujet ), le concept orienté objet permettra de s'assurer, du moins s'il est bien implémenté que tu ne tenteras pas d'utiliser des informations d'une manière qui ne leur convient pas...

Sans aller jusqu'à prétendre que tout doit être géré comme tel, il est vrai que ca apporte pas mal d'avantages.

Maintenant, et c'est là l'une de ses grandes forces, le C++ autorise tout aussi bien une programmation séquentielle classique qu'une programmation orientée objet.

Si tu estimes que dans tel cas, l'orientation objet est nécessaire, tu l'utilises, mais si tu estime que la programmation séquentielle fonctionnera tout aussi bien, libre à toi...

Pour le reste, il faut effectivement bien admettre que le C et le C++ comptent parmis les langages les plus déroutants à appréhender... C'est malheureusement le prix à payer pour un langage performant et utilisable en toutes circonstances...

[Matthieu Brucher]

A vrai dire, l'orienté objet n'a vraiment que pour but de permettre de conceptualiser quelque chose d'aussi abstrait qu'un programme comme ce qui se passe dans la vie de tous les jours...

Pas tout à fait d'accord. Le principal but de l'orienté objet est bien de permettre la modularité et la réutilisabilité.

[koala01]

Pas tout à fait d'accord. Le principal but de l'orienté objet est bien de permettre la modularité et la réutilisabilité.

Tout en liant intimement les données avec leur utilisation, ce qui est la base de la modularité...

Quand tu crées une classe, peut etre sans même t'en appercevoir, tu lie intimement les méthodes de la classe avec ses membres.

Hormis pour les classes réellement génériques, le plus souvent abstraites d'ailleurs, les méthodes de la classe n'ont généralement qu'un seul but: utiliser les membres de manière adéquate, c'est en cela que l'orientation objet tend à proposer une manière de conception "proche de la vie courrente" (cf mon exemple).

Je reconnais, ceci dit, que le raccourcis était un peu osé et qu'il aurait mérité une explication plus poussée... La voilà donnée

[Matthieu Brucher]

Tout en liant intimement les données avec leur utilisation, ce qui est la base de la modularité...

Quand tu crées une classe, peut etre sans même t'en appercevoir, tu lie intimement les méthodes de la classe avec ses membres.

Hormis pour les classes réellement génériques, le plus souvent abstraites d'ailleurs, les méthodes de la classe n'ont généralement qu'un seul but: utiliser les membres de manière adéquate, c'est en cela que l'orientation objet tend à proposer une manière de conception "proche de la vie courrente" (cf mon exemple).

Je reconnais, ceci dit, que le raccourcis était un peu osé et qu'il aurait mérité une explication plus poussée... La voilà donnée

Les classes génériques abstraites, c'est pas forcément le plus judicieux ni le plus utile.

Ce que tu dis, c'est que l'encapsulation est la raison d'être de l'orienté objet, en gros, alors que ce n'est qu'une raison parmi d'autres plus importantes, tandis que la modularité et la réutilisation sont ce qui a fait que l'orienté objet propose aussi l'héritage, la généricité, ...
La modularité n'impose pas des données liées à leur utilisation - regarde du côté de Boost.Graph pour voir le concept de modularité et de réutilisabilité poussé dans ses retranchements sans la moindre méthode membre -, c'est plutôt l'encapsulation.

[koala01]

Les classes génériques abstraites, c'est pas forcément le plus judicieux ni le plus utile.

on est bien d'accord là dessus aussi

Ce que tu dis, c'est que l'encapsulation est la raison d'être de l'orienté objet, en gros, alors que ce n'est qu'une raison parmi d'autres plus importantes, tandis que la modularité et la réutilisation sont ce qui a fait que l'orienté objet propose aussi l'héritage, la généricité, ...

Au risque de dire un bêtise (après tout, un échange d'idée constructif est toujours une bonne chose) dans quelle mesure l'encapsulation n'est-elle pas la condition sine qua non à toutes les autres?

Dans quelle mesure pourrait-on parler de modularité, de réutilisation et d'héritage, par exemple, sans l'encapsulation?

Dans quelle mesure une condition sine qua non n'est-elle pas la première chose à faire comprendre?

Quand tu parle de ta "tasse en verre", finalement, c'est très proche d'un objet qui hérite des caractéristiques d'une tasse et du verre (par opposition au marteau, qui n'est ni un contenant ni en verre)

Et elle n'aurait jamais pu hériter de ces caractéristiques si on n'avait pas trouver le moyen de créer le verre (une belle lapalissade, ca, non ? )

Je me rend compte que je prend, vraissemblablement, le problème à l'envers, et que l'encapsulation n'a sans doute été imaginée que comme "un outil indispensable (ou, à défaux, tres utile)" à l'élaboration des autres concepts, mais, selon moi, il est plus facile de faire comprendre l'utilité d'une chose en changeant de point de vue et en "élagant" tout ce qui peux nuire à la compréhension, quitte à y revenir par la suite.

Si l'on veut persuader quelqu'un de l'utilité de quelque chose, n'est il pas intéressant de lui montrer l'utilité qu'il en as?

Bien sur, le but est la modularité et la réutilisabilité du code, et au final, un gain de temps à la conception.

Bien sur, il est important d'en faire prendre conscience aux gens, mais ce n'est pas en leur fournissant des arguments tels que "ton code sera réutilisable", surtout s'ils débutent dans la programmation, ou dans l'orienté objet, et qu'ils n'ont "jamais eu besoin" de réutiliser un code précédemment (à mettre entre très gros guillemets, on s'entend bien ) que tu les convaincras du bien fondé du concept

Ceci dit, je n'émets là qu'un avis strictement personnel, mais je le partage...

[Luc Hermitte]

Diverses choses.

Tout d'abord, il me semble que tu as pris un mauvais départ. La référence la plus plébicité sur l'apprentissage du C++ est le non traduit Accelerated C++ par Koenig et Moo chez Addisson-Wesley (comme d'hab). Avec tu ne pourras pas dire qu'il faut attendre la moitié du bouquin pour aborder le langage C++ et sa bibliothèque standard.
Le sujet "de comment démarrer en C++" a déjà été maintes fois débattu, je te laisse consulter les archives -- histoire d'épargner mon pauvre 56k.

Ensuite, le C++ ne se limite pas à l'orienté objet. Je doute que cela aurait suffit à ce que je cherche à l'approfondir.

De plus, l'OO, c'est bien des choses différentes. Les deux principales pour moi sont :
- l'abstraction -- je sais, vous parlez tous d'encapsulation. Je vois pour ma part l'encapsulation comme le détail d'implémentation qui permet de mettre en oeuvre l'abstraction dans le paradigme OO. C'est certes simpliste. En plus il y a un petit côté "redite" (le terme exact m'échappe) vu que l'encapsulation est un détail d'implémentation qui sert à ... cacher d'autres détails d'implémentation.

- la substituabilité afin de "se faire utiliser en place de". C'est le polymorphisme d'inclusion ("de premier ordre" ?) façon LSP que l'on connait bien en C++, Java, Eiffel, ... La "réutilisation de code" est, je trouve, un très mauvais argument marketing qui passe à côté de l'essence même du paradigme OO. Très mauvais, car on sait faire sans sortir d'objets, et le newbye risque de sortir des héritages là où ils seraient mal venus. C'est malheureusement un des arguments que l'on retrouve un peu trop souvent, un héritage des années 80-90 ?


Enfin. J'ai l'impression que vous ne parlez pas vraiment de la même chose concernant la généricité. Dans le contexte du C++, on entend la même généricité que celle de l'Ada et de l'Eiffel : celles des Types Abstraits de Données et autre polymorphisme paramétrique. En C++, on fait ça avec les template. Si tu regardes la partie C++ de la SL, 99% de ce sous ensemble de la SL doit être templatisé, et seulement un sous-ensemble contient de l'héritage et des classes abstraites : la sous-partie sur les flux d'E/S.
Tout ça pour dire, qu'en C++, la généricité au sens TAD est complètement décorrélé de l'aspect polymorphisme d'inclusion du paradigme objet.

Pour terminer. Je n'aime pas trop cppreference. Essentiellement parce que c'est très incomplet. Mes références, en-ligne, préférées sont :
- la doc de la SL de Roguewave pour les tuto, en particulier pour tout ce qui touche aux flux
- la doc de la SL de Dinkumware pour de la référence brute : pour quand on recherche les fonctions membre des classes standard et leur signatures
- la doc de la STL de SGI pour des spécs plus formelles sur le sous-ensemble historique STL de la SL.