Anyway, are you going to take my suggestion of using a container of (smart) pointers instead?
Why does anyone need an array? As the name suggests, that class represents a thread, and I need multiple threads.Quote:
I'm with LaserLight that you ought to look at using some kind of smart pointer. Why do you need an array of these things anyway?
I've been questioned on this proposal before, and I'm making it here too.
Smart pointers and threaded programming go together. I've written threaded applications for many years, and at this point I find that writing threaded applications without using smart pointers is more difficult. If I were designing a course study, I'd cover smart pointers before threads; they're that related.
I've encountered puzzlement on this point before. Threading often brings up a problem with containment; it's common to end up creating objects or containers of objects that are handed over to other threads, and at some point one comes to the question "who deletes this?". Smart pointers (reference counted specifically) solve this problem to the point of triviality (well, almost). It provides a similar feature to the memory management common to Java and C# application work, with respect to threading.
That has no direct bearing on the point about the array and construction of your original point, just a response to your indication of dealing with smart pointers AFTER you've worked on threads.
My current stance on C++ programming is that EVERY class must either be well-behaved when copy-constructed or assigned, OR it must prevent copy-construction and assignment, by declaring those both private and leaving them unimplemented.
I also believe that an unnecessarily implemented copy-constructor, assignment operator or destructor is very wrong.
One way or another, your class is broken.
Now it's just a matter of making sure that the next guy who comes along w/this problem is going to get it right away, and not get lost.
I don't understand what all the fuss is about here. Angus wanted to be able to create an array of non-default constructed objects. Use of vector was (appropriately) suggested, at which point is was determined that a vector of objects wouldn't make sense since the objects in question aren't copyable. I fail to see how anything is broken. (Of course, if it hasn't already been done, the JpegThread class should disable copying so that a compiler error is given when it is used with vector or otherwise accidentally copied.)
So, Angus has decided on a container of raw pointers for a perfectly legitimate reason.
Angus, if and when you have time to invest in it, I'd use Boost's ptr_vector over a vector of smart pointers for this solution. You'll have to use boost or TR1 for this anyway (because there is no standard smart pointer suitable for use with a vector), so you might as well use ptr_vector which does a nice job of implementing exactly what you're implementing now, only with a more widely used and tested interface and implementation.