«

I have a struct like

struct MyStruct
{
int a;
int b;
int c:
bool d;
bool e;
}

I want to insert such a struct in a map. I understand I can declare the
< operator for such a struct for lexicographical compare like

x.a < y.a || !(y.a < x.a) && ( x.b < y.b || !(y.b < x.b) && x.c < y.c
.............

or a simple one like this

memcmp(&x,&y,sizeof(MyStruct)) < 0;

This seems to work if I memset and fill the sizeof(MyStruct) with
zeroes in the constructor before I assign a b and c etc. This will take
care of any padding that the compiler adds.

My question is whether the second approach is portable? If so do I
really need the memset ? Does the standard say anything about
initializing the padding bits?

Raj

wrote:
> I have a struct like
>
> struct MyStruct
> {
> int a;
> int b;
> int c:
> bool d;
> bool e;
> }
>
> I want to insert such a struct in a map. I understand I can declare the
> < operator for such a struct for lexicographical compare like
>
> x.a < y.a || !(y.a < x.a) && ( x.b < y.b || !(y.b < x.b) && x.c < y.c
> ............
>
> or a simple one like this
>
> memcmp(&x,&y,sizeof(MyStruct)) < 0;
>
> This seems to work if I memset and fill the sizeof(MyStruct) with
> zeroes in the constructor before I assign a b and c etc. This will take
> care of any padding that the compiler adds.
>
> My question is whether the second approach is portable? If so do I
> really need the memset ? Does the standard say anything about
> initializing the padding bits?

1) Yes. 2) Yes. 3) They are uninitialised unless your object has static
storage duration. Beware, though that as soon as your MyStruct ceases
being a POD (because you added a private section or a virtual function or
something of the sort), use of memset and memcpy on it becomes undefined.

V

schrieb:
> I have a struct like
>
> struct MyStruct
> {
> int a;
> int b;
> int c:
> bool d;
> bool e;
> }
>
> I want to insert such a struct in a map. I understand I can declare the
> < operator for such a struct for lexicographical compare like
>
> x.a < y.a || !(y.a < x.a) && ( x.b < y.b || !(y.b < x.b) && x.c < y.c
> ............
>
> or a simple one like this
>
> memcmp(&x,&y,sizeof(MyStruct)) < 0;
>
> This seems to work if I memset and fill the sizeof(MyStruct) with
> zeroes in the constructor before I assign a b and c etc. This will take
> care of any padding that the compiler adds.
>
> My question is whether the second approach is portable? If so do I
> really need the memset ? Does the standard say anything about
> initializing the padding bits?

Sorry, can't tell you about the padding bits, but it's still not
portable because of endianess issues:

struct Foo
{
int a;
};

Foo f1 = { 1 };
Foo f2 = { 256 };

On big-endian machines a memcmp() compare will work correctly. On a
little-endian machine with 32-bit ints, f1 will contain the byte
sequence 0x01 0x00 0x00 0x00 (minus padding) and f2 will contain 0x00
0x01 0x00 0x00. memcmp() will report f1 as greater than f2.

Cheers,
Malte

You mentioned something about private section. Could you elaborate how
that would change things ?

If the struct carried a vtable pointer or had NON POD could i just
overload new and memset before i call the constructor ?

Raj

<> wrote in message
news: oups.com...
>I have a struct like
>
> struct MyStruct
> {
> int a;
> int b;
> int c:
> bool d;
> bool e;
> }
>
> I want to insert such a struct in a map. I understand I can declare the
> < operator for such a struct for lexicographical compare like
>
> x.a < y.a || !(y.a < x.a) && ( x.b < y.b || !(y.b < x.b) && x.c < y.c

Note that you can also use the (IMO better) following form:
return (x.a!=y.a) ? x.a<y.a
: (x.b!=y.b) ? x.b<y.b
: (x.c!=y.c) ? x.c<y.c
: (x.d!=y.d) ? x.d<y.d : x.e < y.e;

> or a simple one like this
>
> memcmp(&x,&y,sizeof(MyStruct)) < 0;
>
> This seems to work if I memset and fill the sizeof(MyStruct) with
> zeroes in the constructor before I assign a b and c etc. This will take
> care of any padding that the compiler adds.

But not of endianness and other binary representation issues.
Really, I don't think that saving a few statements is worth the
loss of portability. Plus the explicit form gives you much more
flexibility. So why bother?


--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

wrote:
> You mentioned something about private section. Could you elaborate how
> that would change things ?

The layout of an object is only mandated within the same access specifier
section. So, as soon as you introduce private or protected non-static
data members, the struct is not a POD any more, and I am not really sure
why that is, but the Standard makes a point of defining POD-struct that
way.

> If the struct carried a vtable pointer or had NON POD could i just
> overload new and memset before i call the constructor ?

I am not sure what you mean by "overload memset", but yes, essentially,
your task would be to gain control over the "padding bytes" by, for
example, eliminating them using compiler-specific means.

Let me ask a rhetorical questions, though. If you are prepared to give it
overloaded 'new' and 'memset' (let's suppose it's possible somehow), why
don't you just overload the operator < ?

V

Malte Starostik wrote:
> [...]
> Sorry, can't tell you about the padding bits, but it's still not
> portable because of endianess issues:
>
> struct Foo
> {
> int a;
> };
>
> Foo f1 = { 1 };
> Foo f2 = { 256 };
>
> On big-endian machines a memcmp() compare will work correctly. On a
> little-endian machine with 32-bit ints, f1 will contain the byte
> sequence 0x01 0x00 0x00 0x00 (minus padding) and f2 will contain 0x00
> 0x01 0x00 0x00. memcmp() will report f1 as greater than f2.

But won't it report f1 consistently greater than f2? The purpose of
using memcmp (as I understood it) was to forgo the real operator < and
the memberwise comparison just to see if they were different.

V

"Victor Bazarov" <> wrote in message
news:N_f0e.55648$ o.verio.net...

>> My question is whether the second approach is portable? If so do I
>> really need the memset ? Does the standard say anything about
>> initializing the padding bits?
>
> 1) Yes. 2) Yes. 3) They are uninitialised unless your object has static
> storage duration.

Beg pardon? Memcmp portable? I don't see why. As a simple example, I
can't think of any place in the standard that requires all equal bool values
to have the same representation. In other words, I don't see anything wrong
with an implementation that stores a byte in a bool and considers zero to be
false and any nonzero value to be true. Under such an implementation,
memcmp might yield unequal for two values that should be considered equal.

I dont care about that as I want just keep them in a set. If A < B I
just want to make sure A < B all the time

Raj

>Let me ask a rhetorical questions, though. If you are prepared to
give it
>overloaded 'new' and 'memset' (let's suppose it's possible somehow),
why
>don't you just overload the operator < ?

Its some legacy code. The idea being if you add a new member it will
work automatically. If you overload <
you will have to manually update it for the new member

Raj