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]

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]

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]

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'

 

[Rolf Magnus]

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]

Victor Bazarov wrote:




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]

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]

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]

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.

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.

};

 

[Rolf Magnus]

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]

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]

In message <[email protected]>, E. Robert Tisdale

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]

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]

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]

In message <[email protected]>, E. Robert Tisdale

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_.

 

[Victor Bazarov]

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

 

[Rolf Magnus]

Where?

Right there:

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

Still can't see it ;-)

 

[Rolf Magnus]

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.