placement new versus .. more

[ma740988]

I've got a struct which is comprised of POD types. I know in advance
where in memory the struct resides. To make a long story short, I'm
doing transfers of 16 bit ADC sampled data between 'cards'. At the
front end I configure the memory such that - say card 1 will transfer
data to card 2 at a specified region. A header is accompanied with
each data transfer. So now lets say card 1 transferred the header to
location 0xD0000000 of card2. Assume the header is akin to:

typedef unsigned int uint_type;
struct temp {
uint_type param1;
uint_type param2;
uint_type param3;
// etc
};
To see what's in temp, I do:
temp *ptr_temp = (temp*)0xD0000000; // I already know where to map to.
// now do something with the junk received.
int const p1 = ptr_temp->param1;

As far as I know the approach above is perfectly legal or is this a
candidate for placement new?

Here's my confusion. I'm reading Clines text (yes hard copy of the
FAQ) and I'm tryign to get my head around placement new but I'm not
sure if that buys me anything here.

As always, thanks in advance.

[Kai-Uwe Bux]

ma740988 wrote:

I've got a struct which is comprised of POD types. I know in advance
where in memory the struct resides. To make a long story short, I'm
doing transfers of 16 bit ADC sampled data between 'cards'. At the
front end I configure the memory such that - say card 1 will transfer
data to card 2 at a specified region. A header is accompanied with
each data transfer. So now lets say card 1 transferred the header to
location 0xD0000000 of card2. Assume the header is akin to:

typedef unsigned int uint_type;
struct temp {
uint_type param1;
uint_type param2;
uint_type param3;
// etc
};
To see what's in temp, I do:
temp *ptr_temp = (temp*)0xD0000000; // I already know where to map to.
// now do something with the junk received.
int const p1 = ptr_temp->param1;

As far as I know the approach above is perfectly legal or is this a
candidate for placement new?

Placement new will construct an object for you at a memory location that you
specify by means of the passed pointer. The line above does *not* construct
an object at location 0xD0000000. It just makes ptr_temp point there.

If I understand you correctly, card1 has already put all the data there that
you would expect in the header. In that case, the line above is *right* and
placement new would be *wrong* because the object has already been created
by card1.
Best

Kai-Uwe Bux

[Alf P. Steinbach]

* ma740988:

I've got a struct which is comprised of POD types. I know in advance
where in memory the struct resides. To make a long story short, I'm
doing transfers of 16 bit ADC sampled data between 'cards'. At the
front end I configure the memory such that - say card 1 will transfer
data to card 2 at a specified region. A header is accompanied with
each data transfer. So now lets say card 1 transferred the header to
location 0xD0000000 of card2. Assume the header is akin to:

typedef unsigned int uint_type;
struct temp {
uint_type param1;
uint_type param2;
uint_type param3;
// etc
};
To see what's in temp, I do:
temp *ptr_temp = (temp*)0xD0000000; // I already know where to map to.
// now do something with the junk received.
int const p1 = ptr_temp->param1;

As far as I know the approach above is perfectly legal
It's compiler-specific, and moreover, since judging from what you write
it's likely that that region resides on the card itself (otherwise why
use an absolute address?), it's also hardware-specific.
or is this a candidate for placement new?
No.

Here's my confusion. I'm reading Clines text (yes hard copy of the
FAQ) and I'm tryign to get my head around placement new but I'm not
sure if that buys me anything here.

No, it doesn't. Placement new constructs an object in already existing
storage. If you had a non-POD you wished to have in card memory you'd
have to use placement new, but not with a POD.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[ma740988]

Kai-Uwe, Alf. Got it. Thanks!!!

[Bo Persson]

"Alf P. Steinbach" <al***@start.no> skrev i meddelandet
news:45************@individual.net...

* ma740988:

I've got a struct which is comprised of POD types. I know in
advance
where in memory the struct resides. To make a long story short,
I'm
doing transfers of 16 bit ADC sampled data between 'cards'. At
the
front end I configure the memory such that - say card 1 will
transfer
data to card 2 at a specified region. A header is accompanied
with
each data transfer. So now lets say card 1 transferred the header
to
location 0xD0000000 of card2. Assume the header is akin to:

typedef unsigned int uint_type;
struct temp {
uint_type param1;
uint_type param2;
uint_type param3;
// etc
};
To see what's in temp, I do:
temp *ptr_temp = (temp*)0xD0000000; // I already know where to map
to.
// now do something with the junk received.
int const p1 = ptr_temp->param1;

As far as I know the approach above is perfectly legal

It's compiler-specific, and moreover, since judging from what you
write it's likely that that region resides on the card itself
(otherwise why use an absolute address?), it's also
hardware-specific.

And it is also OS specific. :-)

The addresses used in the program most likely is in a virtual address
space. The card probably works with a physical memory address.

Are we sure that these are connected ?
Bo Persson

[ma740988]

> >> As far as I know the approach above is perfectly legal

It's compiler-specific, and moreover, since judging from what you
write it's likely that that region resides on the card itself
(otherwise why use an absolute address?), it's also
hardware-specific.

And it is also OS specific. :-)

Not sure I'm followinig you here.

I disovered what my problem was. Initially I had a _true_ POD header:
struct header {
unsigned int data_size;
unsigned int message_id;
// more stuff
};

Then I changed it to:
struct header {
unsigned int data_size;
unsigned int message_id;
header()
: data_size(0)
, message_id(0)
{}
};

For the latter, header is no longer a POD. As a result all bets are
off, hence I suspect thats the reason the 'destination' was seeing a
bogus value for message_id. It's as if it wasn't initialized.

So I'll just resort back to the C style struct (the former) and memset
the damn thing. This alleviates the need to have to serialize the data
and all the other mess that accompanies the non pod struct.