c++0x pods and constructors
dragan
PODs/aggregates? If not, why not? How about conversion operators? And what
is the difference between a POD and an aggregate anyway?
Victor Bazarov
> 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.
> If not, why not?
Because that's how it's defined. Ask in 'comp.std.c++' for the
rationale behind that definition.
> How about conversion operators?
You can have conversion operators in an aggregate (according to the
definition), if other conditions are met.
> And what
> is the difference between a POD and an aggregate anyway?
And aggregate is a POD. A POD is not necessarily an aggregate.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Johannes Schaub (litb)
Aggregates but not PODs, both in C++03 and C++0x:
string foo[10];
struct bar {
string baz;
};
In C++0x, you can use memcpy on trivially copyable types. POD is too strict
a requirement for this - so if you just want to use memcpy on a type for
example, making a type trivially copyable would suffice, in particular:
- has no non-trivial copy constructors (12.8),
— has no non-trivial copy assignment operators (13.5.3, 12.8), and
— has a trivial destructor (12.4).
A trivial class then is a class that is trivially copyable and that has a
trivial default constructor. F is trivial and G is trivially copyable:
struct F { Foo() = default; F(int a):a(a) { } int a; };
struct G { Foo(int a):a(a) { } int a; };
For other things, a class has to be a standard layout class. Thus is true
for "offsetof", to inspect a common initial sequence when two such structs
are in an union, etc. Look up the details in the latest draft at 9/6.
A POD is a class is trivial and a standard layout class and has no members
of non-POD etc... . Actually, i haven't found something in the c++0x
language in 2960 that still requires things to be PODs. Things either seem
to refer to standard layout classes or trivially copyable.
Vladimir Jovic
> dragan wrote:
>
>> 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?
>
> Aggregates but not PODs, both in C++03 and C++0x:
>
> string foo[10];
> struct bar {
> string baz;
> };
>
std::string (if you are referring to that here) is not POD, therefore
that structure can not be an aggregate.
> In C++0x, you can use memcpy on trivially copyable types. POD is too strict
> a requirement for this - so if you just want to use memcpy on a type for
> example, making a type trivially copyable would suffice, in particular:
>
> - has no non-trivial copy constructors (12.8),
> — has no non-trivial copy assignment operators (13.5.3, 12.8), and
> — has a trivial destructor (12.4).
>
> A trivial class then is a class that is trivially copyable and that has a
> trivial default constructor. F is trivial and G is trivially copyable:
>
> struct F { Foo() = default; F(int a):a(a) { } int a; };
What is that default thing???
> struct G { Foo(int a):a(a) { } int a; };
>
> For other things, a class has to be a standard layout class. Thus is true
> for "offsetof", to inspect a common initial sequence when two such structs
> are in an union, etc. Look up the details in the latest draft at 9/6.
>
> A POD is a class is trivial and a standard layout class and has no members
> of non-POD etc... . Actually, i haven't found something in the c++0x
> language in 2960 that still requires things to be PODs. Things either seem
> to refer to standard layout classes or trivially copyable.
I think you got that wrong. As far as I know (might be wrong), but
agregate is defined as an array or class that has none of the following
characretistics:
1) user declared constructors
2) private or protected non-static data members
3) base classes
4) virtual functions
--
Bolje je ziveti sto godina kao bogatun, nego jedan dan kao siromah!
Johannes Schaub (litb)
> Johannes Schaub (litb) wrote:
>> dragan wrote:
>>
>>> 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?
>>
>> Aggregates but not PODs, both in C++03 and C++0x:
>>
>> string foo[10];
>> struct bar {
>> string baz;
>> };
>>
>
> std::string (if you are referring to that here) is not POD, therefore
> that structure can not be an aggregate.
>
That has nothing to do with it not being an aggregate. Non-PODs can be
aggregates, of course. Please gimme some standard legalese to prove me wrong
:)
>> In C++0x, you can use memcpy on trivially copyable types. POD is too
>> strict a requirement for this - so if you just want to use memcpy on a
>> type for example, making a type trivially copyable would suffice, in
>> particular:
>>
>> - has no non-trivial copy constructors (12.8),
>> — has no non-trivial copy assignment operators (13.5.3, 12.8), and
>> — has a trivial destructor (12.4).
>>
>> A trivial class then is a class that is trivially copyable and that has a
>> trivial default constructor. F is trivial and G is trivially copyable:
>>
>> struct F { Foo() = default; F(int a):a(a) { } int a; };
>
> What is that default thing???
>
This is a C++0x feature, and it means that the user declared constructor
will have a default implementation (which is trivial here).
>> struct G { Foo(int a):a(a) { } int a; };
>>
>> For other things, a class has to be a standard layout class. Thus is true
>> for "offsetof", to inspect a common initial sequence when two such
>> structs are in an union, etc. Look up the details in the latest draft at
>> 9/6.
>>
>> A POD is a class is trivial and a standard layout class and has no
>> members of non-POD etc... . Actually, i haven't found something in the
>> c++0x language in 2960 that still requires things to be PODs. Things
>> either seem to refer to standard layout classes or trivially copyable.
>
>
> I think you got that wrong. As far as I know (might be wrong), but
> agregate is defined as an array or class that has none of the following
> characretistics:
> 1) user declared constructors
> 2) private or protected non-static data members
> 3) base classes
> 4) virtual functions
>
Yes, that's right (for c++03. For C++0x, "user declared" is changed to "user
provided", as you can declare a constructor yourself, but then default it).
So an aggregate can surely contain std::string :) However, where do i say
something contradictory?
James Kanze
> 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.
> > If not, why not?
> Because that's how it's defined. Ask in 'comp.std.c++' for
> the rationale behind that definition.
The rationale is probably simply that they needed the
distinction for some reason. In C++03, the distinction is
clear: aggregates can only be initialized using the aggregate
initialization syntax; other things can't be initialized using
the aggregate initialized syntax. In C++0x, there will be a
universal initialization syntax, which works for both aggregates
and non aggregates, but the semantics are still different: when
initializing an aggregate, you specify the initializer for each
member; when initializing a non-aggregate, you specify the
arguments for a constructor.
> > How about conversion operators?
> You can have conversion operators in an aggregate (according
> to the definition), if other conditions are met.
> > And what is the difference between a POD and an aggregate
> > anyway?
> And aggregate is a POD. A POD is not necessarily an
> aggregate.
Intuitively: an aggregate is determined superficially: an array
or a class with no user defined constructor, but elements of the
array or class aren't necessarily aggregates. A POD is defined
"deeply": for something to be a POD, all of its elements must be
POD's, recursively. There's more to it than that, of course.
The important difference is that whether something is an
aggregate or not determines how it is initialized (in C++03) or
what the initialization arguments mean (in C++0x). The
difference between a POD and a non-POD is that a POD has
constructors and destructors which are effectively no-ops, and
an assignment operator which is the equivalent of memcpy; this
plays a role in various contexts.
--
James Kanze
Vladimir Jovic
> Vladimir Jovic wrote:
>>> string foo[10];
>>> struct bar {
>>> string baz;
>>> };
>>>
>> std::string (if you are referring to that here) is not POD, therefore
>> that structure can not be an aggregate.
>>
> That has nothing to do with it not being an aggregate. Non-PODs can be
> aggregates, of course. Please gimme some standard legalese to prove me wrong
> :)
>
<cut some stuff>
>> I think you got that wrong. As far as I know (might be wrong), but
>> agregate is defined as an array or class that has none of the following
>> characretistics:
>> 1) user declared constructors
>> 2) private or protected non-static data members
>> 3) base classes
>> 4) virtual functions
>>
> Yes, that's right (for c++03. For C++0x, "user declared" is changed to "user
> provided", as you can declare a constructor yourself, but then default it).
> So an aggregate can surely contain std::string :) However, where do i say
> something contradictory?
doh my mistake. An Aggregate can contain non-POD, but POD can't contain
non-POD
sorry
James Kanze
> Johannes Schaub (litb) wrote:
> > dragan wrote:
> >> 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?
> > Aggregates but not PODs, both in C++03 and C++0x:
> > string foo[10];
> > struct bar {
> > string baz;
> > };
> std::string (if you are referring to that here) is not POD,
> therefore that structure can not be an aggregate.
std::string is not an aggregate, but bar is. Aggregation is
determined very superficially; if the class has no user defined
constructor or private data members, it is an aggregate.
> > In C++0x, you can use memcpy on trivially copyable types.
> > POD is too strict a requirement for this - so if you just
> > want to use memcpy on a type for example, making a type
> > trivially copyable would suffice, in particular:
> > - has no non-trivial copy constructors (12.8),
> > — has no non-trivial copy assignment operators (13.5.3, 12.8), and
> > — has a trivial destructor (12.4).
> > A trivial class then is a class that is trivially copyable
> > and that has a trivial default constructor. F is trivial and
> > G is trivially copyable:
> > struct F { Foo() = default; F(int a):a(a) { } int a; };
> What is that default thing???
Something new to C++0x. It just means that the compiler should
use the default implementation. In this case, I suppose that
Foo is a typo for F, and it is used to say that the default
constructor is the compiler generated default (and not absent,
as it would be otherwise in the presence of other constructors).
--
James Kanze
Johannes Schaub (litb)
Oops, yes i typo'ed. Im sorry for any confusion caused :(
Victor Bazarov
OK, so I am wrong saying that an aggregate is POD. An aggregate is POD
*iff* all of its members/elements are POD.
Jerry Coffin
spamb...@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).
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".
Obviously I'm leaving out some of the details -- see N2960, §9/5, 9/6
for the full details.
--
Later,
Jerry.
dragan
> 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. 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).
>> 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.
dragan
> dragan wrote:
>
>> 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?
>
> Aggregates but not PODs, both in C++03 and C++0x:
>
> string foo[10];
> struct bar {
> string baz;
> };
>
> In C++0x, you can use memcpy on trivially copyable types. POD is too
> strict a requirement for this - so if you just want to use memcpy on
> a type for example, making a type trivially copyable would suffice,
> in particular:
>
> - has no non-trivial copy constructors (12.8),
> - has a trivial destructor (12.4).
>
> A trivial class then is a class that is trivially copyable and that
> has a trivial default constructor. F is trivial and G is trivially
> copyable:
>
> struct F { Foo() = default; F(int a):a(a) { } int a; };
> struct G { Foo(int a):a(a) { } int a; };
>
> For other things, a class has to be a standard layout class. Thus is
> true for "offsetof", to inspect a common initial sequence when two
> such structs are in an union, etc. Look up the details in the latest
> draft at 9/6.
>
> A POD is a class is trivial and a standard layout class and has no
> members of non-POD etc... . Actually, i haven't found something in
> the c++0x language in 2960 that still requires things to be PODs.
> Things either seem to refer to standard layout classes or trivially
> copyable.
But a POD is what you want to talk with C and other languages is what I
gather.
dragan
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?
>
> 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.
dragan
> The
> difference between a POD and a non-POD is that a POD has
> constructors and destructors which are effectively no-ops, and
> an assignment operator which is the equivalent of memcpy; this
> plays a role in various contexts.
From N2960, I gather that a POD may not have user-defined: default
constructor, copy constructor, copy assignment operator, destructor. In
addition, it may not have virtual functions or virtual base classes, at most
one base class and no non-static data members in the most-derived class.
Other things too, but I find the aforementioned most important.
So, the good news is, that seemingly a POD can have constructors other
than the ones listed above and can also have a non-virtual base class. I'm
not sure what "no non-static data members in the most-derived class" means
exactly. The section needs more examples if you ask me.
James Kanze
> James Kanze wrote:
> > The difference between a POD and a non-POD is that a POD has
> > constructors and destructors which are effectively no-ops,
> > and an assignment operator which is the equivalent of
> > memcpy; this plays a role in various contexts.
> From N2960,
Note that N2960 is not the standard, but a draft for the next
version of the standard. In particular, it differs signficantly
from the current standard here (in wording---not in effect).
> I gather that a POD may not have user-defined:
> default constructor, copy constructor, copy assignment
> operator, destructor. In addition, it may not have virtual
> functions or virtual base classes, at most one base class and
> no non-static data members in the most-derived class. Other
> things too, but I find the aforementioned most important.
The current standard simply says that a POD must be an
aggregate; some of these requirements are part of being an
aggregate.
But you're formulating it backwards. In order to be a POD, a
class must have a trivial default constructor, a trivial copy
constructor, a trivial copy assignment operator and a trivial
destructor. If any of these is user defined, then it is by
definition non-trivial, but there are other ways for them to be
non-trivial or absent: a class with a deleted copy constructor,
for example (in the draft).
> So, the good news is, that seemingly a POD can have
> constructors other than the ones listed above
If you provide any constructor, the compiler no longer provides
the trivial default constructor---either you provide one (which
will be non-trivial), or there isn't one. Either way, the class
won't be a POD. (Or... I think you can tell the compiler to
provide one explicitly, and that might be trivial.)
> and can also have a non-virtual base class.
Yes, but either the base class or the class itself must be
empty, which sort of makes this provision useless.
> I'm not sure what "no non-static data members in the
> most-derived class" means exactly. The section needs more
> examples if you ask me.
It seems clear enough to me. Given a hierarchy (which may
consist of only a single class), there may be at most one class
in that hierarchy which has non-static data
members---non-static, because static data members don't affect
the layout in any way.
I think the original formulation was clearer, and the original
rules allowed an informal simplification: a POD is something you
could write in C. I'm not sure what we really gain by allowing
anything else. I understand the desire of separating "layout
compatibility" from POD-ness, since they affect different
operations (communication with other languages, memcpy-ability),
but in practice, I don't think it makes any difference.
--
James Kanze
James Kanze
> 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" ... } ;
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 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?
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.)
> >> 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.
--
James Kanze
James Kanze
> 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. 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.
> 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.
--
James Kanze
James Kanze
> 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.
> > 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. 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).
--
James Kanze
dragan
> On Oct 29, 11:49 pm, "dragan" <spambus...@prodigy.net> wrote:
>> James Kanze wrote:
>>> The difference between a POD and a non-POD is that a POD has
>>> constructors and destructors which are effectively no-ops,
>>> and an assignment operator which is the equivalent of
>>> memcpy; this plays a role in various contexts.
>
>> From N2960,
>
> Note that N2960 is not the standard, but a draft for the next
> version of the standard.
I know.
> In particular, it differs signficantly
> from the current standard here (in wording---not in effect).
Where is "here"? I thought that N2960 was pretty close to the "current state
of the art" given that it has a date of October 25, 2009 on it. Prior to
downloading N2960, I had N2800, so surely I'm a lot closer to the final
standard than I was.
>
>> I gather that a POD may not have user-defined:
>> default constructor, copy constructor, copy assignment
>> operator, destructor. In addition, it may not have virtual
>> functions or virtual base classes, at most one base class and
>> no non-static data members in the most-derived class. Other
>> things too, but I find the aforementioned most important.
>
> The current standard simply says that a POD must be an
> aggregate; some of these requirements are part of being an
> aggregate.
OK, I see the disconnect now: You are talking about the current standard and
I asked about C++0x. The current standard does not concern me. Wasn't the
current one instituted in 2003?
>
> But you're formulating it backwards. In order to be a POD, a
> class must have a trivial default constructor, a trivial copy
> constructor, a trivial copy assignment operator and a trivial
> destructor. If any of these is user defined, then it is by
> definition non-trivial,
That's why I said it couldn't have those as a practicality and for most
purposes it was "correct enough". I'm just trying to understand it, not
quote it.
> but there are other ways for them to be
> non-trivial or absent: a class with a deleted copy constructor,
> for example (in the draft).
I kinda/sorta knew that. Someone told me that before. That when I make a
default constructor private so that default construction is not possible,
that all bets are off for it being a POD (?).
>
>> So, the good news is, that seemingly a POD can have
>> constructors other than the ones listed above
>
> If you provide any constructor, the compiler no longer provides
> the trivial default constructor---either you provide one (which
> will be non-trivial), or there isn't one. Either way, the class
> won't be a POD.
In the current standard or the draft? I was under the impression (and so is
at least one other poster in this thread) that PODs can have "convenience
constructors", as he put it.
> (Or... I think you can tell the compiler to
> provide one explicitly, and that might be trivial.)
And how can someone do that?
>
>> and can also have a non-virtual base class.
>
> Yes, but either the base class or the class itself must be
> empty, which sort of makes this provision useless.
Indeed it would make it useless! I didn't get that information from reading
the draft. Is it there or did I just skim over it I wonder.
>
>> I'm not sure what "no non-static data members in the
>> most-derived class" means exactly. The section needs more
>> examples if you ask me.
>
> It seems clear enough to me. Given a hierarchy (which may
> consist of only a single class), there may be at most one class
> in that hierarchy which has non-static data
> members---non-static, because static data members don't affect
> the layout in any way.
It just seems weird, probably for lack of my knowledge of the
intricacies/subtleties. An example would be worth a thousand words. Someone
should pen "a roadmap to the C++ standard, with examples" book. Note that
some "open" softwares have their licenses expressed also in layman's terms,
something I have found not only useful, but interesting.
>
> I think the original formulation was clearer, and the original
> rules allowed an informal simplification: a POD is something you
> could write in C.
Yes! That's really my concern: where C ends and C++ starts.
> I'm not sure what we really gain by allowing
> anything else. I understand the desire of separating "layout
> compatibility" from POD-ness, since they affect different
> operations (communication with other languages, memcpy-ability),
> but in practice, I don't think it makes any difference.
Nor I, for I thought they were the same thing! When I started this thread, I
included "aggregate" in my quest to understand. Then I felt that POD was
what I was really after. Live and learn! Now I think you just told me that
"layout compatibility" is the thing and that makes "POD" nebulous! Errrrgh!
dragan
> 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
> 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
> 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.
Jerry Coffin
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.
James Kanze
> 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
> 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
> >> 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
> 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
Jerry Coffin
cfd3c9...@b15g2000yqd.googlegroups.com>, james...@gmail.com
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.
Brian Wood
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
dragan
> In article <WOOGm.1013$Js....@newsfe10.iad>, spamb...@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.
Whatever happened with projects to bring forth a standard C++ ABI. Itanium
only?
>
>>> 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 would think that cross-platform interoperability is a larger concern. At
least with a C ("POD") struct, you stand a chance at it looking the same in
more than one machine. Not hardly so for classes (I mean with one using all
the C++ "fancy" things).
>
> [ ... ]
>
>> 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.
I understand all that and am accepting of it.
>
> 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.
I've probably encountered that, but I didn't "know" that. So are you
retracting your statement that "convenience constructors" are allowed?
>
> 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;
> };
OK, things are looking rosie then for C++0x. A good enough reason to drop
the current lineup ASAP, IMO. Hopefully the C++0x goodies will start
trickling into compilers even before "ratification" or whatever they call
it.
>
> 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.
And that makes me a happy camper, cuz not allowing "convenience
constructors" is a pet peave of mine. I saw/see no reason why it has to be
without them, so now I know indeed there was no reason other than oversight.
>
> 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.
I would have assumed that the out-of-line Y::Y() would not allow "=default"!
The question becomes: Why does it?! Hehe, so Scott Meyers can right more
"Effective C++" books! (Great series by the way, but if it ever becomes
contrived... oh nevermind).
>
> [ ... ]
>
>> (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.
Alright. Maybe long ago when that stuck in my mind I had experienced the
inline vs. online thing. But I get most of my information from books (and
lately online) and "operators are FAAAST!" sticks in my mind, so I think I
may have read it somewhere. It makes perfect sense to me that operators are
no different than functions except for the obvious syntax. Oh well, could
have been a brainfart.
dragan
What about cross-platform interoperability? Write a struct here, read it
there?
>
>>>> 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.)
I does indirectly. "C-linkage" (is that the right terminology?) is all that
can be exported from DLLs ("sorry" to be so Windows-ish). I guess you
probably could get all that name-mangled stuff to come out of a DLL on a
single machine. You won't be selling that app to other people though, that's
for sure.
>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.
Are you being too hypothetical? I don't give it a second thought: I KNOW
that I'll always be able to call "extern C" functions in a DLL (after
LoadLibrary(), blah, blah.)
>
> 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.
I seem to have missed "the weakness". I'm sure there is one if you say so.
Anyway, I feel like "extern C" and "layout" are separate. It's all good
information though.
>
> The probable reason the committee didn't address the problem is
> that it isn't one in practice.
YES! Thanks for letting me know I'm not "out of it" (a bit insecure maybe,
"out of it", no way!).
> Practically all platforms that
> support C++ have a standard C ABI,
I didn't know that. Well maybe I sorta did because I rely on it ("extern C",
"POD"). So there is a formality like the C++ ABI for Itanium for C?
> 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.
Interesting. Big kudos for C. But it is much easier in C to make a std ABI
than in C++. C++ should have specified one from the beginning, but too late
for that now. Live and learn.
>
> Until the day someone decides that C is dead enough that they
> don't need a C compiler for their platform.
C/Std ABI: 1 point. C++/No Std ABI: -1 point. C++ is keeping C alive!
>
> [...]
>>> 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++.
k.
>
>>> 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.
k.
>
>>> ---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.
And I know that too. I think in terms of the desktop/server space mostly as
those are the applications I am building. I wasn't thinking "what pie piece
of all computers", but rather "the desktop/server space is billions and
billions of dollars of space" (with apologies to Carl Sagan).
> 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 would wager that a poll (eww.. not one of THOSE!) would show that most
readers of this ng are in the client-server (includes all things web etc.
too) space. That is, working on software that interacts with humans (rather
than controlling anti-lock brakes, etc). (Or I am a fish out of water?).
>
>>> ---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.
YOU said "today". The thread is all about C++0x. Indeed he did say that, but
not with your "today" qualifier. I'm 99.9% sure that he is correct too.
> The next version of the standard
> will allow it, I think, but only if you explicitly say you want
> the "trivial" default constructor.
That's what he restated, but the thread was about C++0x, so you are sort of
"preaching to the choir".
> 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).
I assume that too today: that I can write "convenience constructors" and not
have a worry. I just don't do it because it's not official.
>
>>> 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.
Well, and again, the thread is specifically about C++0x. Did you miss that
key aspect?
> 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.
Now THAT is an interesting tangent. I was thinking that C++0x features (at
least a few stocking-stuffers) would be in my favorite compiler for Xmas!
>
> With regards to Visual C++, it's a concrete implementation;
> concrete implementations always give you a lot more guarantees
> than the standard gives.
What do you mean by "concrete implementation"? Did you just mean one
specific implementation? As opposed to worrying about all compilers or the
majority or average of them across all platforms and domains? I just have
some Windows apps to write.
>
> 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.
I understand that. Hopefully that "portable everywhere" hype doesn't keep
"good people down". Which brings up another interesting (to me) tangent:
that C++ doesn't compete with other languages as much as it is in
competition with platform-specific/domain-specific solutions.
>
>>>>>> 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.
I believe it.
dragan
> 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.
While very abstract this subthread portion seems, you seem to be saying:
"yes, you're right, so you're wrong". Let me clarify: I said I can think in
simple terms but not or can't in C++ because C++ has to be like a
president/politician walking the fence trying to be all things to all people
and I live in Greenbough Alabama and just need a new ping pong paddle. In
short, I'd MUCH rather have a language tool that I could compare against my
checkoffs (can/cannot haves) rather than have to spend oodles of time
deciphering terms like "trivial constructor" and the complex interplay
between all the other 1250 pages of the standard. I was just explaining what
I said, but suddenly, I feel catharted!
>
>>> 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.
k. I'm not sure from where in your other post I quoted "requirements".
dragan
> 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.
I've been way to meek about using the guarantees given by my chosen
compiler. More and more, I find myself at MSDN as my source for C++
information. What I find there is guaranteed to work because that's the
compiler I'm using. C++ isn't losing ground, it's lost the war? Has most
value in the Smithsonian?
>
> The current standard doesn't talk about "layout-compatible",
The current standard is off-topic in this thread.
> 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.
Hmm. I thought that was at least part of the point behind "standard layout".
But, from a purely terminological point of view, it would seem to be ripe
for bandaiding the lack of standard C++ ABI. A stepping stone for the
original oversight.
>
> 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).
Any guarantee is better than no guarantee. Even Master C++er Bjarne
Stroupstrup acknowledged this point-of-quality (though somewhat
condescendingly) in a presentation he gave (available on UTube).
>
>> (I'm not sure of the usefullness of "POD" anymore).
>
> Per se, they don't have much use.
I'd say (assertively) that they do, but I'm still struggling with the
definition of such a thing.
> 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.
I was just wondering why the compiler needed control of that special
function. What book did I not buy or decide not to buy because I don't think
that as an application programmer I need to worry about stuff that my
employer calls "get up to speed on your technical skills on your own time so
you can bring direct/real value to the company via purposeful software
applications"?
James Kanze
> In article <1c83cc8c-9e7a-457a-bf85-
> cfd3c93ad...@b15g2000yqd.googlegroups.com>, james.ka...@gmail.com
> 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.
Or that there are two different C compilers on the system, and
they use different ABI's. Here, too, the case should be fairly
rare, due to the fact that most OS's today define their
interface in terms of C.
> [ ... ]
> > 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...
It would almost certainly break something.
> [ ... ]
> > 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.
Yes. And for various reasons, I've not been able to study much
in the last year or so,
--
James Kanze
James Kanze
> James Kanze 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:
[...]
> What about cross-platform interoperability? Write a struct
> here, read it there?
That generally doesn't work, regardless. After all, it doesn't
work for int; how could it work for a struct which contains an
int?
[...]
> >> "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.)
> I does indirectly. "C-linkage" (is that the right
> terminology?) is all that can be exported from DLLs ("sorry"
> to be so Windows-ish).
That's not true. I've used DLL's without any C linkage on at
least three platforms: Solaris, Linux and Windows.
> I guess you probably could get all that name-mangled stuff to
> come out of a DLL on a single machine. You won't be selling
> that app to other people though, that's for sure.
The only time name mangling is relevant is when the user
explicitly loads a DLL and requests the function name (dlsym
under Unix). In such cases, the usual solution is to have a
single factory function as entry point, and declare that (and
only that) as extern "C".
Of course, you can only load DLL's which are binary compatible.
Which means a lot of different things, on different platforms.
> > 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.
> Are you being too hypothetical? I don't give it a second
> thought: I KNOW that I'll always be able to call "extern C"
> functions in a DLL (after LoadLibrary(), blah, blah.)
If you're talking about the standard, you have to consider all
possible cases. I explicitly stated elsewhere that this isn't a
problem in practice.
Of course, if you're calling LoadLibrary, then you're 100%
Windows anyway, so you can count on the guarantees Microsoft
gives as well as those in the standard.
> > 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.
> I seem to have missed "the weakness". I'm sure there is one if
> you say so. Anyway, I feel like "extern C" and "layout" are
> separate. It's all good information though.
The weakness is that for a C++ compiler to compile something
which can be called from C, it needs a C compiler and some
collaboration on the part of the C compiler. And the C++
standard has no influence over C compilers.
And extern "C" and layout are pretty orthogonal; depending on
what you're doing, you might need both extern "C" and some sort
of layout compatibility, however.
> > The probable reason the committee didn't address the problem
> > is that it isn't one in practice.
> YES! Thanks for letting me know I'm not "out of it" (a bit
> insecure maybe, "out of it", no way!).
> > Practically all platforms that support C++ have a standard C
> > ABI,
> I didn't know that. Well maybe I sorta did because I rely on
> it ("extern C", "POD"). So there is a formality like the C++
> ABI for Itanium for C?
It depends on the platform, but for at least Posix and Windows,
there has to be, since the system ABI is defined in terms of C.
In practice, given the simplicity of C, most of the layout
issues depend directly on the hardware---I don't need to read
the compiler specifications for an IBM mainframe, for example,
to know the layout, since a compiler isn't going to introduce
unnecessary padding (it can, but it won't), and the hardware
determines where the padding, etc., is necessary.
C++ is more complicated, since you have to consider things like
how vtables are layed out. And for both C and C++, the calling
conventions can vary. I don't know the situation on modern
mainframes, but a long time ago, I know that different C
compilers for the Siemens BS2000 used different calling
conventions.
> > 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.
> Interesting. Big kudos for C. But it is much easier in C to
> make a std ABI than in C++. C++ should have specified one from
> the beginning, but too late for that now. Live and learn.
The language specification cannot specify a standard ABI. That
has to be hardware specific. Historically, C++ became
significant after most hardware architectures had been
specified, and there were several different C++ compilers around
before C++ became important enough. The Itanium is the rare
exception of an architecture which was defined after C++ was
important, but before any compilers existed for it.
> > Until the day someone decides that C is dead enough that
> > they don't need a C compiler for their platform.
> C/Std ABI: 1 point. C++/No Std ABI: -1 point. C++ is keeping C
> alive!
History is keeping C alive.
> > [...]
> > Unless I explicitly state otherwise, I'm talking about the
> > current standard.
> Well, and again, the thread is specifically about C++0x. Did
> you miss that key aspect?
Yes. Generally speaking, this newsgroup is about programming in
C++; there is a separate group, comp.std.c++ for discussions of
the standard. And while the separation isn't absolute, you
can't program in C++0x today, so most discussion of it probably
would be more appropriate in csc++.
> > 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.
> Now THAT is an interesting tangent. I was thinking that C++0x
> features (at least a few stocking-stuffers) would be in my
> favorite compiler for Xmas!
That is, of course, completely impossible, since the standard
still hasn't been approved, and in fact, we still don't know
exactly what will be in it. Generally, it takes a few years
after the finalization of a standard for implementations to
catch up; for that matter, most compilers today don't implement
all of C++03.
> > With regards to Visual C++, it's a concrete implementation;
> > concrete implementations always give you a lot more
> > guarantees than the standard gives.
> What do you mean by "concrete implementation"?
That it's real. It exists. It's not just an abstract
specification.
> Did you just mean one specific implementation?
Yes. (I suppose that technically, it's several implementations,
since you can control some of the aspects, like the signedness
of a plain char, from the command line.)
> As opposed to worrying about all compilers or the majority or
> average of them across all platforms and domains? I just have
> some Windows apps to write.
If all you're targetting is Windows, then all you need to know
is Visual C++.
--
James Kanze
James Kanze
> James Kanze wrote:
> > 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.
> I've been way to meek about using the guarantees given by my
> chosen compiler. More and more, I find myself at MSDN as my
> source for C++ information. What I find there is guaranteed to
> work because that's the compiler I'm using. C++ isn't losing
> ground, it's lost the war? Has most value in the Smithsonian?
I don't follow you. One of the reasons (not the only one) C++
continues to be important is because it leaves significant
liberty to the implementation. It can be implemented on just
about every platform.
> > The current standard doesn't talk about "layout-compatible",
> The current standard is off-topic in this thread.
Some abstract future standard is arguably off-topic in this
newsgroup. At least, there's a more appropriate news group for
it: comp.std.c++.
> > 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.
> Hmm. I thought that was at least part of the point behind
> "standard layout".
Sort of. I suspect that the intent behind "standard-layout"
does have to do with C compatibility. But the standard can't
impose that, because compatibility is a two way street, and the
C++ standard cannot impose anything on C. In practice, I think
the intent is clear, and if an implementation provides both a C
and a C++ compiler (the usual case when C++ is present), then I
would expect, from a QoI point of view, that a standard-layout
class be compatible with C, provided that it only uses elements
of C (i.e. no pointers to members).
> But, from a purely terminological point of view, it would seem
> to be ripe for bandaiding the lack of standard C++ ABI. A
> stepping stone for the original oversight.
It would be nice if some architectures did define a standard C++
ABI. But it's up to the architectures; the C++ standard can't
do it.
> > 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).
> Any guarantee is better than no guarantee. Even Master C++er
> Bjarne Stroupstrup acknowledged this point-of-quality (though
> somewhat condescendingly) in a presentation he gave (available
> on UTube).
A standard can't guarantee a usable implementation. It's never
more than part of what you count on.
> >> (I'm not sure of the usefullness of "POD" anymore).
> > Per se, they don't have much use.
> I'd say (assertively) that they do, but I'm still struggling
> with the definition of such a thing.
Per se, limited strictly to the guaranteed in the standard, they
don't. What they do is...
> > 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++).
So in practice, they end up having a utility beyond that
specified in the standard.
[...]
> > 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.
> I was just wondering why the compiler needed control of that
> special function.
I'm not too sure what you mean by "control of that special
function". In C, it's possible to write something like:
struct S { int a; int b; };
S s;
and it was desired that this be possible in C++ as well, for
reasons of C compatibility, if nothing else. This means that
the compiler must implicitly declare and define a default
constructor, if the user doesn't. It was also felt that if the
user did define a constructor, it should be impossible to bypass
it. This gives you the rules of the present standard.
--
James Kanze
dragan
That is not important.
>
>>> The current standard doesn't talk about "layout-compatible",
>
>> The current standard is off-topic in this thread.
>
> Some abstract future standard is arguably off-topic in this
> newsgroup. At least, there's a more appropriate news group for
> it: comp.std.c++.
That's your OPINION. (Or your attempt at imposition).
>
>>> 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.
>
>> Hmm. I thought that was at least part of the point behind
>> "standard layout".
>
> Sort of. I suspect that the intent behind "standard-layout"
> does have to do with C compatibility. But the standard can't
> impose that, because compatibility is a two way street, and the
> C++ standard cannot impose anything on C. In practice, I think
> the intent is clear, and if an implementation provides both a C
> and a C++ compiler (the usual case when C++ is present), then I
> would expect, from a QoI point of view, that a standard-layout
> class be compatible with C, provided that it only uses elements
> of C (i.e. no pointers to members).
You said: C++ is dead.
>
>> But, from a purely terminological point of view, it would seem
>> to be ripe for bandaiding the lack of standard C++ ABI. A
>> stepping stone for the original oversight.
>
> It would be nice if some architectures did define a standard C++
> ABI. But it's up to the architectures; the C++ standard can't
> do it.
Hello. Bottleneck imposing itself .
>
>>> 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).
>
>> Any guarantee is better than no guarantee. Even Master C++er
>> Bjarne Stroupstrup acknowledged this point-of-quality (though
>> somewhat condescendingly) in a presentation he gave (available
>> on UTube).
>
> A standard can't guarantee a usable implementation. It's never
> more than part of what you count on.
"If you're stupid, you vote".
>
>>>> (I'm not sure of the usefullness of "POD" anymore).
>
>>> Per se, they don't have much use.
>
>> I'd say (assertively) that they do, but I'm still struggling
>> with the definition of such a thing.
>
> Per se, limited strictly to the guaranteed in the standard, they
> don't. What they do is...
What do they do? Hmm?
>
>>> 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++).
>
> So in practice, they end up having a utility beyond that
> specified in the standard.
>
> [...]
>>> 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.
>
>> I was just wondering why the compiler needed control of that
>> special function.
>
> I'm not too sure what you mean by "control of that special
> function". In C, it's possible to write something like:
>
> struct S { int a; int b; };
> S s;
>
> and it was desired that this be possible in C++ as well, for
> reasons of C compatibility, if nothing else. This means that
> the compiler must implicitly declare and define a default
> constructor, if the user doesn't. It was also felt that if the
> user did define a constructor, it should be impossible to bypass
> it. This gives you the rules of the present standard.
I don't believe you. I live in Romania and know your weak presentations.
James Kanze
> James Kanze wrote:
> > On Nov 7, 6:53 am, "dragan" <spambus...@prodigy.net> wrote:
> >> James Kanze wrote:
> >>> 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...
> >>> [...]
> > I don't follow you. One of the reasons (not the only one)
> > C++ continues to be important is because it leaves
> > significant liberty to the implementation. It can be
> > implemented on just about every platform.
> That is not important.
The fact that C++ can be implemented on just about every
platform is important to the majority of the committee. Some
people don't care about anything but Windows, but they're far
from a majority.
> >>> The current standard doesn't talk about "layout-compatible",
> >> The current standard is off-topic in this thread.
> > Some abstract future standard is arguably off-topic in this
> > newsgroup. At least, there's a more appropriate news group
> > for it: comp.std.c++.
> That's your OPINION. (Or your attempt at imposition).
It's not an absolute, and some discussion of the future standard
is certainly acceptable (since the future standard also concerns
C++). But in general, people who want to discuss purely
standard issues (and anything to do with the future standard is
purely a standard issue, since it is pretty much irrelevant to
programming today) do so in the group which is specialized for
it: comp.std.c++.
> >>> 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.
> >> Hmm. I thought that was at least part of the point behind
> >> "standard layout".
> > Sort of. I suspect that the intent behind "standard-layout"
> > does have to do with C compatibility. But the standard
> > can't impose that, because compatibility is a two way
> > street, and the C++ standard cannot impose anything on C.
> > In practice, I think the intent is clear, and if an
> > implementation provides both a C and a C++ compiler (the
> > usual case when C++ is present), then I would expect, from a
> > QoI point of view, that a standard-layout class be
> > compatible with C, provided that it only uses elements of C
> > (i.e. no pointers to members).
> You said: C++ is dead.
When did I ever say that? Just the contrary, C++ is a lot more
alive than many people want.
> >> But, from a purely terminological point of view, it would
> >> seem to be ripe for bandaiding the lack of standard C++
> >> ABI. A stepping stone for the original oversight.
> > It would be nice if some architectures did define a standard C++
> > ABI. But it's up to the architectures; the C++ standard can't
> > do it.
> Hello. Bottleneck imposing itself .
In what sense? It's just common sense: a standard designed to
be implemented on many different platforms can't impose anything
which has to be specific to a given platform.
> >>> 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).
> >> Any guarantee is better than no guarantee. Even Master
> >> C++er Bjarne Stroupstrup acknowledged this point-of-quality
> >> (though somewhat condescendingly) in a presentation he gave
> >> (available on UTube).
> > A standard can't guarantee a usable implementation. It's
> > never more than part of what you count on.
> "If you're stupid, you vote".
You're not making sense.
> >>>> (I'm not sure of the usefullness of "POD" anymore).
> >>> Per se, they don't have much use.
> >> I'd say (assertively) that they do, but I'm still struggling
> >> with the definition of such a thing.
> > Per se, limited strictly to the guaranteed in the standard, they
> > don't. What they do is...
> What do they do? Hmm?
What I explained immediately following the "Per se, they don't
have much use." Which still immediately follows.
So read Stroustrup's D&E. Those are exactly the reasons
(somewhat summarized) he gives.
> I live in Romania and know your weak presentations.
What does living in Romania have to do with anything? Except
maybe that English isn't your first language, so you
misunderstand some of the finer points, or misexpress what you
are trying to say---but overall, your English seems quite good?
And I don't know what you mean by "weak presentations", either.
I'm just presenting the facts as I know them. There's no effort
on my part to make a particular "presentation".
--
James Kanze
dragan
> On Nov 9, 8:21 am, "dragan" <spambus...@prodigy.net> wrote:
>> James Kanze wrote:
>>> On Nov 7, 6:53 am, "dragan" <spambus...@prodigy.net> wrote:
>>>> James Kanze wrote:
>>>>> 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...
>
>>>>> [...]
>>> I don't follow you. One of the reasons (not the only one)
>>> C++ continues to be important is because it leaves
>>> significant liberty to the implementation. It can be
>>> implemented on just about every platform.
>
>> That is not important.
>
> The fact that C++ can be implemented on just about every
> platform is important to the majority of the committee. Some
> people don't care about anything but Windows, but they're far
> from a majority.
"Oopsies" then, I must be autistic: I thought the world revolved around
Windows! I mean, it's EVERYwhere: desktop, server, mobile, embedded. What
more is there? Is anything more ubiquitous than Windows? Why bother with
anything else? Learn one thing and be done with it, right? So what if every
stoplight has QNX controlling it? Soon it will be Windows Embedded.
>
>>>>> The current standard doesn't talk about "layout-compatible",
>
>>>> The current standard is off-topic in this thread.
>
>>> Some abstract future standard is arguably off-topic in this
>>> newsgroup. At least, there's a more appropriate news group
>>> for it: comp.std.c++.
>
>> That's your OPINION. (Or your attempt at imposition).
>
> It's not an absolute, and some discussion of the future standard
> is certainly acceptable (since the future standard also concerns
> C++). But in general, people who want to discuss purely
> standard issues (and anything to do with the future standard is
> purely a standard issue, since it is pretty much irrelevant to
> programming today) do so in the group which is specialized for
> it: comp.std.c++.
Easy solution for those who don't want to discuss such things: change the
channel (don't view the thread)! Right?
>
>>>>> 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.
>
>>>> Hmm. I thought that was at least part of the point behind
>>>> "standard layout".
>
>>> Sort of. I suspect that the intent behind "standard-layout"
>>> does have to do with C compatibility. But the standard
>>> can't impose that, because compatibility is a two way
>>> street, and the C++ standard cannot impose anything on C.
>>> In practice, I think the intent is clear, and if an
>>> implementation provides both a C and a C++ compiler (the
>>> usual case when C++ is present), then I would expect, from a
>>> QoI point of view, that a standard-layout class be
>>> compatible with C, provided that it only uses elements of C
>>> (i.e. no pointers to members).
>
>> You said: C++ is dead.
>
> When did I ever say that? Just the contrary, C++ is a lot more
> alive than many people want.
In looking to forget it's lineage but still purporting something like that.
You can't have it both ways. And when is this next standard going to be real
anyway? It needs to happen EVERY year or "yer (C++) outta here!". IMHO, of
course.
>
>>>> But, from a purely terminological point of view, it would
>>>> seem to be ripe for bandaiding the lack of standard C++
>>>> ABI. A stepping stone for the original oversight.
>
>>> It would be nice if some architectures did define a standard C++
>>> ABI. But it's up to the architectures; the C++ standard can't
>>> do it.
>
>> Hello. Bottleneck imposing itself .
>
> In what sense? It's just common sense: a standard designed to
> be implemented on many different platforms can't impose anything
> which has to be specific to a given platform.
"Bottlenecks" are those things that cue other things behind them because
they move too slowly: they impede progresss. Parallel paths are prudent and
C++ needs to be "forked" or something (like in open source development): the
backwards-compatible path (which will die off sooner than you think once the
other paths open) and the path going forward. I said that quite well,
actually, if I do say so myself. Kudos to MEEEE! :)
>
>>>>> 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).
>
>>>> Any guarantee is better than no guarantee. Even Master
>>>> C++er Bjarne Stroupstrup acknowledged this point-of-quality
>>>> (though somewhat condescendingly) in a presentation he gave
>>>> (available on UTube).
>
>>> A standard can't guarantee a usable implementation. It's
>>> never more than part of what you count on.
>
>> "If you're stupid, you vote".
>
> You're not making sense.
It was a spoof on "designed by comittee". I think "the comittee" needs
direction.
>
>>>>>> (I'm not sure of the usefullness of "POD" anymore).
>
>>>>> Per se, they don't have much use.
>
>>>> I'd say (assertively) that they do, but I'm still struggling
>>>> with the definition of such a thing.
>
>>> Per se, limited strictly to the guaranteed in the standard, they
>>> don't. What they do is...
>
>> What do they do? Hmm?
>
> What I explained immediately following the "Per se, they don't
> have much use." Which still immediately follows.
And that's why the comittee and standard are undergoing so much revision on
the issue? Maybe I just know what I read and it is not current about what's
going on with the holy standard, but I do know that I read similar
"sentiments" to mine that make your quip "they don't have much use", well,
hogwash.
I was just maybe getting tired after your previous hogwash statement... "I
don't believe you" follows directly: try to fool me once, shame on you. (Try
to fool my twice, shame on me).
>
>> I live in Romania and know your weak presentations.
>
> What does living in Romania have to do with anything?
I don't really live there. I'm from there.
> Except
> maybe that English isn't your first language,
Not hardly, but I think I do pretty well with it because I read other
people's posts and can't decipher them for go to the bank!
> so you
> misunderstand some of the finer points, or misexpress what you
> are trying to say---but overall, your English seems quite good?
I speak better in English than what I learned as an elephant. I find English
quite less demanding: know "rolling rrrrr's" and such. Spelling is pretty
hard though, but I on purpose don't use a spell checker because I don't want
people to think I am someone who I am not.
> And I don't know what you mean by "weak presentations", either.
> I'm just presenting the facts as I know them. There's no effort
> on my part to make a particular "presentation".
I have been following your posts that are in a topic that I find interesting
and you seem to have a pattern. That pattern makes me think that you are
"defender of C++" or "guaranteeing your job". ?
James Kanze
> James Kanze wrote:
> > On Nov 9, 8:21 am, "dragan" <spambus...@prodigy.net> wrote:
> >>>>> [...]
> >>> I don't follow you. One of the reasons (not the only one)
> >>> C++ continues to be important is because it leaves
> >>> significant liberty to the implementation. It can be
> >>> implemented on just about every platform.
> >> That is not important.
> > The fact that C++ can be implemented on just about every
> > platform is important to the majority of the committee.
> > Some people don't care about anything but Windows, but
> > they're far from a majority.
> "Oopsies" then, I must be autistic: I thought the world
> revolved around Windows! I mean, it's EVERYwhere: desktop,
> server, mobile, embedded. What more is there? Is anything more
> ubiquitous than Windows? Why bother with anything else? Learn
> one thing and be done with it, right? So what if every
> stoplight has QNX controlling it? Soon it will be Windows
> Embedded.
Windows is inappropriate for most applications, and most uses.
Most embedded systems require real-time behavior, for example,
which Windows doesn't provide. Most mainframes require a lot of
functionality that Windows doesn't provide (and run on platforms
that Windows doesn't support). Most large scale servers require
more reliability and scalability than Windows provides.
Windows is far from ubiquitous. It's not even the most
wide-spread OS. (VxWorks probably takes that prize.)
[...]
> >> You said: C++ is dead.
> > When did I ever say that? Just the contrary, C++ is a lot
> > more alive than many people want.
> In looking to forget it's lineage but still purporting
> something like that.
Bullshit. I never forgot C++'s lineage.
> You can't have it both ways. And when is this next standard
> going to be real anyway?
Maybe never, the way things are going. Certainly not in the
next few years.
> It needs to happen EVERY year or "yer (C++) outta here!".
> IMHO, of course.
I agree that it needs to happen, and that the fact that it isn't
happening is seriously hurting C++. But that doesn't change the
fact that at present, it isn't happening, at least not too
quickly.
[...]
> I have been following your posts that are in a topic that I
> find interesting and you seem to have a pattern. That pattern
> makes me think that you are "defender of C++" or "guaranteeing
> your job". ?
You loose. I'm a professional, trying to get a job done. With
tools that I stand a chance of seeing.
--
James Kanze
dragan
> On Nov 15, 5:50 am, "dragan" <spambus...@prodigy.net> wrote:
>> James Kanze wrote:
>>> On Nov 9, 8:21 am, "dragan" <spambus...@prodigy.net> wrote:
>>>>>>> [...]
>>>>> I don't follow you. One of the reasons (not the only one)
>>>>> C++ continues to be important is because it leaves
>>>>> significant liberty to the implementation. It can be
>>>>> implemented on just about every platform.
>
>>>> That is not important.
>
>>> The fact that C++ can be implemented on just about every
>>> platform is important to the majority of the committee.
>>> Some people don't care about anything but Windows, but
>>> they're far from a majority.
>
>> "Oopsies" then, I must be autistic: I thought the world
>> revolved around Windows! I mean, it's EVERYwhere: desktop,
>> server, mobile, embedded. What more is there? Is anything more
>> ubiquitous than Windows? Why bother with anything else? Learn
>> one thing and be done with it, right? So what if every
>> stoplight has QNX controlling it? Soon it will be Windows
>> Embedded.
>
> Windows is inappropriate for most applications, and most uses.
> Most embedded systems require real-time behavior, for example,
> which Windows doesn't provide.
Soon it will of course and now there are 3rd parties giving that.
> Most mainframes
There are still some of those? Go figure.
> require a lot of
> functionality that Windows doesn't provide (and run on platforms
> that Windows doesn't support).
Just a matter of time.
> Most large scale servers require
> more reliability and scalability than Windows provides.
Just a matter of time.
>
> Windows is far from ubiquitous.
I beg to differ: life beyond me/us will be all "Windows". It is inevitable.
> It's not even the most
> wide-spread OS. (VxWorks probably takes that prize.)
Windows has won. There soon will be nothing else. Anyone chasing anything
else is a fool.
>
> [...]
>>>> You said: C++ is dead.
>
>>> When did I ever say that? Just the contrary, C++ is a lot
>>> more alive than many people want.
>
>> In looking to forget it's lineage but still purporting
>> something like that.
>
> Bullshit. I never forgot C++'s lineage.
I didn't say "you", I said "C++". C++ is mortaly wounded and maybe you along
with it. (Or maybe someone may want their money back!).
>
>> You can't have it both ways. And when is this next standard
>> going to be real anyway?
>
> Maybe never, the way things are going. Certainly not in the
> next few years.
So, dead: C++ is dead. You said it, so let it be written.
>
>> It needs to happen EVERY year or "yer (C++) outta here!".
>> IMHO, of course.
>
> I agree that it needs to happen, and that the fact that it isn't
> happening is seriously hurting C++. But that doesn't change the
> fact that at present, it isn't happening, at least not too
> quickly.
Too late: it's dead (not that it should have lived forever). Reality bytes.
(At best).
>
> [...]
>> I have been following your posts that are in a topic that I
>> find interesting and you seem to have a pattern. That pattern
>> makes me think that you are "defender of C++" or "guaranteeing
>> your job". ?
>
> You loose. I'm a professional, trying to get a job done. With
> tools that I stand a chance of seeing.
OK. I'm not dissing the Unions. I don't want any part of that. Though I want
you "in the trenches" to know that I've been there.
James Kanze
> James Kanze wrote:
> > Windows is inappropriate for most applications, and most
> > uses. Most embedded systems require real-time behavior, for
> > example, which Windows doesn't provide.
> Soon it will of course and now there are 3rd parties giving
> that.
Been hearing that for quite some years now. The basic structure
of Windows (and Unix, for the most part) doesn't really lend
itself to hard real-time; it's not something you can add on top.
> > Most mainframes
> There are still some of those? Go figure.
A lot of applications need a bit more than a PC. Companies are
still using computers to manage large sets of data.
> > require a lot of functionality that Windows doesn't provide
> > (and run on platforms that Windows doesn't support).
> Just a matter of time.
Like, a million years...
Actually, I'd say that the tendancy is going in the opposite
direction. Most IT organizations are realizing that one size
doesn't fit all, and that you don't necessarily want the same
system handling your critical data as you do on the desktop.
> > Most large scale servers require more reliability and
> > scalability than Windows provides.
> Just a matter of time.
Reliability improves with time, that's certain, and modern
Windows is really pretty stable (which wasn't the case with NT,
for example). But the other systems are aging as well. Linux
is becoming stable---it's already stable enough for a lot of
applications---and it scales a lot better than Windows.
> > Windows is far from ubiquitous.
> I beg to differ: life beyond me/us will be all "Windows". It
> is inevitable.
Obviously, you don't live in the real world, or at least, you're
not aware of what's going on around you.
> > It's not even the most wide-spread OS. (VxWorks probably
> > takes that prize.)
> Windows has won. There soon will be nothing else. Anyone
> chasing anything else is a fool.
Anyone restricting his choices to just Windows is an amateur,
who doesn't understand the real world.
> > [...]
> >>>> You said: C++ is dead.
> >>> When did I ever say that? Just the contrary, C++ is a lot
> >>> more alive than many people want.
> >> In looking to forget it's lineage but still purporting
> >> something like that.
> > Bullshit. I never forgot C++'s lineage.
> I didn't say "you", I said "C++". C++ is mortaly wounded and
> maybe you along with it. (Or maybe someone may want their
> money back!).
Well, I know a lot more than just C++. And I agree that C++ is
"wounded", in some ways. But not morally. If for no other
reason than the fact that for most applications, there's really
no competitor---about the only possible one would be Ada 95, and
that doesn't seem to have caught on.
--
James Kanze
dragan
> On Nov 15, 11:54 am, "dragan" <spambus...@prodigy.net> wrote:
>> James Kanze wrote:
>>> Windows is inappropriate for most applications, and most
>>> uses. Most embedded systems require real-time behavior, for
>>> example, which Windows doesn't provide.
>
>> Soon it will of course and now there are 3rd parties giving
>> that.
>
> Been hearing that for quite some years now. The basic structure
> of Windows (and Unix, for the most part) doesn't really lend
> itself to hard real-time; it's not something you can add on top.
>
>>> Most mainframes
>
>> There are still some of those? Go figure.
>
> A lot of applications need a bit more than a PC. Companies are
> still using computers to manage large sets of data.
>
>>> require a lot of functionality that Windows doesn't provide
>>> (and run on platforms that Windows doesn't support).
>
>> Just a matter of time.
>
> Like, a million years...
No, like right now Mr. Union Man who doesn't no his ass from a hole in the
ground.
>
> Actually, I'd say that the tendancy is going in the opposite
> direction.
Of course you would, but are in denial.
> Most IT organizations are realizing that one size
> doesn't fit all, and that you don't necessarily want the same
> system handling your critical data as you do on the desktop.
But you assume gestapo "organization". (nuff said).
>
>>> Most large scale servers require more reliability and
>>> scalability than Windows provides.
I am against you.
>
>> Just a matter of time.
>
> Reliability improves with time, that's certain, and modern
> Windows is really pretty stable (which wasn't the case with NT,
> for example). But the other systems are aging as well. Linux
> is becoming stable---it's already stable enough for a lot of
> applications---and it scales a lot better than Windows.
>
>>> Windows is far from ubiquitous.
>
>> I beg to differ: life beyond me/us will be all "Windows". It
>> is inevitable.
>
> Obviously, you don't live in the real world, or at least, you're
> not aware of what's going on around you.
Apparently don't ( are you a criminal? ). I assure you I know. You want to
blather more?
bring it?
>
>>> It's not even the most wide-spread OS. (VxWorks probably
>>> takes that prize.)
>
>> Windows has won. There soon will be nothing else. Anyone
>> chasing anything else is a fool.
>
> Anyone restricting his choices to just Windows is an amateur,
> who doesn't understand the real world.
So let it be written?
>
>>> [...]
>>>>>> You said: C++ is dead.
>
>>>>> When did I ever say that? Just the contrary, C++ is a lot
>>>>> more alive than many people want.
>
>>>> In looking to forget it's lineage but still purporting
>>>> something like that.
>
>>> Bullshit. I never forgot C++'s lineage.
>
>> I didn't say "you", I said "C++". C++ is mortaly wounded and
>> maybe you along with it. (Or maybe someone may want their
>> money back!).
>
> Well, I know a lot more than just C++. And I agree that C++ is
> "wounded", in some ways. But not morally.
I said mortally, not morally.
> If for no other
> reason than the fact that for most applications, there's really
> no competitor---about the only possible one would be Ada 95, and
> that doesn't seem to have caught on.
then I am sorry and did not mean to hurt you.. apparenly dying is easy, and
apparently I doing that.
James Kanze
> James Kanze wrote:
> > On Nov 15, 11:54 am, "dragan" <spambus...@prodigy.net> wrote:
> >> James Kanze wrote:
[...]
> >>> require a lot of functionality that Windows doesn't provide
> >>> (and run on platforms that Windows doesn't support).
> >> Just a matter of time.
> > Like, a million years...
> No, like right now Mr. Union Man who doesn't no his ass from a
> hole in the ground.
Like I said, been hearing that for years now. Doesn't seem to
be happening. If anything, with the Web, things are moving the
other direction. (Google doesn't run on Windows.)
> > Actually, I'd say that the tendancy is going in the opposite
> > direction.
> Of course you would, but are in denial.
No, I work in the real world. I don't know of any reasonably
large organization that is 100% Windows.
> > Most IT organizations are realizing that one size doesn't
> > fit all, and that you don't necessarily want the same
> > system handling your critical data as you do on the
> > desktop.
> But you assume gestapo "organization". (nuff said).
> >>> Most large scale servers require more reliability and
> >>> scalability than Windows provides.
> I am against you.
Who cares? Facts are facts, and if you don't care to deal with
them, that's your problem, not mine.
--
James Kanze