Questions C/C++

Bonjour !

Comment allez-vous ?

Je suis relativement perplexe me demandant si le C++ n’est autre qu’un C étendu ?

Vers quoi devrais-je me tourner ?

Bien à vous

Salut !

Je suis relativement perplexe me demandant si le C++ n’est autre qu’un C étendu ?

Cette question laisse perplexe en effet.

Vers quoi devrais-je me tourner ?

Lisp, sans hésiter. Mais le Lisp des montagnes de l’Ouest, pas celui des forêts, qui, entre parenthèses, est bien moins facile à lire.

Salut,

Ta question n’est pas claire du tout, en quel sens ce serait un C étendu ? Qu’est-ce que tu entends par là et qu’est-ce qui te fait dire ça ?
En tout cas la façon de concevoir et programmer en C++ est totallement différente, donc je répondrais non, ce n’est pas un "C étendu"

Pour faire quoi ? Quel est l’objectif ?
Tous les langages ont leurs points forts et leurs points faibles, la réponse à ta question va dépendre de ton ambition

Un C étendu, ce devait être plutôt un U, non ?

Bonsoir,

Ta question n’est pas claire du tout, en quel sens ce serait un C étendu ? Qu’est-ce que tu entends par là et qu’est-ce qui te fait dire ça ?

Après lecture de certains articles par rapport au langage C et au langage C++ j’ai l’impression qu’une zone d’ombre reste sur cette fameuse question.. Mais je ne pense pas que dans le cas présent il soit nécessaire d’en parler.

Pour faire quoi ? Quel est l’objectif ?

Du traitement réseau, algorithmie, apprendre la gestion de la mémoire, accès directe au composant, bref..

Merci à vous

Le C++ est basé sur le C, mais il l’étend tellement que quand on code en C++ on ne pense pas et on ne code pas de la même manière qu’en C. Un compilateur C++ sera capable de compiler un programme écrit en C, mais ce programme n’aurait pas été écrit du tout de la même façon en C++. Une différence majeure est la programmation orientée objet, qui n’est "pas possible" en C.

Aussi, le C++ ne remplace pas le C. Je pense qu’on recherche davantage de développeurs C que C++, pour maintenir et faire évoluer des softs ou des libs écrits en C. Et il y en a beaucoup et encore pour un bon moment. Il ne faut pas voir le C comme l’ancêtre obsolète du C++, ce sont deux langages distincts qui sont chacun utilisés là où ils sont le plus adapté.

Si tu te demandes lequel des deux tu devrais étudier :

• le mieux c’est d’apprendre les deux
• si tu ne devais en apprendre qu’un je préconiserais le C
• tu n’es pas obligé d’apprendre le C en premier même si c’est un cheminement classique

Ahn ! d’accord ! d’où le U++ !

apprendre la gestion de la mémoire, accès directe au composant

Donc tu veux être sur du bas niveau, apprend donc le C, en C++ on évite la gestion manuelle de la mémoire en utilisant le principe RAII

Raisons ? La gestion de mémoire n’est plus à préconiser ?

Pourquoi veux tu gérer la mémoire ?

Les gens font trop de conneries.

Blague à part, je pense également que l’apprentissage du C est intéressant ne serait-ce que pour la culture générale.

Cela dit, (ce point de vue n’engage que moi, mais je ne suis certainement pas le seul à le partager) il ne me viendrait absolument pas à l’esprit de réaliser un projet en C en 2018, pour les mêmes raisons que le langage est intéressant à connaître : il expose (et donne toute la responsabilité de) la gestion de mémoire au développeur, sans filet de sécurité, sans réelle abstraction… Du coup c’est génial pour avoir un aperçu des problèmes auxquels s’attellent les langages plus modernes, mais si ton but est d’être assez rapidement productif, c’est certainement le deuxième pire choix possible derrière un langage d’assemblage.

Le but est en effet d’être "productif" relativement rapidement ne serais-ce que sur des petites tâches, pour répondre ; Je veux apprendre à gérer la mémoire pour plus tard pouvoir m’atteler à des choses plus complexe, 3D, Kernel, Réseau, etc

a- L’objet est émulable en C. En revanche, libérer automatiquement les ressources (à commencer par la mémoire) n’est pas possible en C. C’est là la plus grosse différence dans les codes (corrects) développés dans les deux langages.

b- Hum… Je suis dubitatif. On va dire que cela dépend des secteurs.

c- C’est plus complexe. Il est intéressant pour un développeur professionnel d’avoir des notions de C. Pour les autres, c’est strictement inutile — c’est comme apprendre le latin pour être physicien, ça ne sert à rien. Pour le développeur amateur, autant viser le C++ directement, il est plus simple à manipuler correctement et donc à apprendre à manipuler. Mais … mieux vaut viser d’autres langages plus productifs et abordables comme le Python qui a le vent en bien poupe, aujourd’hui.

A noter que le C++ n’est pas un obstacle à l’embarqué ou à l’écriture de noyaux (moyennant quelques restrictions). Au contraire, certains le préconisent, cf les nombreuses présentations de Dan Saks. Bref. C’est du troll récurrent tout ça, on n’a plus forcément l’envie et l’énergie de produire des réponses claires et sérieuses.

Un compilateur C++ sera capable de compiler un programme écrit en C, mais ce programme n’aurait pas été écrit du tout de la même façon en C++.

C’est la théorie, dans la pratique il y a pleins de points gênants : cast depuis void* obligatoire en C++, designated initializer qui n’existe pas en C++ et n’existera pas sous la même forme de façon standard, C++ est plus restrictif sur les règles d’aliasing dans les unions, etc etc. Comme tu l’as dit ce sont deux langages fondamentalement différents et pour plus de raisons que la façon de gérer de la programmation orienté objet.

On pourrait rajouter qu’il expose une gestion de la mémoire qui n’est pas celle qu’il laisse paraître et que ça produit beaucoup de programmes pas correct, posant beaucoup de soucis pour une compilation vers des plate-formes plus restrictive comme wasm (cast de fonctions, strict aliasing, accès non alignés, undefined behaviour d’un accès random (ou précalculé mais incorrect) en ram, etc).

Le but est en effet d’être "productif" relativement rapidement ne serais-ce que sur des petites tâches, pour répondre ; Je veux apprendre à gérer la mémoire pour plus tard pouvoir m’atteler à des choses plus complexe, 3D, Kernel, Réseau, etc

Apprendre à gérer la mémoire en C côté utilisateur ne va pas forcément t’aider pour le reste. Dans ce que tu as cité ce n’est jamais la partie la plus difficile, autant en théorie qu’en pratique. En 3D il faut avoir une intuition de comment le matériel et le driver fonctionnent dans les grandes lignes et savoir programmer des maths. En noyau il faut des connaissances bas niveau sur les composants, les interruptions, le fonctionnement d’une machine en général. En réseau il faut savoir compresser efficacement des données, savoir gérer les IO, savoir architecturer l’application pour et connaitre les protocoles. En conclusion il faut plutôt des cours de computer science qu’un langage bas niveau pour commencer, quel que soit le domaine dans lequel tu veux aller. Donc prend un langage que tu maîtrises ou que tu as envie de maîtriser plutôt.

Mouais. Il faut peut être arrêter avec ça. Du C sur un ordinateur de bureau et avec un système d’exploitation, on ne gère pas la mémoire sans abstraction. Il y a un gouffre entre la notion de variable en C (et C++) et ce qui se passe en interne.

Le C++ était basé sur le C lors de sa création, mais les deux langages ont continué d’évoluer. Un code source C n’est pas forcément valide en C++

Mouais. Il faut peut être arrêter avec ça. Du C sur un ordinateur de bureau et avec un système d’exploitation, on ne gère pas la mémoire sans abstraction. Il y a un gouffre entre la notion de variable en C (et C++) et ce qui se passe en interne.

Ok, j’arrête avec ça, et je serai reconnaissant envers l’abstraction fournie par mon kernel la prochaine fois qu’une extension écrite en C ou C++ provoquera "seulement" un segfault dans un programme en Python au lieu de corrompre la mémoire ou pire.

Désolé de mon manque de rigueur, je reformule : C permet de manipuler explicitement la mémoire au travers de l’abstraction matérielle fournie par le système d’exploitation, mais de nos jours, en 2018, si je devais descendre à aussi bas niveau, tant qu’à faire je pense que je privilégierais une technologie plus récente dont les abstractions (ou même juste le compilateur) me donnent par défaut la garantie confortable que mon programme n’essayera pas d’écraser une zone de mémoire dans laquelle je ne suis pas censé pouvoir écrire, d’accéder à de la mémoire qui n’est plus allouée, ou à une adresse qui dépasse de la taille de mon tableau (parce qu’autrement c’est vachement dur d’en être vraiment sûr pour nous autres pauvres mortels), ce qui évitera du même coup à l’abstraction fournie par mon système d’exploitation d’interrompre brusquement l’exécution de mon programme sans possibilité de rattraper l’erreur.

a- L’objet est émulable en C. En revanche, libérer automatiquement les ressources (à commencer par la mémoire) n’est pas possible en C. C’est là la plus grosse différence dans les codes (corrects) développés dans les deux langages.

Effectivement. C’est la raison pour laquelle j’ai mis des guillemets. Mais quitte à faire de l’objet, on fait du C++ et pas du C en général. Autant avoir une syntaxe adaptée, de l’héritage, le débogage et les outils de conception qui vont avec, etc.

b- Hum… Je suis dubitatif. On va dire que cela dépend des secteurs.

J’aurais tendance à dire pas tant que ça. La plupart des logiciels et librairies les plus répandus sont en C. Du côté des softs : Linux, Git, une énorme partie de tout l’écosystème Gnu, Apache, PHP, Python, etc. Du côté des librairies : quasiment toutes, et une énorme partie des librairies dans les autres langages n’en sont que des surcouches articulées autour d’un portage/binding. Bref une basecode beaucoup trop vaste, qui marche, assez souvent critique, et trop utilisée par les couches au dessus pour être réécrite.

c- C’est plus complexe. Il est intéressant pour un développeur professionnel d’avoir des notions de C. Pour les autres, c’est strictement inutile — c’est comme apprendre le latin pour être physicien, ça ne sert à rien. Pour le développeur amateur, autant viser le C++ directement, il est plus simple à manipuler correctement et donc à apprendre à manipuler. Mais … mieux vaut viser d’autres langages plus productifs et abordables comme le Python qui a le vent en bien poupe, aujourd’hui.

C’est peut-être pas requis pour faire son boulot pour 90% des développeurs. Mais pour être vraiment un bon développeur c’est mieux de savoir ce qui se passe sous le capot et de savoir redescendre à l’étage en dessous quand il le faut. Un peu comme un pilote de F1, il ne peut pas atteindre le plus haut niveau sans avoir quelques notions de mécanique. Pour moi, un développeur qui ne connaît pas un minimum le C, c’est un noob juste bon à utiliser des frameworks bien documentés.

Par contre c’est vrai que d’une part ce n’est absolument pas requis pour débuter, ni même pour trouver du boulot, et d’autre part ça reste une compétence secondaire par rapport à celles liées directement au boulot qu’on fait, y compris moins techniques.

Edit : Pour illustrer, nohar a parlé de segfaults en python. Si tu fais du python et que tu ne sais pas ce qu’est une segfault, tu peux chercher longtemps.

+1. https://wiki.osdev.org/C%2B%2B <3

La POO en C++ n’est pas sa caractéristique principale non. C’est le RAII qui différencie ce langage de son ancêtre le C.

Quand à savoir si le C permet vraiment de connaître ce qui se passe sous le capot, je suis dubitatif. Quand je fais un malloc sur mon PC, en vrai je ne sais pas vraiment ce qui se passe en-dessous. J’en ai une vague idée certes, mais pas beaucoup plus précise qu’un new en Java. Suffit de regarder la page sur le noyau Linux, avec le superbe schéma qui est dedans, pour voir toutes les couches traversées.

Sur une plateforme très simple, en embarqué, pourquoi pas, mais sur du x86, avec toutes les couches qu’il y a maintenant, c’est difficile de vraiment savoir ce qui se passe sous le capot.

En fait, pour moi, ce qui fait la force du C aujourd’hui et ça a été dit, c’est que c’est la lingua franca lorsqu’on fait une bibliothèque, vu que la majorité des langages peuvent appeller plus ou moins facilement du code C. Même une bibliothèque C++ doit utiliser l’ABI C, c’est dire.

EDIT : je n’ai pas relevé sur le passage d’être un noob bon à n’utiliser que des frameworks si on n’a pas fait de C. Déjà, en dehors du mépris évident, en quoi framework est-il synonyme de facilité ? En quoi avoir fait du C m’aidera à faire un site web scalable, déployé dans le cloud avec un système de traitement de messages en temps réel entre différents composants ? Exemple au hasard hein. Et pourtant j’ai commencé la programmation par le C, je devrais pas être un noob bon à utiliser des frameworks.

Edit SpaceFox : j’ai mis la bonne image

Salut,

Mmm… Le C permet effectivement de faire certaines choses que d’autres langages ne permettent pas (en tous les cas de base), mais j’abonde dans le sens de gbdivers : le langage C n’est pas un langage bas niveau. Il fournit mine de rien une grosse abstraction (la fameuse abstract machine de la norme, entre autre) qui s’éloigne potentiellement très fort du fonctionnement sous-jacent.

Foncièrement, le C est avant tout un langage extrêmement permissif et minimaliste, mais bas niveau pas tellement. Nul besoin de savoir ce qu’est la RAM ou comment elle fonctionne, idem du processeur, des registres ou du cache, idem pour la représentation des types, etc. Toutes ces notions sont bien entendu intéressantes, mais non obligatoires pour programmer en C.

Typiquement, comme le souligne informaticienzero, la gestion manuelle de l’allocation mémoire en C n’implique aucune connaissances particulières : tu appelles malloc() ou une de ses consœurs et c’est tout. La seule différence avec d’autre langage c’est que c’est géré par l’utilisateur, avec les avantages et inconvénients que cela induit.

C’est l’inverse, justement : le C t’aidera a ne pas faire un site scalable, déployé dans le cloud avec un système de traitement de messages en temps réel entre différents composants, parce que tu te diras « Oh putain c’est une usine à gaz ce machin, je vais faire plus simple ».

Il y aussi Haiku si ma mémoire est bonne.

NodeJS, paraît que c’est l’avenir du futur.

Je ne pense pas qu’il est possible de faire un kernel en JS…

Au final, toutes les méthodes ont des avantages et des inconvénients…

J’ai du mal à comprendre pourquoi vous tendez à me diriger vers le C++ ?

Je recherche juste un moyen d’assouvir ma soif de développement avec un langage permettant d’avoir accès à des performances direct