Default ctor, etc generated by compiler for structs?

[JohnQ]

No. Your StructWrapper and B classes have user defined constructors;
therefore they are not POD types. There is no way to guarantee that
instances of a POD type and a non-POD type will be laid out identically in
memory.

Well consider what the intention of the wrapper class is: to give anything
that wants a struct like the one the class wraps, a refence to the embedded
struct via the defined operator.

void BlastToDisk(struct A& s); // when given a StructWrapper object, i
// it gets a struct A& from
it

I didn't mean to suggest that StructWrapper could be memcpy'd and the like
just because the first data member was a struct.

John

 

[JohnQ]

JohnQ wrote:

::: Conceptually, every type has a destructor (or you can say that it
::: does, since you can call it). The standard has s concept of
::: "a pseudo-destructor call", which means that any type has at least
::: a pseudo-destructor. In my book you can say that a concept of
::: a destructor exists for every type.
::
:: Understood. That's what the constructor/copy constructor/assignment
:: operator/destructor do as together: make classes (or structs)
:: behave like built-in types.
::
::: There is no code where the
::: CPU is led to perform some actions when an object of a POD type is
::: disposed of, yes. In that sense, a POD type does not have a
::: d-tor. So, conceptually, yes, physically, no.
::
:: See, now I think someone else said that those things would be
:: generated (maybe they didn't). I had a feeling they weren't. So
:: that's saying restricting those things in structs is unnecessary.

What Victor means with "conceptually" is that the destructor for a POD
doesn't have to do anything. If you look at the machine code generated by
the compiler, you will not find anything.

Does that mean that it is not there, or just that the compiler inlined an
empty function?

:: Hmmm... now if a class is defined just like a struct but has the
:: class' keyword, will the <whatever you call that group of
:: functions> be generated always?
::

A class and a struct is the same, except for the need (or non-need) of the
keyword public.


:::: OK, so from what I gather, the compiler may or may not generate
:::: the functions/operators depending on the data members. Is it
:::: that if there is any non-POD data member, then the
:::: functions/operators get generated? Is it always the full set
:::: (?): default constructor, copy constructor, assignment operator,
:::: (destructor?).
:::
::: No, not always. For example, it's possible to copy-construct
::: a reference, but it's not possible to assign one, so if your class
::: has a data member that is a reference (it does make it non-POD,
::: BTW), then the copy c-tor can (and will) be generated but the copy
::: assignment op cannot (and will not) be.
::
:: That's getting away from "struct with only POD data members", and
:: that is what I'm really only concerned with.

But this is important. One of the basic requirements of a POD is that it
can only have POD members.

What doesn't matter is if you call it a struct or a class.

Well since a class defaults to private access, the moment you put a data
member into it without specifying 'public', it's no longer an aggregate.
"Warning Master Robinson, your struct is no longer what you think it is!".

John

 

[JohnQ]

What's "an identical class"? A class with the same order of its
members, all declared public? No difference.

"Actually, the standard has a definition for "an identical
class". It's called the "one definition rule". But I rather
doubt that this is what JohnQ is talking about. (Of course, I'm
not too sure what he's talking about. He seems to avoid precise
vocabulary intentionally, just to create confusion.)"

That's not true. If by "precise vocabulary" you mean terminology specificly
used in the standard, well the standard is hardly bedtime reading material
for me and not from where I learned C++ from either.

"Anyway, someone else has already posted the definition of POD,
which is about the only real categorization which is recognized
by the standard. (And I know you know that.)"

It would be nice to see the formal definition.

John

 

[James Kanze]

"James Kanze" <[email protected]> wrote in message

JohnQ wrote:
JohnQ wrote:
[..]
struct B
{
B(); // disallow def construction
B(const B&); // disallow copy construction
const B& operator=(const B&); // disallow assignment
int data_member; // public by default
B(int arg)
: data_member(arg) {}
};
If I disallow the stuff in struct B, it acts less like a C struct,
yes?
As soon as you add a c-tor to B, it stops being a POD. Whether you
"disallow the stuff" or not does not matter after that, it's not
"a C struct" any more.
But for all practical purposes, it acts like one?
No, it does not. You have added a constructor.

I meant in memory. I still have the same question as when I
started I guess: "when does a struct stop being a struct?".

"When it's compiled with a C++ compiler? What do you mean by "a
struct", exactly? In C++, even a POD struct is a class type."

But apparently, the moment you add something "class-like" to the struct,
it's not a POD anymore.

No. I suspected that what you were actually talking about were
POD's, but I wanted to make it clear. C++ doesn't really have
"struct"'s, just classes, but it does distinguish between POD's
and other types. And if your problem is interfacing with a C
API, a POD struct is really what you need; it's the equivalent
of a C struct.

[...]

Yeah, I get it now. Bo Pearson's post made it official in my
mind about POD structs. There must be an official definition
of POD somewhere also huh. That would be nice to see.

I thought someone had already posted it, but from the standard:

§3.9 paragraph 11:
Arithmetic types (3.9.1), enumeration types, pointer
types, and pointer to member types (3.9.2), and
cv-qualified versions of these types (3.9.3) are
collectively called scalar types. Scalar types,
POD-struct types, POD-union types (clause 9), arrays of
such types and cv-qualified versions of these types
(3.9.3) are collectively called POD types.

§9 paragraph 4:
A POD-struct is an aggregate class that has no
non-static data members of type non-POD-struct,
non-POD-union (or array of such types) or reference, and
has no user-declared copy assignment operator and no
user-declared destructor. Similarly, a POD-union is an
aggregate union that has no non-static data members of
type non-POD-struct, non-POD-union (or array of such
types) or reference, and has no user-declared copy
assignment operator and no user-declared destructor. A
POD class is a class that is either a POD-struct or a
POD-union.

And finally, §8.5.1 paragraph 1:
An aggregate is an array or a class (clause 9) with no
user-declared constructors (12.1), no private or
protected non-static data members (clause 11), no base
classes (clause 10), and no virtual functions (10.3).

(This is from N2134, the version of the draft that I happen
to have on line here. I think that there's some open work
still in progress here, because in theory, at least, a
compiler is not required to maintain order when there is an
intervening access specifier, even when it doesn't change
access. So---again in theory---given:

class C
{
public: int x ;
public: int y ;
public: int x ;
} ;

the compiler is allowed to put x, y and z in any order, even
though this is---according to the rules above---a POD
struct.)