Base {}; sizeof(Base) == 1?

F

Frederick Gotham

Jerry Coffin posted:
struct XX {
int x;
public:
int y;
};

XX is a POD struct


Incorrect.

8.5.1/5

An aggregate is an array or a class with no user-declared constructors, no
private or protected non-static data members, no base classes, and no
virtual functions.

8.5.9/4

A POD-struct is an aggregate class that has no non-static data members of
type pointer to member, non-POD-struct, non-POD-union (or array of such
types) or reference, and has no user-defined copy assignment operator and no
user-defined destructor.
 
M

Mark P

Frederick said:
Jerry Coffin posted:



Incorrect.

8.5.1/5

An aggregate is an array or a class with no user-declared constructors, no
private or protected non-static data members, no base classes, and no
virtual functions.

8.5.9/4

A POD-struct is an aggregate class that has no non-static data members of
type pointer to member, non-POD-struct, non-POD-union (or array of such
types) or reference, and has no user-defined copy assignment operator and no
user-defined destructor.

And what about struct XX violates this definition?
 
D

Dilip

Frederick said:
Mark P posted:



Read it slowly and carefully. Twice.

I did -- and I don't get your point either.

struct XX is a POD that does not have any user declared ctors, does not
have any private or protected non-static data members, does not have a
baseclass and does not sport any virtual functions -- which makes it an
aggregate.

Further more it does not have any non-static data members of type
pointer to member, non-POD-struct, non-POD-union (or array of such
types) or reference, and does not have any user-defined copy assignment
operator and contains no user-defined dtor either.

There.. what am I missing?
 
F

Frederick Gotham

Dilip posted:
I did -- and I don't get your point either.

struct XX is a POD that does not have any user declared ctors, does not
have any private or protected non-static data members, does not have a
baseclass and does not sport any virtual functions -- which makes it an
aggregate.

Further more it does not have any non-static data members of type
pointer to member, non-POD-struct, non-POD-union (or array of such
types) or reference, and does not have any user-defined copy assignment
operator and contains no user-defined dtor either.

There.. what am I missing?


Reading comprehension skills.

Read it slowly and carefully again.

HINT: The second definition refers to the first.
 
F

Frederick Gotham

Frederick Gotham posted:
HINT: The second definition refers to the first.


Apologies, I got two examples mixed up. The following is definitely not a
POD, because "a" is private:

class MyStruct {

int a;

public:

int b;

};

But as for the the following:

struct MyStruct {

int a;

public:

int b;

};

, I would have thought that the access specifier made no difference. What
part of the Standard indicates that a class or struct is *not* a POD if its
definition contains access specifiers?

If it's a POD, then its members must be in the order as their defined in
the struct or class definition.
 
J

Jerry Coffin

[ ... ]
But as for the the following:

struct MyStruct {

int a;

public:

int b;

};

, I would have thought that the access specifier made no difference.

....but you'd be wrong, just like all of us were for years. AFAIK, I was
the first to notice this particular anomaly, and that was only a few
months ago, after having studied the standard in considerable detail for
years (all the way back to publicly released committed drafts, long
before it WAS a standard).
What
part of the Standard indicates that a class or struct is *not* a POD if its
definition contains access specifiers?

Nothing. As I said, the example given IS a POD struct, because it meets
all the requirements to be a POD struct.
If it's a POD, then its members must be in the order as their defined in
the struct or class definition.

For better or worse, that's just not true. According to section 9.2/12:
"The order of allocation of nonstatic data members separated by an
access-specifier is unspecified (11.1)."

As I said before, much of what most people _think_ is required of a POD
struct really isn't.
 
K

Kai-Uwe Bux

Jerry said:
[ ... ]
Infinitesimal parts would not need to be stored in the object, they would
be part of the address, i.e., pointers would be longer.

First of all, that doesn't strike me as changing much except the name
you give to where you store it -- you're still creating a unique address
for each object, just like you do right now. Under some circumstances
you choose to ignore that difference, but it mostly seems to result in
complexity with little or no benefit.

It seems to me there's a much more straighforward method: nearly all
modern systems support virtual memory anyway. Simply allocate a chunk of
address space without any backing storage. Empty objects get allocated
addresses without backing storage. Everything involved is then supported
quite directly by typical hardware.

That is an interesting idea.
Which (more likely than not) results in even further complexity or even
more wasted space. For example, consider a situation where we cast from
a pointer to derived to pointer to base, then back to pointer to derived
(where the base is empty). In this case, we apparently need to add the
"infinitesimal" part to the pointer during the cast to base, then strip
it back off during the cast to derived -- or else we need to build in
intelligence elsewhere to deal with the fact that a pointer to base may
not always include an infinitesimal part, so everything that looks at a
pointer to base needs to start by figuring out what kind of pointer it's
dealing with.

Except in rather limited situations, this doesn't gain us anything
anyway -- we're changing the terminology from treating the stored data
as part of the object to treating it as part of the pointer, but we're
still stuck with the fact that we're storing some data for each object
we create. Worse still, that's data that really needs to be stored,
using up real memory, whereas simply assigning a new address to each
object can be done without using any real memory to back those
addresses. Worst of all, the amount of data we have to store will
generally exceed the amount we'd use up even if we had backing storage
for each object and assigned each its own address.

The one place I can see this as a possible gain is if we have addresses
with quite a few (at least 20 or so) address bits that are stored but
not used. That, however, almost always means a processor that supports
virtual memory anyway, so it would support the much simpler version I've
outlined above.

Ok, so now we have already two ways of how a compiler could guarantee
uniqueness of addresses for objects without requiring the size of an empty
class to be at least 1. Keep in mind that my original suggestion was just
to answer the (rhetorical) question:
class Base { };

int main() {
Base bases[2];
assert( &bases[0] != &bases[1] );
}

How could the compiler ensure the above assertion is true if sizeof(
Base ) was 0?

I have no opinion on whether using any of the schemes devised by either of
us would be more or less efficient than the simple and straight forward
scheme the standard suggests. I just wanted to point out that there is no
necessity in the sizeof(Base)>0 requirement. The requirement is not there
to make things *possible* it is there to make them *simple*.


Best

Kai-Uwe Bux
 
F

Frederick Gotham

Jerry Coffin posted:

For better or worse, that's just not true. According to section 9.2/12:
"The order of allocation of nonstatic data members separated by an
access-specifier is unspecified (11.1)."

As I said before, much of what most people _think_ is required of a POD
struct really isn't.


Seems like a "bug" in the Standard to me, arising out of a technicality.

Thankfully though it shouldn't be a problem, because we've no reason to place
the redundant access-specifier in there.
 
J

Jerry Coffin

[ ... ]
Seems like a "bug" in the Standard to me, arising out of a technicality.

That's undoubtedly correct -- simply a possibility (and I'll openly
admit, an unusual one) the committee members didn't consider.
Thankfully though it shouldn't be a problem, because we've no reason to place
the redundant access-specifier in there.

Unfortunately, I'm not quite so sanguine about that -- while a person
probably wouldn't put the access specifier there, I can easily imagine a
code generator putting in access specifiers that weren't strictly
necessary (in fact, I know of some that already do so).
 
B

Bo Persson

Jerry Coffin said:
(e-mail address removed)
says...

[ ... ]
Seems like a "bug" in the Standard to me, arising out of a
technicality.

That's undoubtedly correct -- simply a possibility (and I'll openly
admit, an unusual one) the committee members didn't consider.

I think they might very well have considered the case, but simply not
wanted to add "except for redundant public specifiers" to the
complicated rules.
Unfortunately, I'm not quite so sanguine about that -- while a
person
probably wouldn't put the access specifier there, I can easily
imagine a
code generator putting in access specifiers that weren't strictly
necessary (in fact, I know of some that already do so).

Then we have better fix them, rather than changing the language to
accomodate buggy programs. :)

The C++ language inherits PODs from the C language. As soon as we add
access specifiers to a structure, we have already left C land so they
are not PODs anymore.

The thing is that some structures are guaranteed to be compatible with
C. We call them PODs. Some other structures just *might* be compatible
as well, we just don't have any guarantees.

Seeing that the C++0x draft is already over 1000 pages long, I don't
think we need any more corner cased added to it.


Bo Persson
 
J

Jerry Coffin

[ ... ]
Ok, so now we have already two ways of how a compiler could guarantee
uniqueness of addresses for objects without requiring the size of an empty
class to be at least 1.

Actually no. What I'd advocated using memory management hardware would
still give 1 as the size of the object -- each object would be given a
unique address just like usual. The difference would be that it wouldn't
actually consume any real _memory_ for the object, because no memory
would be associated with those addresses.

[ ... ]
I have no opinion on whether using any of the schemes devised by either of
us would be more or less efficient than the simple and straight forward
scheme the standard suggests. I just wanted to point out that there is no
necessity in the sizeof(Base)>0 requirement. The requirement is not there
to make things *possible* it is there to make them *simple*.

It also keeps things predictable. Just for one obvious situation that
inevitably arises, consider what happens when you convert a pointer to
an integer type and back. I realize that at this point you no longer
have portable code -- but (unlike Java) C++ has never attempted to
forbid non-portable code or anything like that.

Anyway, in the end you're basically right: the situation undoubtedly
could be handled in some other way, but it's probably not worth spending
a lot more time on it either.
 
J

Jerry Coffin

[email protected] says... said:
I think they might very well have considered the case, but simply not
wanted to add "except for redundant public specifiers" to the
complicated rules.

From the discussions I've seen between committee members on
comp.std.c++, I _seriously_ doubt that's the case. I've always gotten
the distinct impression that they want the standard to be as complete
and accurate as possible, and are willing to put almost inordinate
effort into ensuring that even strange corner cases be specified
correctly.

My guess is that with a bit of care, the rules could be reworded to fit
this requirement in fairly naturally -- e.g. to say that in a POD
struct, there may be no access specifier between any two variable
declarations.
Then we have better fix them, rather than changing the language to
accomodate buggy programs. :)

They're not buggy. They produce code that's absolutely correct -- and
the ones I've seen put the redundant access specifiers there for a
reason: they're (generally) placeholders with comments telling you what
kinds of things to put in each section. They put a framework in place,
and explicitly put in "blank" spots for you to fill in the details.

Sometimes, however, you don't need to fill in every detail, which can
leave a redundant access specifier.
The C++ language inherits PODs from the C language. As soon as we add
access specifiers to a structure, we have already left C land so they
are not PODs anymore.

Not really true -- C+++ "inherits" a form of struct from C, and that
form is a POD. As is perfectly rasonable in inheritance, however, C++
also extends the definition of POD somewhat, adding a considerable
number of things that aren't directly available in C. Nonetheless, the
intent is clearly that these remain layout-compatible with some similar
struct in C.
The thing is that some structures are guaranteed to be compatible with
C. We call them PODs. Some other structures just *might* be compatible
as well, we just don't have any guarantees.

The problem is that right now, a POD struct isn't guaranteed to be
compatible with C either.
Seeing that the C++0x draft is already over 1000 pages long, I don't
think we need any more corner cased added to it.

Maybe not. Then again, there are times that fixing something actually
makes the result shorter and simpler...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top