c++0x pods and constructors

James Kanze wrote:
> On Oct 29, 11:40 pm, "dragan" <spambus...@prodigy.net> wrote:
>> Victor Bazarov wrote:
>>> dragan wrote:
>>>> Can C++0x PODs/aggregates have user-defined constructors
>>>> and still be PODs/aggregates?
>
>>> From [dcl.init.aggr]:
>>> << 1 An aggregate is an array or a class (Clause 9) with no
>>> user-provided constructors (12.1), no private or
>>> protected non-static data members (Clause 11), no base classes
>>> (Clause 10), and no virtual functions (10.3). >>
>
>>> So, no, once you add a user-defined c-tor, it's not an
>>> aggregate.
>
>> I'm not sure what aggregates are good for.
>
> 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" ... } ;
>

Ah, OK. See, an example is so useful. When I see "aggregate", I will now
think "array" AND initialization.

> 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 },
> // ...
> };

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!).

>
>> I think POD may be the key thing for layout compatibility with
>> C and probably other languages. PODs no longer have to be
>> aggregates in C++0x: they can have constructors, just not
>> default or copy constructors, and no copy assignment operator.
>> (N2690).
>
> 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?

"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++".

>
> 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,

That does seem to be "the least common denominator". Or at least "one of
them" things.

> so the problem
> doesn't come up; C is the lowest common denominator.

I really did write the above before I read you saying it (I feel proud of
myself! ).

> 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.

'Care to restate that reason?

> 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

You meant if a class could look like a struct to C, surely.

> ---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

That covers a lot (the most of it?) of ground, and propably shouldn't be
flattened.

> ---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.)

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).

>
> 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.)

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!

>
>>>> How about conversion operators?
>
>>> You can have conversion operators in an aggregate (according
>>> to the definition), if other conditions are met.
>
>> I assume in a POD also.
>
> A conversion operator is just an ordinary member function.

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).

dragan

James Kanze wrote:
> On Oct 29, 11:56 pm, "dragan" <spambus...@prodigy.net> wrote:
>> Jerry Coffin wrote:
>
>> That's good news. That a POD can be derived from another class
>> is also good news. What kind of class it can be after derived
>> though is still unclear to me: can it have non-static data
>> members?
>
> Only if it's empty itself.

OK. (Not really "OK", I just don't want to think about it now. Again, I
think a few more examples to explain C++'s rules would be great. I would
partition those into categories though: "you have to know this", "mostly of
concern for implementors", etc.)

>
>>> Obviously I'm leaving out some of the details -- see N2960,
>>> §9/5, 9/6 for the full details.
>
>> I downloaded N2960. I like to think in terms of the things a
>> POD can or cannot have rather than the lingo like: trivially
>> copyable, trivial class, standard layout, and on and on. In
>> another post I wrote my understanding of what is and isn't
>> allowed.
>
> The problem is that you can't express the requirements in terms
> of can or cannot have.

Why is that? Is it so absolutely, or just because we are talking about C++?

> At least partially, you have to express
> them in terms of "must have": a POD must have a trivial default
> constructor, for example (which is not the same thing as not
> having a non-trivial default constructor---you have three
> possibilities: no default constructor, trivial default
> constructor and non-trivial default constructor).

But by "requirements", you mean "required by an implementation", yes?

dragan

James Kanze wrote:
> On Oct 29, 4:23 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
>> In article <VV%Fm.41268$EU5.38...@newsfe05.iad>,
>> spambus...@prodigy.net says...
>
>>> Can C++0x PODs/aggregates have user-defined constructors and
>>> still be PODs/aggregates? If not, why not? How about
>>> conversion operators? And what is the difference between a
>>> POD and an aggregate anyway?
>
>> In C++ 0x, the definition of POD no longer includes the
>> requirement that the class be an aggregate. Instead, it
>> introduces a couple of new terms, "standard layout class" and
>> "trivial class". A POD has to be both. A user-defined
>> constructor (by itself) does _not_ prevent the class from
>> being a POD -- but you have to be really careful. In
>> particular, a non-trivial copy constructor or non-trivial
>> destructor _does_ prevent it from being a trivial class (IOW,
>> copying with memcpy/memmove should work correctly).
>
> Attention: the requirement isn't that the class not have a
> non-trivial X; it is that it have a trivial X. Thus, for
> example:
>
> struct S { S( int ); int i; };
>
> doesn't have a non-trivial default constructor, but it doesn't
> have a trivial one either, and thus, is not a POD.

Is it still layout-compatible with C though? (I'm not sure of the
usefullness of "POD" anymore).

> IIUC, in the
> next version of the standard, you will be able to write:
>
> struct S { S( int ); S() = default; int i; };
>
> and it will have the required trivial default constructor.

And what will the compiler do with such a trivial default constructor? Why
does it need to enslave that thing?

>
>> A standard layout class basically says it can't have virtual
>> functions or virtual base classes, etc.
>
>> As long as it fits both of those sets of restrictions, it's a
>> POD. IOW, it _can_ have some "convenience ctors".
>
> But IIUC, only if you ensure that it also has a trivial default
> constructor. Which it won't have be default if you've provided
> any other constructor.

Unless you specify it as you did above, right? I think people are going to
forget it if the reasons a compiler needs to control "trivial default
constructor" are not known. But it seems like too much low-level things are
percolating up to the user level.

dragan

In article <WOOGm.1013$>,
says...

[ ... ]

> > 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.
>
> 'Care to restate that reason?

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.

> > 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
>
> You meant if a class could look like a struct to C, surely.

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.

[ ... ]

> 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).

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.

[ ... ]

> (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).

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.

--
Later,
Jerry.

Jerry Coffin

On Oct 31, 4:12 am, "dragan" <spambus...@prodigy.net> wrote:
> James Kanze wrote:
> > On Oct 29, 11:40 pm, "dragan" <spambus...@prodigy.net> wrote:

> 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!).

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.)

> >> I think POD may be the key thing for layout compatibility
> >> with C and probably other languages. PODs no longer have to
> >> be aggregates in C++0x: they can have constructors, just
> >> not default or copy constructors, and no copy assignment
> >> operator. (N2690).

> > 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?

> "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++".

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.

[...]
> > 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.

> 'Care to restate that reason?

The C++ standard can't impose anything on other languages, only
on C++.

> > 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

> You meant if a class could look like a struct to C, surely.

More or less, yes. With the addition of non-virtual member
functions, but that's about it.

> > ---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

> That covers a lot (the most of it?) of ground, and propably
> shouldn't be flattened.

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.

> > ---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.)

> 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).

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).

> > 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.)

> 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!

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.

> >>>> How about conversion operators?

> >>> You can have conversion operators in an aggregate
> >>> (according to the definition), if other conditions are
> >>> met.

> >> I assume in a POD also.

> > A conversion operator is just an ordinary member function.

> 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).

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.

--
James Kanze

James Kanze

On Nov 6, 7:44 am, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <WOOGm.1013$Js....@newsfe10.iad>, spambus...@prodigy.net
> says...

> [ ... ]

> > > 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.

> > 'Care to restate that reason?

> 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.

It's not quite that bad; you don't need active cooperation with
the C compiler. You do need a C compiler, however, and you need
to know what it does and generates in order to make ``extern
"C"'' work in C++.

> > > 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

> > You meant if a class could look like a struct to C, surely.

> 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.

Exactly. Otherwise, you're not generally too concerned with
POD-ness in itself, only certain properties of it (allows
agglomerate initialization---but a lot of non-PODs do that---or
static initialization).

One interesting idea that I've never seen done would be to
conditionally add convenience functions in the header, something
like:

struct Toto
{
// ...
#ifdef __cplusplus
void someFunction() ;
#endif
};

In practice, I'm sure that this will work, but formally...

> [ ... ]
> 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.

Just curious, but what effect does this have on static
initialization using the agglomerate syntax. Can I still write
something like:

static X const table[] = { 1, 2, 3 };

and be guaranteed that the initialization precedes all code that
I've written (including code in constructors of static objects)?

--
James Kanze

James Kanze

On Oct 31, 4:19 am, "dragan" <spambus...@prodigy.net> wrote:
> James Kanze wrote:
[...]
> >> I downloaded N2960. I like to think in terms of the things
> >> a POD can or cannot have rather than the lingo like:
> >> trivially copyable, trivial class, standard layout, and on
> >> and on. In another post I wrote my understanding of what is
> >> and isn't allowed.

> > The problem is that you can't express the requirements in
> > terms of can or cannot have.

> Why is that? Is it so absolutely, or just because we are
> talking about C++?

It's because the actual requirements contain several "must
have", not can have or cannot have.

> > At least partially, you have to express them in terms of
> > "must have": a POD must have a trivial default constructor,
> > for example (which is not the same thing as not having a
> > non-trivial default constructor---you have three
> > possibilities: no default constructor, trivial default
> > constructor and non-trivial default constructor).

> But by "requirements", you mean "required by an
> implementation", yes?

No. I mean the requirements on a class for it to be a POD.

--
James Kanze

James Kanze

On Oct 31, 4:25 am, "dragan" <spambus...@prodigy.net> wrote:
> James Kanze wrote:
> > On Oct 29, 4:23 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> >> In article <VV%Fm.41268$EU5.38...@newsfe05.iad>,
> >> spambus...@prodigy.net says...

[...]
> > Attention: the requirement isn't that the class not have a
> > non-trivial X; it is that it have a trivial X. Thus, for
> > example:

> > struct S { S( int ); int i; };

> > doesn't have a non-trivial default constructor, but it
> > doesn't have a trivial one either, and thus, is not a POD.

> Is it still layout-compatible with C though?

In practice, with most compilers, yes.

The current standard doesn't talk about "layout-compatible", and
no C++ standard can impose anything on the C compiler. I didn't
see anything in N2914 (the latest draft that I happen to have
handy) that guaranteed that a "standard-layout" class is in
anyway compatible with C.

On the other hand, the whole concept of "layout-compatible"
seems to have been lifted from the C standard, and from a QoI
point of view, I would expect that anything with
"standard-layout" be compatible with C if the system defines a
standard C ABI (as most do).

> (I'm not sure of the usefullness of "POD" anymore).

Per se, they don't have much use. They do restrict the
implementation in some ways, however, that typically allows them
to be used in mixed language headers (headers which are used by
both C and C++).

> > IIUC, in the next version of the standard, you will be able
> > to write:

> > struct S { S( int ); S() = default; int i; };

> > and it will have the required trivial default constructor.

> And what will the compiler do with such a trivial default
> constructor?

Nothing. Otherwise, the constructor wouldn't be trivial.

> Why does it need to enslave that thing?

I'm not sure what you're trying to ask there, but if it is "why
do we need a special syntax for this?", it's because the current
standard says that if a class has any constructor, the compiler
won't provide a default constructor implicitly, and a lot of
code counts on this.

--
James Kanze

James Kanze

In article <1c83cc8c-9e7a-457a-bf85-
>,
says...

[ ... ]

> It's not quite that bad; you don't need active cooperation with
> the C compiler. You do need a C compiler, however, and you need
> to know what it does and generates in order to make ``extern
> "C"'' work in C++.

I was thinking primarily of the fact that anytime the C compiler
changes anything about its ABI, the C++ compiler needs to know about
it and take steps to compensate. Fortunately, at least in most cases
the ABI is fairly stable, so this doesn't arise a lot in practice.

[ ... ]

> One interesting idea that I've never seen done would be to
> conditionally add convenience functions in the header, something
> like:
>
> struct Toto
> {
> // ...
> #ifdef __cplusplus
> void someFunction() ;
> #endif
> };
>
> In practice, I'm sure that this will work, but formally...

In practice, it's likely to work at least as long as none of the
functions is virtual. A virtual function would stand a good chance of
causing breakage though...

[ ... ]

> Just curious, but what effect does this have on static
> initialization using the agglomerate syntax. Can I still write
> something like:
>
> static X const table[] = { 1, 2, 3 };
>
> and be guaranteed that the initialization precedes all code that
> I've written (including code in constructors of static objects)?

I haven't studied that in a lot of detail yet, but it looks like
there's a fair bit of new material to study. First of all, they've
added thread local storage, and associated initialization rules for
it. Then they've added constexpr's, which allow static initialization
in quite a few cases that it wouldn't work in C++ 98/03.

Those have caused enough changes to the text that I haven't yet
sorted out whether the underlying rules have changed a lot, or
whether it's mostly just different text describing mostly similar
rules with a couple of new possibilities thrown into the mix.

--
Later,
Jerry.

Jerry Coffin

On Nov 6, 3:37*am, James Kanze <james.ka...@gmail.com> wrote:
> On Oct 31, 4:12 am, "dragan" <spambus...@prodigy.net> wrote:
>
> > James Kanze wrote:
> > > On Oct 29, 11:40 pm, "dragan" <spambus...@prodigy.net> wrote:
> > 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!).
>
> 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.)
>
>
>
> > >> I think POD may be the key thing for layout compatibility
> > >> with C and probably other languages. PODs no longer have to
> > >> be aggregates in C++0x: they can have constructors, just
> > >> not default or copy constructors, and no copy assignment
> > >> operator. *(N2690).
> > > 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?
> > "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++".
>
> 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.
>
> * * [...]
>
> > > 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.
> > 'Care to restate that reason?
>
> The C++ standard can't impose anything on other languages, only
> on C++.
>
> > > 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
> > You meant if a class could look like a struct to C, surely.
>
> More or less, yes. *With the addition of non-virtual member
> functions, but that's about it.
>
> > > ---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
> > That covers a lot (the most of it?) of ground, and propably
> > shouldn't be flattened.
>
> 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.
>
> > > ---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.)
> > 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).
>
> 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).
>
> > > 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.)
> > 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!
>
> 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.
>

Perhaps what's needed are on line compilers that output
fully instantiated code which can be handled by
"existing" C++ compilers. By that I mean that some
changes to existing compilers would be needed, but the
changes would be relatively minor. That might help in
terms of getting the new version of the language out
and in use. Without doing something radically
different, I think the number of C++0x compilers is
likely to be less than the number of C++ compilers
today. I hope you live to see C++0x in general use,
but at the very least, I think things will be
interesting (curioser and curioser) from here on in.


Brian Wood
http://www.webEbenezer.net

Brian Wood