Les perfs. C’est juste mais il faut savoir que c’est un désastre niveau performances.
Disons avant tout qu’on a le droit de se foutre des perfo si ce n’est vraiment pas un problème dans le cas qui nous occupe.
S=A+B; en C++ ça va calculer A+B, stocker le résultat dans un conteneur temporaire puis recopier tout ça dans S.
S=A+B+C; est encore pire car il le fait deux fois.
Si on veut des perfs, on doit utiliser des lib qui vont bien (ou, localement, écrire soit même la boulce externe sur les coeffs avec S[i]=A[i]+B[i]+C[i] dans la dite boucle…Mais c’est pue lisible).
On obtient les même perfs qu’en fortran soit avec des lib basées sur le template metaprogramming.
Lire par exemple :
mrao.cam.ac.uk/~bn204/public … slides.pdf
Oui alors que si on fait du c++ avec une bonne lib generaliste (sorry pour les accents…j’ai un clavier etrange la…) comme Qt, on se rend vite compte qu’on n’a souvent a gerer la memoire soit meme…ou si peu.
Comme tu dis, on ne parle pas, ou si peu, de la STL…donc de boost ou de qt encore bien plus rarement 
Tout cela produit des gens qui, en sortant de l’ecole:
- ne savent pas coder correctement en C++ (mais ce n’est pas le plus grave)
- ont une fausse idee de ce qu’est le C++ et sont donc incapables de dire si c’est une bonne idee de l’utiliser dans tel ou tel cas…et ca c’est grave pour un inge sortant d’une ecole qui delivre une formation en info
Valvino : on ne va pas parler de ca en detail ici mais le design de la STL (sans destructeur) virtuel me semble tout de meme…pour le moins etrange. Si on commence a faire une vraie hierachie entre les classes, on voit vite que les conteneurs STL sont faits pour etre integres dans des classes plus complexes mais pas pour etre derives…c’est un peu chiant.
stackoverflow.com/questions/1647 … estructors
Oui, pour des vecteurs de dim 3 ça ne sert pas à grand chose.
Les gens (moi compris) codent en C++ comme ils coderaient en C.
Alors tu fais du C compilé avec un compilo C++.
Tout dépend de l’application. Coder un truc comme la partie « GUI » de Qt sans une approche objet est en gros impossible ( l’api ne sera jamais vraiment propre).
Par contre, le C++ n’est pas en soit meilleur que le C. Certains algos. On va parfois des gens définir une hiérarchie d’objets qui en soit à un sens mais n’est pas utile et ensuite ils se retrouvent avec des pb de perfs insolubles : une fois que tout est bien encapsulé, on a parfois à accéder à des données qu’on se retrouve obligé de copier car le modèle objet n’était pas prévu pour ça.
C’est comme d’écrire "def X(self):return self.X en python 
fakbill : Ce bouquin et sa suite sont malheureusement vitaux pour développer en C++ amazon.fr/Effective-Specific … 0321334876 .
oui c’est une des bibles du C++.
Même avec un bon livre, je pense que la seule façon de coder par exemple une bonne lib avec une bonne API en C++ est de la coder, de se rendre compte que c’est de la daube, de la re-coder, de se rendre compte que certains trucs ne vont pas…and so on 
hehe il est clair que le C++ est trop complexe.
De plus, l’encapsulation…je n’ai jamais trop compris l’intéret profond de la chose : Si X est privé, je fais un getter public X(){return X;} et qu’est ce que ça change?? Pas grand chose.
Je préfère le duck typing à la python.
C# n’est pas mal mais il souffre du fait que « c’est microsoft » donc il n’y a pas de communauté scientifique autour de C#. Dommage car; objectivement; le design de ce langage est bon.
fakbill a écrit:
hehe 
il est clair que le C++ est trop complexe.
De plus, l’encapsulation…je n’ai jamais trop compris l’intéret profond de la chose : Si X est privé, je fais un getter public X(){return X;} et qu’est ce que ça change?? Pas grand chose.
L’idée c’est que la partie privée d’une classe peut changer sans avoir à réecrire du code qui l’utilise. Mais en pratique ca ne marche pas car on ne peut utiliser une classe sans avoir connaissance de tous ses membres même privés, à l’aide des en-têtes.
En fait l’encapsulation marche avec un design pattern proxy privé :
Header :
// ma classe .h
struct Classe;
class Interface {
public:
int getVariable() const;
private:
boost::scoped_ptr<Classe> instance;
};
Source :
// ma classe .cpp
struct Classe {
Classe() { ... }
int maVariablePrivee;
};
int Interface::getVariable() {
return instance->maVariablePrivee;
}
Quand je codais des API sensibles, c’était la meilleure solution. Car sinon on divulgue des tonnes de détails rien qu’avec la structure de nos classes.
En général ce n’est pas trop contraignant si l’API est une sorte de boite noire qu’on initialise avec des données et produit un résultat. Sa structure interne est complètement opaque comme ca.
En particulier (je ne connais rien au C++ mais j’ai déjà programmé en Java, donc j’imagine que c’est similaire) avoir un champ x privé accessible à l’aide d’une fonction publique getX() peut être très pratique si l’on tient, comme l’a souligné Marc de Falco, à utiliser des API. Ainsi, s’il existe plusieurs implémentations différentes du même objet, il suffit à chacune de ces implémentations de disposer des fonctions publiques requises par l’API pour être utilisables.
Et, de manière générale, on peut commencer par créer une interface, que pourront implémenter diverses classes ; puis une équipe de programmeurs crée différentes implémentations de cette interface, tandis qu’une autre est capable de programmer des objets faisant appel à des fonctions prévues par cette interface, et qui seront opérationnels dès lors que l’on disposera d’une implémentation de ladite interface.
Marc de Falco : ha oui…je ne pensais qu’à des arguments techniques et non pas à des argu de propriétés indu.
V@J : pour moi, un getter n’a de sens que s’il teste qqch. Partant de là, il a rarement un sens:
Supposons que K soit une temperatue en Kelvin. Je peux penser que GetK() (qu’on écrit souvent juste K() comme dans Qt par ex.) devrait tester si K (la variable privée) est bien >0 (en supposant qu’on est dans un cas basique et pas dans un laser où des temperatures…bref ). En fait, non, ça n’a pas de sens. On doit crier au moment où on SetK(ActualK) sir ActualK<0. Donc les Setters oui. Les Getter bof.
La séparation du travail que tu drécis marche très bien dans tous les langages. C’est uniquement une question de documentation de l’API et de com des changements entres les équipes durant le devel. La preuve, ça marche très bien en C pour des choses aussi complexe que le noyo linux.
je retiens l’argu du « je veux cacher le maximum »…et je remarque que tu considères (comme moi) que le C++ sans boost et ou qt ce n’est pas vivable 
ben…justement…tu fais quoi en pur c++ sans lib?? par grand chose
Je n’ai pas dit qu’il fallait faire du c++ pur sans lib (ce qui est très limitatif effectivement), j’ai juste dit que qt ou boost ne sont pas indispensables selon le projet
tu ne penses qu’à la partie graphique de qt je suppose…mais qt c’est bcp plus que ça.
qt est un ensemble de lib extrêmement pratiques.
Rien que qmake : tu peux faire des makefile dans un langage indémerdable des années 70 mais qmake sera la même chose de façon beaucoup plus simple.
doc.qt.digia.com/qq/qq19-containers.html
« Whereas STL’s containers are optimized for raw speed, Qt’s container classes have been carefully designed to provide convenience, minimal memory usage, and minimal code expansion. For example, Qt’s containers are implicitly shared, meaning that they can be passed around as values without forcing a deep copy to occur. »
on peut faire sans mais on constate que le nouveau standard de C++ intègre beaucoup de concepts testé dans boost Pour moi, pas de C++ sans boost ou qt. De toutes façons, je ne fais presque plus que de python (on n’a pas de temps à perdre à gérer la mémoire et la std lib de python est gigantesque et ultra bien fichue )
imo utiliser qt pour ça c’est un peu sortir le tank pour tuer la mouche. Pour boost on est d’accord.
C’est juste faux en 2012.
Certains pensent toujours que qt est « lourd, mal foutu ou je ne sais quoi ».
Cette légende vient du fait que la licence de la première version n’était pas libre d’où des trolls du genre « ça pue c’est pas libre »…ça date mais c’est toujours vivace (comme bcp de trolls). L’API de qt est d’une propreté assez sidérante.
Après je le redis…si tu aimes le langage des makefiles…
). Par exemple, c’est une **très très mauvaise idée de faire coder les opérations + * sur les matrices avec de la surcharge d’opérateur : c’est justement l’un des cas où il ne faut surtout pas s’y prendre comme ça.