Discussion :

[3DArchi]

J'ai parcouru plusieurs Delannoy sur le C++, et à chaque fois j'étais effaré de ce que j'y ai lu. Donc, à moins qu'il se soit amélioré récemment, je conseillerais fortement d'éviter.

Extrait du chapitre 5 de l'édition 5 dispo en PDF :

Avec ce chapitre, nous abordons véritablement les possibilités de P.O.O. de C++. Comme nous l'avons dit dans le premier chapitre, celles-ci reposent entièrement sur le concept de classe. Une classe est la généralisation de la notion de type défini par l'utilisateur1, dans lequel se trouvent associées à la fois des données (membres données) et des méthodes (fonctions membres). En P.O.O. "pure", les données sont encapsulées et leur accès ne peut se faire que par le biais des méthodes. C++ vous autorise à n’encapsuler qu'une partie des données d'une classe (cette démarche reste cependant fortement déconseillée). Il existe même un type particulier, correspondant à la généralisation du type structure du C, dans lequel sont effectivement associées des données et des méthodes, mais sans aucune encapsulation. En pratique, ce nouveau type structure du C++ sera rarement employé sous cette forme généralisée. En revanche, sur le plan conceptuel, il correspond à un cas particulier de la classe ; il s'agit en effet d'une classe dans laquelle aucune donnée n'est encapsulée. C'est pour cette raison que nous commencerons par présenter le type structure de C++ (mot clé struct), ce qui nous permettra dans un premier temps de nous limiter à la façon de mettre en oeuvre l'association des données et des méthodes. Nous ne verrons qu’ensuite comment s'exprime l'encapsulation
au sein d'une classe (mot clé class).

puis :

Notion de classe
Comme nous l'avons déjà dit, en C++ la structure est un cas particulier de la classe. Plus précisément, une classe sera une structure dans laquelle seulement certains membres et/ou fonctions membres seront "publics", c'est-à-dire accessibles "de l'extérieur", les autres membres étant dits "privés".

plus loin (c'est moi qui souligne) :

Pour C++, les unions et les énumérations sont aussi des classes. Ces deux types peuvent donc disposer de fonctions membres. Notez bien que, comme pour le type struct, les données correspondantes ne peuvent pas se voir attribuer un statut particulier : elles sont, de fait, publiques.

Ou comment dire n'importe quoi sur les structures.

Un exemple de main :

Code :

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

1
2
3
4
5
6
7
main()
{ point a(5,2) ;
a.affiche () ;
a.deplace (-2, 4) ; a.affiche () ;
point b(1,-1) ;
b.affiche () ;
}

Encore :

En théorie, constructeurs et destructeurs peuvent être publics ou privés. En pratique, à moins d'avoir de bonnes raisons de faire le contraire, il vaut mieux les rendre publics. En effet, un destructeur privé ne pourra pas être appelé directement1, ce qui n'est pas grave, dans la mesure où cela est rarement utile. En revanche, si le constructeur d'une classe est privé, il ne
sera plus possible de créer des objets de cette classe2, que ce soit par une déclaration ou une allocation dynamique. A la rigueur, un constructeur privé peut se justifier dans le cas où la classe concernée est destinée à donner naissance, par héritage, à des classes dérivées.

Si tous le reste est à l'avenant, ça laisse rêveur...

[Goten]

La dernière fois que j'ai lu du Delannoy il essayait d'implémenter une classe string et il mélangeait allégrement des new[] et delete ... (entre autres). Pas mal de code faux.
Pars sur du AC++ histoire d'avoir de bonnes bases

[3DArchi]

Salut,

Je ne suis pas tout à fait certain que les maths soient le meilleur exemple, en maths justement, la notion d'objet, et de propriétés liées à ces objets, est extrèmement importante ("cette fonction est continue, et l'ensemble que l'on considère est ouvert, ou fermé, ou compact, donc...")

Je pensais à la démarche lorsqu'on résout un problème ou une démonstration. Mais c'est sûrement un biais de ma part.

Mon impression, c'est que ca marche bien quand il n'y a pas besoin d'abstraire... Avec de "vrais objets" comme la souris, les fenêtres, les boutons, les fichiers, l'objet marche bien, parce que c'est une façon naturelle de décrire le monde. Pour tout ce qui est simulation, c'est idéal.


Là où ca tourne souvent mal, c'est quand justement, il faut abstraire, parce que les "objets", les classes, ne sont pas faciles à voir... On peut bien sur s'en sortir, avoir une superbe intuition, et faire du code objet sublime, mais alors, il est à peu près certain que le développeur qui suivra ne comprendra rien à notre trait de génie...

Je pensais à ceux qui au début confondent instances et classes créant ainsi des hiérarchies de classes dont les classes dérivées ne pourraient être en fait que des instances de la classe de base.
Cependant, il faut aussi savoir dépasser le réel. Un niveau abstrait plus élevé permet plus de réutilisabilité. Mais, ça dépasse même le cadre objet. En général, en se détachant des contingences spécifiques on a plus de facilités à ressortir la trame du problème à résoudre, ce qui est important, ce que seront les points de variations, etc.

[Armulis]

Moi j'ai commencé par le C dans le but de faire le C++.
Après, j'ai écrit de petits programmes, et en cas de problème, je les présentais sur des forums d'entraide pour obtenir de l'aide.
9 fois sur 10 je me faisais casser les couilles (parfois de manière très agressive) parce mon programme en C++ utilisait des fonctions C.

À vos conclusions =D

[mintho carmo]

On conclue que les gens sur les forums d'entraide sont des casses-couilles ?

D'un autre côté, quand 9 fois sur 10, l'origine de tes problèmes sont que tu utilises du code C en C++, c'est normal qu'on te dise de ne pas mélanger du C et du C++
Et rassures toi, on n'a pas fini de te casser les couilles

(HS : tu gagnes le trophé "détérage de post")

[r0d]

9 fois sur 10 je me faisais casser les couilles (parfois de manière très agressive) parce mon programme en C++ utilisait des fonctions C.

Le fait d'utiliser des fonctions libres en c++ est, selon moi, une question d'opinion (elle n'est pas objective, donc pas sérieusement discutable). Pour ma part, j'en utilise de plus en plus (ça reste marginal tout de même), et ça n'engendre pas de problèmes particuliers dans le code que je produit.
Ce qui peut être plus gênant, c'est lorsqu'on utilise des choses qui sont héritées du C pour des raisons de compatibilité, mais qui ne sont pas dans la philosophie du c++ (par exemple les void*, les char*, new, et malloc) car ce sont des choses qui entrent en contradiction avec les principes de base du c++ (RAII dans mon exemple) et donc ont des incidences négatives sur le reste de l'implémentation (utilisation des exceptions dans mon exemple).

[mintho carmo]

Je comprends pas la remarque sur les fonctions libres. Fonction libres != fonctions C. L'utilisation de fonctions libres en C++ n'est pas du tout problématique, n'est pas du tout déconseillé (voir par exemple begin(), end(), make_shared() du C++11 ou make_unique() du C++14).
Et ce n'est pas qu'une question d'opinion, il y a eu pas mal de discussion sur ce point, en particulier sur le design tout objet de la STL au début (en particulier de Stepanov ? Lmghs pourra confirmer ou infirmer, je me souviens plus)

Par contre, l'utilisation de fonction C est effectivement problématique. Déjà parce que beaucoup de code C sont mauvais en C (aucune vérification des erreurs retournées par les fonctions) et encore plus en C++ (les exceptions rendent invalide un code correct en C). Voir l'article sur les retours de fonction vs les execptions

[r0d]

Je comprends pas la remarque sur les fonctions libres.

De par la tournure de la phrase que je cite dans mon message, ainsi que le champ lexical utilisé, j'ai pensé que Armulis parlait en réalité de fonctions libres lorsqu'il parlait de "fonction C". Parce que "fonction C", en soi, ça n'a pas de sens. Peut-être voulait-il dire "fonctions de la bibliothèque standard du C", auquel cas ma remarque est effectivement inutile.

Je soutiens cependant que l'utilisation de fonctions libres en C++ tient de l'opinion. On n'est jamais obligé d'utiliser de fonctions libres, mais on peut le faire. Il n'y a pas de raison objective, il s'agit juste de préférence, et je connais beaucoup d'excellents développeurs C++ qui refusent d'utiliser des fonctions libres, pour la simple et bonne raison qu'ils n'aiment pas. C'est souvent une question d'organisation de code (où mettre une fonction libre lorsque tout le reste du code est organisé en classes), et parfois une question d'esthétique (au sens étymologique), telle qu'on trouve parfois dans les considérations sur les chartes de nommage par exemple.

[Invité]

En baccalauréat moi j'ai commencé par apprendre le C moins avant le c++. (c'était à l'époque ou le c++ moderne n'existait pas encore)

J'ai surtout appris les notions suivantes :

-Les pointeurs.
-Les tableaux.
-Les structures.
-Les fonctions.
-Les variables.
-Les condition et les boucles.

J'ai appris le java en parallèle avec la couche orientée objet en plus.

Et on nous faisait pondre des algorithmes à l'aide d'exercices de plus en plus complexe ou il fallait produire des résultats à partir de données. (On avait 4h par exercices, parfois plus, ça dépendait de la difficulté mais bien souvent c'était 4h, ce qui correspondait à un labo.)

J'ai trouvé que c'était bien, après l'apprentissage du c++ est passé tout seul, j'avais des notes extraordinaire (plus extraordinaire que en java encore) et pourtant le java est sensé être plus facile à apprendre.

Donc oui c'est bien de ne pas commencer directement par un langage OO, pour savoir comment un langage OO fonctionne et apprendre plus facilement par après plutôt que de te taper toutes les notions d'un coup.

Bref si tu es comme moi tu vas avoir envie de savoir comment les algorithme du c++ moderne fonctionnent afin de pouvoir bien comprendre leur sémantique, mais le code source de la STL est assez chiadé (faut pas leur en vouloir, ils ont sûrement beaucoup plus de contraintes à respecter que nous), c'est toujours bon donc de passé par le c avant de se lancer.

Mais par la suite je te conseille quand même d'essayer de réutiliser ce qui existe déjà. (Ca t'évitera d'avoir bien des crashs et autres galères)
Malheureusement c'est pas toujours possible moi par exemple j'ai du inventer mon propre système de placeholders car std::bind ne répondait pas à mes besoins.

[Luc Hermitte]

Et ce n'est pas qu'une question d'opinion, il y a eu pas mal de discussion sur ce point, en particulier sur le design tout objet de la STL au début (en particulier de Stepanov ? Lmghs pourra confirmer ou infirmer, je me souviens plus)

Stepanov ne considère effectivement pas la STL comme étant OO. Au sujet des fonctions libres, il y a son Notes on Programming où il lâche subrepticement que si std::size() et std::begin() n'avaient pas été définies à l'époque, c'était pour être consensuel avec l’intelligentzia OO qui considérait en gros que seul l'OO était valable. Les choses ont changé en C++11 -- et tout cela me fait aussi penser à la video de Koenig où il introduit Stroustrup lors de la CppCon2014

.
Au sujet de la STL qui n'est pas OO, il en parle parfois dans des videos (comme celle-ci si mes souvenirs sont justes (pas le temps de la reregarder)

).

Concernant les fonction libres, ce n'est certainement pas ça qui est critiqué dans les programmes des gens qui viennent du C. Au sujet des fonctions libres et du sucre syntaxique OO: http://isocpp.org/files/papers/N4174.pdf

a- En baccalauréat moi j'ai commencé par apprendre le C moins avant le c++. (c'était à l'époque ou le c++ moderne n'existait pas encore).

b- Donc oui c'est bien de ne pas commencer directement par un langage OO, pour savoir comment un langage OO fonctionne et apprendre plus facilement par après plutôt que de te taper toutes les notions d'un coup.

c- c'est toujours bon donc de passé par le c avant de se lancer.

a- Même si le terme n'avait pas encore vu le jour, le C++ moderne existe depuis la fin des années 90 et le début des 2000. Le RAII était déjà dans le TC++PL de Stroustrup, AC++ de Koenig et Moo existe déjà depuis pas mal de temps. Mais les déclencheurs sont probablement les articles sur l'exception-safety qui datent de l'époque. Bref, ce n'est pas jeune.

b- Et c'est vers 99 que l'on m'avait montré la lumière : comme quoi le C n'était pas un passage obligé avant de démarrer le C++.
Il n'est pas obligatoire de montrer le paradigme OO en premier tout ça parce que l'on montre le C++. Il y a tout le fil à lire (pour une fois il est court, je ne vais pas y revenir)

c- Non, c'est plutôt néfaste si on ne prend pas le temps d'apprendre correctement le C. Quelqu'un qui a appris à programmer en C dans le pays magique où les erreurs n'existent pas ne comprendra pas pourquoi on lui tombe dessus à tour de bras quand il fait du C++ avec ses constructs venant du C. Alors que s'il avait appris le C++ moderne sans passer par la case historique, il n'aurait pas pris l'habitude d'utiliser des constructs qui sont à proscrire quand on veut écrire du code robuste. S'il avait correctement appris le C, il verrait vite les avantages des destructeurs -- à moins de faire un blocage, ce qui arrive aussi parfois.

[mintho carmo]

@r0d: Armulis a tendance en effet à écrire du code assez sale (et c'est ce qui l'amène à venir poser des questions)[/url])

Pour les fonctions libres, je voulais dire qu'il y a aussi des raisons techniques. Ecrire make_unique/make_shared en fonction membre, cela implique qu'il faut les mettre static et donc alourdir l'écriture pour les utiliser, alors qu'en fonction libre, cela fonctionne très bien.
Mais bon, tu as raison, si quelqu'un ne souhaite pas utiliser de fonctions libres, il peut. Mais je ne suis pas sûr que ça soit une bonne pratique.

[Luc Hermitte]

Tous les débutants écrivent du code sale qui ne vérifie pas les erreurs, et c'est exacerbé par les cours de C. Après, nul besoin de verser dans l'ad hominem.
Cela n'apporte rien.