Sujet Le pub des programmeurs
- 1 925 réponses
- 117 participants
- 123 070 vues
- 130 followers
y a des programeurs sur AF si oui vous bossez sous quoi ?
Pov Gabou
Dr Pouet
zieQ
Dr Pouet
Hors sujet : Appelle nous Pouet et Gabou, restons simples, cher zieQ 
Pov Gabou
zieQ
Pov Gabou
Citation :
Ne pas oublier la protection des données encapsulées : public, protected, private... Tu vas me dire que c'est une contrainte de protéger les données, moi je vais te répondre que ça évite de faire des conneries
Je dis pas que c'est pas important, je dis que c'est trivial, et que tout langage a cette possibilite, y compris le C finalement.
La encore, cette difference private/public/protected n'existe qu'en C++ et en java, parce que c'est une limitation du typage statique. En plus, en C++, t'as un gros probleme a ce niveau la a cause de headers, qui revient a faire pareil qu'en C finalement. Si tu veux cacher l'implementation dans des projets d'un peu gros calibre (et par la, j'entends a peu pres n'importe quoi qui ne soit pas un exemple de bouquin)
header:
/* forward declaration */
class A_imp;
class A {
private:
A_imp *m_imp;
};
implementation
class A_imp {
// bla bla
};
Du coup, c'est comme en C ou tu declares les structures, mais ou tu les definis pas (tu peux declarer FILE* a, mais pas FILE a avec stdio). Tu peux aussi utiliser une classe virtuelle, et heriter d'elle, mais c'est pas super joli non plus.
En C++, t'as pas de mecanisme pour decoupler fonctions membres et "variables" membres (pas sur du terme technique).
Citation :
Là va falloir m'expliquer cette remarque parce que je ne comprends pas ce que tu veux dire.
C'est fondamental: deja, tu ne peux deriver aucun type du langage C++. Tu peux pas faire "class MyInt : public int". Ensuite, une fonction n'est pas un objet en C++, donc tu peux pas passer facilement des fonctions en arguments (les pointeurs de fonctions membres en C++, je suis pret a parier que la majorite des programmeurs C++ savent pas comment ca marche). Une classe non plus.
En python (je prends python parce que je connais plus que superficiellement, mais ca reste valable pour pleins d'autres langages), le fait qu'une classe EST un objet est super utile; rien que pour avoir des attributs de classe par exemple.
Le fait que ce soit dynamique est aussi super utile: par exemple, j'ai une classe qui modele un modele numerique en python, GMM. Normalement, ca marche en multi dimension, mais en 1 dimension, on peut faire plus rapidement, surtout si j'implemente la dite fonction en C. Et bien en python, je peux faire (self est l'equivalent de this en C++; en python, il est explicite):
from foo import super_fast_func
class GMM:
def __init__(self, dim):
if dim == 1:
self.foo = super_fast_foo
Si je suis en dimension 1, l'implementation est changee a la volee. Le truc super important, c'est que ca se change n'importe quand, y compris quand l'objet instancie de GMM est deja cree (en fait, avant l'appel d'__init__, l'objet est deja construit en python, mais je veux pas rentrer dans les details). Donc par exemple, tu peux rajouter des fonctions a la volee selon l'etat de l'objet.
Citation : Ce problème est inhérent à *tous* les langages objets, et pas spécifiquement le C++.
Non, c'est inherent aux langages a typage statique (C++ et Java, en gros). Dans un langage a typage dynamique, si tu as fait une erreur de conception, c'est pas un probleme, car tu n'utilises pour ainsi dire *jamais* le fait qu'une instance de B est aussi de type A. On s'en fout, ce qui compte, c'est que l'interface (ie les membres, fonctions, attributs, etc..) soit la meme.
Un des inventeurs du concept objet, Kay, qui a aussi invente le smalltalk, il l'a fait avec un langage a typage dynamique. C'est pas par hasard, je pense.
Citation : Ben euh tu passes ton objet en référence ?
Je parle de la valeur de *retour*. C'est la le probleme, pas l'entree. Tu peux pas passer une valeur de retour par reference en C++ (puisque ca n'a pas de sens sans gestion automatique de la memoire).
La gestion de memoire automatique: le temps reel, Ok, les GC courants sont pas adaptes, car ils privilegient le debit par rapport a la latence, alors que temps reel est le contraire. Mais quand tu fais du temps reel, je crois que tu geres de toute facon pas de memoire dans les threads temps reels; malloc est souvent plus couteux qu'un declenchement de GC (a moins que le malloc soit gere a l'aide de mmap/pools, mais a ce niveau la, c'est plus facile de toute allouer a l'avance). Bon, je m'avance beaucoup sur ce point, j'ai tres peu d'experience; pour la MAO, en tout cas, tout ce qui est DSP, le malloc est fortement deconseille (tout appel systeme est prohibe en fait). Tu lockes une partie de la memoire pour eviter le cout eventuel de la pagination, et tu fais avec ce que tu as allouer a l'initialisation ou au reste de l'algo dsp, point barre.
Ensuite, pour a peu pres tout le reste, ca sert pas a grand chose, la grestion memoire a la main. Par exemple, la memoire allouee par un GC respecte beaucoup le principe de localite qu'un malloc classique (au moins sous linux; mais je suis pres a parier que le malloc sous linux est bien plus performant que sous windows de toute facon); y a moins de pbs de fragmentation. Quand tu sais comment fonctionne un malloc et un GC basique, tu vois vite que c'est pas si different dans le principe.
En particulier, pour les containers STL, java est aujourd'hui tout aussi performant si tu utilises les JVM IBM sous linux sur tous les benchmarks que j'ai pu voir (j'ai pas pousse trop loin non plus; il y a surement des cas ou ca foire; en fait, le pire cas doit etre bien pire en java qu'en C++, je pense). C'est aussi lie au pb que je soulevais avant vis a vis de l'absence de retour sans copie en C++ (la STL etant base sur la copie; t'es sur de te planter a un moment si tu as list<blop> ou blop est un pointeur; tu peux eviter ca en utiliser noncopyable de boost, cependant, mais c'est pas tres elegant).
Citation :
C'est moins souple à l'utilisation mais ça fait des programmes avec moins d'erreurs.
Encore une fois, ton raisonnement sous entend que toute autre chose etant egal, le typage statique est plus safe. Mais justement, tout autre chose n'est pas du tout egale. Je suis d'accord qu'il y a des projets ou declarer le type de certains fonctions est tres utile, et c'est un manque dans python.
Pour finir sur une note positive, je trouve que le meilleur argumentaire *pour* le C++, c'est celui de L. Soras que je copie de la:
http://lalists.stanford.edu/lad/2003/02/0068.html
(contexte: reponse a une interview de E. Castro de Lopo, un des developpeurs les plus celebres de la scene programmation audio sous linux, auteur de libsndfile, et SRC, qui a bosse pour fairlight pendant qqs annees, et haissant profondement le C++, plus que moi; je suis entre autre pas d'accord sur le fait que le C est plus adapte, ou plutot moins pire que le C++ pour de la conception objet; je suis d'accord pour les template par contre
)Citation :
Erik de Castro Lopo wrote:
>
> 1) C++ is not the only solution.
> 2) OO can be done in Standard C.
> 3) Some people (me included) might prefer doing OO programing in C
> rather than C++.
I agree, but partially. My opinion about OO in C vs C++ :
I think C++ adds (very useful) functionalities to C. You
can still emulate them, but it's often a pain and less
"encapsulated" than equivalent C++ concept. More, goals
of language constructions are more obvious if written
in native C++, making easier communication between
developers. C++ is just more suitable for OO developement.
Who does seriously want to write a book with a typewriter
when one can use a word processor ?
C++ is not safer or faster than C or whatever. If you want
to make something stupid, nothing prevents you to do it.
I agree C++ is still far from perfect, but for me it's today
the best solution for audio development. It needs strong
coding rules, deep comprehension of the language, software
engineering knowledge and experience to be used efficiently.
It won't make miracles just because it's C++. Learning and
applying all these concepts won't happen "in 21 days", for
sure.
Finally I'd say it makes gain time when mastered, a lot of
time, one of the most valuable ressource in today's world
IMHO.
-- Laurent
Pov Gabou
emx
Dr Pouet
- < Liste des sujets
- Charte