composite type initilization

You must know that fields of a class are initialized in the order they appear in the class's declaration and not in the order they are defined in the initialization list.

I mean that in that code:

struct tp1 {
unsigned int val2;
tp2 tp;
tp1()
: tp(), val2(0)
{}

};

val2 is initialized before tp, and thus, before tp.val1.
What mean that if you did something like that:

void func(tp1* p)
{
// here p->tp.val1 is not yet initialized
}
struct tp1 {
unsigned int val2;
tp2 tp;
tp1()
: tp(), val2(func(this))
{}

};

Perhaps that fact confused you.

But, for now, I don't understand what you meant in the word "transfer".
If you mean assignment or construction-copy, then, please post the faulty code that behaves strangely.

Greetings Paul,

I'm transferring data between two cards. It's a PCI 'transfer' utilizing a vendor API across a protocol called 'starlink'. All that's irrelevant though. Why do you say it's irrelevant? It is very relevant if you are attempting to copy the object in question this way. Are you attempting to do this with the object you described in your first post?
The important thing though is that, I
1. I allocate a bucket of memory on the destination card.
2. the source card gets what's called a handle to that bucket of memory on the destination card.
As a result I transfer header and data to the destination cards memory.
...
So I thought well. The ideal thing to do would involve giving each struct a constructor
...
Note also that. When the destiantion receives the header. All the destination needs to do at that point is cast to the appropriate type.
i.e
vp_hdr_t *ptr_vp = (vp_hdr_t*)0xD0000000;
...
You drew up a plan, but none of it is guaranteed to work in C++.

Again, the original structs were POD, and now the structs are now non-POD. I know it may sound strange, but C++ does not work this way with non-POD types, where you take a memory location, and bingo, you can say an object is there. In C++, non-POD objects must be constructed, assigned, destroyed (with one exeception, operator new using the placement syntax). Maybe placement-new is what you're looking for?
Are you suggesting that I need to provide a copy constructor/assignment operator with the struct? This because I introduced a constructor?No, what I'm saying is once you introduced a constructor, you've gone from the 'C' world into the C++ world.

Basically, non-POD objects cannot be copied, moved, assigned, created, written to files, written across sockets, etc. using 'C' techniques where you are copying raw bytes of memory. This means that you cannot use 'C' functions such as malloc() or calloc() to create such objects, memcpy() or memset() to initialize these objects, you can't use fwrite(..., sizeof(object)) or similar functions to write these objects to a file, and you certainly cannot pass these objects over a socket (which is essentially moving the raw bytes of the object from one location to another).

In C++, the only way to create and copy non-POD types is to actually construct these objects, and using proper copy constructor and assignment to assign these objects. Use any othe method, and the behavior is undefined. From looking at what you're doing, maybe you should be using placement-new, I don't know.

The other workaround is to properly serialize the objects, by sending POD data that gives you enough information to recreate the object on the other side. This is no different than if you were to attempt to write a std::vector<int> to a file -- you don't write the std::vector<int>, you write the number of values in the vector, followed by each integer. Then when you read the file, you create an empty vector, read the number of integers, and populate the empty vector with the values.

The thing is that what you thought of as irrelevant wasn't, and goes into the heart of why you are failing to see the results you expected to see.

Regards,

Paul McKenzie

The best thing to do with C++ classes of this nature that need to be serialised in a binary format is to give them a data() method (not necessarily that name) that should return the required opaque format. It is also useful to have your classes have a constructor or a load method that takes such a format should that also be required.

Internally these methods can use memcpy if they want (char_traits calls it anyway) but users of your class should not be calling it directly, and there is no need for casting.

If you really want to optimise the copying then design your class to store the data in the required format in contiguous memory and use / return that.

Remember to make your data() function const if it does not modify the class nor supply a buffer that can be modified.

In a "performance critical" situation one takes all sorts of short-cuts, including some that you cannot be guaranteed to get away with.

Assuming we are not in such a situation but want to write integers as 4-byte big-endian we will know that the size of your header is 108 and we will know the size of the message. A routine to write an unsigned int is fairly straightforward using shifts thus:

void UIntToBuf( unsigned char * buf, unsigned int num )
{
for ( int byteNum = 3; byteNum >=0; --byteNum )
{
buf[ byteNum ] = static_cast<unsigned char >(num & 0xff);
num >>= 8;
}
}

Works too. i.e the struct is _still_ POD. The only issue is, I'll need to remember to call initialze.

Yes, it is a POD type (at least, with my understanding of the standard).
You are correct!
:)