Version imprimable
Je ne m'en sers que sur du legacy code -- comme patcher openjpeg, ou m'interfacer avec du C -- je tourne au C++ le reste du temps (industriel -> spatial et cie). Le RAII et la généricité me manquent trop pour me restreindre volontairement au C autrement. Dit autrement, je fais parti des gens pour qui le "encore" s'applique.
Je suis essentiellement sur de l'unix (Solaris il y a longtemps, linux PC et embarqué).
C'est surtout pour cette raison que j'ai préféré utilisé ce mot dans le titre car souvent le C est de plus en plus utilisé en second plan voir plus du tout du point de vu professionnel comme dans mon cas où mon prochain travail va être axé sur la plateforme .Net mais personnellement du C à la maison lorsque j'ai un peu de temps.Citation:
Envoyé par Luc Hermitte
Citation:
Envoyé par Franck.H
Idem, je n'ai pas envie de perdre mon savoir donc je le revalorise @home :mrgreen:
J'utilise le C uniquement à titre personnel pour programmer une carte Arduino, pour un projet qui ne réclame pas une connaissance approfondie du langage.;)
Au bureau, pour mes collègues de travail, je ne connais pas le C. :roll:
Ça me permet de rester à l'écart de la maintenance de certaines procédures écrites par des programmeurs "rusés" : pointeurs de pointeurs de pointeurs, indices de tableaux passés en référence à des fonctions qui les incrémentent et autre joyeusetés... sans compter les accès à Oracle et le tout sans aucun commentaire.:aie:
Plusieurs heures pour comprendre quelques lignes de code :cry:
Je préfère laisser ça à d'autres :oops:
Bonjour,
J'utilise le C pour un usage personnel sur de la programmation système et du développement embarqué.
Au bureau, le C est utilisé de manière très marginal, préférant l'utilisation des langages et de l'assemblage de frameworks.
A+
charlespf
moi j'utilise le C pour tout...
Personnel ou professionnel. Il faut dire orienté 100% unix/linux
Du graphisme (la Xlib), du code mpeg ou gif ou tiff ou.. pour les images ou films, des maths, des clients/serveurs..
Appris sur le tas par nécessité (IHM en X11/Motif en 89) il me covneint, est souple, et surtout permet de tout faire. En ayant une base de progs et de blblios persos (au cours des projets), me permet de ne pas me poser de questions et faire du code rapide, précis, efficace tant en temps qu'en mémoire..
De plus indépendant d'add-on ou blibliothèques externes (Boost ou autres), en termes de structures de projets et code c'est bien plus maintenable/découpable logiquement que les innombrables fichiers/classes/interdépendances des langages objets...
Pour l'autonomie, la puissance, la rapidité, le contrôle des ressources utilisées... Non-informaticien de base, tout ce que je souhiate c'est un lanagge qui me permet de faire ce que je veux de manière logique sans m'encombre l'esprit de concepts inutiles... (le seul concept à assimiler est celui des pointeurs)
:)
Ce n'est pas trop le fil pour cela (si des modos veulent forker, je comprendrai), mais je ne vois pas le rapport.Citation:
Envoyé par souviron34
Ce qui fai(sai)t défaut au C++, le fait obligatoirement au C. Il faut donc se rajouter toutes les choses que l'on se rajoute en C++ -> pthread/POSIX (pour le système -- j'exclus le besoin de portabilité vu que tu es en 100% nixoides), plein de trucs chez apache, voire même une lib pour les conteneurs et algos de base (glibc ?). Plus éventuellement des libs métiers (pour le calcul scientifique, d'orbitographie, etc).
Cela fait tout autant, sinon plus de lib tierces (ou du moins hors du périmètre du C99), à aller chercher. Il n'y a pas de différence avec ce que nous faisons en C++ (puisque tu l'évoques indirectement) avec boost (au détail que boost+Qt ont un petit côté de standard de-facto ; comme apache, glibc, etc).
J'ai même envie de dire que l'emploi de ces standards de-facto est largement préférable aux solutions maison, pour lesquelles il faut assurer une maintenance, et plus ennuyeux: il faut former les nouveaux membres des équipes de devs pour qu'ils apprennent à s'en servir. (Bon, si on veut se rendre indispensables, elles sont certes préférables ^^)
Si maintenant un système est mal découpé/conçu, ce n'est pas parce qu'il va avoir été mis au point avec des technos objets, services ou autres. C'est plutôt le manque d'expérience/recul qui va faire toute la différence. S'il faut vraiment chercher un avantage au C, peut-être est-ce dû au fait qu'il ne reste dessus essentiellement que des développeurs motivés. Les débutants qui conçoivent (mal) doivent s'y faire plus rares que sur les autres technos qui ont plus le vent en poupe. On rejoint là, le coup de gueule de Linus Torvald qui se réjouit de l'élitisme imposé par ses choix de technos. (où comment recentrer le débat vers les migrations de développeurs)
C'est le point ou je suis assez d'accord , le langage C est un le langage par défaut dans apprentissage, et effectivement ceux qui reste dans ce langage sont ceux qui ont été motivé et du coup plus compétents , vu que les autres transites sur d'autre langages.Citation:
Envoyé par Luc Hermitte
Après de mon point de vue le C demande (trop ?) de rigueur a son programmeur donc seul ceux qui sont expérimenté sur ce langage peuvent l'apprécié , a mes souvenir quand j'ai débuté j'avais souvent des segfaults , fuites de mémoire ou autre et rarement une compilation réussi du premier coup :aie:
Il est vrai que ça doit faire fuir pas mal de monde.
Pourquoi le sondage est-il à une seule réponse?
Le forum ne permet-il pas de faire des sondages avec des cases à cocher plutôt que des boutons radio?
Avant j'utilisais le C surtout par choix, surtout pour du code "réutilisable". Mais depuis, j'utilise beaucoup plus souvent le C++ et le C# pour la stabilité qu'ils offrent par rapport au C.
Je m'efforce quand même de donner à mes bibliothèques une "interface C" toutefois, pour plus d'interopérabilité.
J'utilise le c lorsque je n'ai pas le choix par exemple lorsque le système que je programme a ces API publiée en C uniquement, ou bien lorsqu'on me l'impose
On peut forker ;)Citation:
Envoyé par Luc Hermitte
En gros, j'aime pouvoir fournir du "clé en main", un binaire...
La seule biblio "externe" à laquelle j'ai eu recours en 25 ans a été la runtime de X11/Motif (ou lesstiff sous linux).
Que ce soit libjpeg, libtiff, les Graphics Gems, les mpeg encoder/ecoder, etc, tout un tas de code ne nécessite strictement que la lib standard...
Encore faut-il utiliser des threads ;)Citation:
Envoyé par Luc Hermitte
Les trucs métiers bien entendu..Citation:
Envoyé par Luc Hermitte
Au détail près que , comme tu dis, Boost+qt+X11, alors que X11+Motif/lesstif ;)Citation:
Envoyé par Luc Hermitte
Ce qui me dérange, c'est qu'il n'y pas de séparation claire : X11+add-on pure IHM
Java, VC++, et autres, on mélange des fonctionalités IHM avec des choses indépendantes IHM..
Peut-être suis-je trop "formaté" par la vision en couches, qui me semble parfaite...
Je suppose que ça doit dépendre des environnements/projets...Citation:
Envoyé par Luc Hermitte
Dans mes boulots, il est toujours préférable d'utiliser des trucs maisons, et les cas où cela n'a pas été le cas virent souvent au drame...
Bonjour,
Dans le monde telecom, comme dans le monde bancaire, il y a beaucoup de C, et le peu de C++ que j'ai vu etait tellement mal ecrit que j'aurais prefere y trouver de l'assembleur....
C'est surement pour de mauvaises raisons, c'est a dire principalement pour des raisons "historiques", des vieux programmes qui etaient en C, et donc on continue avec ce langage.
Dès que des traitements algorithmes lourds sont à effectuer j'utilise le C. j'ai fait récemment une application pour smartphone android en java de traitement de fichiers vidéos qui durait bien trop longtemps (attendre plusieurs dizaines de minutes un résultat sur un smartphone c'est rédhibitoire). J'ai écrit la routine de traitement en C, appelée depuis java (android-ndk et jni). Le temps de traitement a été divisé par SOIXANTE !! Un traitement qui durait 5 minutes ne durait plus que 5 secondes. L'application devenait utilisable.
Il y a quelques années je me disais à quoi bon essayer de gagner du temps au niveau de la programmation, il n'y a qu'à attendre les progrès (fulgurants il est vrai) des processeurs. mais là j'étais tombé sur un contre-exemple.
Les programmeurs qui n'ont pas commencé par le C ne se rendent pas compte de la différence d'efficacité qui existe entre ce langage et ses successeurs C++, java, C#..., surtout que les enseignants toujours attirés par la nouveauté attribuent aux nouveaux langages des avantages qui n'en sont pas. Un professeur de grande école d'ingénieur qui a enseigné tous ce langages me disait "au début je parlais des avantages du nouveau langage que j'enseignais, et plus tard je ne disais plus avantages, mais caractéristiques".
Je programme depuis 1966 avec des langages généraux : PAF, Fortran, APL, Cobol, Basic, Forth, C, C++, Java.. et des langages spécifiques d'applications : Lisp, PostScript, Latex, Matlab, Scilab, Maxima, HTML...
Heureusement que la retraite est arrivée !! A mes débuts, on faisait quasiment tout avec un seul langage. Maintenant plusieurs langages sont en compétition dans chaque domaine d'application.
Il n'y a pas d'instance magique qui puisse réguler ou orienter tout ça.
D'après moi, ce forum est utile car il permet aux individus, comme moi de livrer leur expérience. Malgré sa longueur (de mon expérience), je ne sais que conclure et ne conclurait pas, sinon qu'en disant que si un langage à su faire sa place c'est qu'il a dû à une époque correspondre à un besoin ?
Pour terminer, je rappellerai qu'en ce qui concerne les traitements algorithmiques lourds le C reste le langage le plus efficace en terme de rapidité, bien au-delà des chiffres généralement admis. Pour vérifier, faites vous-même vos propres tests.
Meme si globalement, les programmes C sont plus performants que les programmes Java, il y a aussi des contre-exemples qui permettent d'avoir des performances meilleures en Java qu'en C (si si). Le truc, c'est qu'on n'a pas toujours le temps de faire un prototype dans tous les langages pour savoir lequel sera le plus efficace.Citation:
Envoyé par mllibre
j'utilise essentiellement 2 langages C et pythons
aussi bien a la maison qu'au boulot.
quelques soit ce que j'ai a faire je pense d'abort C (limite du fanboyisme) avant que la raison me revienne et que je reflechit a voir si le faire en python ne serai pas plus simple (boulot). parcontre a la maison c'est C uniquement quelque soit le projet meme si ca me demande de passer les 3/4 du temps a reinventer la roue pour des fonctions qui existent dans d'autre langages.
sur je dernier point je dirai comme un certain Tyron Lanister qui utilise les livres pour eguiser son unique arme, moi j'utilise le C pour la meme tache.
a- OK. Je vois.Citation:
Envoyé par souviron34
Le C++ (je ne parlerai pas de Java) a longtemps souffert d'une bibliothèque standard trop dépouillée par rapport aux attentes des utilisateurs. Du coup, pour chaque bibliothèque qui a voulu se positionner sur un sujet, prenons les IHMs, en fonction de la date de création de chaque bibliothèque (p.ex. avant 98, ou à cause de compilos qui trainaient les pieds à se rendre conformes), il a été nécessaire à certaines de réinventer plein de choses pour être portable. Ces bibliothèques sont devenus des frameworks. Et toujours plus loin dans ce soucis de "je veux que mon framework fasse tout pour mon utilisateur qui ne veut pas de 50 COTS/lib externes" (un peu à l'opposé de la philo *nix: une tâche == un petit outil dédié) ils se sont mis à faire 150.000 trucs.
b- Chez nous, le recours à des composants libres, ou "juste" open-source, est de plus en plus fréquent. Notre objectif n'est jamais de réinventer la roue, mais de fournir des produits spécifiques qui répondent aux attentes des clients.
Pour l'industriel, l'efficacité première est le coût de développement bien souvent. Si les besoins client dictent des contraintes de performances plus serrées à tenir. Ben ... ce n'est jamais qu'une exigence de plus à remplir.Citation:
Envoyé par mllibre
Mais je soupçonne que tu voulais parler de performances/vitesse d'exécution.
Pour le C++, je ne suis pas d'accord avec ton affirmation. Il est au moins aussi rapide que le C. Si un truc qui vient du C++ est plus lent qu'un équivalent du C, il suffit de prendre l'équivalent du C pour assurer des perfs au moins aussi bonnes. (typiquement flux C++ vs I/O du C). Quand un truc du C++ est plus rapide, on le prend (std::sort VS qsort). En perfs, on peut disposer du meilleur de chacun des deux mondes avec le C++.
a : tout à fait :) c'est exactement ça qui me dérange... Et qui me hérisse un peu le poil quand on me dit "c'est plus facile à maintenir, c'est de plus haut niveau, etc etc etc".. Un découpage soigné est beaucoup plus facile à maintenir, faire évoluer, et même concevoir... Et il me semble que avoir des briques élementaires, que ce soit sous formes de biblos "à soi" ou "spécialiséées", est plus simple que quand tu as partout une dépendance sur un ramasse-miettes de 30000 fonctions/objets... (sans parler du temps de compilation : le dernier gros projet sur lequel j'ai travaillé, c'était 20 minutes les 5 exécutables en C, 4h30 les mêmes 5 en C++, à cause des classes imbriquées, des dépendances, etc...)Citation:
Envoyé par Luc Hermitte
Comme je dis, je suis profondément marqué par les "couches", et le découpage "unixien", une tâche = un exé ou une tâche = 1 module/fichier... ça fait des répertoires sources simples, des gestions simples, une appréhension simple par un novice, une compil simple, une install simple, bref que des avantages à mon avis...
b- nous ne travaillons alors vraiment pas dans les mêmes domaines... ;) Dans les industries pour lesquelles j'ai travaillé l'efficacité première était la vitesse d'exécution et la parfaite adéquation du module avec la fonctionalité demandée (pas de code inutile), plus la notion de "secret industriel".. ... Le temps de dev et le budget venait - relativement - loin derrière....
Lorsque l'on vante les mérites d'un framework, on se place généralement du point de vue du manager ou du dev nouvellement arrivé. La philosophie "il ne faut pas réinventer la roue" vise généralement à assouplir la gestion du personnel, c'est à dire remplacer un dev par un autre. Coder de façon modulaire et efficace relève de pratiques transverses valables aussi bien en objet que dans d'autres paradigmes. J'ai parfois pu constater que l'objet sert de prétexte pour ne pas prendre en compte ces pratiques (j'ai également vu des lib en procédural qui ne les respectaient pas non plus :aie:).
Ce n'est pas qu'il ne peut pas y avoir de framework simple et efficace, c'est plutôt que ces framework doivent prendre en compte d'autres considérations. Parmi elles, le fait que la prise en main de la lib doit être rapide possible. La conséquence directe est qu'utiliser un framework, c'est être dans l'a peu près aussi bien au niveau architecture qu'au niveau fonctionnalité.
Les archis des bibliothèques sont pensés pour retrouver les méthodes facilement et non pour comprendre le fonctionnement du projet sur lequel on travaille.
Au niveau fonctionnalités, c'est parfois des traitements superflu ou insuffisant selon les cas. C'est aussi beaucoup de code inutile qui pourrait ne pas être présent. Moins de code à lire et moins de fichiers à parcourir joue sur la compréhension de l'ensemble.
Plus généralement, l'utilisation de framework participe au nivellement par le bas des développeurs. C'est le but implicite. Il s'agit de permettre au développeur de ne pas avoir a comprendre l'élégance caché derrière un jeu de pointeurs abscons au premier abord avant d'être enfin productif.
si vous voulez faire ECPG SQL embarqué en C
et avoir une super macro (Dll) qui gère vos tables
moi j'utilise le "C" voir http://postgresql.developpez.com/doc...tion/francais/
maintenant vous couplez cela avec du C++ et vous avez une application avec très peu de lignes pour faire de la gestion :ccool:
du "C" très pratique pour faire un mini driver pour les douchettes et manipuler les datas
'Lut,
j'utilise le C pour le taf (progiciel logistique portable sur Windows et Unix).
Et je prie pour que cela dure.
Perso, je fais aussi du C++ et Java parce que les lib standard sont quand même souvent un gain de temps et que j'aime bien l'approche OO de ces langages.