Reply to thread

Message: [QUOTE="Jerry Coffin, post: 3972346"] [ ... ] The bottom line is pretty simple: something like 'extern "C"' is really trying to give a guarantee about a C compiler, but the C++ standard doesn't really have any control over C compilers. You can only accomplish something useful with 'extern "C"' by having a C compiler that's written to cooperate with your C++ compiler -- but the C++ standard can't really do anything about that, and for that matter the C standard really can't either. I think what he's saying (in effect) is that the main time PODs matter or get used, is when you have a header that you can compile as either C or C++, and you want to have (at least some) assurance of compatibility between the two. [ ... ] Yes -- to be a POD, the default ctor, copy ctor and dtor must all be trivial. A trivial ctor must be generated by the compiler -- any user defined ctor is non-trivial. Even if it's carefully written to do exactly what a compiler-generated ctor would have done, the fact that you wrote it still means it's non-trivial. In C++ 98/03, if you define any ctor, that prevents the compiler from generating a default ctor. If you want a default ctor, you need to define one, and by definition, when/if you do so, it won't be a trivial ctor. Likewise with the dtor, copy ctor and copy assignment operator. In C++ 0x, however, there's an "=default" syntax that allows you to tell the compiler to generate a default ctor, copy ctor, copy assignment operator, and/or dtor, even if you _have_ defined some other ctor. For example: class X { int data; public: X(int val) : data(val) {} X() = default; X(x const &) = default; X &operator=(X const &other) = default; ~X() = default; }; Now, we have a user-defined ctor that takes a value of type int that is used to initialize the data member -- but we also have explicitly defaulted the definitions of the other special member functions, so they remain "trivial" and the type is still a POD. One other strange wrinkle: it's possible to create a non-trivial special member function using the '= default;' syntax. To be trivial, the function must (among other things) be inline, and the '=default;' must be on the _declaration_ of the function. If (for whatever strange reason) you choose to, you can do something like: class Y { // ... public: Y(); }; Y::Y() = default; You've now explicitly defaulted the default ctor, BUT the '=default' isn't on the initial declaration, and your definition is _not_ an inline function, so it's no longer trivial. [ ... ] An overloaded operator _is_ a function -- it just has a rather different name than most other functions. Overloaded operators are typically quite short functions, so there's a good chance that the compiler can generate inline code. Nonetheless, the fact that it's an overloaded operator does not (in itself, at least with any compiler I've ever seen or heard of) make any difference in whether the code will be generated inline. The code generation depends on the size and complexity of the function, not the name it's given. [/QUOTE]

Verification