Jump to content
  • Advertisement
Sign in to follow this  

Is this STL use correct?

This topic is 4773 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm using Microsoft Visual Studio .NET: First I defined class CVector { public: float pos[3]; public: void operator=(CVector &dest) { pos[0]=dest.pos[0]; pos[1]=dest.pos[1]; pos[2]=dest.pos[2]; } ...(Member functions); }; class CContain { public: CVector m_vector; void operator=(CContain &dest) { m_vector=dest.m_vector; } }; I defined a vector: std::vector<CContain> array; But when I use these command: CContain temp; array.push_back(temp); The compiler gives a error, it says there is no "=" operator which takes the right-hand operator of type <Unknown>, But I've defined the "=" operator and the right-hand operator should not be <Unknow>, but "class CContain &"!

Share this post


Link to post
Share on other sites
Advertisement
usually operator=() will return a reference to its own class instead of void.
so: void operator=(CContain &dest) { m_vector=dest.m_vector; }

would become: CContain& operator=(CContain &dest) { m_vector=dest.m_vector; return *this; }

Share this post


Link to post
Share on other sites
The return should be const as well.
const CContain& operator=(const CContain& src)
{
pop[0]=src.pos[0];
//...
return *this;
}

Unless CVector has some hidden pointers in the implementation, the default copy ctor and assignment operators ought to be sufficient.

And you would pass in the source, not the destination to operator=.

Share this post


Link to post
Share on other sites
Thanks, I see, if you don't add "const" in parameter of operator=, Microsoft Visual C++ .NET won't compile. But for GCC, there is no problem.

Share this post


Link to post
Share on other sites
Quote:
Original post by Magmai Kai Holmlor
The return should be const as well.


To be semantically correct it should be non-constant, as the saying goes "do as the ints do"

@N64Marin

Don't write user declared copy constructors and/or assignment operators when you don't need to, one is implicitly defined by the compiler that by default does a member-wise or bit-wise copy if it's a POD-type (Plain Old Data type a technical term used in the standard) copy/assignement, you should always prefer compiler generated over user-declared/defined especially for a 3-vector where you want it to be POD-type to be efficent in the first place.

That means no user-declared copy constructors or assignement operators (same applys for all it's data members) for it to be a POD-class type.

And as a tip your arithmetic operators should be built-in terms of arithmetic assignment operators i.e.:


struct foo {

foo& operator+=(const foo&) { /* ... * /}

foo operator+(const foo& f) const {
return foo(*this) += f;
}
};


Note you have to provide user declared arithmetic assignment operators there not implicitly generated for you [smile]

[Edited by - snk_kid on April 27, 2005 3:19:56 AM]

Share this post


Link to post
Share on other sites
Quote:
Don't write user declared copy constructors and/or assignment operators when you don't need to, one is implicitly defined by the compiler that by default does a member-wise or bit-wise copy if it's a POD-type (Plain Old Data type a technical term used in the standard) copy/assignement, you should always prefer compiler generated over user-declared/defined especially for a 3-vector where you want it to be POD-type to be efficent in the first place.


Did you actually meassure user declared copy constructors/assigment operators to be less efficent than the ones generated by the compiler?

Share this post


Link to post
Share on other sites
Quote:
Original post by Amma
Did you actually meassure user declared copy constructors/assigment operators to be less efficent than the ones generated by the compiler?


I don't need to, the fact is if your type has user-declared copy constructor and/or assignment operator then your type is not a POD-class type there-for it's not bit-wise copyable which user-declared ones never are. Certain C++ standard library algorithms wont you use optimized strategies for a collection of non-POD types.

For example nearly all implementations of std::copy will (at compile-time) dispatch to use memmove internally for POD types instead of using an explicit loop & assignment which is more efficent.

You should never use any C memory functions (like memcpy) on a collection of non-POD types that is why you should generally prefer to use C++ algorithms on collections because it will do tag & type dispatch at compile-time to choose the most optimized strategy depending on iterator category & the type contained.

Now for a basic low-level type such as a 3-vector the implicitly defined copy & assignement operations generated is more than appropriate and you generally do a lot of work on collections of 3-vectors so you want your 3-vector to be a POD-type so you get the most efficiency out of your collections end of story.

Share this post


Link to post
Share on other sites
Quote:

const CContain& operator=(const CContain& src);


You should read Scott Meyer's "Effective C++" (I'm pretty sure its in this one, and not "More Effective C++"). In there he talks about why you shuoldn't return a const. Basically it breaks the possibility of something like this happening.


int i = 10, j = 10, k = 10;

(i + j) = k;




Now why you you ever want to do something like this? I don't know, but he makes an interesting arguement. If its good enough for ints (which it is legal), then its good enough for classes. The use of const would break its abilitiy to do that.

It's a weird arguement, but it makes sense. The c++ language allows it.

[edit]
It should be noted that a compiler might not allow it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rattrap
If its good enough for ints (which it is legal), then its good enough for classes.


Er... actually it's not legal and if you want your classes to be like an int you shouldn't do it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!