Discussion :

[liberal1]

Un des gros soucis avec le langage C est que le développeur doit se soucier en permanence des problèmes de gestion de la mémoire, des caches, entre autres, estime Eric Raymond

Quelqu'un comprend cette phrase?

Je que je dis c'est que le C permet de faire n'importe quoi vraiment ,

Comme quoi par exemple?

par exemple le Pascal était enseigner parce que il était extrêmement rigoureux , je n'ai pas fait de python mais je pense que il oblige un peu plus au programmeur de faire attention de la manière de comment on écrit son code , qui me semble assz fondamentale.

Pascal est juste un jouet. Il est tellement limité, c'est une blague.

Le C disparaîtra le jour ou nos ordinateurs fonctionneront sans CPU, GPU et autres contrôleurs .

Je me voit mal écrire un driver sans C. Mais je l'ais abandonné pour mes projets Desktop avec le C++, qui me permet d'écrire mes codes avec plus d'aisance.

Pourquoi pas écrire le driver en C++?

[boboss123]

Quelqu'un comprend cette phrase?

ça veut dire qu'il faut déclarer la réservation et la libération de la mémoire (malloc, free)

Comme quoi par exemple?

Accéder aux registres de manière optimale => créer un driver (on peut être encore plus optimisé en utilisant de l'assembleur mais pour développer de gros drivers, ça devient vite compliqué pour au finale ne pas avoir forcément un résultat probant)
Accéder aux fonctions bas niveau de l'OS : par exemple en java, il est impossible de forger intégralement des paquets Ethernet sans utiliser une bibliothèque externe (écrite en C).

[liberal1]

Accéder aux registres de manière optimale => créer un driver (on peut être encore plus optimisé en utilisant de l'assembleur mais pour développer de gros drivers, ça devient vite compliqué pour au finale ne pas avoir forcément un résultat probant)

Quels registres?

Comment accéder aux registres de manière "optimale" en C?

Qu'est-ce que la manière "optimale"?

Accéder aux fonctions bas niveau de l'OS : par exemple en java, il est impossible de forger intégralement des paquets Ethernet sans utiliser une bibliothèque externe (écrite en C).

En quoi le C permet de "forger intégralement des paquets Ethernet"?

[gangsoleil]

Pourquoi pas écrire le driver en C++?

Pourquoi l'écrire en C++ ? Qu'est-ce que ce langage t'apporte par rapport à C pour l'écriture d'un driver ?

[Médinoc]

Pourquoi l'écrire en C++ ? Qu'est-ce que ce langage t'apporte par rapport à C pour l'écriture d'un driver ?

Tous les filets de sécurité que le C++ apporte, au moment où l'on en a besoin.

[commandantFred]

Go fait beaucoup plus d'ombre à C++ qu'à C.

Je l'utilise encore pour ses perfs et sa transparence - Où on devine à quoi va ressembler le code machine. Pour faire du traitement de signal. Dans ce cas, on peut toujours trouver un moyen de l'encapsuler dans du C++ au pire, et aboutir dans une dll.

Pour les IHM, il faudrait être fou ! J'en avais écrit une en C sous DOS dans les 90's. Finalement, je les fais en C# et ça ne risque pas de changer. Déjà que je m'arrache les cheveux avec les messages windows dans le code Purebasic, pas question d'entrer dans la boucle des messages sur les grands projets.

Ma question est : Quand verra-t-on une IHM bien faite sous GO ??? -- Larry, tu m'entends ? Ah ! Pardon c'est Bill et Satya, excusez moi... Je me suis trompé de numéro...

[Mat.M]

Un des gros soucis avec le langage C est que le développeur doit se soucier en permanence des problèmes de gestion de la mémoire, des caches, entre autres, estime Eric Raymond. Ce qui peut être très fatigant à la longue pour un programmeur qui ne trouve plus nécessairement le temps de se focaliser sur les aspects métier de son travail.

c'est exact mais bof...avec C# par exemple et même avec Visual Basic 6 de jadis s'il y a une exception eh bien on obtient tout de même une belle fenêtre d'exception...
pour ce qui est de la mémoire avec un langage et machine-virtuelle (C#,java...) il faut tout de même la gérer.
Si on adresse une instance de classe qui n'est pas instanciée par new on obtient une exception et le programme est planté.
Pour apprendre à programmer c'est pas grave sur un projet professionnel ça peut bloquer l'utilisateur.
Par contre c'est évident que le langage C peut causer des fuites mémoires si un pointeur n'est pas désalloué avec free()

[Christophe]

On peut écrire des pilotes en python

Les exemples fournis ne sont pas des pilotes.

Le premier créé un pipe, utilise les fonctions systèmes open, write, flush de la libc.

Le second lien est un wrapper vers une bibliothèque ... écrite en C.

Un code écrit en C++ sera plus rapide qu'un code python, Python étant interprété :
http://ceg.developpez.com/tutoriels/...cution-script/
Mais avec la puissance actuelle des CPU, ce n'est plus forcément le critère le plus important.

Python a l’avantage d'être facile d'accès, bien documenté, comprenant pléthore de modules, modifiable sans devoir recompiler.

Il ne remplace pas C/C++ mais est complémentaire. Selon le projet, C++ sera plus pertinent que Python et vice-versa.

[kilroyFR]

Dans l'embarqué c'est encore ce qui tient le mieux la route.
On est bien passé en C# (windows CE) mais on tombe sur des problemes qu'on n'avait pas avant en C/C++
(genre :
a/ faire derouler du code de temps en temps pour eviter que l'equipement ne "s'endorme" et ne necessite une recompilation de code au moment ou l'usager veut s'en servir
b/ garbage collector qui se lance a un moment non approprié et provoque un 'lag' sur l'equipement.
etc.
bref des choses qu'on maitrise parfaitement en C, mais qu'on subit en C#.
Alors oui l'interet du C pour moi a toujours ete de pouvoir maitriser parfaitement tout ce que tu fais (memoire, pointeurs etc), mais jugé trop compliqué on a inventé le C# pour des devs qui veulent faire du C a la sauce Visual Basic (sans se prendre la tete). Ceci dit les pbs de memoire on les a maintenant en C# car il faut savoir quand bien faire des Dispose() et autres operations du genre.

Alors oui on parle de temps de reponse qui doivent etre largement inferieurs a la seconde (un usager qui se pointe devant notre equipement et qui attend plus d'une seconde est inacceptable).

[commandantFred]

...
b/ garbage collector qui se lance a un moment non approprié et provoque un 'lag' sur l'equipement.
etc.
bref des choses qu'on maitrise parfaitement en C, mais qu'on subit en C#.
Alors oui l'interet du C pour moi a toujours ete de pouvoir maitriser parfaitement tout ce que tu fais (memoire, pointeurs etc), mais jugé trop compliqué on a inventé le C# pour des devs qui veulent faire du C a la sauce Visual Basic (sans se prendre la tete). Ceci dit les pbs de memoire on les a maintenant en C# car il faut savoir quand bien faire des Dispose() et autres operations du genre.

Alors oui on parle de temps de reponse qui doivent etre largement inferieurs a la seconde (un usager qui se pointe devant notre equipement et qui attend plus d'une seconde est inacceptable).

On peut forcer le garbage collector :https://msdn.microsoft.com/en-us/lib...(v=vs.71).aspx

Idéalement juste après dispose() sur de grandes plages mémoire mais on peut aussi oublier le dispose , la GC libérera toutes les ressources qui n'ont plus de référence active. J'ignore si c'est propre ou non. C# ne fonctionnera jamais sans GC mais il se peut que le code soit porté vers un langage sans GC ...


Pour moi, l'intérêt du C est sa vitesse d’exécution et l'absence de runtime sujet à engorgements. Difficile de dire combien d'applications utilisent le .Net Framework à l'instant T et ça peut poser questions dans le cas d'un driver. La vitesse d'exécution reste le critère primordial pour le traitement de signal.

Je crois que les développements de gestion ont tendance à considérer le traitement de signal comme une sorte de curiosité métier très verticale. Pour ma part, elle a la même priorité que la gestion des données.
Ce qui m'agace un peu, c'est qu'on parle uniquement de "programmation système" alors qu'en l'espèce, ce sont plutôt des traitements virgule flottante lourds. Le système n'a rien à voir...

[VivienD]

Je rejoins plus ou moins Kannagi. Le C a encore toute sa place dans la programmation embarquée, même s'il y a une couche Embedded Linux intermédiaire; il en va de même que la programmation système. D'autre part, le langage qui peut véritablement faire de l'ombre au C n'est autre que le C++ qui, si on s'y prend correctement, nous permet les mêmes joyeusetés tout en ajoutant 'encapsulation et les templates dans l'équation. Enfin, le C oblige, certes, à se soucier de la gestion de la mémoire mais cela permet, entre autres, de gérer la dite mémoire comme on l'entend, sans compter sur le fait que cette gestion, aussi basique puisse-t-elle être, ne devrait pas relever de la gageure pour quiconque avec déjà quelques décennies d'expérience en C.

[commandantFred]

Je rejoins plus ou moins Kannagi. Le C a encore toute sa place dans la programmation embarquée, même s'il y a une couche Embedded Linux intermédiaire; il en va de même que la programmation système. D'autre part, le langage qui peut véritablement faire de l'ombre au C n'est autre que le C++ qui, si on s'y prend correctement, nous permet les mêmes joyeusetés tout en ajoutant 'encapsulation et les templates dans l'équation. Enfin, le C oblige, certes, à se soucier de la gestion de la mémoire mais cela permet, entre autres, de gérer la dite mémoire comme on l'entend, sans compter sur le fait que cette gestion, aussi basique puisse-t-elle être, ne devrait pas relever de la gageure pour quiconque avec déjà quelques décennies d'expérience en C.

Okay, je suis un fan absolu de C. C'était mon premier job, mes premières émotions de developpeurs...

J'ai loué sa simplicité et son rapport simple avec le système jusqu'à ce que...
...je comprenne que c'est aussi sa principale faiblesse ! C n'installe pas de framework compliqué, arbitraire, son framework à lui, c'est le CPU et c'est là que le bas blesse. Car s'il sait très bien optimiser la vitesse en adressant les registres, la pile système (celle qui est pointée par CPU->SP), il n'est pas moins très standardisé dans leur usage et il n'a pas été difficile aux pirates d'utiliser cette simplicité à leur avantage. Stocker les adresses de retour de fonctions sous la pile du CPU était limpide dans les 70's. Aujourd'hui, c'est une faille de sécurité majeure.
Ne pas vérifier le dépassement des chaines et des tableaux, se contenter de les ajouter sur le tas était tellement logique... Aujourd'hui c'est devenu la première porte d'entrée des trojans !!

Alors, j'ai déchanté un peu.

Sur le C++ , je suis plus mitigé. Je crois qu s'il était vraiment réussi, il n'y aurait pas autant de prétendants à la même filiation avec le vénérable ancêtre de Kernighan et Ritchie.

Sa seule spécificité consistait à hériter le link statique mais Go s'est justement invité dans cette singularité en ajoutant une vraie couche de gestion mémoire. C++ est terriblement hypersensible aux versions de compilateur, versions de dll.... Dés qu'on change un byte du système, il faut recompiler...

[mister3957]

Décidément je ne comprendrai jamais ces guéguerres entre langages..

Pour un projet de A à Z, j'ai fait les choix :
- HTML5 / CSS3 / JS pour la partie front
- NodeJS pour la partie back / services
- C++ en méta prog pour la structure du moteur de calculs (embarquée dans un module NodeJS)
- C pour les opérations de calculs
- Python pour différents traitements annexes
- Java pour l'appli Android

Pourquoi sans cesse vouloir distinguer un langage d'un autre ? Ils ont chacun leurs avantages et chacun leurs inconvénients, il faut juste les utiliser au bon endroit au bon moment selon le besoin c'est tout.

Ça m'a fait rire ma dernière expérience "on veut une full stack JS comme ça tout le monde connait, ça fera du temps de formation en moins et chacun est interchangeable".. Résultats mitigés

[pfeuh]

Hello,

Prenons un jeu à coder pour une rétro-machine, genre ATARI 800, MSX, ou Amstrad: Le jeu en lui-même tout en C (assembleur pour l'Atari, pas de C performant sur cette machine)... Mais tous les outils de développement en python: Générateur de fontes, image converter, midi vers tables de fréquences pour la musique, génération de map, exécutable vers fichier ou ROM dédié à la machine, etc... Le seul programme nécessitant vraiment de l'efficacité est le jeu lui même.

Prenons un capteur genre température ou pression atmosphérique sur un 8051: Le capteur en lui-même tout en C ... Mais tous les outils qui tournent autour en python: Génération de lookup-tables (compensations et autres), réception de données sur PC, stockage pour csv ou base de données, etc... Le seul programme nécessitant vraiment de l'efficacité est le capteur lui même.

Vous allez me dire que le 8051 est devenu bien trop cher comparé à des bêtes de course à deux ou 3 dollars comme les STM32 et autres. Que le pourcentage de gens accrocs au rétro-computing est très faible. C'est vrai. Avec les microcontrôleurs d'aujourd'hui, , on ne programme plus, on clique. Finies les contraintes de taille mémoire, de stabilité, de compacité du code et pire que tout la factorisation... Le niveau baisse lamentablement. De même qu'un bachelier d'aujourd'hui n'est pas sûr d'avoir un certificat d'études d'il y a cinquante ans, un ingé d'aujourd'hui n'est pas sûr d'avoir un bac d'il y a cinquante ans. D'abord la langue française était incontournable, je n'en vois pas beaucoup sur ce fil qui conjuguent correctement, ça pique carrément les yeux. Je constate que le progrès nous pousse vers la médiocrité, et c'est une tendance générale, il n'a pas de raison que le développement ne suive pas le mouvement.

Dans ce contexte, je pense que le C est condamné à plus ou moins longue échéance. Mais comme l'humanité l'est aussi, je m'en fous un petit peu. D'ici une cinquantaine d'années, plus personne ne saura ce qu'était l'humanité, alors le langage C...

[lulu7]

Le niveau baisse lamentablement. De même qu'un bachelier d'aujourd'hui n'est pas sûr d'avoir un certificat d'études d'il y a cinquante ans, un ingé d'aujourd'hui n'est pas sûr d'avoir un bac d'il y a cinquante ans. D'abord la langue française était incontournable, je n'en vois pas beaucoup sur ce fil qui conjuguent correctement, ça pique carrément les yeux. Je constate que le progrès nous pousse vers la médiocrité, et c'est une tendance générale, il n'a pas de raison que le développement ne suive pas le mouvement.

Pas d'accord.

L'informatique à évoluer. On est plus sur uniquement des petits programmes en C/ASM. Tu as d'autre domaine qui sont apparues. Par exemple l'ia ou le big data.
Tu est peut être bon pour coder des micro contrôleur mais incapable de faire un algo génétique ou un map reduce.

Faut arrêter de croire que coder en C/assembleur c'est être supérieur aux autres, et faut arrêter de dénigrer les autres. Ceux qui font du web sont par ailleurs assez souvent dénigrer a tord.

Et sinon je trouve que l'informatique évolue dans le bon sens. Avant on faisait des petits programmes en C/ASM très buggé. Aujourd'hui on mets l'accent sur la stabilité (tests fonctionnel, unitaires...) et l'ingénierie des exigence.
On ne peu pas comparer un tetris/pong à Witcher 3 en terme de complexité. Faire un open world en assembleur/C c'est juste pas possible.
Au lieu de se la péter avec un pong en 2D sur Atari je trouve bien plus impressionnant Minecraft coder en Java.

une petite capture qui montre l'évolution et justement l'augmentation du niveau des jeunes (et non une régression)


Vous pouvez me dire : je trouve les logiciels d'aujourd'hui plus buggé qu'avant
Je vous répond que le complexité à augmenter de manière exponentiel et c'est l'oins d’être vrai. Les vielles versions de windows/Linux avec 100000 lignes de codes était très instable. Aujourd'hui les dernières versions de ces os avec plusieurs millions de lignes de code sont beaucoup plus stable. Une grosse partie du code des distribution linux sont coder en python (hors kernle). T'installe une debian/ubuntu/rhel/fedora ou autre si tu enlève python t'a plus grand chose, tu n'as plus apt/yum déja.

Et encore une fois apt/yum sont plus utile/intéressant qu'un vulgaire pong 2d sur Atari, enfin ce n'est que mon avis.

[mb90821]

Hello,

Prenons un jeu à coder pour une rétro-machine, genre ATARI 800, MSX, ou Amstrad: Le jeu en lui-même tout en C (assembleur pour l'Atari, pas de C performant sur cette machine)...

Perso, j'irais vers Atari 2600, Colecovision, Intellivision.

Que le pourcentage de gens accrocs au rétro-computing est très faible.

J'en suis.

Avec les microcontrôleurs d'aujourd'hui, , on ne programme plus, on clique. Finies les contraintes de taille mémoire, de stabilité, de compacité du code et pire que tout la factorisation...

Moi, ça me fascine. Par analogie, conduire une Corvette 1968, c'est cool, mais j'aimerais beaucoup mieux la Tesla Roadster.

Le niveau baisse lamentablement. De même qu'un bachelier d'aujourd'hui n'est pas sûr d'avoir un certificat d'études d'il y a cinquante ans, un ingé d'aujourd'hui n'est pas sûr d'avoir un bac d'il y a cinquante ans.

Nous avons droit à la calculatrice et à nos livres aux examens. Heureusement!

D'abord la langue française était incontournable,

Antidote

C est condamné à plus ou moins longue échéance. Mais comme l'humanité l'est aussi, je m'en fous un petit peu. D'ici une cinquantaine d'années, plus personne ne saura ce qu'était l'humanité, alors le langage C...

Elon Musk est venu nous sauver.
Jeff Bezos d'Amazon et Blue Origin vient de dépasser la fortune de Bill Gates.

À cheval sur leurs fusées, accroche-toi bien, on va aller sur Mars bientôt!

[CaptainDangeax]

Pour le thermostat qui fait "clic" quand on tourne le potar, il y a beaucoup moins cher et plus fiable q'un µC. Ca s'appelle un bilame (cf. wiki) et ça fait le job même en l'absence de toute alimentation. C'est juste une petite pièce de métal qui fait à la fois interrupteur et sonde de température... M'enfin c'est juste pour l'exemple qui tombe mal. Pour le reste je suis amplement d'accord. Pour les controleurs genre atmel , y'a pas mieux que C.

Désolé commandantfred mais tu te plantes. La bilame, c'était sur les convecteurs d'il y a 30 ans avec une température qui variait en 15 et 25 degrés dans une heure. Regarde ton chauffage électrique aujourd'hui : plus de clic parce qu'il y a un TRIAC et la petite led clignote, la régulation de température se fait par le rapport cyclique. Et comment fait-on pour avoir une régulation de température avec le rapport cyclique ? On utilise un microcontrôlleur. Le moindre Microchip PIC (tm) à quelques pouièmes de centime en volumes embarque un timer/counter qui peut être utilisé en PWM, plusieurs ADC et même un comparateur. Ajoute une bête CTP à ton circuit et ton programme est tout simple : Si température < consigne augmente rapport cyclique sinon diminue rapport cyclique. Avec le bon taux d'amortissement sous la forme d'une moyenne des températures sur un temps donné, même pas besoin de quartz le circuit rc interne à 32,768 kHz suffit amplement.
Quant à la question du coût, le procédé industriel pour faire coller ensemble 2 métaux sans utilisation de métal d'apport pour la fabrication de ta bilame n'a rien de trivial, et n'oublie pas les contacts anti-corrosion à mettre au bout. Quant à la compatibilité d'un contact ouvert à l'air libre qui commute du 220 V AC avec une atmosphère potentiellement explosive, je préfère ne pas m'étendre sur le sujet. Donc ta bilame, elle est au musée.

[vivid]

"Un des gros soucis avec le langage C est que le développeur doit se soucier en permanence des problèmes de gestion de la mémoire, des caches, entre autres, estime Eric Raymond"

Un branleur....

[lilington]

"Un des gros soucis avec le langage C est que le développeur doit se soucier en permanence des problèmes de gestion de la mémoire, des caches, entre autres, estime Eric Raymond"

Un branleur....

+1 et -1 en meme temps. En faite oui c'est un soucis mais en meme temps c'est la tout l'interet du C. c'est pas un defaut, c'est volontaire. Le veritable probleme AMHA c'est que ca demande aux gens de reflechir a autre chose que juste le developpement du logiciel en question. c'est vue comme un perte de temps et source de bug surtout par le chef d'equipe.

Faut arrêter de croire que coder en C/assembleur c'est être supérieur aux autres, et faut arrêter de dénigrer les autres. Ceux qui font du web sont par ailleurs assez souvent dénigrer a tord.

Et sinon je trouve que l'informatique évolue dans le bon sens. Avant on faisait des petits programmes en C/ASM très buggé. Aujourd'hui on mets l'accent sur la stabilité (tests fonctionnel, unitaires...) et l'ingénierie des exigence.

Il ne dit pas (du moins avec ma comprehension) que les nouveaux languages sont mediocres. Ce qu'il dit c'est que avec toutes le couche d'abstraction la nouvelle generation ne sais pas et NE PEUT PAS savoir ce qu'elle fait reellement. Et honetement avec les super nouveaux langages, il y a des choses que je fais sans vraiment comprendre ce qui ce passe. et vous de direz OSEF et oui c'est vrai mais en meme temps va prouve juste qu'on se dirige vers une diminution des competenses. Je pense que c'est bon pour le bussness mais mauvais pour l'intellecte.

Le C en un langage suffisement haut niveau pour etre accessible a tous et suffisement bas et proche de l'assembleur pour demander au cerveau de faire autre chose que pisser du code. Comme beaucoup le repete c'est un outils l'aimer ou le detester n'a aucun sens, mais le voir comme un outils vous permettant de faire beaucoup de chose et en plus permettant a votre cerveau de rester actif est une maniere plus saine de voire le C.

[ilapasle25]

Cela s'appelle l'évolution.
Ces couches d'abstractions permette de ce concentrer sur autres choses ! cela permet de créer des spécialisations.

Vous ne savez pas chasser/élever des chèvres cela ne vous empêche pas de manger et cela vous permet de vous concentrer dans des taches que vous considérer plus importantes.

Une baisse de niveau à mon sens se caractériserait pas l'impossibilité des jeunes à concevoir de nouveaux produits/besoins.

Ce qui n'est pas le cas. Au lieu de perdre leurs temps dans ces futilité (gestion de la mémoire...) ils délègue cela à d'autre et ce concentre sur l'essentiel.
Résultat : ils maîtrisent d'autres compétences. Par exemple ils maitrise la programmation objet en java au lieu des pointeurs/structures en C. OU bien le langage OCL.
c'est un autre monde, une autre discipline qui enrichie l'informatique
C'est un autre monde