Se connecter
Se connecter

ou
Créer un compte

ou
Agrandir
Les Mains dans le Cambouis
Bidouille & Développement Informatique

Sujet Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 122 527 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
181
Je rejoins un peu miles1981, y a bcp de défauts que tu cites qui n'en sont pas. Oui la STL peut faire peur au début mais personnellement, je l'utilise tout le temps et je n'ai jamais les problèmes dont tu parles. En plus, on a le choix des libraries pour effectuer les fonctions dont on a besoin.

Mais je reconnais quand même que le C++ a plein de défauts. Comme tu dis, le packaging c'est chiant. Les pointeurs a débugger c'est chiant. Maintenant, quand on prend les bonnes habitudes, on fait moins d'erreurs connes. J'ai maintenant une grosse appli multiplateforme en C++ que je maintiens facilement et qui est performante.

Maintenant ma devise c'est de choisir les bons outils pour faire un truc. Et pour le moment, vu la quantité de librairies qu'on trouve écrites en C++ et qu'on peut réutiliser, je ne suis pas prêt d'en changer. Crois-moi, si seul l'outil comptait, ça ferait longtemps que je serais passé à autre chose. P-e un peu de python, et certainement bcp d'eiffel/smalltalk. Le fait d'utiliser python m'intéresse beaucoup. Mais actuellement, tu le dis toi-même, on ne peut pas faire ce que je souhaite. Donc pour moi ça s'arrête là, pour le moment du moins ;)
182
Utiliser .Net, c'est excellent..;)

Perso, je developpe en C++ depuis un paquet d'années, sur windows avec les MFC
depuis un autre paquet d'année, et depuis que je suis passé à .Net et C#, je
trouve que tout est plus simple.

C'est pas que le framework t'apporte des choses que tu ne pouvais faire avant,
mais simplement, il te simplifie la vie, accelère les developpements, etc.

Perso, je travaille dans une boite ou l'on fait des simulateurs (rail, defense,
aérien).. et utiliser C++/MFC ou C#, c'est kif kif... et quel plaisir de
travailler en environnement Visual Studio...

Alors, je sais bien que bcp d'entres vous n'aimes pas trop windows, mais
il faut reconnaitre que cet environnemnet est vraiment bien fait.. (de plus
il y a une version entièrement gratuit, visual Studio Express...)

Donc, "Open your mind to C# ;)"

THe Monz, Toulouse
183
Utiliser .Net, c'est excellent..;)

Perso, je developpe en C++ depuis un paquet d'années, sur windows avec les MFC
depuis un autre paquet d'année, et depuis que je suis passé à .Net et C#, je
trouve que tout est plus simple.

C'est pas que le framework t'apporte des choses que tu ne pouvais faire avant,
mais simplement, il te simplifie la vie, accelère les developpements, etc.

Perso, je travaille dans une boite ou l'on fait des simulateurs (rail, defense,
aérien).. et utiliser C++/MFC ou C#, c'est kif kif... et quel plaisir de
travailler en environnement Visual Studio...

Alors, je sais bien que bcp d'entres vous n'aimes pas trop windows, mais
il faut reconnaitre que cet environnemnet est vraiment bien fait.. (de plus
il y a une version entièrement gratuit, visual Studio Express...)

Donc, "Open your mind to C# ;)"

THe Monz, Toulouse
184

Citation :
Je rejoins un peu miles1981, y a bcp de défauts que tu cites qui n'en sont pas. Oui la STL peut faire peur au début mais personnellement, je l'utilise tout le temps et je n'ai jamais les problèmes dont tu parles. En plus, on a le choix des libraries pour effectuer les fonctions dont on a besoin.



J'attaquais pas tant le C++ en tant tel que son utilisation pour le prototypage. Je veux dire, j'ai jamais entendu qqn avant utiliser le C++ pour prototyper quelque chose. C'est ca qui me parait bizarre, et c'est dans ce sens que c'est penible, la stl. Rien que gerer les infini, les divisions par zero, c'est extremememnt penibles dans un langage compile... Pour du traitement de signal, tu peux pas comparer matlab et le C++ niveau facilite et puissance, c'est pas le meme monde. Python permet justement de faire ce que matlab permet (en gros), tout en ayant un 'vrai' langage.

Les problemes dont je parle pour la stl, l'ABI, le packaging, sont des lieux communs (valarray, meme stroustrup a reconnu que c'etait un echec dans les dernieres editions de son bouquin), pour le reste. Evidemment, un plugin VST, tu vas le faire en C++. Un gros soft audio, tu vas le faire en C++ (je pense que ce doit etre le langage de 90% des programmes audio "lourds", toute plateforme confondu, mac, pc ou linux).

Citation :
Alors, je sais bien que bcp d'entres vous n'aimes pas trop windows, mais
il faut reconnaitre que cet environnemnet est vraiment bien fait.. (de plus
il y a une version entièrement gratuit, visual Studio Express...)



En dehors du fait windows only, le probleme de visual studio est que si t'es pas programmeur, c'est extremememt lourd a gerer. A chaque nouvelle version, il faut reapprendre pas mal de trucs, et perso, etant avant tout scientifique, j'ai pas le temps pour ca. Maintenant, je reconnais qu'il y a pas mal de trucs bien faits dans visual studio (je connais surtout la version 6, ca a du s'ameliorer depuis: debuggage, header pre compiles, performances).

Sinon, C#, il y a mono sous unix, et ca marche plutot pas mal.
185
Je ne suis qu'à moitié d'accord. OK, pour du prototypage, c'est pas le top - et encore, je fais ça ! -. Par exemple std::vector, c'est un wrapper autour des tableaux en C, sans compter que les algos sont plus rapides.

L'orthogonalité des conteneurs/algorithmes de la STL est voulue pour la réutilisabilité et la maintenance. A la place d'avoir O(NM) fonctions, on n'en a plus que O(N+M), une sacré différence !

Y'a pas de liste -> et std::list, c'est quoi ? Les hashmap ne sont pas encore standard, mais ça vient ! De même que pour les pointeurs intelligents, quand je dis pointeurs intelligents, il y a bien plus que les auto_ptr, de même pour les générateurs aléatoires.

Et pour ce qui est de réapprendre VS, comme rien n'a changé entre VC6 et VC8 à part la conformité du standard, et aussi, on voit bien qu'on a pas besoin de makefile ;)
Bon, on voit bien qu'on a chacun des intérêts divergents, de mon côté, ce qu'il me faut, c'est une exécution rapide. Je n'ai pas le temps de développer un test en python puis de porter les pièces trop lentes, il me faudra une semaine pour faire une simple exécution qui me prend 1 jour en C++. Je fais aussi des stats des optimisations, et à longueur de journée. Clairement, Python n'est pas assez puissant pour moi, je préfère C++ avec les templates. Je perd 5 minutes à la compilation, mais je gagne quand je passe d'un test en float à un test en double parce que pas tout à redéfinir - vive la généricité -, et je gagne un facteur 2 sur mes tests après - qui durent quelques jours voire semaines -. Le choix est vite fait. C++ natif.
186

Citation :
Par exemple std::vector, c'est un wrapper autour des tableaux en C, sans compter que les algos sont plus rapides.



Plus rapides que quoi ? Je pense que c'est dure de battre une implementation basee sur atlas pour tout ce qui est algebre lineaire.

std::list ne fait pas vraiment partie du langage: des que tu dois pas ca en argument a une fonction C (quand meme la majorite des librairies de calcul numerique), tu perds tout le benefice. C'est comme les strings, en fait. Puis les messages d'erreur sont penibles pour la stl (j'en avais chie quand j'avais utilise blitz++, que j'ai abandonne depuis).

Citation :
Bon, on voit bien qu'on a chacun des intérêts divergents, de mon côté, ce qu'il me faut, c'est une exécution rapide. Je n'ai pas le temps de développer un test en python puis de porter les pièces trop lentes, il me faudra une semaine pour faire une simple exécution qui me prend 1 jour en C++. Je fais aussi des stats des optimisations, et à longueur de journée.



J'avoue quand meme etre surpris. Parce qu'en stats comme ailleurs, la regle des 80/20 reste valide. J'ai du mal a croire que tu sois limite plus par le temps d'execution que le temps de programmation, c'est quasiment toujours l'inverse qui arrive. Des trucs comme matlab sont beaucoup utilises pour cette raison, fondamentalement.

Mais bon, t'es peut etre un genie de la programmation, j'ai rencontre qqs personnes qui sont capables de coder ce que je code en python en C++ en moins de temps. C'etait pas la majorite.

Citation :
Je perd 5 minutes à la compilation, mais je gagne quand je passe d'un test en float à un test en double parce que pas tout à redéfinir - vive la généricité -, et je gagne un facteur 2 sur mes tests après - qui durent quelques jours voire semaines -.



Changer de float en double est quand meme plus simple dans un langage haut niveau qu'en C++ ;)
187
ATLAS est la plus rapide pour les calculs matriciels, OK. Maintenant, pour ce qui est de la sélection du type de données, c'est pas aussi simple qu'un paramètre template dans une classe.
std::list fait partie du langage, c'est une partie de la STL, il n'y a pas plus de différence qu'avec Python, Java ou autres où la liste n'est pas non plus un type de données natif.

Changer un type de données de float en double, c'est 2 secondes chronomètre en moins : un simple typedef à changer et tout le programme utilise un nouveau type de données. Vive les templates.

En ce qui concerne Matlab, je suis comme toi, je n'ai pas :D Je l'utilise juste parce qu'il fait de beaux graphiques quand je lui donne des nuages de points à manger et à afficher en couleurs. Si Python est capable de le faire mieux en moins de temps, je prend sans hésiter !
188

Citation :
ATLAS est la plus rapide pour les calculs matriciels, OK. Maintenant, pour ce qui est de la sélection du type de données, c'est pas aussi simple qu'un paramètre template dans une classe.



ben si, puisque python (enfin numpy) fait le truc pour toi. Tu travailles en double par defaut, mais tu peux travailler en float avec une ligne au debut de ton script (ou module).

Puis le typedef, tu peux le faire en C, je vois pas pourquoi t'aurais besoin des template pour ca. L'interet des template est quand meme autre.

Citation :
std::list fait partie du langage, c'est une partie de la STL, il n'y a pas plus de différence qu'avec Python, Java ou autres où la liste n'est pas non plus un type de données natif.



Si parce que c'est integre au langage, a tous les niveaux. T as beaucoup de code c++ qui n'utilise pas la stl, alors que t as pas de code python sans liste. In fine, tu peux toujours dire que c'est equivalent, parce que finalement, python est implemente en C, et donc tu peux reimplementer python en C++...

Puis niveau syntaxe, le concept de list comprehension est quand meme plus lisible en python, la aussi consequence du fait que ce soit partie integrante du langage. Parce que le

std::list<int> a(n)
std::list<int>::iterator i
int j(0);
for(i = a.begin(); i != a.end(); ++i) {
*i = j * j
}

j'ai jamais accroche, mais bon, c'est peut etre perso. (je pense que meme qu'en general, les gens preferent a = [i*i for i in range(n)] ).

Citation :
En ce qui concerne Matlab, je suis comme toi, je n'ai pas



Si, si, j'ai. Je suis vraiment curieux de savoir ce que tu codes comme truc, pour de vrai. Si tu pouvais en dire plus :)
189
En fait, j'ai fourché, je n'aime pas, je l'ai parce que je dois l'utiliser, mais je n'aime pas, la modularité est pourrie :(
En fait je fais des modèles d'apparence non linéaires - la version classique, c'est l'ACP, là, c'est non linéaire ou linéaire par morceau -. Et tout est programmé à peu près proprement ;)

Le typedef sert à spécialisé le template d'une classe matricielle générique ;)

C'est clair que si Python te fait la sélection de manière transparente, ça va.
190

Citation :
C'est clair que si Python te fait la sélection de manière transparente, ça va.



Typiquement, le defaut est au double, ce qui est normal. Mais tu peux changer ca si tu veux. Les fonctions detectent automatiquement le type a traiter, et appellent les bonnes fonctions derriere en BLAS/LAPACK (les wrappers sont automatiquement geres depuis fortran, ou atlas, ou autre implementation blas/lapack).

Pour l'ACP, tu fais ca sur quel types de donnees ? des photos satelitaires ? Des videos ? Parce que pour que ca prenne des jours ou des semaines, ca doit etre de sacres dimensions !