 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Tomás
Guest
|
 Posted: Tue May 23, 2006 3:21 am Post subject: Struct members -> Array elements |
 |
|
Do you think the following code should be legal?:
struct Monkey {
double a;
double b;
double c;
};
int main()
{
Monkey obj;
double *p = obj.a;
++p = 54.3;
++p = 23.17;
}
There's a lot of novices out there who have no knowledge of padding; they
commonly ask why sizeof(SomeArbitraryStruct) is not equal to the sum of
its members.
We all know that it's possible to position an object in memory directly
after another object of the same type, and this is how we can increment a
pointer to go through an array's elements.
However, I propose that the Standard guarantee that there be no padding
between members of the same type within a POD struct. Such that the
following code would work perfectly:
struct Monkey {
union {
double array[5];
struct {
double a;
double b;
double c;
double d;
double e;
};
};
};
int main()
{
Monkey monkey;
monkey.array[2] = 65.3;
monkey.d = 23.23;
}
(The idea is that the named members correspond directly to the array
elements).
I can't think of any reason why this wouldn't work on any platform.
-Tomás
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
 |
kanze
Guest
|
| Posted: Tue May 23, 2006 3:21 pm Post subject: Re: Struct members -> Array elements |
|
|
"Tomás" wrote:
| Quote: | Do you think the following code should be legal?:
struct Monkey {
double a;
double b;
double c;
};
int main()
{
Monkey obj;
double *p = obj.a;
++p = 54.3;
++p = 23.17;
}
|
No. Why on earth should it be?
| Quote: | There's a lot of novices out there who have no knowledge of
padding; they commonly ask why sizeof(SomeArbitraryStruct) is
not equal to the sum of its members.
|
Generally, I suspect that the opposite is true. Why on earth
should a novice suppose anything about the layout of a class?
It takes a relatively experienced C++ programmer to recognize
that this is a POD, and that there is no real reason why the
compiler wouldn't lay it out exactly as it would an array.
| Quote: | We all know that it's possible to position an object in memory
directly after another object of the same type, and this is
how we can increment a pointer to go through an array's
elements.
However, I propose that the Standard guarantee that there be
no padding between members of the same type within a POD
struct.
|
And what would that buy us?
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Greg Herlihy
Guest
|
| Posted: Tue May 23, 2006 4:21 pm Post subject: Re: Struct members -> Array elements |
|
|
"Tomás" wrote:
| Quote: | Do you think the following code should be legal?:
struct Monkey {
double a;
double b;
double c;
};
int main()
{
Monkey obj;
double *p = obj.a;
++p = 54.3;
++p = 23.17;
}
There's a lot of novices out there who have no knowledge of padding; they
commonly ask why sizeof(SomeArbitraryStruct) is not equal to the sum of
its members.
We all know that it's possible to position an object in memory directly
after another object of the same type, and this is how we can increment a
pointer to go through an array's elements.
|
Correct. Objects in an array all align properly with no padding between
any of them. In other words, if one object in memory is correctly
aligned (such as Monkey.a), then an object of the same type directly
following it in memory must also be correctly aligned (such as
Monkey.b) - and no intervening padding will exist between them.
Moreover padding can be inserted between objects only where it is
needed for correct alignment, and cannot be inserted between objects
already correctly aligned. Therefore we can conclude that there is no
padding between Monkey.a, Monkey.b, and Monkey.c.
| Quote: | However, I propose that the Standard guarantee that there be no padding
between members of the same type within a POD struct.
|
I believe that such a guarantee can be deduced from the Standard
already.
Greg
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Ducky Yazy
Guest
|
| Posted: Tue May 23, 2006 4:21 pm Post subject: Re: Struct members -> Array elements |
|
|
"Tomás" wrote:
| Quote: | Do you think the following code should be legal?:
struct Monkey {
double a;
double b;
double c;
};
int main()
{
Monkey obj;
double *p = obj.a;
|
I don't think the line above is legal. Are you expecting the following
code?
double *p = &obj.a;
| Quote: |
++p = 54.3;
++p = 23.17;
|
Oooops these two lines! If your expected "p" is pointed to "obj.a",
these two lines
maybe work ok on some compiliers. But this trick may not work sometimes
because
of the "memory alignment (padding)".
..
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Tue May 23, 2006 4:21 pm Post subject: Re: Struct members -> Array elements |
|
|
In article <Hgscg.9439$j7.306147 (AT) news (DOT) indigo.ie>, Tomás
<No.Email (AT) Address (DOT) ucar.edu.invalid> writes
| Quote: | Do you think the following code should be legal?:
struct Monkey {
double a;
double b;
double c;
};
int main()
{
Monkey obj;
double *p = obj.a;
++p = 54.3;
++p = 23.17;
}
There's a lot of novices out there who have no knowledge of padding; they
commonly ask why sizeof(SomeArbitraryStruct) is not equal to the sum of
its members.
We all know that it's possible to position an object in memory directly
after another object of the same type, and this is how we can increment a
pointer to go through an array's elements.
However, I propose that the Standard guarantee that there be no padding
between members of the same type within a POD struct. Such that the
following code would work perfectly:
struct Monkey {
union {
double array[5];
struct {
double a;
double b;
double c;
double d;
double e;
};
};
};
int main()
{
Monkey monkey;
monkey.array[2] = 65.3;
monkey.d = 23.23;
}
(The idea is that the named members correspond directly to the array
elements).
I can't think of any reason why this wouldn't work on any platform.
And I cannot think of a reason why we should want to spend valuable |
committee time considering such a proposal. The special handling of PODs
is purely for backward compatibility with C. Now either you can
demonstrate that C requires your code to work (and then you have a
compatibility issue which could be addressed) or it does not in which
case your change would introduce a compatibility issue which would be a
reason for not accepting it.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Tomás
Guest
|
| Posted: Tue May 23, 2006 8:21 pm Post subject: Re: Struct members -> Array elements |
|
|
Firstly, I did make a typo in my original post; I should have written:
double *p = &obj.a;
(I left out the ampersand in my original post).
I'll reply in sequence to the replies which have been posted thus far.
kanze posted:
<in reference to my proposal>
| Quote: | And what would that buy us?
|
We would be able to write:
struct Monkey {
union {
double array[5];
struct {
double a;
double b;
double c;
double d;
double e;
};
};
};
rather than:
class Monkey {
public:
double array[5];
double &a, &b, &c, &d, &e;
Monkey() : a(*array),
b(array[1]),
c(array[2]),
d(array[3]),
e(array[4]) {}
};
The first form is prefereable as it's a POD, there's no need for a
constructor, and there's no need to complicate things with references.
Greg Herlihy posted:
| Quote: | Therefore we can conclude that there is no
padding between Monkey.a, Monkey.b, and Monkey.c.
snip
I believe that such a guarantee can be deduced from the
Standard already
|
It's a minority who are prepared to make that assertion (as you can see
from the replies). I do agree with your logic... (which is why I started
this thread)... but it seems that some people here are quick to discredit
the code as simply being incorrect, stating that the code makes a false
presumption that the double's are positioned right after one another in
memory.
The purpose of my proposal is that the Standard will explicitly state in
plain English that there's no padding, such that the topic won't even be
open for debate as it is now.
Ducky Yazy posted:
| Quote: | But this trick may not work sometimes
because of the "memory alignment (padding)".
|
My argument is that there shouldn't be any padding because the objects are
of the same type, and thus should fit neatly one after another in memory.
(The padding needed at the end of a struct is already taken into account by
"sizeof", and this value is used in pointer arithmetic -- which is how we
get the desired behaviour of using a pointer to go through an array).
Francis Glassborow posted:
| Quote: | And I cannot think of a reason why we should want to spend valuable
committee time considering such a proposal.
|
It would improve the language. (If the committee time is "too valuable" to
consider improving the language, then maybe we need a new committee).
| Quote: | The special handling of PODsis purely for backward compatibility with C.
|
I am vehemently against this argument. The Fancy Class Types we have in C++
are built upon the fundamental core functionality of primitive types and
POD's. C++ should progress and improve and get better and better, but it
should never forget that it's built on the core functionality of primitive
types and POD's. C++ would be a poor language if the following code was
illegal:
struct Monkey {
union {
long double a;
struct {
int b;
void* c;
};
};
char d;
short e;
};
int main()
{
Monkey obj;
int * const p = reinterpret_cast<int*>(&obj);
*p = 67;
if ( obj.b != 67 ) PeformSomeUndefinedBehaviour();
}
I believe that this "core functionality" should be milked for everything
it's worth, stretching it as far as we can, getting every last penny out of
it. An advanced programming language with features such as mutliple virtual
inheritance, and templates, would be even better if it was built on a solid
core functionality. We should improve this core functionality by explicitly
stating in the Standard that there's no padding between members of the same
type within a POD.
| Quote: | Now either you can
demonstrate that C requires your code to work (and then you have a
compatibility issue which could be addressed) or it does not in which
case your change would introduce a compatibility issue which would be a
reason for not accepting it.
|
Can anyone mention one sole platform upon which there would be padding
between members of the same type in a struct? I can't think of any reason
whatsoever why there would be. I'd go on to say that the following two
structures should be exactly the same size:
struct { double a,b,c,d,e };
struct { double array[5] };
-Tomás
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Guest
|
| Posted: Tue May 23, 2006 8:21 pm Post subject: Re: Struct members -> Array elements |
|
|
Ducky Yazy wrote:
| Quote: | "Tomás" wrote:
Do you think the following code should be legal?:
^^^^^^^^^
struct Monkey {
double a;
double b;
double c;
};
int main()
{
Monkey obj;
double *p = obj.a;
...
++p = 54.3;
++p = 23.17;
Oooops these two lines! If your expected "p" is pointed to "obj.a",
these two lines
maybe work ok on some compiliers. But this trick may not work sometimes
because
of the "memory alignment (padding)".
|
Of course that doesn't work with the standard as it is currently
written. The point of his message was to propose that standard be
changed to prohibit such padding between consecutive data members of
the same type.
My own opinion is that if you want values of the same type to be
contiguous, you should declare an array, and store those values in the
elements of that array. I think this proposed change would encourage
bad coding practices that treat unrelated data items as if they were in
fact related. Code that relied upon such a feature would break if any
one of the variables involved were changed to a different data type;
such code is too fragile for my tastes.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Ron Natalie
Guest
|
| Posted: Tue May 23, 2006 9:21 pm Post subject: Re: Struct members -> Array elements |
|
|
Greg Herlihy wrote:
| Quote: | double *p = obj.a;
|
Presuambly double *p = &obj.a;
*++p = 54.3;
| Quote: |
Moreover padding can be inserted between objects only where it is
needed for correct alignment, and cannot be inserted between objects
already correctly aligned. Therefore we can conclude that there is no
padding between Monkey.a, Monkey.b, and Monkey.c.
|
Upon what do you base this? There is nothing in C or C++ that seems
to preclude internal padding for whatever whim the implementation
desires.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Seungbeom Kim
Guest
|
| Posted: Tue May 23, 2006 10:21 pm Post subject: Re: Struct members -> Array elements |
|
|
Tomás wrote:
| Quote: |
Can anyone mention one sole platform upon which there would be padding
between members of the same type in a struct? I can't think of any reason
whatsoever why there would be. I'd go on to say that the following two
structures should be exactly the same size:
struct { double a,b,c,d,e };
struct { double array[5] };
|
The Library Issue 387 states "All existing implementations already have
the layout proposed here." From this, I can infer that no existing
implementation has padding between members of type T in std::complex<T>,
and thus (probably) neither between members of the same type in a POD
struct.
--
Seungbeom Kim
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Seungbeom Kim
Guest
|
| Posted: Tue May 23, 2006 10:21 pm Post subject: Re: Struct members -> Array elements |
|
|
kanze wrote:
| Quote: | "Tomás" wrote:
However, I propose that the Standard guarantee that there be
no padding between members of the same type within a POD
struct.
And what would that buy us?
|
Suppose you have a struct with members named x, y, and z, and you could
want to refer to them sometimes by names, and sometimes by indices. The
former because it's more natural and closer to the problem domain, and
the latter because it's better suited for across-the-board operations
(and can even benefit from standard algorithms such as std::for_each,
std::transform, etc.). Without any guarantee from the standard, though,
you are forced to write something like:
struct point
{
double x, y, z;
double& operator[](int i)
{
switch (i) {
case 0:
return x;
case 1:
return y;
case 2:
return z;
default:
assert(false && "index out of range");
}
}
// and the const version:
const double& operator[](int i) const { /* ... */ }
};
I'm not sure, though, whether the condition for no padding "between
members of the same type within a POD struct" is either necessary or
sufficient for something useful; maybe we can guarantee more, or
maybe we can require less.
I feel this is also related to Library Issue #387 ("std::complex
over-encapsulated"), which proposes essentially that the real part and
the imaginary part of z should be accessible by an array of value_type
laid on z.
--
Seungbeom Kim
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Tomás
Guest
|
| Posted: Tue May 23, 2006 10:21 pm Post subject: Summary Code |
|
|
To summarise, I'd like to see the following program output the following
on all platforms:
"Program is absent of Undefined Behaviour. YIPPIE!"
(I wonder if anyone can find a platform where it wouldn't? I doubt it.)
#include <iostream>
#include <cstdlib>
bool has_printed_UB = false;
void PerformUndefinedBehaviour()
{
std::cout << "Undefined Behaviour!\n";
has_printed_UB = true;
}
struct Monkey {
union {
double array[5];
struct { double a, b, c, d, e; };
struct { int f; int g; };
};
char h;
double i;
double j;
};
int main()
{
Monkey obj;
/* First demonstrate that the struct elements correspond
to the array elements */
obj.a = 1;
obj.b = 2;
obj.c = 3;
obj.d = 4;
obj.e = 5;
if ( *obj.array != 1 ||
obj.array[1] != 2 ||
obj.array[2] != 3 ||
obj.array[3] != 4 ||
obj.array[4] != 5 ) PerformUndefinedBehaviour();
/* Now demonstrate that the first member of a POD union or POD struct
has the same address as the actual union/struct. (Yes I realise
that the Standard already guarantees this.) */
int * p = reinterpret_cast<int*>(&obj);
*p = 67;
*++p = 54;
if ( !( 67 == obj.f && 54 == obj.g ) ) PerformUndefinedBehaviour();
/* Now show that i and j are contiguous: */
if ( sizeof(double) ! reinterpret_cast<const char*>(&obj.j)
- reinterpret_cast<const char*>(&obj.i)
) PerformUndefinedBehaviour();
if (!has_printed_UB)
std::cout << "Program is absent of Undefined Behaviour. YIPPIE!
\n";
std::system("PAUSE");
}
-Tomás
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Tue May 23, 2006 11:21 pm Post subject: Re: Struct members -> Array elements |
|
|
In article <1148365513.144333.64220 (AT) u72g2000cwu (DOT) googlegroups.com>, Greg
Herlihy <greghe (AT) pacbell (DOT) net> writes
| Quote: | Moreover padding can be inserted between objects only where it is
needed for correct alignment, and cannot be inserted between objects
already correctly aligned. Therefore we can conclude that there is no
padding between Monkey.a, Monkey.b, and Monkey.c.
|
No that is not true. Let me give you an example:
struct X {
char a, b, c;
};
If you set your compiler switched to optimise for space it will usually
just add a byte of padding at the end. If you set it for speed, on some
platforms it might add three bytes of padding between each of a, b and
c. (Optimum alignment on 32 bit word systems). Nonetheless for an array
of char it has to take the no padding route.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Tue May 23, 2006 11:21 pm Post subject: Re: Struct members -> Array elements |
|
|
In article <e4vu27$57d$1 (AT) news (DOT) Stanford.EDU>, Seungbeom Kim
<musiphil (AT) bawi (DOT) org> writes
| Quote: | The Library Issue 387 states "All existing implementations already have
the layout proposed here." From this, I can infer that no existing
implementation has padding between members of type T in std::complex<T>,
and thus (probably) neither between members of the same type in a POD
struct.
|
May well be true for doubles but not necessarily true for char (just as
an example)
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Guest
|
| Posted: Tue May 23, 2006 11:21 pm Post subject: Re: Struct members -> Array elements |
|
|
"Tomás" wrote:
...
| Quote: | kanze posted:
in reference to my proposal
And what would that buy us?
We would be able to write:
struct Monkey {
union {
double array[5];
struct {
double a;
double b;
double c;
double d;
double e;
};
};
};
rather than:
class Monkey {
public:
double array[5];
double &a, &b, &c, &d, &e;
Monkey() : a(*array),
b(array[1]),
c(array[2]),
d(array[3]),
e(array[4]) {}
};
The first form is prefereable as it's a POD, there's no need for a
constructor, and there's no need to complicate things with references.
|
What you haven't explained is why that's desireable. If a, b, c, and d
are truly independent meanings, what value is there in having them
adjacent? If there's value in having them be adjacent, then they should
be stored as an array, and the existence of seperate named references
pointing at the elements of that array is merely a notational
convenience. In other words, in the only case where the creation of
'array' make sense to me, the second approach strikes me as a better
representation of the way you should be thinking about it.
| Quote: | Francis Glassborow posted:
And I cannot think of a reason why we should want to spend valuable
committee time considering such a proposal.
It would improve the language. ...
|
How? Please explain.
| Quote: | ... (If the committee time is "too valuable" to
consider improving the language, then maybe we need a new committee).
|
He's not saying the committee time is "too valuable" to consider
improving the language. He's saying that he doesn't consider this
suggestion to be a significant improvement in the language. I agree.
| Quote: | The special handling of PODsis purely for backward compatibility with C.
I am vehemently against this argument. The Fancy Class Types we have in C++
are built upon the fundamental core functionality of primitive types and
POD's. C++ should progress and improve and get better and better, but it
should never forget that it's built on the core functionality of primitive
types and POD's. ...
|
You might not like it, but that is indeed the approach the committee
has chosen, and it has already moved a long way along that road. The
concept of a POD type was invented solely to allow certain gaurantees
to apply to POD types that do NOT apply to C++ classes in general. The
last time I posted a list of those guarantees on this newsgroup it had
about 26 items. That's 26 important ways in which C++ classes are
allowed, by a deliberate decision of the C++ committee, to differ from
"core functionality" of POD types.
You can try to convince them that this was a bad idea, but an attitude
with that much momentum behind it isn't likely to change easily.
Note: Saying "primitive types and PODs" is redundant - the primitive
types are POD types.
| Quote: | ... C++ would be a poor language if the following code was
illegal:
struct Monkey {
union {
long double a;
struct {
int b;
void* c;
};
};
char d;
short e;
};
int main()
{
Monkey obj;
int * const p = reinterpret_cast<int*>(&obj);
*p = 67;
if ( obj.b != 67 ) PeformSomeUndefinedBehaviour();
}
|
I can't imagine any reason why code like that should be encouraged. It
goes seriously wrong, without producing any compile-time error
messages, if the type of 'b' is changed, or if any data members are
added prior to the union, or prior to b within the unnamed struct.
Setting p to point directly at obj.b would be much safer.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Carl Barron
Guest
|
| Posted: Wed May 24, 2006 12:21 am Post subject: Re: Struct members -> Array elements |
|
|
In article <1148365513.144333.64220 (AT) u72g2000cwu (DOT) googlegroups.com>, Greg
Herlihy <greghe (AT) pacbell (DOT) net> wrote:
| Quote: |
Moreover padding can be inserted between objects only where it is
needed for correct alignment, and cannot be inserted between objects
already correctly aligned.
Not what I read. outside the first member of the struct be at the |
same address as the struct itself, I see no requirements about what
padding is not allowed other than the offset of the first member of a
POD struct is zero.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
