Printable View
I have this problem where I want to use the new operator to create an array, and pass the constructors the same data. I've tried this
and thisCode:pThreads = new JpegThread[nThreadCount](cdnWaiting, nOriginalWidth, nOriginalHeight, nWidth, nHeight);
but nothing seems to appease the compiler. What am I doing wrong?Code:pThreads = new JpegThread(cdnWaiting, nOriginalWidth, nOriginalHeight, nWidth, nHeight)[nThreadCount];
Trying to create an array of objects of a type without a default constructor :DQuote:
Originally Posted by Angus
Anyway, this is a simple solution:
If you want a more complex solution then look into the use of placement new.Code:std::vector<JpegThread> pThreads(nThreadCount,
JpegThread(cdnWaiting, nOriginalWidth, nOriginalHeight, nWidth, nHeight));
So there's no solution that doesn't involve STL's vector or placement new? Ok, I'll use that. Thanks
If placement new is what I think it is, I took one look at it and swore I'd never use it.
Why the aversion against STL's vector? It is such a useful tool that one (practically) never needs to use new[] / delete[].
The placement new thing is probably rather ugly: this is what std::vector actually does for you.
When the implementation of something is extremely ugly, usually the language is trying to tell you something... I.e. your whole approach isn't right.
Because, all I wanted to do is 1 new, 1 delete, and a whole lot of [] references. Beside, my expressions were already getting pretty long withoutQuote:
Originally Posted by anon
Code:std::vector<JpegThread>::this_::that:and_his_brother
You can still use operator[] with std::vector<JpegThread>, and the use of typedefs can help if you find yourself needing to create iterators or use std::vector<JpegThread>::size_type often.Quote:
Originally Posted by Angus
And now I've got another reason to be averse to STL's vector: JpegThread can't be copied, and std::vector does that (behind the scenes, which is why it took me 30 minutes to figure out what was wrong)
So I'm back to my original problem: how can I do this using a simple array (created with new []) so that I know exactly what's going on, w/out any of that STL cleverness?
I don't understand your complaints about std::vector. JpegThread can't be copied because it's a RAII object. These sorts of things should not be placed into containers. That is NOT the fault of std::vector, it is a fault in your design.Quote:
Originally Posted by Angus
Yes, all the standard containers require that the objects they store be copyable.Quote:
Originally Posted by Angus
Use a container of (smart) pointers to JpegThread instead.Quote:
Originally Posted by Angus
EDIT:
"RAII object" is ambiguous. You are saying that JpegThread has auto_ptr copying semantics?Quote:
Originally Posted by brewbuck
It is quite likely that you won't know better. E.g: what happens if an exception is thrown from some place?Quote:
how can I do this using a simple array (created with new []) so that I know exactly what's going on
I mean RAII in the most general sense -- an object which acquires resources in its constructor and releases them in its destructor. Copying of such objects usually makes no sense because the underlying resource can't be duplicated.Quote:
Originally Posted by laserlight
A RAII object might support some kind of resource sharing and lightweight copying, but I don't think that's a requirement to call something "RAII."
Says who?Quote:
Originally Posted by brewbuck
You're trying to take an object which is inherently not default-constructible, and default-construct it. Failing that, you're trying to take an object which is non-copyable, and copy it. How many other impossible things are you willing to try?Quote:
Originally Posted by Angus
Blaming the language isn't the answer.
Ah, but then the focus should not be on RAII; it should be on the fact that the object is not copyable.Quote:
Originally Posted by brewbuck
That normal copying semantics does not make sense is not a requirement to call something "RAII" either.Quote:
Originally Posted by brewbuck