access to member array via public members

[jimmy]

Hi,

I would like to initialize a member array of 3 floats with a memcpy
(for reasons of efficiency). Later I would like to access the floats
via public members (e.g. foo.x, foo.y, foo.z).

Is this possible? (will post ideas in a second)

-Jimmy

[jimmy]

public:
// add some compiler directive to tightly pack
float x;
float y;
float z;

// later on use memcpy(&foo.x, p_float_data, 3*sizeof(float))

Would this work? How do I tell the compiler to tightly pack? would the
memcpy cause a runtime error?

-jimmy

[Victor Bazarov]

jimmy wrote:

I would like to initialize a member array of 3 floats with a memcpy
(for reasons of efficiency).
Whatever your reasons, they are probably important to you.
Later I would like to access the floats
via public members (e.g. foo.x, foo.y, foo.z).

Is this possible? (will post ideas in a second)

Yes, it is possible.

V

[Victor Bazarov]

jimmy wrote:

public:
// add some compiler directive to tightly pack
float x;
float y;
float z;

// later on use memcpy(&foo.x, p_float_data, 3*sizeof(float))

Would this work? How do I tell the compiler to tightly pack? would the
memcpy cause a runtime error?

You could simply declare a real array, and then make x, y, and z the
references to the array elements.

V

[Andrew McDonagh]

Victor Bazarov wrote:

jimmy wrote:

I would like to initialize a member array of 3 floats with a memcpy
(for reasons of efficiency).

Whatever your reasons, they are probably important to you.

And yet, if the OP doesn't know how to initialize the array, I doubt
fully they understand the the need for the 'efficiency'

Later I would like to access the floats
via public members (e.g. foo.x, foo.y, foo.z).

Is this possible? (will post ideas in a second)

Yes, it is possible.

;-)

V

[Rolf Magnus]

Victor Bazarov wrote:

jimmy wrote:

public:
// add some compiler directive to tightly pack
float x;
float y;
float z;

// later on use memcpy(&foo.x, p_float_data, 3*sizeof(float))

Would this work? How do I tell the compiler to tightly pack? would the
memcpy cause a runtime error?

You could simply declare a real array, and then make x, y, and z the
references to the array elements.

Yes, but that's likely to increase the size of the class considerably (I'd
expect a factor of 2 to 3).

[Victor Bazarov]

Rolf Magnus wrote:

Victor Bazarov wrote:

jimmy wrote:

public:
// add some compiler directive to tightly pack
float x;
float y;
float z;

// later on use memcpy(&foo.x, p_float_data, 3*sizeof(float))

Would this work? How do I tell the compiler to tightly pack? would the
memcpy cause a runtime error?

You could simply declare a real array, and then make x, y, and z the
references to the array elements.

Yes, but that's likely to increase the size of the class considerably (I'd
expect a factor of 2 to 3).

Why? References do not necessarily take up space, as you may know.

V

[E. Robert Tisdale]

jimmy wrote:

I would like to initialize a member array of 3 floats with a memcpy
Don't be silly.
for reasons of efficiency).

(Later I would like to access the floats
via public members (e.g. foo.x, foo.y, foo.z).
That's a bad idea.
Is this possible? (will post ideas in a second)
Just do this:
cat foo.cc

class foo {
private:
// representation
float a[3];
public:
// functions
const
float& x(void) const { return a[0]; }
float& x(void) { return a[0]; }
const
float& y(void) const { return a[1]; }
float& y(void) { return a[1]; }
const
float& z(void) const { return a[2]; }
float& z(void) { return a[2]; }
// constructors
foo(void) {
x() = 0.0;
y() = 0.0;
z() = 0.0;
}
};

[Rolf Magnus]

Victor Bazarov wrote:

Rolf Magnus wrote:

Victor Bazarov wrote:

jimmy wrote:

public:
// add some compiler directive to tightly pack
float x;
float y;
float z;

// later on use memcpy(&foo.x, p_float_data, 3*sizeof(float))

Would this work? How do I tell the compiler to tightly pack? would the
memcpy cause a runtime error?

You could simply declare a real array, and then make x, y, and z the
references to the array elements.

Yes, but that's likely to increase the size of the class considerably
(I'd expect a factor of 2 to 3).

Why? References do not necessarily take up space, as you may know.

They usually do if used as members of classes. A reference doesn't
necessarily refer to a member variable of the same object. It could also
refer to another variable, and how would the program know which one if its
address isn't stored somewhere?
I know this is compiler specific (which is why I added the word "likely"),
but I don't think you can find a compiler that doesn't do it like that.

[jimmy]

As the example demonstrates, I am trying to load a 3D model from disk
(i.e. need to load lots of data fast).

I assumed a memcpy of 3 doubles would be faster than 3 assignments.

I also need to do manipulate the coordinates alot. I assumed read/write
would be faster via public access (not to mention backwards compatible
with the existing C implementation that uses structs).

They perhaps are false assumptions but seem reasonable to me. -j

[Richard Herring]

In message <d6**********@nntp1.jpl.nasa.gov>, E. Robert Tisdale
<E.**************@jpl.nasa.gov> writes

jimmy wrote:

I would like to initialize a member array of 3 floats with a memcpy
Don't be silly.

I don't like using memcpy, but it's a sensible enough way to get data
into an array of built-in type.

for reasons of efficiency).
(Later I would like to access the floats
via public members (e.g. foo.x, foo.y, foo.z).
That's a bad idea.

Inviting a proposed solution which doesn't share the reasons why it's
bad.

Is this possible? (will post ideas in a second)
Just do this:

> cat foo.cc

class foo {
private:
// representation
float a[3];
public:
// functions
const
float& x(void) const { return a[0]; }

Const function returning non-const reference to member? Are you sure?
float& x(void) { return a[0]; }
Did you mean
float & x();
float x() const;

or maybe
float & x();
float const & x() const;
?

Either way, what have you gained? As soon as you have access functions
returning references, you've exposed the implementation, and might just
as well have made the member data public in the first place.
const
float& y(void) const { return a[1]; }
float& y(void) { return a[1]; }
const
float& z(void) const { return a[2]; }
float& z(void) { return a[2]; }
// constructors
foo(void) {
x() = 0.0;
y() = 0.0;
z() = 0.0;
}
Ugh.
};

--
Richard Herring

[Rolf Magnus]

jimmy wrote:

As the example demonstrates, I am trying to load a 3D model from disk
(i.e. need to load lots of data fast).

I assumed a memcpy of 3 doubles would be faster than 3 assignments.
If you need maximum speed, assumptions are not a good thing. Btw: Some
compilers actually do automatically make use of memcpy in such a situation.
On others, memcpy might be slower than the assignments. You should measure
the speed or at least look at the generated assembler code to see what the
compiler made out of it. More often than not, you might be surprised.
I also need to do manipulate the coordinates alot. I assumed read/write
would be faster via public access (not to mention backwards compatible
with the existing C implementation that uses structs).

An inline function that returns a reference ususally gets optimized away
completely. And if you need it to be POD, you can still keep the array
member public.

[Rolf Magnus]

Richard Herring wrote:

Just do this:

> cat foo.cc

class foo {
private:
// representation
float a[3];
public:
// functions
const
float& x(void) const { return a[0]; }

Const function returning non-const reference to member? Are you sure?

Where?

float& x(void) { return a[0]; }

Did you mean
float & x();
float x() const;

or maybe
float & x();
float const & x() const;
?

Either way, what have you gained? As soon as you have access functions
returning references, you've exposed the implementation, and might just
as well have made the member data public in the first place.

The difference is that the member is still an array, but when accessing it,
you don't have to write myvec.a[2], but rather myvec.z(), which shows the
intent much more clearly.

[Kai-Uwe Bux]

Richard Herring wrote:

In message <d6**********@nntp1.jpl.nasa.gov>, E. Robert Tisdale
<E.**************@jpl.nasa.gov> writes

[snip]

Just do this:

> cat foo.cc

class foo {
private:
// representation
float a[3];
public:
// functions
const
float& x(void) const { return a[0]; }

Const function returning non-const reference to member? Are you sure?

float& x(void) { return a[0]; }

Did you mean
float & x();
float x() const;

or maybe
float & x();
float const & x() const;
?

Either way, what have you gained? As soon as you have access functions
returning references, you've exposed the implementation, and might just
as well have made the member data public in the first place.

Well, it can be an advantage to have x, y, and z as an array float[3] in
your class. Think of vector arithmetic, think of memcopy, memmove. The
array makes sure that x, y, and z are alligned properly and can be
addressed by member-functions through an index (could be good for computing
cross-products and inner produtcs). In fact, it might be even better to use
boost::array. These are aspects of the implementation that are *not*
exposed by the proposed interface.
Best

Kai-Uwe Bux

[Richard Herring]

In message <d6*************@news.t-online.com>, Rolf Magnus
<ra******@t-online.de> writes

Richard Herring wrote:

Just do this:

> cat foo.cc
class foo {
private:
// representation
float a[3];
public:
// functions
const
float& x(void) const { return a[0]; }

Const function returning non-const reference to member? Are you sure?

Where?

Right there:

float& x(void) const { return a[0]; }

A constant function taking no arguments and returning a non-const
reference to a float, namely a[0].

--
Richard Herring

[Victor Bazarov]

Richard Herring wrote:

In message <d6*************@news.t-online.com>, Rolf Magnus
<ra******@t-online.de> writes

Richard Herring wrote:

Just do this:

> cat foo.cc
class foo {
private:
// representation
float a[3];
public:
// functions
const
float& x(void) const { return a[0]; }
Const function returning non-const reference to member? Are you sure?

Where?

Right there:

float& x(void) const { return a[0]; }

A constant function taking no arguments and returning a non-const
reference to a float, namely a[0].

I guess you're not so good at reading declarations that span two lines,
are you? Just look at the line _preceding_ the one you're referring to.

V

[Richard Herring]

In message <d6*************@news.t-online.com>, Rolf Magnus
<ra******@t-online.de> writes

Richard Herring wrote:

Just do this:

> cat foo.cc
class foo {
private:
// representation
float a[3];
public:
// functions
const
float& x(void) const { return a[0]; }

Const function returning non-const reference to member? Are you sure?

Where?

float& x(void) { return a[0]; }

Did you mean
float & x();
float x() const;

or maybe
float & x();
float const & x() const;
?

Either way, what have you gained? As soon as you have access functions
returning references, you've exposed the implementation, and might just
as well have made the member data public in the first place.

The difference is that the member is still an array, but when accessing it,
you don't have to write myvec.a[2], but rather myvec.z(), which shows the
intent much more clearly.

True.

But in both cases the implementation is exposed, you're committed to
maintaining some kind of member which can be returned as a reference,
and you lose the opportunity to perform contract-enforcement checks on
any value that gets assigned to it.

--
Richard Herring

[Richard Herring]

In message <d6**********@murdoch.acc.Virginia.EDU>, Kai-Uwe Bux
<jk********@gmx.net> writes

Richard Herring wrote:

In message <d6**********@nntp1.jpl.nasa.gov>, E. Robert Tisdale
<E.**************@jpl.nasa.gov> writes[snip]

Just do this:

> cat foo.cc
class foo {
private:
// representation
float a[3];
public:
// functions
const
float& x(void) const { return a[0]; }

Const function returning non-const reference to member? Are you sure?

float& x(void) { return a[0]; }

Did you mean
float & x();
float x() const;

or maybe
float & x();
float const & x() const;
?

Either way, what have you gained? As soon as you have access functions
returning references, you've exposed the implementation, and might just
as well have made the member data public in the first place.

Well, it can be an advantage to have x, y, and z as an array float[3] in
your class.

Certainly.
Think of vector arithmetic, think of memcopy, memmove.
I did. After all, hat's what the original question was about.
The
array makes sure that x, y, and z are alligned properly and can be
addressed by member-functions through an index (could be good for computing
cross-products and inner produtcs). In fact, it might be even better to use
boost::array. These are aspects of the implementation that are *not*
exposed by the proposed interface.

Indeed. But if you make the "setter" function take an argument instead
of returning a reference, there's no need to expose _anything_.

--
Richard Herring

[Rolf Magnus]

Richard Herring wrote:

Const function returning non-const reference to member? Are you sure?

Where?

Right there:

const
float& x(void) const { return a[0]; }

Still can't see it ;-)

[Rolf Magnus]

Richard Herring wrote:

Either way, what have you gained? As soon as you have access functions
returning references, you've exposed the implementation, and might just
as well have made the member data public in the first place.

The difference is that the member is still an array, but when accessing
it, you don't have to write myvec.a[2], but rather myvec.z(), which shows
the intent much more clearly.

True.

But in both cases the implementation is exposed, you're committed to
maintaining some kind of member which can be returned as a reference,
and you lose the opportunity to perform contract-enforcement checks on
any value that gets assigned to it.

That's right. However, I'm just viewing this from another perspective, since
I have done similar things, too, for realtime 3D graphics using OpenGL. In
my case, the class needed to be as efficient as possible, since there will
be millions of instances of it, and every second, millions of operations on
instances of it need to be executed. In addition to that, OpenGL is a C API
that wants pointers to raw arrays of float, so the data needs to be exposed
and needs to be in the form of an array.

[Richard Herring]

In message <yv*******************@newsread1.mlpsca01.us.to.ve rio.net>,
Victor Bazarov <v.********@comAcast.net> writes

Richard Herring wrote:

In message <d6*************@news.t-online.com>, Rolf Magnus
<ra******@t-online.de> writes

Richard Herring wrote:

> Just do this:
>
> > cat foo.cc
> class foo {
> private:
> // representation
> float a[3];
> public:
> // functions
> const
> float& x(void) const { return a[0]; }
Const function returning non-const reference to member? Are you sure?
Where? Right there:

> float& x(void) const { return a[0]; }

A constant function taking no arguments and returning a non-const
reference to a float, namely a[0].

I guess you're not so good at reading declarations that span two lines,
are you?

Only when I write them ;-)

It's been a long day. I take that point back, and substitute a
different one. Who on earth splits that kind of declaration over two
lines, unless they deliberately intend to cause confusion?
Just look at the line _preceding_ the one you're referring to.

But my comment about the following line still stands.

--
Richard Herring

[Billy]

I was infact using "getters" with my initial implementation. I came to
the same realization as Richard; that by using getters I might as well
just make them public.

The implementations are about equal length because I needed to add a
copy cons. and assign. op. for the implementation using reference
members.

I am fairly convinced that using assignment and getters can be only "as
good" as using memcpy and public access. Though as Rolf has pointed
out, the only way to surely tell is to profile and/or look at the
assembly.

Thanks everyone for your help and opinions. -J

"And yet, if the OP doesn't know how to initialize the array, I doubt
fully they understand the the need for the 'efficiency'" -Andrew

I am pretty sure I understand the need for efficiency. I am just not a
seasoned c++ programmer. That's why I am asking for help.