Reply to thread

Message: [QUOTE="James Kanze, post: 3968160"] Initialization syntax. The most important use is for arrays, since you can let the compiler count the members when using aggregate initialization, e.g.: std::string const names[] = { "Abert", "Bertha", "Charles" ... } ; It's also useful for structs, however, when you need static initialization (especially for tables of structs), e.g.: struct MapInit { char const* key; int value; }; MapInit const initTable[] = { { "toto", 42 }, { "titi", 0 }, // ... }; Layout compatibility is an awkward problem. C++ can mandate a certain number of things with regards to how the C++ compiler lays out data, but it can't mandate anything with regards to how other languages layout data. In the end, it's a lot like the ``extern "C"'' fiasco: C++ requires a compiler to support it, stating that functions declared ``extern "C"'' must be callable from C (or something along those lines). Which is all nice and fine, but what does it mean if the platform doesn't have a C compiler? Or if it has several C compilers, with different calling conventions? In practice, of course, on most small and medium sized systems today, the system ABI is defined in terms of C, which means that there will be a C compiler, and all C compilers will use a commun layout and common calling conventions, so the problem doesn't come up; C is the lowest common denominator. If you look at it closely, you'll see that the standard doesn't actually give any guarantees with regards to standard layout and other languages, for the reason stated above. There may be some advanced programming techniques which depend on standard layout, but for the everyday user, the only really significant distinction is whether the class could be written in C or not---if it could, it will be accessible from C, and probably from most other languages as well (on typical small and medium general purpose computers---I wouldn't count on it on mainframes, nor for that matter on embedded systems); otherwise, it won't be. (You may, of course, add non-virtual member functions, including conversion operators, but not constructors, destructors or assignment operators, without causing problems.) The other thing that is often important is whether the class is an aggregate which supports static initialization. But in practice, the two overlap; there are very few cases where you can use static aggregate initialization but couldn't write the class in C. (The presence of a pointer to member in the class would be an example of one.) A conversion operator is just an ordinary member function. [/QUOTE]

Verification