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.