Remarque en passant : il faut faire attention à bien vérifier que le nombre d’arguments ne dépasse pas la taille du tableau, sinon tu vas te retrouver avec un joli buffer overflow qui risque de donner l’accès à toute ta machine si jamais le programme est exécuté en root.
Je ne sais plus comment on fait pour s’assurer de ça, mais ça se trouve sur le net.
C’est rigolo un cours de C++ qui ne contiens pas de chapitre sur l’orientation objet. 
Vouloir faire du fonctionnel c’est bien mais le C++ est tout de même un langage Objet avant d’être un langage fonctionnel (pour peu qu’il en soit un).
Edit : pour moi le document qui en parle bien c’est tout de même celui-ci :
www2.research.att.com/~bs/new_learning.pdf
+1…
Le C et le C++ n’ont finalement pas grand chose à voir quand on sait ce qu’est l’approche objet, si ce n’est leur syntaxe. Si on n’a pas conçu de modèle objet avant de programmer en C++ (au moins dans sa tête, même si c’est toujours déconseillé), aucun intérêt à l’utiliser.
Mine de rien, la notion d’objet simplifie beaucoup la programmation. C’est un peu comme fabriquer des éléments qui pourront interagir entre eux, comme si le programme devenait composé de petits modules. Enfin, je vois surtout ça utile pour les gros programmes.
Sympa le document! en anglais, mais sympa! merci!
Absolument ! Mais pour ça il faut d’abord bien assimiler le concept de l’orienté objet dans son ensemble, bien étudier ses tenants et aboutissants, et aussi maîtriser un modèle tel qu’UML (enfin c’est mon avis).
Donc pour l’instant j’en suis encore à l’étude de la théorie de l’orienté objet, j’apprendrais le C++ seulement après, car je pense qu’une fois qu’on est capable de bien modéliser son programme, la syntaxe du langage n’est plus grand chose (en tout cas c’est ce que j’ai vécu avec la méthode MERISE pour les bases de données, je n’ai pas vraiment de problème à utiliser les SGBDR à partir du moment où je sais interpréter un schéma relationnel).
@MisterFreez, Cluxter
L’objectif n’est pas l’apprentissage du concept/paradigme objet, ni même un processus de réalisation mais le langage C++ avec une approche dé-corrélée du C comme peuvent le faire beaucoup d’ouvrage, site … puisqu’il s’agit effectivement de 2 langages distincts.
+1
[quote=“Totor”]@MisterFreez, Cluxter
L’objectif n’est pas l’apprentissage du concept/paradigme objet, ni même un processus de réalisation mais le langage C++ avec une approche dé-corrélée du C comme peuvent le faire beaucoup d’ouvrage, site … puisqu’il s’agit effectivement de 2 langages distincts.[/quote]
Je vois pas ce qui, dans cet objectif, empêche de parler de la programmation objet. C’est quelque chose qui s’adresse à des non-programmeurs et il n’y a pas de chapitre sur les classes. Pour donner un exemple il décris ce qu’est une fonction.
[quote=“Cluxter”]Absolument ! Mais pour ça il faut d’abord bien assimiler le concept de l’orienté objet dans son ensemble, bien étudier ses tenants et aboutissants, et aussi maîtriser un modèle tel qu’UML (enfin c’est mon avis).
Donc pour l’instant j’en suis encore à l’étude de la théorie de l’orienté objet, j’apprendrais le C++ seulement après, car je pense qu’une fois qu’on est capable de bien modéliser son programme, la syntaxe du langage n’est plus grand chose (en tout cas c’est ce que j’ai vécu avec la méthode MERISE pour les bases de données, je n’ai pas vraiment de problème à utiliser les SGBDR à partir du moment où je sais interpréter un schéma relationnel).[/quote]
C’est beaucoup se prendre la tête je trouve. Pour moi au fur et à mesure de l’apprentissage, il faut que j’applique ce que je vois pour que ça s’ancre réellement dans mon crâne.
Le découpage aussi brutale théorie/pratique, peut être que ça marche pour beaucoup, mais je trouve ça très dommageable. C’est séparer deux choses qui n’ont pas de raison de l’être.
De manière générale, j’ai d’abord besoin de connaître la chose d’un point de vue théorique dans son ensemble pour avoir du recul sur le fonctionnement de la chose.
Ce n’est qu’après avoir compris les avantages/inconvénients que je vais passer à la pratique pour cette fois bien assimiler l’aspect technique, en faisant toujours le lien avec la théorie, jusqu’à maîtriser suffisamment pour que la théorie devienne quelque chose de naturel dans mon raisonnement.
Ca demande peut être un peu plus de temps, mais ça me permet de garder les idées claires sur tout ce que j’apprends. Chacun sa méthode 
Tu apprends en autodidacte ou en fac ?
En autodidacte, je ne suis professionnellement pas du tout dans l’informatique à vrai dire.
Ça m’impressionne une tel démarche hors formation universitaire. 
J’ai une passion pour l’informatique et tout ce qui s’y rattache, c’est ce qui me motive. J’adorerais bien maîtriser l’UML et le C++ (et/ou le Java) pour pouvoir faire de vrais logiciels complexes, notamment pour Linux. De plus l’UML me permettrait de modéliser également mes bases de données, ça serait formidable de pouvoir tout faire avec un seul concept !
Je ne suis pas un très grand fan de la programmation assistée par modèle. Le problème c’est que souvent ça se passe ainsi :
[ul]
[li]tu crée ton super modèle[/li]
[li]tu lance la création de tes classes et du profile de leur fonction ainsi que de leur données membres[/li]
[li]tu code[/li][/ul]
Jusque là tout va très bien. Ensuite tu veut faire évoluer le logiciel :
[ul]
[li]avec de la chance tu peut régénére le modèle à partir des sources[/li]
[li]tu modifie ton modèle[/li]
[li]et ensuite ?..[/li][/ul]
Ensuite soit tu recode tout le logiciel après avoir régénérés des classes dépourvues de code, soit tu as un système pour réappliquer tes modifications à ton code et là c’est super lourd pour refaire coïncider ton code au nouveaux prototype.
Mais ce n’est qu’un point de vu. Moi j’aimerais bien toucher un peu à scala qui à l’aire agréable à utiliser.
Tu es censé toujours avoir ton modèle sur une feuille papier ou dans un document non ? Donc tu peux toujours modifier ton modèle et appliquer les changements à ton code ? Je croyais que la programmation orientée objet était là pour pouvoir ajouter ou modifier facilement des propriétés et des fonctions aux objets.
Alors effectivement je ne sais pas ce que ça donne concrètement, je manque de pratique jusqu’ici.
Après codage si tu dois découper une fonction en deux, changer le type des variables, déplacer un bout de fonction dans un autre objet,…
C’est le genre de traitement où j’ai un doute sur le fait que ça s’applique bien.
Ce sont des modifications de fond qui ne sont pas censées intervenir souvent. Normalement si on a bien pensé le modèle et qu’on l’a prévu pour évoluer en estimant les besoins potentiels futurs, ça ne devrait pas arriver, ou très rarement.
De ce que je crois me souvenir, une fonction est censée pouvoir être appliquée à n’importe quel objet (si son encapsulation le permet), donc on ne devrait jamais avoir à déplacer un bout de code, simplement rajouter du code pour adapter la fonction au nouvel objet. Peut être que je me trompe ?
Ce sont des modifications de fond qui ne sont pas censées intervenir souvent. Normalement si on a bien pensé le modèle et qu’on l’a prévu pour évoluer en estimant les besoins potentiels futurs, ça ne devrait pas arriver, ou très rarement.[/quote]
Ça c’est très théorique. Il n’est pas possible de penser à l’avenir du logiciel à plus ou moins long terme. C’est de l’ordre de la prédiction.
Les techniques d’extrêmes programming conseillent au contraire de ne pas tenter de prévoir ce qu’il va se passer car souvent on se plante.
De ce que je crois me souvenir, une fonction est censée pouvoir être appliquée à n’importe quel objet (si son encapsulation le permet), donc on ne devrait jamais avoir à déplacer un bout de code, simplement rajouter du code pour adapter la fonction au nouvel objet. Peut être que je me trompe ?[/quote]
Un signal s’envoie sur un objet d’une classe (ou de toutes les classes filles). Tu peut avoir le besoin d’implémenter un design pattern qui te fait déplacer une fonction d’une classe à une autre.
Après il est claire que tout ça est très subjectif faut pas trop se formaliser et certains concepts sont très liés aux familles de langage (duck typing notamment).