«

I need an dynamic array of pointers to MyObj in a class.
Am I doing this right?

class SomeClass
{
public: SomeClass();
~SomeClass();
MyObj **pMyObj; // pointer to pointer == pointer to array of
pointers
int iNumPointers; // counter
}

SomeClass::SomeClass()
{
iNumPointers = 123;

pMyObj = new MyObj*[iNumPointers]; // create array of iNumPointers
pointers to MyObj
for (int i = 0; i < iNumPointers; i++) pMyObj[i] = new MyObj(); // init each
pointer object
}

SomeClass::~SomeClass()
{
for (int i = 0; i < iNumPointers; i++) delete pMyObj[i]; // destroy each
object first
delete [] pMyObj; // and destroy array of pointers
}

Is there an easier/smarter way to the same thing to avoid destructors? e.g.
using std::vector?

John <>, on 24/06/2010 19:42:17, wrote:

> I need an dynamic array of pointers to MyObj in a class.
> Am I doing this right?
>
> class SomeClass
> {
> public: SomeClass();
> ~SomeClass();
> MyObj **pMyObj; // pointer to pointer == pointer to array of
> pointers
> int iNumPointers; // counter
> }
>
> SomeClass::SomeClass()
> {
> iNumPointers = 123;
>
> pMyObj = new MyObj*[iNumPointers]; // create array of iNumPointers
> pointers to MyObj
> for (int i = 0; i< iNumPointers; i++) pMyObj[i] = new MyObj(); // init each
> pointer object
> }
>
> SomeClass::~SomeClass()
> {
> for (int i = 0; i< iNumPointers; i++) delete pMyObj[i]; // destroy each
> object first
> delete [] pMyObj; // and destroy array of pointers
> }
>
> Is there an easier/smarter way to the same thing to avoid destructors? e.g.
> using std::vector?

Yes, you just need to use some kind of smart pointer, make a search and
you'll find plenty of options.

Just as a side note, the next time you post code on a medium that could
wrap, either put single line comments on separate lines or use block
comments.

Cheers

--
FSC
http://userscripts.org/scripts/show/59948

>> Is there an easier/smarter way to the same thing to avoid destructors?
>> e.g.
>> using std::vector?
> Yes, you just need to use some kind of smart pointer, make a search and
> you'll find plenty of options.

can you show an short example how would you do the above with smart pointer
(preferably std::vector)? wrapping smart pointer in a class constructor is
kind-of abstract to me...

John <>, on 24/06/2010 21:41:52, wrote:

>>> Is there an easier/smarter way to the same thing to avoid destructors?
>>> e.g.
>>> using std::vector?
>> Yes, you just need to use some kind of smart pointer, make a search and
>> you'll find plenty of options.
>
> can you show an short example how would you do the above with smart pointer
> (preferably std::vector)? wrapping smart pointer in a class constructor is
> kind-of abstract to me...
>


Well, nothing really difficult, you would just replace your array with a
vector, then in the constructor of you container (as well as somewhere
else, if needed) you would push smart pointers into the vector, maybe
within a loop, just like when you have looped your array to assign the
raw pointers with the addresses of the newly created objects:

vec.push_back(smart_pointer(new obj));

where vec is a std::vector, obj is the name of the class you want to
store pointers of, and smart_pointer is the constructor of the smart
pointer you decide to use - and that's the truly important point: the
smart pointer that you choose.

Make a search for "std::auto_ptr with std::vector" and you will see what
I mean.

--
FSC
http://userscripts.org/scripts/show/59948

Christian Hackl <>, on 24/06/2010 22:41:52, wrote:

> Christian Hackl ha scritto:
>
>> John ha scritto:
>>
>>> I need an dynamic array of pointers to MyObj in a class.
>>> Am I doing this right?
>>>
>>> class SomeClass
>>> {
>>> public: SomeClass();
>>> ~SomeClass();
>>> MyObj **pMyObj; // pointer to pointer == pointer to array of
>>> pointers
>>> int iNumPointers; // counter
>>> }
>>
>> class SomeClass
>> {
>> public:
>> SomeClass(int count);
>>
>> private:
>> std::vector<std::vector<MyObj> > vec;
>> };
>
> Actually, if I really understand what you try to accomplish, then this
> solution is incorrect. Use the other one with shared_ptr! (Use
> std::vector<MyObj> and just forget about pointers if MyObj is not
> polymorphic.)

The decision about directly storing objects or just pointers to them
doesn't just depend on whether they're polymorphic or not, it does
depend on their size too - but in that case, even the choice of the
container (std::vector vs std::list, for example) should be pondered.

Hey, if I can dare suggesting, avoid feeding "pappa pronta"

--
FSC
http://userscripts.org/scripts/show/59948

On Jun 24, 3:38*pm, Christian Hackl <ha...@sbox.tugraz.at> wrote:
> SomeClass::SomeClass(int count) :
> * *vec(count, std::shared_ptr<MyObj>(new MyObjDerived))
> {
>
> }

I think this will create a bunch of pointers to the same object. If
instead he wants a bunch of pointers to distinct objects, he might
try:
SomeClass::SomeClass() :
myObjPtrs(123)
{
std::for_each(myObjPtrs.begin(),
myObjPtrs.end(),
[](std::shared_ptr<MyObj> & i) { i =
std::shared_ptr<MyObj>(new MyObjDerived); });
};

John H. <>, on 24/06/2010 14:00:00, wrote:

> On Jun 24, 3:38 pm, Christian Hackl<ha...@sbox.tugraz.at> wrote:
>> SomeClass::SomeClass(int count) :
>> vec(count, std::shared_ptr<MyObj>(new MyObjDerived))
>> {
>>
>> }
>
> I think this will create a bunch of pointers to the same object. If
> instead he wants a bunch of pointers to distinct objects, he might
> try:
> SomeClass::SomeClass() :
> myObjPtrs(123)
> {
> std::for_each(myObjPtrs.begin(),
> myObjPtrs.end(),
> [](std::shared_ptr<MyObj> & i) { i =
> std::shared_ptr<MyObj>(new MyObjDerived); });
> };

Eheheehh, just to make the OP's life easier throwing in lambda functions...

Not that I dislike the advice, on the contrary, but maybe explicitly
mentioning it would have been nice

--
FSC
http://userscripts.org/scripts/show/59948

On Jun 24, 4:08*pm, "Francesco S. Carta" <entul...@gmail.com> wrote:
> John H. <oldman_fromt...@yahoo.com>, on 24/06/2010 14:00:00, wrote:
> > SomeClass::SomeClass() :
> > * *myObjPtrs(123)
> > {
> > * * *std::for_each(myObjPtrs.begin(),
> > * * * * * * * * * *myObjPtrs.end(),
> > * * * * * * * * * *[](std::shared_ptr<MyObj> *& *i) { i =
> > std::shared_ptr<MyObj>(new MyObjDerived); });
> > };
>
> Eheheehh, just to make the OP's life easier throwing in lambda functions....


Your point is well taken. Another way to do the above:

SomeClass::SomeClass() :
myObjPtrs(123)
{
for(int i=0; i<123; i++)
{
myObjPtrs[i] = std::shared_ptr<MyObj>(new MyObj);
}
}

On Jun 24, 9:38 pm, Christian Hackl <ha...@sbox.tugraz.at> wrote:
> John ha scritto:

> > I need an dynamic array of pointers to MyObj in a class.
> > Am I doing this right?

> > class SomeClass
> > {
> > public: SomeClass();
> > ~SomeClass();
> > MyObj **pMyObj; // pointer to pointer == pointer to array of
> > pointers
> > int iNumPointers; // counter
> > }

> class SomeClass
> {
> public:
> SomeClass(int count);

> private:
> std::vector<std::vector<MyObj> > vec;
> };

Except that he wanted pointers. He didn't say why, so we can't
make any real assumptions: most of the time, pointers are used
for navigation between entity objects, which aren't copiable, so
the vector of object type doesn't work.

> Or, if you really need pointers to MyObj (for example if MyObj is a
> polymorphic base class):

> class SomeClass
> {
> public:
> SomeClass(int count);
>
> private:
> std::vector<std::shared_ptr<MyObj> > vec;
> };

Again, if the pointers are used for navigation, this is not
a good solution. std::shared_ptr is handing in some specific
cases, but it is definitely not a general solution.

> > SomeClass::SomeClass()
> > {
> > iNumPointers = 123;

> > pMyObj = new MyObj*[iNumPointers]; // create array of iNumPointers
> > pointers to MyObj
> > for (int i = 0; i < iNumPointers; i++) pMyObj[i] = new MyObj(); // init each
> > pointer object
> > }

This, on the other hand, makes it look like the vector of
objects *is* the best solution, and that his use of pointers is
wrong.

> If MyObj is not polymorphic:

> SomeClass::SomeClass(int count) :
> vec(count)
> {
> }

This supposes a default constructor, of course.

> If it is polymorphic:

> SomeClass::SomeClass(int count) :
> vec(count, std::shared_ptr<MyObj>(new MyObjDerived))
> {
> }

If all of the objects do belong to SomeClass, yes.

> > SomeClass::~SomeClass()

> No destructor needed at all.

But you might want to provide one anyway, for various reasons.
The default destructor is inline.

--
James Kanze

Christian Hackl <>, on 25/06/2010 01:43:58, wrote:

> Francesco S. Carta ha scritto:
>
>> [...]
>> The decision about directly storing objects or just pointers to them
>> doesn't just depend on whether they're polymorphic or not, it does
>> depend on their size too
>
> It is of course over-simplifying to make this decision depend on whether
> the class is polymorphic. More generally, you do not (that is, you
> cannot) put objects of non-copyable classes into a vector, and it is
> usually not a good idea or outright impossible for an entity class to
> support copying.
>
> So if the OP's "MyObj" is actually "DatabaseConnection" or
> "WindowFrame", then of course you store the objects as pointers.
>
> If "MyObj" is a non-entity class, then I'd say that semantics dictate
> whether to store the objects as pointers or not. If you conceptually
> need a copy, then just store objects, and put performance-related tricks
> (copy-on-write etc) into the implementation of MyObj instead of dealing
> with ownership issues outside of the class.

Well, I was oversimplifying too - polymorphism and size aren't enough,
we must take in account other issues and you correctly pointed out them.

>> - but in that case, even the choice of the container (std::vector vs
>> std::list, for example) should be pondered.
>
> Yes, that's true.
>
>> Hey, if I can dare suggesting, avoid feeding "pappa pronta"
>
> The "pappa" was far from "pronta", though! I noticed that the pappa
> the OP had already cooked for himself was quite wrong, so I had to do
> something about it. It's not like he can copy and paste it into his own
> code, but it is correct enough to serve as an example.

My bad, that statement was so sharp that it didn't really represent what
I meant. I was referring to the fact of pointing out the shared pointer
in particular, while my approach to this topic was to make the OP aware
of the issues and investigate about all the possible solutions - for
that reason, I pointed out one smart pointer which is well known to be
the wrong choice in these cases (i.e. std::auto_ptr).

[OT]
Are you the same Christian Hackl that runs on the bobsleighs?
Just out of curiosity
[/OT]

--
FSC
http://userscripts.org/scripts/show/59948