Le pub des programmeurs

Citation : Mais je suis vraiment curieux, parce qu'une grosse partie de ton argumentaire, a toi et pouet, est base sur ces fameux gros projets maintenus sur 10 ans, et que je vois toujours pas ce qu'ils ont de si particulier.

Citation : Y a quand meme un truc que je comprends pas. Ca veut dire quoi gros projet pour vous ? Parce que bon, les gros projets en libre, par exemple, c'est pas ca qui manque, et y en a pas beaucoup en C++ quand meme.

char*c=malloc(sizeo(char*))

Citation : Le fait que le C soit pas beaucoup utilise en libre, c'est parce que le libre s'est developpe sur unix, et que le C++ est a l'antithese de la philosophie unix, je pense. Contrairement a toi, je pense que c'est fondamentalement un probleme esthetique/ideologique, plus que pratique. Je pense que l'association windows/c++ est assez pertinente, modestie mise a part: c'est vraiment la meme philosophie.

Citation : Un callback, c'est une fonction, sans attributs. Un objet possède à la fois des attributs et des fonctions qui modifient les attributs. Et bien tu fais une classe de base, et tu dérives tes composants de cette classe de base, en spécialisant leur comportement. Il n'y a aucun callback dans les libraries GUI écrites en C++.

Hors sujet :
desole pour la reponse un peu tardive a plusieurs posts, mais AF rame a mort, la

Citation :
Non je ne joue pas sur les mots. Là, t'es en train de dire que le fonctionnel c'est pareil que l'objet.

Citation :
>"I also think that there is a real problem with the way classes are defined
>in C++ and this is a problem which really does impact design. The problem is
>that you are forced to define the private data members and functions at the
>same time as the public ones. This is OK for the trivial C++ examples you
>see in textbooks but as soon as you REALLY want to hide the private
>information you end up defining the class to have a single private void
>pointer which gets something allocated to it in the implementation. This is
>basically the same thing you do when doing OO programming in C, so where is
>the benefit of C++?"
>
>--
>
>You are not forced to define the private data members and functions at the
>same time as
>the public ones in C++. The way to handle this is to put the public
>interface in a pure
>virtual class:
>
>class animal
>{
>public:
> virtual int legs() = 0; // returns number of legs the animal uses when
>moving around
>};
>
>and then derive from that interface:
>
>class dog : public animal
>{
>public:
> int legs() { return 4; }
>};

i love C++. i think its one of the best things ever. but i happen to
agree with Erik. the solution proposed by martijn doesn't scale well,
and doesn't really address the issue in a comprehensive way. it
requires one pure virtual class per distinct set of private members,
for a start.

the kinds of problems i have with C++ stem from the fact that you
cannot mark a section of protected members as accessible from only a
particular set of friends. the only way to say "only class Foo can
access these member (functions)" is to create a separate class, make
Foo a friend of that class, and then inherit from it.

this gets really messy really soon. the editor object in Ardour
contains many distinct sets of functionality that i would really like
to partition. i could create a set of discrete classes that cover each
aspect of the functionality, and then do MI from all of them. the
problem is that is each one of these aspects *internally* needs to
know about the others, which now means that they each have to be
friends of each other. so what's the point? i'd end up with something
ludicrous like:

class EditorFoo {
...
protected:
friend class EditorThis;
friend class EditorThat;
friend class EditorTheOther;
...
friend class ObjectThatInteractsWithEditorFoo;
...
};

...

class Editor : public EditorFoo, EditorThis, EditorThat,
EditorTheOther .... {
}

which is really no help at all. the other alternative is to use HAS-A
instead of IS-A, and its even worse. we end up with lots of code like:

editor->foo->...
editor->that->...
editor->theother->...

all i'd really like it to be able to say:

class Foo {
protected:
/* scope A */
friend class Bar;
...
protected:
/* scope B */
friend class Baz;
...
};

such that Bar can only access stuff within "scope A" and Baz can only
access stuff in "scope B". that is, access control keywords
("private", "protected", "public" define access scopes). right now, a
friend class declared anywhere within the class declaration is a
friend, period.

none of this helps with the problem erik identified. i would really
love a C++ that did this:

class Foo {
public:
... stuff ...
private:
<some tokens that meant something like #include>
};

and then in other files, you would do:

#use "foo.h"

or

#implementation "foo.h"

or something like that. the first one would just bring in the public
declarations, and its what you'd use when you're calling or creating
Foo objects. the second one would be used in the definitions for the
member functions of Foo, and hence would almost certainly be limited
to "foo.cc".

note that the private stuff would be in a file that looked just like
the class declaration, but had no public (and protected?)
declarations. in other words, the class declaration it includes is
implicitly 100% private, but it can include header files that are
necessary for the private declarations.

just dreaming.

--p

Citation :
Mauvais exemple, les mots clés rajoutés par QT ne sont pas du C++ standard. Ils ont été introduit pour palier à une limitation du C++. N'empêche qu'avec d'autres librairies GUI, tu n'as pas besoin de ces mots-clés et ça ne justifie pas non plus l'utilisation de callbacks (ou pointeurs de fonction si tu veux)

Citation :
Et bien si justement :

extern "C" {
// ton code C ici
}

Citation :
Je connais pas mal Qt et un petit peu Mozilla, c'est très "objet", le code est très propre et lisible, et ne verras pas de pointeurs de fonction dedans

Citation :
En gros, je te conseille de relire le bouquin de Gamma et al. car j'ai l'impression que tu as loupé pas mal de trucs.

Citation :
La plupart des limitations que tu imputes au C++ concernent justement des pirouettes qui rendent difficile la maintenance de gros projets

Citation :
Dans les projets du libre, comme la plupart du temps c'est bénévole, si le projet est gros et compliqué tu n'auras (quasiment) que des développeurs compétents, voire très ou extrêmement compétent. Dans l'industrie, pour une bonne partie, c'est un gagne-pain, voire le seul boulot que tu as trouvé (je connais des docteurs en électro-magnétisme, un agrégé de poissons exotiques... qui pissent du code sur des applis de "gestion" ). Donc dans une équipe de 10 personnes, tu as au moins un maillon faible ( ), voire plusieurs.

Hors sujet :
Je me rends compte qu'encore une fois, je m'emporte un peu, et ca peut passer pour des attaques personnelles... C'est pas l'effet voulu, mais je trouve que ce genre de discussions permet d'approfondir des points qu'on connait pas forcement, et de voir un autre point de vue. Donc meme si j'en ai pas l'air, je trouve tres interessant vos arguments, car vous venez pouet et toi d'un autre contexte que le mien.

Citation :
Dans ces cas-là, il faut faire simple et clair, et éviter comme la mort le "balaize", "l'acrobatique", "l'astucieux"... D'ailleurs même quand c'est du code que tu as écrit toi-même, si tu dois le retoucher après l'avoir laissé 2 ans, tu as du mal à t'y retrouver si ce n'est pas "simple voire stupide".

int foo(int);

for_each(v.begin(), v.end(), _1 = bind(foo, _1));

[foo(i) for i in v]

Citation : extern C, c'est la convention de linkage; rien a voir avec la compatibilite C/C++ au niveau source. Ca permet au contraire aux fonctions C++ d'etre appeles par des facilites faites pour le C (par exemple dlopen sous unix).

Citation : Je crois pas non, mais je veux bien que tu me donnes un exemple d'un truc que j'ai pas compris Vu qu'on a jamais parle des design pattern pour l'instant, je vois difficilememtn comment tu pourrais savoir ce que j'en ai compris ou pas, cependant...

Citation : Ou l'approche QT (ou par macro, mais je pense que derriere, c'est equivalent). Tous les deux sont des astuces pour donner l'impression que tu peux passer une fonction en argument d'une autre (ce que moi j'appelle un callback, mais je pense que le terme est ambigu, car pour toi, ca veut dire pointeur, alors que pour moi, ca veut juste dire pouvoir passer une fonction comme une variable).

Citation : Mais c'est bien ce que je reproche au C++: le fait que c'est tellement complexe quie chacun implemente un sous ensemble, qui est chaque fois different...

Citation : J'ai jamais parle de fonctionnel (serieux, ou est ce qu'on parle de currying, de closures, etc... la ? )

Citation : The problem is that you are forced to define the private data members and functions at the same time as the public ones.

Citation : Je suis bien conscient de ca. Mais du coup, je trouve que ca apporte beaucoup d'eau a mon moulin sur le fait que le C++ n'est pas un langage fantastique; en gros, on l'utilise parce que c'est ce que les gens connaissent, et que comme tout le monde connait le C ou le Java, on peut faire du C++, les 3 langages etant tres similaires...

Citation : Donc ton argument, c'est que le C++ est un bon langage pour eviter ca ? Serieusement, je comprends pas le raisonnement. Faire du code lisible, c'est quand meme nettement plus possible en python (ou en ruby, lisp, VB, ce que tu veux) qu'en C++. Si je veux appliquer une fonction a une liste C++, on fait un truc du style

Citation : Faire du code lisible, c'est important pour moi parce que la duree, c'est en annee, et c'est souvent un peu complique algorithmiquement (les structures de donnees sont hyper simples, par contre, dans la majorite des cas). C'est une des raisons pour laquelle j'ai abandonne tres vite blitz, par exemple.

Citation : Je me rends compte qu'encore une fois, je m'emporte un peu, et ca peut passer pour des attaques personnelles... C'est pas l'effet voulu, mais je trouve que ce genre de discussions permet d'approfondir des points qu'on connait pas forcement, et de voir un autre point de vue. Donc meme si j'en ai pas l'air, je trouve tres interessant vos arguments, car vous venez pouet et toi d'un autre contexte que le mien.

Citation : Sinon comme dis Dr Pouet, ilog views est bien fichu aussi d'après ce que j'ai entendu.

Citation : Y a quand meme un truc que je comprends pas. Ca veut dire quoi gros projet pour vous ? Parce que bon, les gros projets en libre, par exemple, c'est pas ca qui manque, et y en a pas beaucoup en C++ quand meme.