# Is this STL use correct?

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

## 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 on other sites
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 on other sites
Also, if you're going to pass by reference, it should be constant.

##### 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 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 on other sites
Quote:
 Original post by Magmai Kai HolmlorThe 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 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 on other sites
Quote:
 Original post by AmmaDid 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 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.

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

##### Share on other sites
Quote:
 Original post by RattrapIf 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.

1. 1
2. 2
3. 3
4. 4
frob
15
5. 5

• 9
• 12
• 20
• 12
• 13
• ### Forum Statistics

• Total Topics
632146
• Total Posts
3004439

×