Bonjour,
Je suis programmeur C, et je n'ai jamais eu besoin du C++. Je me demande donc quels sont ses avantages ?
De plus, je trouve les programmes en C++ beaucoup moins lisibles que ceux écrit en C. Il y a aussi le "nullptr" dont je ne vois pas l'intérêt, le "NULL" me paraît plus rapide à écrire et plus lisible car écrit en majuscules.
Certains diront: l'avantage est la programmation objet. Mais avec l'option de GCC "-fms-extensions", on peut imbriquer les structures de la sorte:
struct sphere {
int type;
int x;
int y;
int z;
}
struct soleil {
struct sphere;
int light_intensity;
}
struct planete {
struct sphere;
int habitable;
}
enum {
SOLEIL,
PLANETE
};
int main() {
struct planete Terre;
Terre.type = PLANETE;
}
C'est pratique pour programmer plus facilement. Ensuite, on peut utiliser toutes les planètes et tous les soleils, avec des pointeurs sur une structure sphere, et en fonction de leur type, on peut accéder aux données spécifiques à chaque type d'objet, en recastant le pointeur.
Concernant les attributs "private", "protected", et "public", des classes du C++, je ne vois aucun intérêt à ça.
Et utiliser une fonction pour lire ou écrire chaque variable présente dans une classe, je trouve ça complètement inefficace et ça réduit les performances, car ça fait un appel de fonction au lieu de lire et écrire directement la variable.
Donc je ne vois pas quels sont les avantages du C++ sur le C ?
# sans interet pour toi peut-etre ?
Posté par NeoX . Évalué à 6 (+3/-0).
quand tu auras de tres gros projets tu seras peut-etre content d'avoir des attributs ou des fonctions private (utilisables uniquement au sein de l'objet et connu de lui seul), ou des protected (lisible de tous mais pas modifiable en dehors des fonctions de l'objet ?)
et enfin des "public" lisibles et modifiables de tous (pot commun de données)
mais comme tout le monde tu as surement appris le C, tu le maitrises, et le C++ demande de revoir quelques principes.
les anciens ont appris l'assembleur avant le C et ne voyaient pas l'interet de ce langage.
les intermediaires auront appris directement le java et ne comprennent pas comment on a pu coder en C ou en assembleur ?
et les plus jeunes ne jureront que par le "noCode"
[^] # Re: sans interet pour toi peut-etre ?
Posté par David Demelier (site web personnel) . Évalué à 5 (+3/-0).
s/noCode/ChatGPT
git is great because linus did it, mercurial is better because he didn't
[^] # Re: sans interet pour toi peut-etre ?
Posté par NeoX . Évalué à 3 (+0/-0).
désolé c'est que j'ai deja un train de retard sur le sujet :D
# Pas le même paradigme
Posté par arnaudus . Évalué à 7 (+4/-0).
En fait, tu es en train de demander quelque chose comme "quel est l'avantage du bateau sur la voiture?". On va te répondre "Il peut aller sur l'eau". Et tu vas dire "Bah je n'ai pas besoin d'aller sur l'eau, et puis avec un 4x4 je peux rouler dans les flaques".
Je ne sais pas si C++ est un bon langage objet, je le trouve verbeux, piégeux, hyper-complexe, et ses évolutions le rendent encore plus complexe et plus technique. Mais bon, le C++ moderne est un langage objet et ses dernières évolutions permettent une programmation générique assez poussée, et il est probable que tu n'aies aucune idée de ce que ça permet si tu les compares avec les enum et les struct de C.
Là, tu es en train de dire "sur ma voiture le volant est noir alors que sur les bateaux le volant est blanc, donc je ne vois pas l'intérêt d'acheter un bateau plutôt qu'une voiture".
Deux possibilités. La possibilité 1, c'est que des millions d'ingénieurs ont conçu, appris, amélioré, et utilisé dans des milliers de logiciels des concepts de programmation qui n'ont aucun intérêt. La possibilité 2, c'est que ta formation et ton expérience en programmation sont trop parcellaires pour que tu comprennes l'utilité de ces concepts, et même trop limitées pour que tu puisses comprendre ce qu'il te manque pour comprendre l'utilité de ces concepts.
J'ai ma petite idée sur la possibilité qui est la plus vraisemblable, mais je ne veux pas influencer :-)
Par contre, je pense que ça illustre pas mal le fait que tu n'as probablement pas besoin d'utiliser C++ pour tes projets, donc pas besoin de se poser trop de questions : n'apprends pas C++. Ceci dit, je ne pense pas que C soit un bon langage pour n'importe quoi d'autre que des applications très proches du système, et il y a quand même un côté "vieux grognon" à toujours pousser vers la compréhension fine du fonctionnement des ordinateurs quand on commence la programmation.
[^] # Re: Pas le même paradigme
Posté par Walter5 . Évalué à -4 (+1/-6).
Le problème, c'est que certaines librairies logicielles publiées par des organisations sont en C++, au lieu du C. Par exemple LibTorch et CUDA.
Résultat, je dois coder en C++ aussi, et faire des librairies wrapper qui font l'interface entre des programmes C et des librairies C++.
J'ai aussi l'impression que le C++ est utilisé pour complexifier volontairement, c'est à dire obfusquer, le code source de certains programmes et librairies open source. Et ce, dans le but de dissimuler des bugs qui font que ça fonctionne bien sous Windows mais pas sous GNU/Linux, pour dissimuler des failles de sécurité, et aussi pour empêcher des programmeurs indépendants de faire des forks de meilleure qualité que l'original.
Voilà pourquoi je suis, d'un point de vue politique, pour l'obligation légale et internationale de publier un programme C et une librairie C, répondant à la norme POSIX, quand une organisation veut publier une librairie ou un programme open source, sans lui interdire de publier aussi dans un autre langage.
La situation actuelle, c'est qu'au lieu de faire des librairies pour enrichir et faciliter le développement d'applications en C, les organisations font des librairies pour plein de nouveaux langages: C++, Rust, Python, etc… Mais elle n'en font pas pour le C.
Je ne sais pas pourquoi, mais j'ai l'impression que le langage C est fortement méprisé par nombre de programmeurs ou par les commerciaux qui dirigent les équipes de programmeurs.
Car même pour les librairies et applications GNU/Linux, ce sont principalement des multinationales qui sont derrière, y compris Microsoft. Donc les commerciaux doivent probablement avoir une influence sur le développement des librairies et applications GNU/Linux. Suffit de regarder ce qu'est devenu GNOME quand il est passé de la version 2 à la version 3, je doute fortement que ce soit par la volonté des programmeurs et des utilisateurs.
Les protected et private, ça empêche les programmeurs qui utilisent la librairie de faire ce qu'ils veulent avec l'objet. Je suis pour la liberté de programmation, et le C++ permet de restreindre cette liberté, je trouve que c'est contraire à la philosophie du Libre.
Concernant les commerciaux ou "ingénieurs" qui dirigent les équipes de programmeurs, on leur a appris: "le C++ c'est mieux, la programmation objet c'est mieux" et beaucoup ne vont pas chercher plus loin, ils croient ce qu'on leur a dit, et une fois en entreprise ils imposent du développement C++, voir Java, Rust, et même Python.
Ou alors, ces concepts de private et protected sont pour les débutants et les programmeurs qui ont du mal à gérer les objets ? Parceque lire et écrire une variable d'un objet avec des méthodes du type GetVariable() et SetVariable(), ce n'est certainement pas pour faire un programme efficace, ça fait des appels de fonction inutiles. Et c'est contraire à la philosophie du Libre qui veut que l'on fasse le programme le plus efficace possible.
Y a t'il vraiment plus de difficultés à trouver les bugs quand on écrit "int tmp = objet.a" que lorsqu'on écrit "int tmp = objet.GetA()" ?
[^] # Re: Pas le même paradigme
Posté par arnaudus . Évalué à 7 (+4/-0).
Rassure-moi, c'est une caméra cachée ou un truc comme ça? :-)
En fait, quand tu demandais "quels sont les avantages du C++?", tu ne voulais pas une réponse, tu envoyais une bouteille à la mer pour savoir à quel point tu étais seul sur ton perchoir?
[^] # Re: Pas le même paradigme
Posté par Graveen . Évalué à 2 (+0/-0).
J'allais répondre à OP mais je pense également qu'il n'a pas envie de comprendre et/ou qu'il n'est pas assez expérimenté.
"Plus j'apprends, plus je réalise que je ne sais pas." (attribué à Albert Einstein)
[^] # Re: Pas le même paradigme
Posté par arnaudus . Évalué à 8 (+5/-0).
En tout cas, il a l'air bien convaincu que l'esprit du Libre, c'est de coder en C, autrement, tu vas en prison.
Compte créé aujourd'hui, peut-être juste un troll? En tout cas, son manque de culture rend l'affirmation qu'il est développeur assez douteuse (par exemple, les problèmes liés au type de NULL, ça devrait être dans les cordes d'un developpeur C, non?)
[^] # Re: Pas le même paradigme
Posté par Aldebaran (site web personnel) . Évalué à 1 (+0/-0).
J'ai beaucoup rit ;)
Sans vouloir être suffisant ou quoi que ce soit, il faut reconnaître l'existence de plusieurs approches. Le C en a une, le C++ une autre (même pas très éloignée).
La philosophie du libre implique ça ? Je ne le savais pas. En tout cas, poser des droits d'accès à des variables dans un code à plusieurs avantages. Si tu fais une librairie, les variables qui doivent pouvoir être manipulées par l'utilisateur seront en public, le reste en privé. Ça évitera que les utilisateurs de la lib ne touche quelque chose d'interne et de sensible sans le vouloir.
Encore une fois, la philosophie du libre implique ça ?
Pour l'histoire des setter / getter, ça a l'air bête, mais ça permet par exemple de tracer plus simplement un programme, ou d'instrumentaliser le set. On peut par exemple vouloir limiter les valeur assignées dans le setter. Imaginons une variable int qui ne doivent jamais dépasser 25, je me pose dans mon setter et j'ajoute une condition.
Sans le setter je dois faire ce test à chaque assignation d’où une duplication du code.
De plus je ne pense pas me tromper en disant que le compilo optimisera les getter et setter à la compilation.
Tu semble regretter de ne pas pouvoir faire certaines chose en C++ par rapport au C, mais en vrai, si t'aime pas les setter n'en utilise pas. Met tout en public, ou ne créé même pas d'objets. En gros fait du C.
Maintenant si tu as envie d'essayer autre chose, tu verra que ça peut avoir de l’intérêt.
D'une manière générale, ce n'est pas parce qu'un langage se montre permissif qu'il sera bon, dans beaucoup de cas, se retrouver contraint permet de produire plus facilement un code avec moins de bugs ou d'erreurs. Le rust par exemple brille dans ce domaine je trouve, j'ai l'impression d'écrire du code plus idiomatique, justement parce que je suis très contraint.
Quand tu as une fonction avec une variable en const tu te limites dans ce que tu fera avec cette variable, tu aura l'assurance qu'elle n'est pas modifiée. Tu évites ainsi tout un tas d'erreurs bêtes. C'est la même idée avec public, private, protected. Pareil pour l'utilisateur de la fonction, il saura que ce qu'il envoie ne sera pas modifié, sans même à avoir à lire la fonction.
[^] # Re: Pas le même paradigme
Posté par totof2000 . Évalué à 3 (+1/-0).
Je pense que le problème du posteur initial vient surtout du fait qu'en général l'apprentissage de la programmation objet est mal fait (que ce soit par des profs ou via des tutoriels en ligne). Parce que effectivement, quand la seule chose qu'un prof ou un tutoriel dit c'est "déclarer les propriétés de classe en privé et faites des méthodes pour y accéder", ça n'a pas de sens. Par contre lorsqu'on explique que l'intéret d'encapsuler ses objets et de mettre en place des interfaces pour y accéder, là on comprend mieux (l'exemple de la tempértature en degré ou en kelvin, ou l'expression des coordonnées d'un point en coordonnées polaires ou rectangulaires est plus parlant).
Si on n'explique pas que le but c'est de pouvoir changer l'implémentation sans que les développeurs qui utilisent nos classes ne soient impactés, il est difficle de se faire une idée de la raison d'être de l'encapsulation. L'idéal est d'avoir un cas concret comme exemple.
[^] # Re: Pas le même paradigme
Posté par arnaudus . Évalué à 4 (+1/-0).
Je pense que ce qui n'est pas très clair pour beaucoup (y compris pour moi), c'est à quel point un langage comme C++ est multiparadigme, et à quel point il n'implique pas d'utiliser toutes ses possibilités. Ce n'est pas parce qu'une police de caractères propose des glyphes latins, grecs, et hébreux que c'est une bonne idée de mélanger tout ça dans le même texte.
Certains utilisent C++ comme un C amélioré (avec des classes à la place des struct, les opérateurs <<, les const et les références par exemple), d'autres comme un pur langage objet (encapsulation et héritage), d'autres ne jurent que par les algorithmes génériques à la STL, certains excluent les templates ou les exceptions, etc.
En théorie, j'ai l'impression les avantages majeurs de la POO se voient surtout sur les gros projets (travail indépendant sur des modules, évolutivité à long terme), surtout quand leur architecture générale a été conçue par des gens qui connaissent bien leur boulot (design patterns etc). Tant que tu as des exemples du style "class Voiture: public Vehicule", ça parait complètement déconnecté de ce dont tu as besoin pour écrire un programme lambda de 150 lignes.
Mais sur le fond, certaines possibilités offertes par le C++ sont quand même des trucs de niche, qui sont à des années lumière de ce qu'un programmeur peu expérimenté peut maitriser. Je crois qu'il m'a fallu des années pour comprendre par exemple que la surcharge des opérateurs n'était pas utile pour 99.9% des projets, ou qu'on pouvait faire du code propre sans template variadique. Et puis après j'ai arrêté le C++ parce que ça n'était pas l'outil dont j'avais besoin, et voila.
[^] # Re: Pas le même paradigme
Posté par Tonton Th (Mastodon) . Évalué à 2 (+0/-0).
Deeplop, sors de ce corps !
# Expérience
Posté par David Demelier (site web personnel) . Évalué à 4 (+2/-0).
NULL est problématique parce que c'était 0 en C++ et un cast de
void *de 0 en C. Rien que pour ça il y a problème de compatibilité.En étant 0, il y a ambiguité dès lors qu'on a deux fonctions surchargées qui peuvent prendre soit un
intsoit un pointeur quelconque. Le mot clénullptrest spécifiquement là pour les pointeurs. En plus, en C23 il y a aussinullptr:).La programmation orientée objet n'est pas la réponse à tout. Quand je vois certains projets avec 7 niveaux de hierarchie avec des fonctions virtuelles/abstraites de tous les côtés je suis bien content de pas y mettre les pieds. Comme disait Carmack, parfois la meilleure implémentation n'est qu'une fonction. En C on peut faire un peu d'orienté objet avec des pointeurs de fonction, c'est la méthode la plus courante pour implémenter des choses abstraites. Un système de fichier virtuel est clairement un des exemples les plus concret
Il y en a, heureusement sinon personne ne l'utiliserait. Je vais faire court.
gtk_tree_widget_my_super_fonction? qui aime avoir un conflit de noms parce qu'une autre bibliothèque a un nom identique ?json foo{"bar", baz};.Bon la liste est longue donc je te laisse faire ton propre avis. Et parce que j'aime beaucoup le C et que je trouve que le C++ devient de plus en plus dégueu au fur et à mesure des nouvelles normes je fais aussi un exemple opposé.
std::string xon a aucune idée de ce qu'il risque de se passer sur l'allocation mémoire, en C on a quasiment aucune surprise.Note, je suis dans le développement embarqué donc mon avis est un peu biaisé bien que j'ai passé une grande partie de ma vie à développer des applications en C++.
git is great because linus did it, mercurial is better because he didn't
# à propos des setters/getters
Posté par totof2000 . Évalué à 4 (+2/-0).
Le but n'est pas de définir une fonction pour chaque élément de ta structure, mais de masquer les détails d'implémentation. Un exemple : une structure ou classe qui a une propriété température. Comment l'implémenter, sachant que l'on peut exprimer une température en kelvin (système international), en degré Celsius ou en Degré Fahrenheit. Si tu donnes directement accès à la propriété, tu vas devoir choisir de définir l'unité d'implémentation, et t'y tenir parce que es gens feront des trucs comme par exemple: temperature_degre = instance_objet.temperature
Par contre si tu rend ta propriété température privée, mais que tu crées des interfaces qui retournent la température soit en degré celsius, soit en kelvin, soit en degreé Fahrenheit, tu peux te sentir libre de changer du jour au lendemain la façon dont tu va stocker ta température. Les utilisateurs de ton objet n'auront qu'à appeler l'interface, qui leur retournera toujours la même chose. Ils n'auront rien à changer dans leur code (il n'y a que toi qui aura à faire les adaptations).
# Troll
Posté par moi1392 . Évalué à 3 (+1/-0).
Je suis le seul à ne voir qu'un troll/canular/blague dans ce post ?
Rien que cette remarque complètement explicite sur la caractère non sérieux des arguments aurait dû mettre la puce à l'oreille de tout le monde :
Après ça je ne vois pas trop l'intérêt de répondre autrement que sur le ton de l'humour à ce message.
[^] # Re: Troll
Posté par David Demelier (site web personnel) . Évalué à 2 (+0/-0).
Non je ne pense pas que ce soit un troll, la question du NULL est légitime si on a pas la notion entre les deux. Dans les dernières versions de C++ il y a tellement de fonctionnalités qu'il est légitime de se poser ce genre de question pour un néophyte.
NULL va rester car le supprimer maintenant détruirait une grosse partie des projets C++, mais je le vois bien à terme être déclaré comme obsolète (et éventuellement supprimé à très long terme).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Troll
Posté par moi1392 . Évalué à 2 (+0/-0).
ça n'est pas la question du NULL, qui effectivement peut tout à fait être légitime, qui fait de ce post un troll mais les arguments avancés.
+rpd a ékrir ?
PLUS LISIBLE CAR EN MAJUSCULES ?
Sérieusement ?
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.