Reply to thread

Message: [QUOTE="dragan, post: 3968741"] Ah, OK. See, an example is so useful. When I see "aggregate", I will now think "array" AND initialization. I think "aggregate" gets thrown around so much, but it should probably be reserved more for implementer-level discussion rather than user-level. It seems so minor relative to the notion of POD (or layout compatibility! Errgh, so frustrating!). "extern C" fiasco? News to me that it was a fiasco (you must be an implementor/insider, I bet)! I thought it was more like "thank god we can still use DLLs in C++". That does seem to be "the least common denominator". Or at least "one of them" things. I really did write the above before I read you saying it (I feel proud of myself! :)). 'Care to restate that reason? You meant if a class could look like a struct to C, surely. That covers a lot (the most of it?) of ground, and propably shouldn't be flattened. I'm still hoping that Mr. Coffin was right about "convenience constructors" being OK. (Else I'll have to research and find out why there cannot be such. I'll blindly accept the concrete "special functions" as being special and reserved, but I really would want to know why "convenience constructors" are a no-go, if indeed so). I should have stopped responding to your post probably after I asked whether you meant the current standard or the yet-to-be (draft) C++. All of a sudden, I feel like I know NOTHING! Errrgh!! I think my house may explode if I start up Visual C++ and _I_ use it! I saw no red sticker on the box.. I got it for free as a download! ;) A positive note for the post to end on! At least something is concrete! (Until someone says a POD can't have member functions!) (Aside: Are overloaded operators fast compared to functions? I don't know why that sticks in my mind. Yeah I know, I could test it, but I think in the past I have and have found that. I may be mistaken). [/QUOTE]

Verification