Re: C++ template pointers vs. objects
Re: C++ template pointers vs. objects
- Subject: Re: C++ template pointers vs. objects
- From: Howard Hinnant <email@hidden>
- Date: Wed, 25 May 2005 23:34:37 -0400
On May 25, 2005, at 10:52 PM, Wesley Smith wrote:
Hi,
What is best practice in C++ when using templates and large
objects...is it to declate a vector of pointers to an object or a
vector of objects as in:
std::vector<largeObject *> objvect;
or
std::vector<largeObject> objvect;
My first reaction is to always try to work with
std::vector<largeObject>. The vector will not copy your objects around
/that/ often (maybe 2 or 3 times amortized over all objects). And if
that is too expensive, perhaps another container such as deque or list
is a better choice (which tend to copy objects with less enthusiasm).
Go with what is simple, and then measure.
If you do go with std::vector<largeObject*>, which isn't always a bad
idea, then you need to deal with memory ownership. Who owns the
pointer? vector doesn't. If you can easily maintain ownership with a
wrapper class around the std::vector<largeObject*> then great.
Otherwise you might explore std::vector<shared_ptr<largeObject> >
though that may or may not realize the performance gains you are
looking for (and watch out for multithread complications).
Whatever your decision, hide it from your clients. The best decision
today may not be the best decision tomorrow. You want to be able to
change your container choices without breaking API or ABI
compatibility.
In the not-to-distant future, std::vector<largeObject> is going to
become much less expensive due to move semantics (assuming C++
committee cooperation, and a few very easy additions to largeObject).
Indeed Metrowerks Pro 10/Mac will offer such extensions to the C++
standard hopefully within only a few months time frame. However such
code won't be portable for several more years - assuming all things
going as well as possible.
-Howard
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden