Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Base {}; sizeof(Base) == 1?

Reply
Thread Tools

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

 
 
Frederick Gotham
Guest
Posts: n/a
 
      08-15-2006
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.

--

Frederick Gotham
 
Reply With Quote
 
 
 
 
Mark P
Guest
Posts: n/a
 
      08-15-2006
Frederick Gotham wrote:
> 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.
>


And what about struct XX violates this definition?
 
Reply With Quote
 
 
 
 
Frederick Gotham
Guest
Posts: n/a
 
      08-15-2006
Mark P 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?



Read it slowly and carefully. Twice.

--

Frederick Gotham
 
Reply With Quote
 
Dilip
Guest
Posts: n/a
 
      08-15-2006
Frederick Gotham wrote:
> Mark P 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?

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

 
Reply With Quote
 
Frederick Gotham
Guest
Posts: n/a
 
      08-15-2006
Dilip 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?



Reading comprehension skills.

Read it slowly and carefully again.

HINT: The second definition refers to the first.

--

Frederick Gotham
 
Reply With Quote
 
Frederick Gotham
Guest
Posts: n/a
 
      08-15-2006
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.

--

Frederick Gotham
 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      08-15-2006
In article <fC9Eg.12683$(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed)
says...

[ ... ]

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

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      08-15-2006
Jerry Coffin wrote:

> In article <ebpb4m$qau$(E-Mail Removed)>, (E-Mail Removed)
> says...
>
> [ ... ]
>
>> 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.

>> However, since
>> infinitesimal parts can be ignored most of the time, it is very likely
>> that the compiler could optimize away that overhead for almost all types
>> within any given program.

>
> 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
 
Reply With Quote
 
Frederick Gotham
Guest
Posts: n/a
 
      08-15-2006
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.

--

Frederick Gotham
 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      08-15-2006
In article <F3kEg.12694$(E-Mail Removed)>, (E-Mail 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.

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

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
sizeof(EmptyStruct) in C and C++ (was: Base {}; sizeof(Base) == 1?) Alex Vinokur C Programming 7 08-14-2006 04:57 PM
Access of base class' private base class: qualification required, why Alf P. Steinbach C++ 6 09-03-2005 04:03 PM
Format of compiler generated derived destructor when base has 'virtual ~base() throw():" qazmlp C++ 1 04-10-2005 03:09 PM
Virtual function 'BasicMidReader::~BasicMidReader()' conflicts with base class 'base 'TMemoryStream' tomek C++ 2 12-01-2003 06:31 AM
Virtual function 'BasicMidReader::~BasicMidReader()' conflicts with base class 'base 'TMemoryStream' tomek C++ 3 11-30-2003 12:18 AM



Advertisments