Thread: Creating an array of object w/no default constructor

Originally Posted by Angus

What am I doing wrong?

Trying to create an array of objects of a type without a default constructor

Anyway, this is a simple solution:

Code:

std::vector<JpegThread> pThreads(nThreadCount,
    JpegThread(cdnWaiting, nOriginalWidth, nOriginalHeight, nWidth, nHeight));

If you want a more complex solution then look into the use of placement new.

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.

Originally Posted by Angus

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 without

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.

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.

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)

Yes, all the standard containers require that the objects they store be copyable.

Originally Posted by Angus

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?

Use a container of (smart) pointers to JpegThread instead.

EDIT:

Originally Posted by brewbuck

JpegThread can't be copied because it's a RAII object. These sorts of things should not be placed into containers.

"RAII object" is ambiguous. You are saying that JpegThread has auto_ptr copying semantics?

how can I do this using a simple array (created with new []) so that I know exactly what's going on

It is quite likely that you won't know better. E.g: what happens if an exception is thrown from some place?

Originally Posted by laserlight

"RAII object" is ambiguous. You are saying that JpegThread has auto_ptr copying semantics?

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.

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."

Originally Posted by Angus

Says who?

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?

Blaming the language isn't the answer.

Originally Posted by brewbuck

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.

Ah, but then the focus should not be on RAII; it should be on the fact that the object is not copyable.

Originally Posted by brewbuck

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."

That normal copying semantics does not make sense is not a requirement to call something "RAII" either.