Back to General and Gameplay Programming

Template classes

General and Gameplay Programming Programming

Started by d000hg May 24, 2005 02:23 AM

26 comments, last by Jiia 18 years, 11 months ago

593

May 25, 2005 04:29 AM

Quote:..std::vector you should look that up and use that instead

I am not telling him to not use templates. I am suggesting on using the standard library vector instead of C-style dynamic arrays, which is good advice.

I oppoligize if he's not trying to understand how to write a template class, but that is the title of the thread. You're telling him to skip the whole process and use std::vector. Using std::vector may be beneficial, but it's not going to help him figure this out.

d000hg

1,208

Author

May 25, 2005 05:04 AM

The sample code was just the simplest template example I could think of. I'm not trying to implement an array.

The comments on not including copy constructors / operators are well made though - I don't think any of my classes define these. I commonly allocate memory using new but I don't ever see myself wanting to copy my classes. It's bad from a C++ design view though I guess. My main reasons not to use st::vector for everything is that then I can't use ZeroMemory etc, and that it makes the code look ugly with iterators everywhere!

If I always use std::vector instead of new, will my class be safe to copy?

DigitalDelusion

874

May 25, 2005 05:12 AM

you can dissallow copying of object by hiding their copy ctor and assignment operator like this:

class NoCopy{private:  NoCopy(const NoCopy&);  NoCopy& operator=(const NoCopy&);};

don't need to supply function bodies.

Also using std::vector will make them safer to copy as long as what's in the vectors are safe to copy, i.e. a vector of pointers tills won't be safe but it's a step in the right direction.

Also if you have POD (Plain Old Data) types stored in your vector you can actually use ZeroMemory just fine, just take the address of the first element in the vector and pass that pointer.

HardDrop - hard link shell extension."Tread softly because you tread on my dreams" - Yeats

Jiia

593

May 25, 2005 05:16 AM

Quote:Original post by d000hg
iterators everywhere!

[lol] Well put. Think that's a Korn song.

Quote:If I always use std::vector instead of new, will my class be safe to copy?

Just don't take the easy way out. Use vectors if they make sense. Don't use them to avoid understanding the methods used. You can write copy constructors for any class you want. That usually just means reallocating dynamic objects, or sharing them with reference counts, depending on the situation.

snk_kid

1,312

May 25, 2005 05:18 AM

Quote:Original post by d000hg
I commonly allocate memory using new but I don't ever see myself wanting to copy my classes. It's bad from a C++ design view though I guess.

A good saying is "do as the ints do" of course only where that makes sense, value-semantics only make sense for particular types for example the I/O streams are non-copyable there not value types it would make no sense to be able to copy/assign them in anycase.

Quote:Original post by d000hg
My main reasons not to use st::vector for everything is that then I can't use ZeroMemory etc.

Well you should never ever use ZeroMemory or any C memory routines on non POD-types (Plain old data type, a technical definition in the C++ standard), which most C++ user-defined types are.

Quote:Original post by d000hg
and that it makes the code look ugly with iterators everywhere!

Its something to get use to, using the standard library generic algorithms help more to make code clean, concise, short, less prone to bugs and at all the same time efficient. In anycase you don't have to use iterators when using std::vector, it has overloaded subscript operators.

Quote:Original post by d000hg
If I always use std::vector instead of new, will my class be safe to copy?

Yep because the standard library containers implement value semantics, therefore correctly does deep copies and assignement. That means the default copy constructor & assignement operators implicitly defined for your user-defined types will correctly copy/assign too, so you don't need to explicitly define copy constructor or assignement operator if that behaviour is appropriate for your situation, in most cases it is.

As DigitalDelusion points out though, if you store pointers instead you still have to take of this your self, no container or array will do this for you.

DigitalDelusion

874

May 25, 2005 05:20 AM

Quote:Original post by Jiia
Just don't take the easy way out. Use vectors if they make sense. Don't use them to avoid understanding the methods used. You can write copy constructors for any class you want. That usually just means reallocating dynamic objects, or sharing them with reference counts, depending on the situation.

Ever heard of the KISS principle? I would say always use std::vector unles you have a good reason not to. And if you plan on reference counting something eiteher save yourself the headache by using boost or some other library or if you (like me) like the learning experience code your own generic shared_ptr class and then use that don't go reimplementing it whenever you need it.

HardDrop - hard link shell extension."Tread softly because you tread on my dreams" - Yeats

Enigma

1,410

May 25, 2005 05:24 AM

Quote:Original post by d000hg
The comments on not including copy constructors / operators are well made though - I don't think any of my classes define these. I commonly allocate memory using new but I don't ever see myself wanting to copy my classes. It's bad from a C++ design view though I guess.

If you want to specify that a class is non-copyable then declare the copy constructor and assignment operator as private and don't define them. This will result in a linker error if you try to copy them:

class NonCopyable{	private:		NonCopyable(NonCopyable const &);		NonCopyable & operator=(NonCopyable const &);};

Quote:My main reasons not to use st::vector for everything is that then I can't use ZeroMemory etc, and that it makes the code look ugly with iterators everywhere!

Those are excuses, not reasons [smile].

// 20 elements, all set to zerostd::vector< int > zeroedVector(20, 0);// 32 elements all set to 7std::vector< int > nonZeroedVector(32, 7);// zero a vector using std::fillstd::fill(nonZeroedVector.begin(), nonZeroedVector.end(), 0);// 17 elements all set to 42std::vector< int > anotherNonZeroedVector(17, 42);// zero and resize a vector using assignanotherNonZeroedVector.assign(101, 0);

And trust me, iterators looking "ugly" is just a case of getting used to them. It doesn't take long before it's pointers than look "ugly" to you instead of iterators.

Quote:If I always use std::vector instead of new, will my class be safe to copy?

The vector will copy safely and deeply (it will create a new vector with the same contents). If you want a safe shallow copy then consider a dynamically allocated vector stored in a std::auto_ptr for ownership transfer or std::tr1::/boost::shared_pointer for shared ownership.

Enigma

Jiia

593

May 25, 2005 05:24 AM

Quote:Original post by DigitalDelusion
Ever heard of the KISS principle? I would say always use std::vector unles you have a good reason not to.

Would a good reason be not having a list of something? Because that's the current situation.

Quote:Original post by DigitalDelusion
And if you plan on reference counting something eiteher save yourself the headache by using boost or some other library or if you (like me) like the learning experience code your own generic shared_ptr class and then use that don't go reimplementing it whenever you need it.

I agree [smile]

Template classes

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Template classes

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines