Reprise du message précédent :

Je comprends maintenant pourquoi tu te dis Gaulois

'avais pas vu ta réponse. Oui bien sur, mais bon, un random gcc sur un random PC a de fortes chances d'etre comme ça

 
J'avais pas vu non plus.  
 
Bizarrement, l'hypothese qui a le plus de chance de ne pas etre respectee n'est pas explicitee: il faut des char signes.
 
Des char sur plus de 8 bits se trouvent entre autres avec des DSP.

Tiens, ça c'est expliqué dans les premiers chapitres de mon bouquin!    
 

Oui j'avais remarqué, j'sens que ça va m'plaire tout ça!
 
 
EDIT : Au fait, tout ce que vous racontez à propos des gcc, dsp, et tant d'autres...C'est un peu du charabia pour moi!
Donc je relirais tout ça une fois que j'aurais terminé le bouquin pour voir si j'comprends mieu!  

 
gcc: le compilateur C du projet GNU; GCC: GNU Compiler Collection, la suite de compilateurs (C, C++, Ada, Fortran) du projets GNU.
 

 
Digital Signal Processor: processeur specialise pour le traitement du signal.

Je vois pas pourquoi il serait ammené a coder sur un dsp dans un usage personnel.
 
Vous etes vraiment allé beaucoup trop loin.
 
Un Programmeur > tu m'as eclairé, j'ai revisé un peu et c'est bon. j'avais collé quelques notions d'ARM dans la partie de mon cerveau consacrée au x86 . Merci

On est homo sapiens, pas des bourriques. L'intérêt c'est d'apprendre correctement histoire de ne pas perdre son temps.

D'un autre côté, ça veut aussi dire "ne pas apprendre des choses inutiles pour ne pas perdre son temps"

 
Il y a d'autres lecteurs que l'auteur du premier message.

On essaie juste de corriger les malappris. C'est pas notre faute si la majorité des professeurs / ouvrages enseignent le C au défi même de sa nature et de son histoire. Si tu tombes sur un cours qui n'explique en introduction que le C est un langage à la définition sans ambigüité, fait pour être portable et que c'est ce souci de portabilité et de facilité d'implémentation qui prime partout, c'est là que tu peux te barrer.
 
A propos des profs, c'est toujours très intéressants. T'en trouves pas mal, eux même malappris, qui t'enseignent limite un dialecte / pré ANSI. Genre qui t'enlèves 1 point quand tu fais une affectation de struct (expérience perso) ou qui te font des cours sans <stdio.h> parce que c'est pas standard et que open/read/write/close c'est plus 'rapide'.

 
  toute ma vie resumé en un post

Taz >> Il faut savoir si on fait du C comme support de cours (d'algo par exemple) où si on suit des cours de C pour apprendre véritablement le C, ce n'est pas la même optique et ça explique que le C n'est pas forcément dans le premier cas la priorité des profs.  
J'ai tendance à penser qu'on ne peut pas apprendre véritablement le C à la fac et qu'il faut se mettre les mains dans le cambouis avec des problèmes réels pour commencer à comprendre sa douleur. C'est comme une langue étrangère, tu l'apprends à l'école et quand tu vas à l'étranger tu te rends compe que tu ânnones trois mots et que certains te reprennent dans le meilleur des cas ou se foutent de ta gueule dans le pire, comme ici.

 
Le C est un langage a la définition imprécise, laissant énormément de choses volontairement non définies, créé pour implémenter Unix sur un PDP-11 en dérivant d'un langage non typé destiné à des machines adressable par mots.  Il a eu du succès, ce qui a amené à un désir de standardisation.  Celle-ci s'est retrouvée à faire des compromis entre définir plus clairement le langage et décrire l'existant -- c'est ce dernier point qu'elle a favorisé.

pas du tout d'accord. autant apprendre à écrire en zappant l'orthographe.

Moi suis plutôt d'accord avec Trap D (sans verser non-plus dans l'excès que tu cites). Il y a des gens qui n'ont besoin que d'avoir une orthographe correcte pour leurs besoins quotidiens (rapports, conférences, etc.) et ceux qui font hypocagne. Idem en C. Certains, dont l'infomatique n'est pas leur premier métier, n'ont qu'un besoin "superficiel" du C. D'autres vont impérativement avoir besoin de jongler avec les pointeurs doubles ou triples, les copies de structures contenant des pointeurs (deep/shallow) et autres amusements de ce type...

Pas d'accord. Le C est un langage trop permissif pour etre manie a la legere. L'adage dit qu'en C, il est facile de se tirer une balle dans le pied, et c'est ce que font a peu pres tous les gens qui debutent dans ce langage.  
 
Le probleme avec le C est que meme pour un besoin "superficiel" c'est difficile d'ecrire quelque chose de correct ; j'ai des amis qui font de l'informatique financiere et qui n'ont qu'une vision tres floue du C ; OK ca ne les empeche pas d'utiliser ce langage, par contre regulierement j'ai droit a un coup de fil de leur part parce qu'ils ont une erreur qu'ils ne comprennent pas. Le plus souvent ca correspond a l'utilisation de char* sans allocation prealable, ou de close sur des FILE*, ou des debordements de tableaux ...  
 
Leur philosophie est "si ca compile, c'est que ca doit etre bon", ce qui est carrement faux en C. Ces gens la n'ont qu'a faire du Matlab au lieu d'utiliser un  
langage pour informaticiens.
edit : Le probleme du C est qu'il n'est pas possible pour debutant d'intuiter si une construction syntaxique va poser probleme ou non. Du genre, l'emploi de == pour comparer des chaines, des malloc sans free (ceux qui viennent du java sont des champions dans le domaine), ou encore la copie de tableaux qui affecte le pointeur local, j'en passe et des meilleures ...

Au moins le malloc sans free ça fait pas des programmes invalides, au pire il boufferont un peu trop de ram.
 

 
À te lire on dirait que savoir programmer en C fait de toi un membre de l'élite.
Assez hautain comme raisonnement.
 
La vérité c'est que le C est sémantiquement très faible, et beaucoup de débutants, même ayant une bonne expérience en prog dans des langages de haut niveau se cassent la gueule en le prenant pour un langage haut niveau.
.... "un langage pour les informaticiens" .... ouai, c'est comme dire que le langage utilisé par les hommes préhistoriques est "un langage pour les humains".... oui c'était le cas à une certaine époque.... et puis on a évolué, les informaticiens aussi devraient évoluer.

Je suis d'accord avec toi : le probleme se trouve dans le fait que le C ne se comporte pas comme d'autres langages de haut niveau mais qu'il y ressemble. C'est exactement ce que je dis quand je dis dans mon post precedent "Le probleme du C est qu'il n'est pas possible pour debutant d'intuiter si une construction syntaxique va poser probleme ou non", sous-entendu "dans la mesure ou beaucoup de constructions syntaxiques pieges ressemblant a celles des langages de haut niveau (exemple du == pour comparer des chaines) sont autorisees".  
 
Mais savoir programmer en C ne se limite pas a en connaitre les pieges, ca necessite aussi de savoir implementer tout ce qui n'est pas acquis d'office dans les langages de haut niveau (initialisations automatiques, gestion de memoire, passage de parametres par reference, manipulations de strings, etc ... ) et ca, ca implique un travail supplementaire. Le C, C difficile (jeu de mot pourri, desole) et c'est pour ca que les langages de haut niveau existent ...
 

Tu interpretes mal ce que je dis. Ce que j'entends par "langage pour informaticiens" c'est un langage qui ne devrait etre utilise que dans le cas ou l'application est purement informatique : drivers, API systeme, etc ... bref, les programmes dont la vocation n'est pas de calculer quelque chose et ou c'est normal de mettre les mains dans le cambouis parce que c'est du cambouis qu'on manipule de toutes facons (ca n'est pas exactement la meme chose que "langage de bas niveau" mais c'est tres proche). Ce sont les personnes qui travaillent sur ce genre de programmes que je nomme - peut etre a tort - informaticiens. Le C est adapte a l'ecriture de ce genre de programmes et on ne pourra jamais s'en passer (autant vouloir ecrire un OS en PHP).
 
Dans les domaines applicatifs (les programmes qui modelisent un probleme qui ne vient pas de l'informatique) Je suis completement d'accord avec toi sur le fait qu'il faille evoluer, et c'est precisement ce que je dis - avec un ton exaspere, soit - quand je conseille d'utiliser matlab dans le cas de l'informatique financiere. Je deteste utiliser le langage C et ca m'horripile de voir que ce choix est souvent fait alors que dans 9 cas sur 10, il aurait mieux valu autre chose. Et qu'on m'epargne l'argument de la rapidite d'execution, principale justification de ce choix stupide. Le plus souvent le langage est mal utilise (allocations de memoire dans la boucle critique ou recopies a tout-va) si bien qu'au final c'est plus si rapide.
 
Et pour finir, quelque chose de strictement personnel, mais qui colore le ton de mes messages. Oui, je suis exaspere par les gens qui font du C "a la legere" parce que j'ai souvent a reprendre du code C mal ecrit, alors que ca aurait pu etre evite. Dernierement, j'ai du porter un programme ecrit par un gars qui ne savait pas qu'on pouvait caster le type d'un tableau. Ce programme manipule des images sur 16 bits, tous les tableaux sont adresses par des BYTE*, et le programme est rempli de :

qui rendent le code imbitable, source d'erreurs,  et accessoirement plus lent. Bref, ca rend aigri de devoir bosser sur un tel programme...  
 
 
edit pour repondre a 0x90 : le malloc sans free ca depend a quel endroit ils sont, si c'est dans une boucle qui doit tourner en continu, il y a un moment ou y'aura plus de memoire et c'est generalement a ce moment la qu'on commence a se demander si on devrait pas faire des free de temps en temps ....

Autant gagner du temps => free(malloc(...))    

Tout ce que j'ai à dire, c'est que je trouve criminel l'apprentissage du C dans les fac et écoles, surtout lorsque le cursus des étudiant ne s'oriente pas vers des études approffondies d'informatique.
 
Effectivement, outre la difficulté inhérente de travailler avec un langage "non typé" (puisqu'on peut mélanger n'importe quel type avec n'importe quel autre en C, je l'interprète comme non typé) qui va avoir des comportement souvent contradictoires avec la sémantique des oppérateurs utilisés (== entre deux entiers vérifie bien l'égalité de des deux entiers, mais == entre deux chaînes, arrays ou éléments complexe en mémoire ne va vérifier que l'égalité des pointeurs par exemple), il pose d'autres problèmes...
Notamment des difficultés accrues pour tout ce qui est des traîtements de chaînes, d'interface graphique, ou simplement pour le débug -puisqu'un programme qui fait absolument n'importe quoi peut tout à fait compiler sans problème-.
 
Il existe d'autres langages haut niveau gratuits, souvent largement aussi répendus, plus riches grammaticalement, mais aussi plus simples. Que dans une fac d'économie on décide d'apprendre aux étudiants comment marche un CPU, why not, mais à ce moment, plutôt que de faire du C, autant leur apprendre quelques rudiments de l'ASM, dont les concepts resteront tout aussi valides que ceux du C -utilisation de registres corrects pour stocker une valeur, comparaisons, gestion de la mémoire, utilisation de piles, découpage d'algos en micro-instructions, etc.- puis se lancer directement vers des langages de haut niveau qui seront généralement bien plus utiles.
 
Par exemple, un mec qui fait HEC, il va être à coup sûr un grand consommateur de macros Excel : pourquoi ne pas lui apprendre le VBA ? Il a de grosses lacunes par rapport à d'autres langages, mais il a l'avangtage d'être simple, suffisament puissant pour illustrer des concepts, et surtout, il sera utile dans le parcours professionnel de l'étudiant.
Si les profs ne veulent pas utiliser de technos proprio, il existe l'équivalent d'OpenOffice, mais aussi Java ou C#, qui sont accessibles gratuitements, et adaptables sur différentes plateformes.
 
Bref, pour moi, le C (et même le C++) devraient être destinés uniquement aux personnes dont l'informatique va être le métier, et encore, même parmis celles-ci, seule une minorité en aura effectivement besoin : par exemple, j'ai jamais eu à écrire une ligne de C ou C++ pour le boulot, et je ne m'en porte pas plus mal.
 
A mes heures perdues, quand j'ai envie de me sodomiser le cervelent, je me lance en auto-didact sur des sources d'un jeu et ce que j'ai pu apprendre comme concepts à l'école avec l'ADA, ou au boulot avec VB et C# me suffisent amplement pour comprendre pourquoi mes modifs en C plantent (pas pour les corriger mais c'est normal, l'inverse est vrai aussi... un expert en C qui n'a jamais fait d'objet va avoir l'air bien con le jour où on va le mettre derrière un projet Java déjà tout fait et qu'il doit le modifier )

en même temps un expert en C qui a baroudé comprends pourquoi on a évolué vers des langages objets  
donc si il a jamais fait de C++/Java, c'est d'automatismes qu'il va manquer par rapport aux possibilitées du langage, mais une fois qu'il les a vu il les réutilisera...
 

Rien que dans mon DUT Info, on ne fait pas du C mais du C++ (okay sans la couche objet, mais c'est deja moins barbare). Et je crois que maintenant ils ont switché en C# comme support à l'algorythmique. (le pourquoi du comment je sais pas).
 
En fait on fait du C qu'en programmation Systeme & Reseau. Sinon c'est Java point barre des que l'objet arrive, le C++ etant une option en 2e année.
 
Et franchement tout ceux que je connais qui on debuté la prog avec du C (genre en DUT GEII donc pas informatique pur), bah ils ont souvent pas tres bien compris, et juste sortie le code parce que ça marche.

c'est un peu con.
perso niveau formation, je verrais plus un tronc commun
 
archi matérielle / asm / C (par le même prof)
C++ / Java (par le même prof, un autre que le premier, mais qui se met d'accord avec le premier)
l'algo par un troisième prof, mais où tu as des mini-projets en collaboration avec les deux autres prof.
 
pour moi c'est pas d'être extrêment pointu sur chaque langage (l'élève aura de toutes manières à bouquiner le long de sa carrière professionnel), mais c'est de bien montrer les cas d'utilisations et l'approche respective à chaque problème.
 
mes potes de BTS qui bitaient rien à l'asm ou aux subtilitées du C, c'était surtout dû à la formation asm/C/archi séparée incohérente qui permettait pas de construire mentalement le séquencement des choses.
 
MEI >> bon par contre du C++ sans objet ça donne quoi ?

Essentiellement ça donne des vrai chaine de caractère et des vrai booleen. Et aussi de memoire des signature de fonction plus simple avec notament je crois le mot clef const qui n'est pas present en C, non ?  
 
Meme si en C++ y'a des chose du C qui passent, pedagogiquement c'est difficile de justifié la riguer de l'algorythmique avec un langage comme le C ou plein de bidouille sont là.

Le C, on le retrouve aussi énormément dans tout ce qui est jeux vidéos et grosses applications.
Car il a un gros avantage : plus rapide que la plupart des autres langages.
 
Ceci dit, je prends l'exemple du jeu OpenTTD, qui était il y a quelques mois écrit 100% en C, qui passe progressivement au C++.
 
Bon, ceci n'empêche pas TTDPatch d'être encore actuellement principalement codé directement en ASM

tu comprends pas grand chose aux pointeurs, c'est pas notre faute    

Ouai enfin quand tu programmes des sockets avec des cast a tout bout de champs et des * et & dans tout les sens tu fini par franchement regretté un langage moderne.
 
Ca deviens vite vraiment illisible car il y a plus de "syntaxe" qu'autre chose.
 
Enfin je sais pas ou alors c'est que j'ai trop l'habitude de faire du code propre en Java.

si tu comprends pas la sémantique derrière, ça l'est. La syntaxe ça m'émeut peu, le seul problème étant que le gogo de base caste à tout va, et que le C permettant d'exprimer la corruption mémoire, bah t'arrives vite à une daube. Toutes façons, on est juste pour le C pour ce qu'il est.

vu que personne n'a répondu a mon troll ( on ne respecte plus rien de nos jours ...   ), pourquoi pas ocaml ?

Personnellement, j'ai eu quelques notions d'ASM auparavant, et maintenant je me mets au C... Et je ne trouve pas ça spécialement compliqué ou je ne sais quoi, j'ai concience que des erreurs peuvent facilement être commise mais justement ça apprend à être rigoureux!
Enfin, en même temps, je ne connais rien dutout aux autre langages, donc bon... (sauf html et php mais bon c'est bien différent)

 
pour que mon C2D à 3.4ghz ait le rendement d'un P2 300Mhz ? (a non merde c'est le java ça)

nop vous êtes mal renseignés, il permet la compilation en bytecode ou en natif au choix ( il est classé derrière le C dans ce bench de langages de prog http://shootout.alioth.debian.org/ ) , c'est un très bon langage fonctionnel avec des traits impératifs, il permet également la prog objet ( Objective Caml ) il est très fortement typé, polymorphe paramétrique et possède une inférence de types et on a même l'interopérabilité avec le C   .
 
C'était ma propagande du jour, mais ocaml le mérite bien   .

 
Euh, t'es sur d'avoir bien compris la page de bench ?

Pourquoi pas en effet. Tout dépend de ton besoin

 
C'est ce que disent tout les frustré qui n'utilisent pas le langage parfait

Chut, j'avais besoin d'arguments

( mais ocaml est réellement pas loin du C hein )

J'ai pas envie de troller sur ocaml mais je plaiderais pour autre choses que les sempiternels C/C++/Java.  
Il y a autre chose dans la vie que les boucles et les pointeurs. J'ai fait longtemps du C, mais depuis peu j'ai ouvert les yeux et je découvre d'autres mondes, d'autres méthodes et quand je réfléchis maintenant à un problème, je ne le pense plus à le résoudre à la manière C mais en Prolog, j'ai mis du temps à m'y mettre, c'est dur, c'est pas encore très satisfaisant, mais tout de même, quel plaisir.  
Je commence aussi à me plonger dans les délices de l'évaluation paresseuse des langages fonctionnels, je suis encore loin d'avoir tout compris, mais je crois avoir compris que tout étudiant en info devrait y passer, et qu'ensuite, s'il en a envie ou s'il le faut, qu'il apprenne toutes les arcanes du C, qu'il se coltine la norme les pointeurs et tutti quanti.
Tout ça pour dire que ce n'est pas le langage qui est important en soi, mais la philosophie de la programmation sous jacente qui l'est, et tous les programmeurs devraient connaître ces différentes façons de penser et ensuite choisir en connaissance de cause.

 
Surtout en fonction des besoins du projet
 
Le C est interessant pour les optimisations qu'il permet, c'est tout. On est proche de la machine, on a tout controle sur ce qu'elle fait. c'ets tres utile pour des bouts de code ou la rapidité d'eecution est capitale.
 
Par contre pour l'interface utilisateur opu des chose du genre (en fait, tout ce qui ne demande aps un max de sauce), l'objet est quand meme bien plus adapté.

le C++ fait les deux ca tombe bien.