Sujet Le pub des programmeurs

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