Anyway, are you going to take my suggestion of using a container of (smart) pointers instead?
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Well, 'fact is, I've never broken into smart pointers, and right now I'm still trying to cut my teeth on pthreads. I found the next best solution in making an array of pointers, and looping the creation of all my objects, and of course looping their destruction as well. I'll do smart pointers next time. Thanks anyway.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Right, so I identified containers as the problem, abandoned them, and therein lay an acceptable solution.
Why does anyone need an array? As the name suggests, that class represents a thread, and I need multiple threads.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.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
Originally it's what I said it was about in my first post. Then it went through a yarn of whether I should change my class to suit containers, or throw out containers to suit my class, then I announced which of those options I would choose. Then it looped right back to weather I should change my class to suit containers or throw out containers to suit my class.
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.