Reply to thread

Message: [QUOTE="James Kanze, post: 3972390"] Yes and no. For the user, aggregate initialization can be an advantage in certain cases, e.g. my examples of letting the compiler calculate array size. For the user, there are really three things which interesting: 1. Aggregate initialization: useful for letting the compiler calculate the size of an array, and in general for static data. 2. Static initialization, for avoiding order of initialization issues. This requires trivial constructors and constant expressions in the initializer; for compound types (struct's and arrays), the type must be an aggregate, and aggregate initialization must be used. (Otherwise, you must have a constructor somewhere, and the type ceases to be trivial.) 3. PODs or layout compatibility: mainly important with regards to communicating with other languages, especially C. (The system API is generally defined in terms of C these days.) Fiasco may be too strong a word, but formally, the standard guarantees much less than it seems to. (I certainly doesn't guarantee anything with regards to DLLs, for example.) All that it says (with regards to C) is ``Every implementation shall provide for linkage to functions written in the C programming language, "C", and linkage to C + + functions, "C++".'' Except that it doesn't specify how these "functions written in the C programming language" are to be compiled or linked; an implementation may require you to compile them using a special C compiler, which generates code incompatible with the system API, for example. And it doesn't address the issue of what to do if there is no C compiler for the system. At least some of the people involved with the standardization proceedure are aware of this weakness, although the committee doesn't seem to have wanted to address it. I think the general intent is more along the lines that IF there is at least one C implementation available on the platform, then the compiler must support linkage with one of them, and document which one, and what is necessary to make it work. The probable reason the committee didn't address the problem is that it isn't one in practice. Practically all platforms that support C++ have a standard C ABI, which is adhered to by all C compilers, and practically all C++ compilers come with a C compiler, and require no special steps to link C and C++. So the standard may not say exactly what was wanted, but in practice, everything works as was desired. Until the day someone decides that C is dead enough that they don't need a C compiler for their platform. [...] The C++ standard can't impose anything on other languages, only on C++. More or less, yes. With the addition of non-virtual member functions, but that's about it. Typical small and medium general purpose computers represent but a small percentage of all computers. I'd guess off hand that something like 90% of all computers are embedded systems. At the other end, and this is the place where I suspect most of the problems come, are the mainframes. IBM System z doesn't define everything in terms of C, at least under the traditional OS's. (You can also get it with Linux.) Cobol is still the predominant language there. You can't add "convenience constructors" today, and I'm sure that Jerry didn't say that. The next version of the standard will allow it, I think, but only if you explicitly say you want the "trivial" default constructor. And while initialization syntax has been somewhat unified, I still don't think you can get all of the features of aggregate initialization (especially static initialization) if you provide any constructor; at most, you'll be guaranteed a C compatible layout (but that's typically the case today, with most compilers). Unless I explicitly state otherwise, I'm talking about the current standard. There are no implementations of the next standard (can't be, since it doesn't exist yet), and the way things are going, I'm beginning to wonder if there will be any in my lifetime. With regards to Visual C++, it's a concrete implementation; concrete implementations always give you a lot more guarantees than the standard gives. As long as you're not concerned with portability, you can use all of the guarantees the implementation gives. Once you're concerned about portability, especially about potential portability to systems you don't know yet, it becomes trickier. An overloaded operator is just an ordinary function with a funny name. The only time they might impact performance is when they are used instead of a built-in operator. [/QUOTE]

Verification