array of TCheckBox - is it possiible?

[Encapsulin]

Hello there,
i need to create some(possible 2) checkboxes:

TCheckBox *aCb = new TCheckBox(this);
aCb->Parent = this;
aCb->Left = 20;
aCb->Top = 120;

TCheckBox *aCb1 = new TCheckBox(this);
aCb1->Parent = this;
aCb1->Left = 40;
aCb1->Top = 120;

But the problem is i don't know,how much checkboxes will be created,
possible X.
I do not shure, is it possible to create dynamic array of CheckBoxes?
The following code isn't correct:

int X=16;
TCheckBox[X] *aCb = new[X] TCheckBox(this);
for(int i=0;i<X;i++)
aCb = new TCheckBox(this);

So, is it possible to create array of TCheckBox?
Thank you.

 

[Sensei]

So, is it possible to create array of TCheckBox?

Yes, as you can have arrays of any kind... What you do with your array
and what it may mean, it's up to you.

 

[Alan Johnson]

I do not shure, is it possible to create dynamic array of CheckBoxes?

Use std::vector. See http://www.sgi.com/tech/stl/Vector.html

-Alan

 

[Zara]

Use std::vector. See http://www.sgi.com/tech/stl/Vector.html

-Alan

If this TCheckBox you mention is a VCL (Borland) control, you may not
use std::vector<TCheckBox>. One option (I use it) is
std::vector<std::auto_ptr<TCheckBox> >, which makes all cleaning up easy

 

[Alan Johnson]

If this TCheckBox you mention is a VCL (Borland) control, you may not
use std::vector<TCheckBox>. One option (I use it) is
std::vector<std::auto_ptr<TCheckBox> >, which makes all cleaning up easy

auto_ptr is not suitable for storage in standard containers.
Specifically, it doesn't meet the CopyConstructible or Assignable
concept requirements. It may _seem_ to work with some STL
implementations, but it is not a safe thing to do. Something like
boost::shared_ptr is more appropriate for storage in containers.

As for TCheckBox, I don't know anything about it, so I can't say whether
it meets the requirements for storage in standard containers.

-Alan

 

[Old Wolf]

If this TCheckBox you mention is a VCL (Borland) control, you may
not use std::vector<TCheckBox>. One option (I use it) is
std::vector< std::auto_ptr<TCheckBox> >

Using auto_ptr in a vector is treading on very thin ice. Read
the section titled "Things Not To Do, and Why Not To Do Them" at
http://www.gotw.ca/publications/using_auto_ptr_effectively.htm

It would be safe to have std::vector< boost::shared_ptr<TCheckBox> >
but boost and Borland don't mix too well.

My preferred option would be to have std::vector<TCheckBox *>
as a member of an object, and delete the pointers in the
object's destructor.

Note (Borland-specific): In this case, the best solution is
to set the checkbox's Owner property to 'this' . Then
the parent object will automatically delete the pointer
when the parent object is deleted.

 

[Zara]

Old Wolf wrote:
(...)

Using auto_ptr in a vector is treading on very thin ice. Read
the section titled "Things Not To Do, and Why Not To Do Them" at
http://www.gotw.ca/publications/using_auto_ptr_effectively.htm

Thank's for the link. As always, one is never the first to do
something. I created a "const_auto_ptr" class myself, thinking I was
cute. Ha! And I seee Borland doesn´t warn of this misuse.

It would be safe to have std::vector< boost::shared_ptr<TCheckBox> >
but boost and Borland don't mix too well.

Really! Boralnd CBuilderX Personal comes with a copy of Boost library
and no way to make it work with the compiler.

My preferred option would be to have std::vector<TCheckBox *>
as a member of an object, and delete the pointers in the
object's destructor.

Generically:

template <typename T>
class VCLArray
{
/*...*/
private:
typedef T* elementType;
typedef std::vector<elementType> arrayType;
arrayType data;
/*...*/
public:
/*...*/
~VCLArray()
{
for (typename arrayType::iterator
i=data.begin();i!=data.end();++i)
delete *i;
}
/*...*/
};

Note (Borland-specific): In this case, the best solution is
to set the checkbox's Owner property to 'this' . Then
the parent object will automatically delete the pointer
when the parent object is deleted.

Only if this derives from TComponent