Re: is this portable, conforming to standard, elegant?

From:

"Craig Scott" <audiofanatic@gmail.com>

Newsgroups:

comp.lang.c++

Date:

17 Feb 2007 00:57:09 -0800

Message-ID:

<1171702629.090406.234160@q2g2000cwa.googlegroups.com>

On Feb 15, 7:01 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:

Craig Scott wrote:

On Feb 15, 1:49 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:

Craig Scott wrote:

On Feb 15, 2:04 am, "Emmanuel Deloget" <log...@free.fr> wrote:

On 13 f=E9v, 20:00, "Alexei Polkhanov" <apolkha...@relic.com> wrote:

On Feb 9, 5:05 pm, "Craig Scott" <audiofana...@gmail.com> wrote:

class U
{
// Normally, x,y,z would be private, but OP needs them
// to be public
public:
    float x;
    float y;
    float z;

// operator[] should be public
public:
    // Should also provide a const version of this
    float& operator[](int index)
    {
        if (index == 0)
            return x;
        else if (index == 1)
             y;
        else if (index == 2)
             return z;
        else
             // Throw exception or something else appropriate
    };

};

Personally, to me this then becomes the "best compromise" solut=

ion

to the original poster's problem. It allows clients to continue
using x,y,z member variables but also access using array index
notation. It

Agree, this solution is much better, however I was under impressi=

that
using "union" had to be part of the solution since it was part of
the question.

- Alexei.

I (really) dislike being the one who says "there is a better soluti=

on,

look at mine", but that's going to be what I'm going to do - as the
solution I proposed is quite elegant, standard-proof, and doesn't
require any (endless?) if/then/if/then/else block. The static array=

pointer to members allows a direct access to the variable you need,=

extensible, and doesn not add any space to the class itself, since
it's a class static. As I said, I'm not really sure about the init
time of this array, but given the fact that it's a static POD array,
it should be initialized quite early. Further refinement (throwing a
out_of_range exception) is not difficult to implement (as it only
requires a test against the size of the array, and the mandatory th=

row

statement). The simplicity of operator[] will make this method a go=

candidate for inlining, so in the end the code is quite efficient.

Now, there may be some problems I haven't seen (I don't see every
problem) - if you find some, please tell me.

Probably the biggest weakness is that using the static array makes
your class unsuitable for use in a multi-threaded application. If yo=

app is single threaded, then it's fine.

I am not sure about that.

The proposed solution was essentially this:

struct Vector3 {

  float x, y, z;

  float const & operator[](unsigned int i) const {
    static float Vector3::* const proxy[3] =
      { &Vector3::x, &Vector3::y, &Vector3::z };
    return (*this).*proxy[i];
  }

  float & operator[] ( unsigned int i ) {
    return
      ( const_cast<float&>
        ( const_cast<Vector3 const *>(this)->operator[](i) ) );
  }

};

#include <iostream>

int main ( void ) {
  Vector3 a;
  a[1] = 2;
  std::cout << a.y << '\n';

}

The static array is const. It never changes, so apart from initializat=

ion

issues, I do not see a problem in multithreading (probably, I am very
naive here:-). If there is a problem, one could make operator[] atomic
using some RAII mutex wrapper so that reads to the static data is
properly serialized. That would take care of the initialization issue,=

well. Code could look like this:

class Vector3 {

  static some_lock_type the_lock;

public:

  float x, y, z;

  float const & operator[](unsigned int i) const {
    SomeLockAcquiringWrapper the_guard ( the_lock );
    static float Vector3::* const proxy[3] =
      { &Vector3::x, &Vector3::y, &Vector3::z };
    return (*this).*proxy[i];
  }

  float & operator[] ( unsigned int i ) {
    return
      ( const_cast<float&>
        ( const_cast<Vector3 const *>(this)->operator[](i) ) );
  }

};

However, it might be to costly to do that :-(

Your static array is const but you cast away the const-ness with your
non-const operator[], so clients would be free to try to change the
contents with potentially lethal results.

No, they can't even try: the const_cast is not applied to the static
object "proxy" at any time, it is applied to the object for which the
member function operator[] is called. That does not propagate to static
members. Nobody, at any time, can change the pointer-to-member entries in
proxy.

However, if you feel uncomfortable using the harmless const_cast<> trick,
you can easily rewrite the whole thing equivalently as follows:

#include <cassert>
#include <cstddef>

class Vector3 {

  static
  float Vector3::* const
  proxy ( std::size_t i ) {
    static float Vector3::* const the_proxy [3] =
      { &Vector3::x, &Vector3::y, &Vector3::z };
    return ( the_proxy[i] );
  }

public:

  float x, y, z;

  float const & operator[] ( std::size_t i ) const {
    assert( i < 3 );
    return (*this).*(proxy(i));
  }

  float & operator[] ( std::size_t i ) {
    assert( i < 3 );
    return (*this).*(proxy(i));
  }

};

#include <iostream>

int main ( void ) {
  Vector3 a;
  a[1] = 2;
  std::cout << a.y << '\n';

}

The use of locking will, of
course, get you around the data corruption issue, but I doubt clients
of the class would be expecting to pay the penalty of locking just to
access a class like this. I certainly wouldn't.

I still don't see any data corruption issue. Could you present a scenario,
in code, where it might happen.

Best

Kai-Uwe Bux

Ah, thanks for your patience. I had not properly read the previous
postings and was incorrect in my statements. See my other recent post
in this topic for remaining niggles with this otherwise elegant
solution. :)

--
Computational Fluid Dynamics, CSIRO (CMIS)
Melbourne, Australia