Reprise du message précédent :
Ça a été rectifié dès les premières propositions quand même...
 
nraynaud, si tu connais 20 langages c'est très bien, c'est une bonne ouverture d'esprit. Je n'en suis pas encore là .
Mais je trouves que tu es trop académique puriste.
Est-ce que tu codes beaucoup en pratique ?
 
Bah voilà, j'ai rien d'autre à ajouter à ce topic passionant, mais comme ça on est tous là .

 
non, ça me casse les couilles et m'abîme les yeux, je fais le strict minimum et en général c'est jamais dans le langage que je veux. Je codais beaucoup quand j'atait ado mais j'aurai mieux fait de m'abstenir, c'était de la merde (esprit "ceux qui trouvent que le C est pas safe c'est parce qu'ils savent pas coder" ), aujourd'hui, j'en suis à réfléchir à virer la protection mémoire entre les applications (dans le cadre d'un éventuel-futur projet).
 
Actuellement je suis sur pocketsmalltalk/palm (je fous une deuxième pile pour y mettre les handlers d'exception), je suis obligé de le faire en C car je trouve pas de compilo ADA pour palmos.
Sinon c'est des cours, donc 90% de C ils nous foutent ce langage à toutes les sauces : systèmes distribués, vxworks (génial sur une cible sans mmu) et j'en oublie.

Il y a une certaine logique qu'on puisse trouver des compilateurs C sur tant de plate-formes : ce langage a été conçu comme un assembleur de haut-niveau (pour faire simple) !
 

Ah bon ?    Revois ton dictionnaire d'info, mon cher : C date de 1968, Ada de 1983... Une paille à l'échelle de l'histoire de l'informatique !  

selon http://www.levenez.com/lang/ :
ADA: 1979
C: 1971

 
Ma remarque n'est pas dans ce sens, c'est que le TP sur XDR ou sur TCP se finit tout le temps en TP de malloc, sigsegv etc. Il m'arrive de montrer à 3 personnes comment récupérer un SIGSEGV dans gdb au cours d'un seul TP.
Alors que des langages plus expressifs permettent de se concentrer sur ta socket, ton protocole etc. Surtout lorsque les étudiants sont sensés maîtriser C, Smalltalk, java, Ada et C++ (ce qu'il sont loin de faire, mais au moins ils vont pas galérer sur des conneries qui n'ont rien à voir avec la choucroute).

OK pour C en 1973 (version définitive du langage pour les créateurs de C d'après levenez.com), mais je persiste pour Ada : 1983. Même s'il a fallu plusieurs années pour concevoir le langage (tout comme pour C, d'ailleurs).
Et 10 ans, c'est un changement de génération.
 
nraynaud> Je suis entièrement d'accord avec toi. Un outil est un outil, et c'est seulement un outil. Quand cet outil est censé faciliter des manipulations complexes, mais qu'il ajoute à cette complexité sa propre complexité, alors c'est un outil inadapté. Et C, comme C++, est inadapté à la plupart des usages. Ces deux langages sont sans doute très bien pour écrire des applications proches du système (usage pour lequel ils ont été conçus à l'origine, d'ailleurs), mais, au moins pour tout le reste, ce sont des outils inadaptés. Plus exactement : ils fonctionnent, bien sûr, mais on dispose par ailleurs d'outils beaucoup moins coûteux à mettre en oeuvre pour faire la même chose.
 
Mais je reconnais que très très peu de programmeurs acceptent vraiment le fait que le langage est un outil, au même titre que le compilateur, le débogueur, l'environnement de test, et que la manière dont est conçu le langage a une influence énorme sur les possibilités de détection des bugs précoce, et donc sur la qualité effective du code une fois en production. Quand on parle amélioration de la qualité du code, ils pensent toujours meilleur débogueur, environnement de test plus puissant, exceptions, ramasse-miettes... Quasiment jamais langage de programmation.
 
Mais ça viendra. Il faudra le temps, mais ça viendra. Et en attendant, il faut continuer à argumenter, patiemment, petitement. Je ne vois pas d'autre solution.

 
Moi j'ai arrêté, j'insulte directement à l'heure actuelle.
 
Pour illustrer la dérive dont tu parles : on en est à utiliser des simulateurs de processeur (valgrind) pour débugger la mémoire en C !! Alors que Lisp, un langage qui ne permet pas de faire une erreur de mémoire (hormis tout bouffer, bien sûr) a été inventé en 1958.

Je ne sais pas ce qu'il en est dans vos boites
mais personnellement je developpe des librairies pour
des developpeurs de jeux et passer a un autre langage que C++ est un no/no sur ce genre de marche.
(deja que le leader concurrent propose une interface C et qu'il a fallu convaincre une generation de developpeurs que C++ c'etait meilleur que C ou que l'assembleur inline).
 
La faute a qui? a tout le monde: les constructeurs de console adaptent gcc ou VC++ pour leur machine ou ne proposent que des compilateurs C/C++ dans leur SDK donc il faut faire avec.
De plus avec les 24 Mo de la gamecube les developpeurs sont obsedes par le memory footprint que pourrait avoir une machine virtuelle par exemple.
 
La situation de C++ sur le marche est dominante et ca ne risque pas de changer de si tot, un langage de haut niveau n'est evalue au mieux que pour faire du scripting, et la seule vraie alternative c'est l'assembleur pour programmer les vector units de la playstation 2.
 
Enfin bon je sais je suis pitoyable
je devrais aller insulter tous nos clients..
 
LeGreg

 
Quelques arguments à leur donner :
Eiffel par exemple utilise le C comme langage intermédiaire. Je pense qu'il existe d'autres langages qui le font, si le marché le demande, les compilos seront développés (évidement, un compilo caml est largement plus facile à développer qu'un compilo C++ ou  un compilo Eiffel).
 
Une machine virtuelle n'est pas réellement nécessaire, surtout sur un RISC (je spécule que c'est est un) où les instructions sont faciles à générer. En général, le truc le plus nécessaire est un GC (adapté à la contrainte de place, éventuellement de temps de réponse), qui consome asymptotiquement moins qu'une gestion manuelle et l'allocateur qui va avec (qui est classiquement entre 5 et 10 fois plus rapide qu'un malloc).
Malheureusement, beaucoup de conneries circulent sur les trucs que les gens ne conaissent pas (l'autre fois j'ai entendu un de mes profs dire qu'un GC pour java c'était un compteur de références).
 
edit : typo

Le C, j'ai déjà exprimé ce que j'en penses:
http://forum.hardware.fr/forum2.php3?post=29181&cat=10 Pourquoi rester en C au lieu d'utiliser C++ ?
http://forum.hardware.fr/forum2.php3?post=29182&cat=10 Le C et le C de C++ doivent-ils rester compatibles ?
 
 
Le C++ n'est pas orienté sur les concepts du programmeur, mais sur ceux de la machine.
De même que le C est considéré come un assembleur de haut niveau, je considère C++ comme un assembleur d'encore plus haut niveau, un assembleur de concepts.
 
Il est donc pas facile, mais il permet le code le plus efficace en vitesse ou encombrement... à condition de le maîtriser.
Et cela sans trop compter sur un compilateur intelligent pour réorganiser efficacement à la traduction.
 

J'ai déjà lu cet avis, écrit par des experts reconnus.
Et pourtant je doute... avec quel code compares-t'on ?
S'il alloue tout partout dans l'insouciance et l'allégresse, je comprends.
S'il est conçu au plus tendu, la gestion manuelle ne peut être que plus efficace.
 
Les conteneurs C++ disposent d'un paramètre allocateur qui permet, en surchargeant new et delete, de choisir toute stratégie d'allocation: sous-allocation, pile, châine, mélange, libération groupée...
Bonus: C'est optionnel et peut être fait à postériori, une fois que le code marche.
 
 
Je sais pas trop si ça se fait pour les consoles, un ramasse-miettes .
Rien que pour ça j'ai du mal à comprendre qu'on puisse louer Java (par exemple) pour l' "embarqué".
Ce sont à priori des machines avec des ressources limitées (mémoire surtout), à consommer avec parcimonie.
 
En fin de compte, le ramasse-miettes reviens à globaliser et uniformiser la gestion de la mémoire.
"One size does nor fit all" <-> "Une taille unique ne convient pas à tous".
 
Le mieux serait d'avoir le choix. J'ai lu que C# le permet, qu'est-ce que ça vaut en pratique ?
 
 
legreg:
Tu pourrais m'en dire plus sur le développement de librairies pour jeux ? Du genre...
Utilises-t'on la généricté, ou est-ce adapté au cas par cas en détail ?
A-t'on recours à des librairies utilitaires conteneur, numériques... ?
Jusqu'où vont les exigeances de rapidité/compacité ?

Parce qu'on en est encore souvent à raisonner comme quand on devait économiser chaque octet et chaque cycle mémoire du programme (l'époque des machines 8 bits, vous avez connu ?). Et en plus, on passe son temps à opposer efficacité des programmes et sécurité. C'est complètement stupide. Et pire : on ne se rend pas compte combien en réalité, c'est complètement faux.
 
Je te donne un exemple, certes un peu simpliste au premier abord, mais largement généralisable.
En C -- et très souvent en C++ -- quand on a un tableau, on va écrire pour le parcourir "for (int i = 0; i < taille_tableau; i++) { ...". Et régulièrement, la borne max est fausse, pour une raison ou pour une autre => BOUM !  
En Ada, on va écrire "for i in monTableau'Range loop...". Quelles que soient les bornes réelles du tableau, ce code fonctionne, par construction. "i" parcourt tout le tableau et rien que le tableau, et en plus, on n'a même pas à prévoir un quelconque contrôle de bornes sur "i", donc le code est très sûr et en même temps, il est très efficace (au passage, on accuse souvent Ada d'être verbeux par rapport à C. Ici, j'ai plutôt l'impression que c'est le contraire...   ).
Et on pourrait multiplier les exemples comme celui-là.
 
Musaran> Tes critiques sur le GC ("Une taille unique ne convient pas à tous" ) s'applique tout autant au malloc, je te signale. La preuve, on s'est senti obligé de surcharger les new en C++ pour rendre la gestion mémoire plus souple. Mais qu'est-ce qui interdit d'avoir, par exemple, des pragmas pour donner des indications similaires au GC ? Avantage : cela ne fait pas partie des instructions (au sens algorithmique du terme), mais ce sont de simples indications de génération de code pour le compilateur (qui éventuellement sont débrayables pendant le développement).

 
Et en Pascal "for i := Low(monTableau) to High(monTableau) do ..."
 

minable  
 
en python :

 
et en lucane (:whistle

et en PHP :
 
foreach($monTableau as $i) { ... }
 
ou un truc du genre

en VB c exactement le même principe
 

Et en C++, on utilise les types container de la STL que l'on parcours en utilisant un iterator.

Non, "la gestion manuelle" consiste à calculer (au moins partiellement) l'évolution du graphe d'objets à "l'avance" (statiquement), en disant : "ce point du code est le plus tôt où j'ai la garantie que plus personne ne référence cet objet". Mais si plus personne ne référençait l'objet longtemps avant ce point du code, il ne sera tout de même pas récupéré plus tôt. Hors un garbage collector le ferait (puis qu'il collecte les objets qui ne sont _réellement_ pas référencés).  
Les applications un peu sérieuses, commencent à avoir des graphes d'objet assez complexes et hyper mobiles, et c'est là que vient la ca tastrophe en gestion manuelle : le cas courrant est de faire un max de copie profondes, ou de laisser tous les objets vivant jusqu'à un point où on les détruits par paquets complet (syle destruction programmée de l'objet qui les aggrège, avec au passage un risque de God-class) au bout d'un moment, le gars, voyant la catastrophe  commence à écrire lui-même un système automatique (cf. OpenCascade par ex.) et là, le gars, n'ayant jamais rien lu ou su sur les GC, ("et c'est là que survient le drame" ) il fait un système de comptage de références. Et il dit à tous ses potes : les GC ça rame et ça sait pas recycler les structures cycliques (si il s'en est apperçu ce qui n'est même pas sur). D'autre applications ont fait un choix plus intelligeant dès le départ : Autocad et emacs par ex. développés dans un langage d'assez haut niveau mais surtout avec un GC dès le départ.
 
edit :
je ne vois pas ce que veut dire "une taille ne convient pas pour tous". Un GC c'est réglable, la taille de départ des différents espace, les divers seuils etc. c'est réglable. Même l'algo pourraît être changé (mais là je sais pas si en pratique ça existe).

bon et a propos, j'attends toujours plein de doc sur les GC

http://www.memorymanagement.org/
http://www.cs.rpi.edu/~gorik/garbage/
 
amuses-toi bien

y'a un bibliolink...
http://forum.hardware.fr/forum2.php3?post=23900&cat=10

 
L'argument habituel qui se mord un peu la queue.
Effectivement, les developpeurs ne sont passes a C++ majoritairement que depuis quelques annees et principalement
parce que les consoles ont enfin propose des compilateurs
C++ decents (mais aussi peut-etre parce que les developpeurs
les demandaient ?).
 
Je connais beaucoup de developpeurs qui font des experimentations sur le langage (scripting en java,
en python, en LUA, en CAML ou Skol..), donc ce n'est
pas forcement une mauvaise volonte de leur part  
mais cote librairies c'est un peu le consensus sur le langage.
 
Ce qui est certain c'est que boite de jeu = ric rac
sur le budget, donc les experimentations sont faites
sur le temps libre et beaucoup de tentatives innovantes
se heurtent a des contraintes bien reelles que seuls
des developpeurs payes a plein temps pour ca pourraient
resoudre.
 
On pourrait leur retorquer que leur jeu pourrait etre
meilleur et bien moins cher a produire, oui mais qui prendra le risque a faire une experimentation grandeur nature sur leur prochain jeu.. Soit ca passe. soit tout le monde y passe.
 

 
L'allocation est un des gros problemes sur consoles..
Il faut combattre la fragmentation; on evite d'allouer de maniere non deterministe : un niveau prendra telle place en memoire, si il prend un bit de plus ca ne tiendra pas.
En ce moment une personne est en train de reecrire un allocateur memoire alternatif (qui remplacera le malloc de la lib standard)
mais evidemment elle achoppe sur des problemes bas niveau dont j'aurais prefere ne pas entendre parler (driver qui n'accepte que des blocs contigus etc..)
 

 
Hmm, quelqu'un m'a dit aujourd'hui que l'on avait l'infrastucture
necessaire pour detecter les references cycliques mais que lancer la routine prenait une frame entiere. ca marche sur le papier mais qui voudrait l'utiliser dans les faits?
Alors que balancer toutes les donnees et recharger ce qu'il faut a chaque changement de niveau fonctionne encore tres bien.
(et on est cense eliminer toute allocation en dehors de l'initialisation forcee).
 
 
Quelqu'un connait Jak and dexter, ce jeu est une merveille du point de vue ingenierie, il tourne sur PS2 une console
censee n'avoir aucune memoire (mais plus que la game cube..)
il affiche des decors et des personnages assez detailles et il y a un monde gigantesque sans aucun chargement visible entre les zones.
Connaissant les outils disponibles sur PS2, j'en deduis qu'ils ont developpe la plupart de leurs outils eux-meme
et que la plupart des methodes utilisees (chargement en memoire de classes par bloc avec "fix-up" des pointeurs) sembleraient des methodes inacceptables pour un programmeur d'applications "normales".
 
LeGreg

premier paragraphe :
justement, une infrastructure adaptée (au dessus du langage) t'aide et fait ça mieux que à la main.
 
deuxième :
effectivement, détecter des cycles est super-facile, ça nécessite juste l'infrastructure d'un GC normal (un marquage quoi), donc si tu fout cette infrastructure, c'est on bon début, maintenant tu vires tes compteurs de références devenus inutiles (ce qui va te faire économiser une référence par objet et des millions de cycles, et moins te polluer tes caches) et tu a un mark-and-sweep de base (qui est déjà un GC un peu plus sérieux même si c'est pas pro).
Concernant la technique que vous utilisez (tout virer et récupérer que l'utile) c'est la première technique de GC qui a été inventée (pour LISP) : ils foutaient le tas sur le disque et récupéraient les objets vivant à partir des racines restées en mémoire. La deuxième étape pour améliorer est de ne faire ça que sur les objet jeunes ("scavenger" entre la 1ère et la 2ème génération), ça réduira le temps de ramassage (je ne fais l'explication que sur demande, trop la flemme).
 

 
je voudrais bien te croire.  
Perso je suis un debutant a la formation classique (CAML, java)
et je suis oblige de remettre en cause mes conceptions de la programmation en permanence (notamment sur le bas niveau, quand j'entends parler de manipulation de paquets DMA j'ai des boutons).
Enfin je suis paye pour faire un truc que je sais faire
(programmer en C++ sans trop d'erreur) et penser a la place du client, en le poussant a faire naturellement des choses qu'il n'aurait pas voulu en premier lieu (par exemple utiliser une librairie haut niveau cross-platform).
 

 
en fait ce n'est pas ce que l'on utilise "nous" puisque ce sont nos utilisateurs qui decident quoi faire de leurs donnees.
Par contre appeler ca une technique de GC ce n'est pas vraiment le mot que j'emploierai mais a t'entendre tout se rapporte a la GC alors .
 
LeGreg

 
Disclaimer: notre cas est un peu particulier, ca depasse le cadre de la programmation generale ou de la discussion en cours et ca risque d'induire des generations de nouveaux developpeurs en erreur. Donc n'ecoutez pas ce que je dis sur notre projet .
 
La genericite est reduite au minimum.
Quand je suis arrive ici j'ai pleure quand j'ai vu comment ils utilisaient l'heritage. ceux qui ont concu cette architecture NE sont PAS des bons programmeurs C++. Maintenant apres quelques mois, je suis juste blase quand je vois passe un "virtual inline". J'ai pose la question. La reponse que l'on m'a donne n'etait pas satisfaisante. "Whatever.."
 
On a ecrit nos propres listes (qui sont des tableaux). Et on n'utilise que ca comme structure conteneur. Il n'y a pas d'iterateurs. Un jour j'ai essaye de recuperer le compte d'elements depuis la classe de base des listes. Je ne pouvais pas, il fallait que je caste vers tous les types de listes possibles a la main pour pouvoir le faire. J'ai pose la question. On m'a repondu : "celui qui a ecrit le type de base y etait totalement oppose". Bon heureusement il a quitte la boite (et je n'ai donc pas entendu son explication). J'ai donc modifie sa classe pour recuperer le compte d'objets depuis la classe de base..
 
Notre rapidite n'est pas tres bonne. N'importe qui peut nous battre en ecrivant du code specifique a ses besoins et adapte a la console. Mais si c'etait le cas, il ne ferait pas appel a nous (ou a nos concurrents).  
 
La compacite est un probleme. On a une infrastructure super complexe qui nous permet d'exporter un fichier depuis max ou maya et de l'ouvrir tel quel sur n'importe quelle console.
Malheureusement, on est tres lourd en pratique et des qu'un jeu est un peu complexe, ca bloque sur la conso memoire. Il faudrait que le programmeur du jeu gere ses donnees de maniere plus efficace mais il ne sait pas forcement comment faire et surtout il aimerait qu'on l'aide ou qu'on lui propose une solution toute faite. En plus notre systeme est tellement pratique a utiliser que les gens ne voudraient pas se casser la tete a developper autre chose.
 
Certaines personnes ont essaye de coupler notre solution
avec celle d'hybrid (dpvs) et d'havok. Mais a la fin il n'y a plus assez de memoire pour les donnees du jeu..
 
LeGreg

En C++:

Le boxon, c'est qu'il faut créer séparément 'fonction_unaire', qui reçoit séparément chaque élément en argument.
La librairie Boost Lambda permet de la créer sur place avec une expression (exemple: 'cout << _1 << endl', mais ça fricote à fond avec les templates et c'est lourd.
 
C++ n'est pas au point pour ce truc simple... il devra encore évoluer.
 
 

Bjarne en parle.
Quand (et pas si) un GC sera intégré au C++, cela aura des répercussions très profondes sur le langage lui-même, et la façon de s'en servir.
Il y aura deux façons d'écrire du C++...
 

Avec ce que j'ai lu ici et ailleurs, je ne doute pas qu'il existe d'excellents ramasse-miettes auquels il vaut mieux confier la gestion mémoire plutôt que de tâtonner soi-même.
Ce que je veux dire, c'est qu'un mécanisme unique et uniforme ne peut convenir pour toutes les situations. Tu m'as bien compris.
Le malloc/free à tout faire de C, c'est pas bien.
Le ramasse-miettes imposé de Java, c'est pas bien.
Un langage complet proposerait un vaste choix.
 
 

C'est tout-à fait le genre de choses que veux être capable de faire. J'en suis loin.
Un langage devrait supporter ce genre d'acrobatie.

 
Vu les standardisations de langages que je connais, je pense plutot que l'on s'oriente vers l'oppose, i.e. rendre cela de plus en plus dur.
De toute facon dans la conception d'un langage personne ne voudra s'attarder a traiter ces besoins specifiques, ca reste possible de le traiter avec un langage bas niveau pour celui qui veut s'amuser alors a quoi bon s'embeter ?
 
Par exemple, Microsoft encapsule ca dans son API de haut niveau et les drivers se chargent du sale travail, avec des langages de bas niveau (assembleur et C). Dans la derniere version de Dx on a meme un sdk managed Dx. Par contre ils ne le porteront jamais sur leur console actuelle (pas fous..).
 
LeGreg

 
Faut faire gaffe au problème inverse : régler un GC finement est un travail de docteur, mais pour aller dans ce sens, l'arrivée de C-- ( http://www.cminusminus.org ) dans le futur va régler un paquet de problèmes.
 
edit : typo

Pétard!
 
J'en ai appri plus sur ce post qu'en 9 mois d'étude à la maison!  
nreynaud J'ai pas le niveau pour suivre tout ce que tu dis, mais qd t'insulte pas tout le monde c'est tellement plus intéressant et ça donne envie de faire l'effort...

 
Bouge, pas je t'apprends autre chose : Raynaud ça s'écrit avec un a comme dans trou-du-cul .... ah non tiens ....
 
edit : il semble qu'à 4 grammes par litre je sois capable d'orthographier l'onomatopée "ah"

 
tu sais, ca peut paraitre idiot, mais l'ortho de ton pseudo, hé bien, comment dire.....

 
perso je ne vois pas trop l'interet d'insulter les gens mais bon.. ca doit etre du second degre ?
 
LeGreg
 

n'empeche que ces querelles de clochées ca va un moment ...
Y a des gens pour ki le langage X ou Y suffit , y a pas de miracle ni de langage surpuissant top safe, top ceci cela ...
 
Alors, entre gens civilisés ... on pourrait quand même passée à autre chose non ?
 
PS : J'ai rien à dire, je fais du C/C++ depuis 8 ans, du LISp, du CAML, j'ai même taté du Pyhton. Et c'est pas pour ca que j'arrive en insultant tt le monde ..
 
sur ceux :  

Moi aussi d'ailleurs. Il est crispant de le voir insulter avec condescendance certains forumeurs qui ne le meritent pas, mais a part cela (et un proselytisme pro-ADA irrealiste au vu du marché du travail actuel), l'essentiel de ses propos n'est pas du vent, mais le point de vue de quelqu'un qui sait de quoi il parle, et avec qui je suis d'accord le plus souvent.
A+,

 
Monsieur n'a pas peur de la calomnie, ça fait plaisir les gens audacieux. Va lire un peu plus de mes post STP.

 
En dehors du probleme moral il y a pire: il y a rupture du contrat
(cf les regles du forum)
 
LeGreg

Elle est super intéressante votre discution, si vous pouviez vous pencher sur la misère dans le monde ou sur le protocole de Kyoto avec la même énergie, il n'y aurait plus de problème dans le monde. Malheureusement, l'heure est à Loft-story et vous préférez dire des trucs super-intéressant sur moi (et qui paradoxalement semble intéresser du monde, je me demande pourquoi) plutôt que de faire des trucs qui auraient une portée un peu plus longue. Allez donc aider les débutants ou tenir des discutions intelligeantes. Si vous avez-pas d'idées, en voici :
 - Comment résoudre le problème du NULL dans les langages
 - Comment enseigner aux débutants les IO monads sans leur faire peur
 - Comment implanter une finalization en langage hôte sans faire une 2ème pile d'exécution
 - Quelles méthodes de développement utiliser pour des langages lazy ?
 
Ca devrait déjà vous occuper un peu.
Sinon, si vous aimez le concret et que vous êtes pas des grosses taches, y'a le projet C-- ( http://www.cminusminus.org/ ) qui a besoin de monde.

Devrais-je dire alors: de langages modernes degagées de nombres de scories historiques et malheureusement pas adoptés par l'industrie logicielle majoritairement retrograde?
A+,