Le pub des programmeurs

Citation : Et je vois vraiment pas le probleme de maintenance. En GUI, tu fais comment sans les callbacks ?

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.

Citation :
php, je connais pas du tout. Mais en C, tu connais les membres de FILE, toi ? Non, moi non plus. FILE est une classe, fopen et cie les fonctions membres. L'implementation est cachee, seule l'API est decouverte.

Citation : Ca fait longtemps que c'est plus le cas, quand meme, au niveau des sources... Et au niveau binaire, ca revient a ecrire des wrappers, et je pense pas que ca mette plus de temps en python qu'en C++ d'ecrire des wrappers compatibles avec les semantiques modernes du langage (exception safe, entre autre).

Citation :
Et bien en l'occurence, FILE c'est un type (une struct il me semble) et les fonctions f* sur les FILE sont des fonctions. Ce n'est pas objet du tout, ce sont des restes de C qui ont été intégrés dans le C++. Dans le C, la notion de classe et fonction membres n'existent pas, il n'y a que les struct et les fonctions.

Citation :
Il n'y a aucun callback dans les libraries GUI écrites en C++.

Citation : Je mixe allègrement du C++ avec des appels de fonctions C sans problème dans mon code, et sans encapsuler.

Citation :
On ne te parle pas spécifiquement de projets *libres*. Un gros projet, c'est maintenu plus de dix ans en entreprise, et par plusieurs personnes.

Citation : Non mais tu joues sur les mots, la. Oui, il y a pas le mot cle class en C, Mais concretement, ca change pas grand chose. En C++, le compilo t'aide un peu, c'est tout. Quand tu fais a.foo(), en fait, c'est juste foo(a); le compilateur fait la transcription, mais c'est juste un peu de syntaxe. C'est ce que je disais precedemment

Citation :
QT, les signals et les slots, ce sont des mots cles pour finalement avoir des fonctions comme objets. Alors si pas callback tu entends pointeur de fonction, oui, c'est pas tout a fait ca, mais si la encore tu vois un peu plus haut niveau, cad fonction comme argument d'une autre fonction, ben c'est pareil.

Citation : Je crois qu'on parle pas de la meme chose. Ce que je voulais dire, c'est qu'en general, tu peux pas compiler du code C avec un compilateur C++; donc le C n'est pas un subset du C++. C'Etait vrai il y a longtemps, mais ca l'est plus.

Citation : linux, apache, python, perl, gcc, mozilla, kde, qt, X, open office, c'est des petits projets avec 2 personnes pendant 3 mois ? Bien sur qu'il y a pas que le libre, mais il y a en tout cas de sacres gros projets maintenus sur le long terme en libre, *aussi*.

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.

Citation :
Erratum, j'ai écrit fonctionnel au lieu d'impératif. Pour l'objet en C, je trouve qu'il y a déjà un abus de langage. Si tu peux effectivement coder à la main une structure d'objet en C, tu n'as pas tous les avantages d'un vrai langage objet. Et le C, pour moi c'est de l'impératif car la notion d'objet, de polymorphisme, d'encapsulation des données et des méthodes n'existent pas en C "normal".

Citation :
Pour ton exemple d'héritage et de factorisation de code, ben ils en parlent dans le même bouquin et expliquent qu'il faut préférer l'aggrégation à l'héritage pour cette raison.

class Foo:

    # do nothing

    pass



class Decorator:

    def __init__(self, decoree):

        self.inst = decoree

    def __getattr__(self, name):

        return getattr(self.inst, name)



f = Foo()

d = Decorator(f)

# -> si blop existe dans decorateur, c'est Decorator.blop qui est excutee, 

# c'est dispatche vers les membres de f sinon

d.blop() 

Citation :
Ben écoutes, j'utilise des libraries écrites initialement en C dans mes programmes C++ grâce à cette technique donc je sais bien que ça fonctionne.

extern "C" {

    int foo(void);

}



int bar(void);



int main(void)

{

    bar();

    foo();

    return 0;

}

U foo

U __gxx_personality_v0

T main

T _Z3barv

Citation :
Ce que j'appelle callback c'est bien une fonction que tu passes en paramètre, et la fonction n'a pas d'attributs propres comme pour les objets. Donc en C++ c'est un forcément pointeur sur une fonction. Je ne sais plus ce qu'impliquent les signals et slots en termes de fonctionnalités du langage, mais ça ne se situe pas au niveau des callbacks il me semble puisque c'est réalisable en C++ standard.

Citation :
No, the right way to write a function that must return a new object is to have that function return a new object. For Rational's operator*, that means either the following code (which we first saw back on page 102) or something essentially equivalent: (Item E23, P24)

inline const Rational operator*(const Rational& lhs,
const Rational& rhs)
{
return Rational(lhs.n * rhs.n, lhs.d * rhs.d);
}

Sure, you may incur the cost of constructing and destructing operator*'s return value, but in the long run, that's a small price to pay for correct behavior. Besides, the bill that so terrifies you may never arrive. Like all programming languages, C++ allows compiler implementers to apply certain optimizations to improve the performance of the generated code, and it turns out that in some cases, operator*'s return value can be safely eliminated (see Item M20). When compilers take advantage of that fact (and current compilers often do), your program continues to behave the way it's supposed to, it just does it faster than you expected.

Citation :
Name Mangling ¤ Item M34, P4

Name mangling, as you may know, is the process through which your C++ compilers give each function in your program a unique name. In C, this process is unnecessary, because you can't overload function names, but nearly all C++ programs have at least a few functions with the same name. (Consider, for example, the iostream library, which declares several versions of operator<< and operator>>.) Overloading is incompatible with most linkers, because linkers generally take a dim view of multiple functions with the same name. Name mangling is a concession to the realities of linkers; in particular, to the fact that linkers usually insist on all function names being unique. ¤ Item M34, P5

As long as you stay within the confines of C++, name mangling is not likely to concern you. If you have a function name drawLine that a compiler mangles into xyzzy, you'll always use the name drawLine, and you'll have little reason to care that the underlying object files happen to refer to xyzzy. ¤ Item M34, P6

It's a different story if drawLine is in a C library. In that case, your C++ source file probably includes a header file that contains a declaration like this, ¤ Item M34, P7

void drawLine(int x1, int y1, int x2, int y2);

and your code contains calls to drawLine in the usual fashion. Each such call is translated by your compilers into a call to the mangled name of that function, so when you write this, ¤ Item M34, P8

drawLine(a, b, c, d); // call to unmangled function name

your object files contain a function call that corresponds to this: ¤ Item M34, P9

xyzzy(a, b, c, d); // call to mangled function mame

But if drawLine is a C function, the object file (or archive or dynamically linked library, etc.) that contains the compiled version of drawLine contains a function called drawLine; no name mangling has taken place. When you try to link the object files comprising your program together, you'll get an error, because the linker is looking for a function called xyzzy, and there is no such function. ¤ Item M34, P10

To solve this problem, you need a way to tell your C++ compilers not to mangle certain function names. You never want to mangle the names of functions written in other languages, whether they be in C, assembler, FORTRAN, Lisp, Forth, or what-have-you. (Yes, what-have-you would include COBOL, but then what would you have?) After all, if you call a C function named drawLine, it's really called drawLine, and your object code should contain a reference to that name, not to some mangled version of that name. ¤ Item M34, P11

To suppress name mangling, use C++'s extern "C" directive: ¤ Item M34, P12

// declare a function called drawLine; don't mangle
// its name
extern "C"
void drawLine(int x1, int y1, int x2, int y2);

Don't be drawn into the trap of assuming that where there's an extern "C", there must be an extern "Pascal" and an extern "FORTRAN" as well. There's not, at least not in °the standard. The best way to view extern "C" is not as an assertion that the associated function is written in C, but as a statement that the function should be called as if it were written in C. (Technically, extern "C" means the function has C linkage, but what that means is far from clear. One thing it always means, however, is that name mangling is suppressed.) ¤ Item M34, P13

For example, if you were so unfortunate as to have to write a function in assembler, you could declare it extern "C", too: ¤ Item M34, P14

// this function is in assembler — don't mangle its name
extern "C" void twiddleBits(unsigned char bits);

You can even declare C++ functions extern "C". This can be useful if you're writing a library in C++ that you'd like to provide to clients using other programming languages. By suppressing the name mangling of your C++ function names, your clients can use the natural and intuitive names you choose instead of the mangled names your compilers would otherwise generate: ¤ Item M34, P15

// the following C++ function is designed for use outside
// C++ and should not have its name mangled
extern "C" void simulate(int iterations);

Often you'll have a slew of functions whose names you don't want mangled, and it would be a pain to precede each with extern "C". Fortunately, you don't have to. extern "C" can also be made to apply to a whole set of functions. Just enclose them all in curly braces: ¤ Item M34, P16

extern "C" { // disable name mangling for
// all the following functions

void drawLine(int x1, int y1, int x2, int y2);
void twiddleBits(unsigned char bits);
void simulate(int iterations);
...
}

This use of extern "C" simplifies the maintenance of header files that must be used with both C++ and C. When compiling for C++, you'll want to include extern "C", but when compiling for C, you won't. By taking advantage of the fact that the preprocessor symbol __cplusplus is defined only for C++ compilations, you can structure your polyglot header files as follows: ¤ Item M34, P17

#ifdef __cplusplus

extern "C" {

#endif

void drawLine(int x1, int y1, int x2, int y2);
void twiddleBits(unsigned char bits);
void simulate(int iterations);
...

#ifdef __cplusplus

}

#endif

There is, by the way, no such thing as a "standard" name mangling algorithm. Different compilers are free to mangle names in different ways, and different compilers do. This is a good thing. If all compilers mangled names the same way, you might be lulled into thinking they all generated compatible code. The way things are now, if you try to mix object code from incompatible C++ compilers, there's a good chance you'll get an error during linking, because the mangled names won't match up. This implies you'll probably have other compatibility problems, too, and it's better to find out about such incompatibilities sooner than later, ¤ Item M34,

Hors sujet : Gabou tout as le sujet de stage en MP

Citation :
Là j'ai un stage à filer à un élève ingénieur de dernière année