Correct way of making a vector class behave as an array

[Majabat]

Dear All,
I’m implementing a vector class that allows me to do vector arithmetic.

What I’ve implemented is the following:

class mVec
{
private:
	float vec[3];

public:
	mVec();
	mVec(const float * const parray);
	mVec(const float a, const float b, const float c);
        ~mVec();

	mVec operator+(const mVec& param);
	mVec operator-(const mVec& param);

	//other operators...

	float* useAsArray()	{ return vec; }
};

As I have already created many functions that work with arrays of three floats, I would like to make my class mVec also compatible with them, without having to overload all these functions.
What apparently works is the member function “useAsArray()”, as it allows me to pass arguments to functions as pointer-to-float, and in this way I can read or write data member vec inside of mVec.

Something like this:

void normalizeVector(float* vec);

Could be used like this:

normalizeVector( a.useAsArray() );

Although it seems to work properly I’m not sure if this is the correct way of doing things. I will appreciate any advice on how to do it better.

Thanks in advance!

Regards,
M.

[mike_2000_17]

Well, as a basic-level solution, yours is totally fine. It is _correct_ in the sense that it will do what you expect and without error. It is _ok_ in the sense that since you are stuck with code that you cannot or don't want to change that needs regular arrays, it is fine to make this accommodation. Of course, I can suggest a few improvements:

I'm not sure this was one of your operator overloads, but I can point out that you can also overload the [] operator (for indexing) such that you can use your vector class exactly as if it was an array:

class mVec
{
  private:
    float vec[3];

  public:
    mVec();
    mVec(const float * const parray);
    mVec(const float a, const float b, const float c);
    ~mVec();

    mVec operator+(const mVec& param);
    mVec operator-(const mVec& param);

    //define a read-write access to element i, to allow: "mVec v; v[i] = 0.0;"
    float& operator[](int i) { return vec[i]; };
    //define a read-only access to element i, to allow indexing into a "const mVec".
    const float& operator[](int i) const { return vec[i]; };

    //other operators...

    float* useAsArray()	{ return vec; }
};

I don't know if you are familiar with the basic use of templates. If you are, you can simply define your functions (without reimplementing them) such that they except any array-like type (whether it is mVec, or float*, or vector<float>, or float[3], or whatever), as such:

template <class FloatArrayType>
void normalizeVector(FloatArrayType vec) {
  float norm = sqrt(vec[0]*vec[0] + vec[1]*vec[1] + vec[2]*vec[2]);
  vec[0] = vec[0] / norm; 
  vec[1] = vec[1] / norm;
  vec[2] = vec[2] / norm;
};

The above will work with any type that has an indexing operator. One caveat, you can hardly link with template functions, so you have to basically all have them implemented inline (in the header file). If you don't, you will have to use "explicit instantiation of templates", which you can look up for yourself if you are in that situation.

If you are not familiar with templates, and are not willing to learn it (that's a bad attitude btw), then there is this simple alternative if you want to just make the use of your function more clean:

void normalizeVector(float* vec);

inline void normalizeVector(mVec& vec) {
  normalizeVector(vec.useAsArray());
};

This way, at least, you won't have to use the useAsArray() function for calls to your array functions. You can use the above before you get to know templates, but you should get to know them, they are, arguably, the most important aspect of C++.

[Majabat]

Dear Mike,

Thank you very much for your suggestions! I also appreciate your crystal clear explanations :)

I’ll be implementing the subscript operator ( [] ) and I will probably later implement the functions using templates. I’ve used templates in the past but I need to read a little to do it the right way.

I’ll also have to investigate a little about the caveat you mention, because that's not clear to me right now.

Thanks again!

Regards,
M.