Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Bidouille & Développement Informatique
Agrandir
Bidouille & Développement Informatique
Les Mains dans le Cambouis
Bidouille & Développement Informatique
Actu 1 1
Articles
Médias 33 33
Tutoriels
Forums 326 326

Le pub des programmeurs

  • 1 927 réponses
  • 117 participants
  • 123 835 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
551
ZieQ : les FILE* ont une API, et d'après les écrits de Sutter et autres, les fonctions fpon et autres font bien partie de la classe FILE, sans aucun doute.

Gabou, tu es quand même un peu paradoxal, tu parle de refactoring, mais l'héritage, c'est pas trop pour toi alors que c'est l'une des bases du refactoring pour éviter la réécriture du code, donc bon :| Quand on lit les 2 ouvrages de référence à ce sujet, c'est clair.
De plus, les templates, c'est super pratique pour changer une stratégie efficacement, il est vrai que le C++ ne considère pas les classes comme des objets, et le Python fait cela de manière dynamique, et c'est pas plus mal ;)

Enfin, pour les détracteur de Qt, discutez d'abord avec le créateur du C++, s'il l'utilise pour enseigner à ses étudiants, c'est peut-être pas tant batard que ça, vous ne trouvez pas ?

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

552
Ah oui, Java, c'est pas trop le top pour moi, je suis à la limite de ce qui est acceptable en consommation mémoire - 2.2G -, donc passer par un langage avec GC, ça me paraît risqué.
Mais je vais tenter un mini projet en Python, ça me permettra de me faire la main et de tester Python, je l'ai promis depuis si longtemps à Gabou :D

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

553

Citation :
Gabou, tu es quand même un peu paradoxal, tu parle de refactoring, mais l'héritage, c'est pas trop pour toi alors que c'est l'une des bases du refactoring pour éviter la réécriture du code, donc bon



C'est une base du refactoring en langage a typage statique peut etre, mais dans des langages dynamiques (le contexte dans lequel je me placais), l'heritage est pas tres utile. Par exemple, tu utilise peu l'heritage pour heriter d'une interface en python, ca sert a rien, puisque tu n'utilises jamais le type. Si tu veux changer certaines fonctions membres, les mettre dans une autre classe (lors du prototypage par exemple), c'est extremement lourd en C++.

Je sais pas de quel ouvrage de reference tu parles, mais beaucoup d'ouvrages sont ecrits pour le C++ ou le java, et je trouve que ces langages sont vraiment tres pauvres en expressivite pour comprendre les concepts objet. Un debutant, avec le C++, il va bien se prendre la tete avant de faire des functor, des factory et cie. Quand j'ai commence a utiliser python, j'ai vraiment eu une sorte d'illumination sur tous ces aspects.

Template pour changer de strategie, je comprends pas, la, par contre. Par exemple, je trouve pas que la stl tienne ses promesses sur l'independance container/algorithmes: si tu veux tester par exemple du code en utilisant soit des list, soit des vector, il suffit pas de remplacer list<int> par vector<int>. Typiquement, le sort marche pas de la meme maniere, etc... c'est d'une lourdeur, en general, et tres difficile a debugger (t'as plus le code sous les yeux); je garde un tres mauvais souvenir de blitz, par exemple. Certains trucs comme boost::python utilisent a fond les templates, et sont interessants, mais je trouve ca finalement assez anecdotique. Qt utilise assez peu les template, par exemple, et c'est certainement une des raisons pour lesquelles j'apprecie qt.

Perso, je code en C ou pire en C++ vraiment que si j'ai pas le choix, et ca veut dire en general performances. Mais j'evite au maximum, maintenant.
554

Citation :
Ah oui, Java, c'est pas trop le top pour moi, je suis à la limite de ce qui est acceptable en consommation mémoire - 2.2G -, donc passer par un langage avec GC, ça me paraît risqué.



Java consomme plus de memoire, mais je pense pas que ce soit le GC qui soit le probleme, au contraire. Typiquement, ce qui prend vachement de memoire avec une vm evoluee comme celle de java, c'est le JIT compiling. Ce serait interessant de comparer un programme ecrit en java et compile avec gjc, et un programme en C++; j'aurais tendance a penser que le programme compile avec gcj prendrait beaucoup moins d'espace memoire que le meme au dessus d'une vm.

Citation :
Mais je vais tenter un mini projet en Python, ça me permettra de me faire la main et de tester Python, je l'ai promis depuis si longtemps à Gabou :D



Le teste pas pour ton truc a 2 Go, parce que la, c'est clair que c'est pas le top :)
555
Les 2 livres dont je parlent sont :
- Refactoring to Patterns
- Refactoring - Improving the Design of Existing Code

Effectivement plus orienté type statique. Je vois très exactement ce à quoi tu fais référence quand tu parles de l'inutilité du type, c'est en fait de ce manque du C++ que je m'affranchis grâce aux templates, en quelque sorte, sans arriver à al même puissance que Python tout de même.
Par exemple, j'ai défini une classe de sous-matrice qui a la même interface que les matrices usuelles de ma bibliothèque, grâce à quoi tous mes algos fonctionnent rigoureusement de manière identique, sauf que ça me permet de travailler à plusieurs échelles, par exemple - typiquement, une optimisation multi-points où je ne prends successivement qu'une partie des points, alors que par le passé, j'utilisais tous les points -, mais c'est le genre de choses que Python fait naturllement de par sa nature typage dynamique ;)

Pour ce qui est de Qt avec les templates, c'est utilisé, sauf que ce n'est pas possible dans leur hiérarchie QObject à cause de moc, justement, ça entraîne en revanche parfois un peu d'acrobaties dans le cas où on veut utiliser 3 stratégies statiques sans devoir recoder le support de ces stratégies - je me comprend, mais je ne me fais pas comprendre, je crois ;) -

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

556

Citation :
Pour ce qui est de Qt avec les templates, c'est utilisé



Oui, bien sur, mais c'est pas base dessus. Ca n'utilise pas les template de maniere intense comme peut le faire gtkmm ou boost.

Apres, l'utilite ou non du typage, j'irais pas non plus jusqu'a dire que c'est inutile. C'est un debat sur lequel bien des personnes plus qualifiees que moi se sont dechire (ML vs LISP, par exemple); python est d'ailleurs fortement type.

La ou je trouve que le typage a la C++ est tres fortement surestime, c'est que ca se place finalement sous le mauvais angle: finalement, ce qui compte plus, c'est le contrat entre classes, et la, on rejoint la philosophie d'eiffel en quelque sort. Il y a discussion en ce moment a propos de python pour rajouter le typage optionnel, et un des points d'achoppement, c'est celui la.

Pour un langage oriente calcul vectoriel, un truc qui a l'air interessant, c'est fortress, je sais pas si t'en as deja entendu parler ?

http://research.sun.com/projects/plrg/

Je pense vraiment que tout ce qui est vm va se developper beaucoup. Ca consomme plus de memoire pour etre performant, mais une fois que le 64 bits va devenir courant, ce sera plus trop un probleme je pense.
557
Non, je ne connais pas cette bête ;)
Le truc, c'est comme on a une plateforme commune entre tous les membres du labo, la politique est C/C++, point final :|
En revanche, c'est certain qu'on ne tournera jamais avec un langage à VM qui bouffe un tant soi peu de mémoire, déjà comme ça on doit faire gaffe - j'ai dû modifier mes algos pour supprimer méchemment à la hache des temporaires parce que je dépassais la mémoire autorisée - et que le swap, c'est pas une option :|

Tout ça pour rerererereredire qu'à chaque application, son langage :)

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

558
C'est clair qu'il y a des trucs qui demandent pas mal d'optimisation, et que tu vas pas utiliser un langage sur vm pour certains trucs. Mais en utilisant le C/C++, tu fais deja un compromis. Les fonctions ont un cout en C ou pire eventuellement, en C++; l'objet a un cout meme en C++: la vtable prend de la place. C'est le plus souvent negligeable, mais si tu as des millions d'objets, ca l'est plus forcement, etc...

C'est la que j'etais pas d'accord finalement avec les autres participants de la discussion precedemment. Non pas sur le fait qu'evidemment, il y a des projets ou le C/C++ est clairement adapte; mais plus sur les cas ou c'est reellement adapte.

Le GC a un cout, mais c'est vrai aussi pour malloc (typiquement, le coup ou le gars critiquait mac os x qui etait 40 % plus lent que linux sur le meme code C sur la meme machine pour du code de calcul statistique... ben en fait, c'etait a cause des optimisations differentes de malloc entre les deux OS; le malloc de linux par defaut etant quand meme tres bon en general); etc... Dire que le C est la solution pour la recherche d'optimisations pures, c'est oublier qu'il y a 30 ans, un appel de fonction prenait beaucoup de temps sur un ordinateur. D. Cutler, un des chefs du projet NT au depart chez MS, decrit bien le probleme des developpeurs qui codaient tout en assembleur a l'epoque, et des problemes de mentalite.

En codant en C, on fait deja beaucoup de compromis, un peu plus mais pas beaucoup en C++ (sauf dans certains cas ou ca peut faire mal). ET les compilos ont vachement progresse, rendant l'assembleur le plus souvent inutile par rapport au C... au prix deja de l'occupation memoire; linux, code en C, t'auras pas une interface graphique avec 4 Mo de ram (je crois que linux de base seul, maintenant, en 2.6, refuse de booter avec seulement 4 Mo de Ram). Pourtant, windows 95 tournait sous 4-8 Mo de ram (peniblement).

Quand tu fais du pseudo temps reel pour un plug audio par exemple, tu dis au revoir a tout appel systeme, donc entre autre au syteme de memoire fourni par l'OS, faut le faire a la main de nouveau, etc..

Je pense que les vm, ce sera comme aujourd'hui le C/C++. Necesssaire, indispensable dans certains cas particuliers, mais le reste se fera avec GC ou autre systeme de gestion automatique de memoire, et avec vm. Les gros projets a millions de lignes en C ou en C++, c'est pas l'avenir de l'informatique, je pense.
559
Je profite de ce regroupement d'expert en audio et info pour poser une petite question.

La nouvelle version de windows, nommée Vista, intégre une nouvelle sorte de moteur audio et video. Les données sont notamment traitée avec une plus haute priorité, à un plus haut niveau hiérarchique (?). Est ce que vous pensez que cela va amener des avantage au niveau du traitement audio professionnel (autre que lire un mp3 ou regarder un dvd) ou pas ?



Source : http://www.clubic.com/article-66145-10-microsoft-windows-vista-rtm-dossier.html
560
A la place d'utiliser des drviers ASIO, on utilisera peut-être plus ces drivers là s'ils ont une bonne interface, sinon ça sera comme les WDM, certains logiciels les supporteront, d'autres non, et l'ASIO restera.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/