Is this a shortcoming of the compiler or the C++ language?

[Ramon F Herrera]

I have some code like this:

RadioButtonGroup *empty_vector = new RadioButtonGroup();
ListOfRadioButton.push_back(*empty_vector);

Coming from the Java camp, I keep on trying to write the above as
follows:

ListOfRadioButton.push_back(new RadioButtonGroup());

but my compiler (MSVC++) doesn't allow me. Is that behavior sanctioned
by the standard?

-RFH

 

[Andrew Kerr]

I have some code like this:

RadioButtonGroup *empty_vector = new RadioButtonGroup();
ListOfRadioButton.push_back(*empty_vector);

Coming from the Java camp, I keep on trying to write the above as
follows:

ListOfRadioButton.push_back(new RadioButtonGroup());

but my compiler (MSVC++) doesn't allow me. Is that behavior sanctioned
by the standard?

You must not attempt to use parentheses for the default constructor when
calling the new operator. Observe:

ListOfRadioButton.push_back(new RadioButtonGroup); // does what you want

If however you are passing arguments to the constructor, you would use
the typical syntax as also seen in Java:

// also does what you want.
ListOfRadioButton.push_back(new RadioButtonGroup(arg));

 

[Ramon F Herrera]

> You must not attempt to use parentheses for the default constructor when
> calling the new operator. Observe:

You just answered my next question, Andrew.

Thanks,

-Ramon

 

[Ramon F Herrera]

What behaviour? Not allowing you to violate the type requirement? Your
'ListOfRadioButton' is likely a list of *instances*. You're trying to
stick a pointer there. Make your 'ListOfRadioButton' contain the actual
pointers, and the compiler will let you. So, your code should be either

RadioButtonGroup *empty_vector = new RadioButtonGroup();
ListOfRadioButton.push_back(empty_vector); // NO ASTERISK!!!

or

ListOfRadioButton.push_back(new RadioButtonGroup());

You could, of course, do

ListOfRadioButton.push_back(* (new RadioButtonGroup()));

or simply

ListOfRadioButton.push_back(RadioButtonGroup());

(no need for 'new'). I guess you need to unlearn some habits Java
pushed on you, like the desire to stick 'new' all over the place.

Victor:

Thank you very much for your recommendations. Some of the suggested
statements you propose are not being accepted by the compiler. I will
post a full example, because this is driving me nuts and would like to
make some sense out of it. What I have so far is black box magic. I
should try gcc as well.

-Ramon

 

[LR]

Victor:

Thank you very much for your recommendations. Some of the suggested
statements you propose are not being accepted by the compiler. I will
post a full example, because this is driving me nuts and would like to
make some sense out of it. What I have so far is black box magic. I
should try gcc as well.

-Ramon

BTW, should you insist on doing something like
typedef std::vector<RadioButton> RadioButtonGroup;
std::vector< RadioButtonGroup* > ListOfRadioButtonGroup;
and then
ListOfRadioButtonGroup.push_back( new RadioButtonGroup );

remember to delete everything in ListOfRadioButtonGroup before it goes
out of scope. Because unlike,
typedef std::vector<RB> RBG;
std::vector< RBG > LORBG;
and then
LORBG.push_back( RBG() );

the code with pointers may result in memory leaks, if you don't delete
what you newed, either by doing it yourself explicitly, or by use of
some smart pointer. If you do it yourself, then beware exceptions that
might take you out of scope.

But what is it you're trying to do?

Do you want
std::vector< RadioButtonGroup* > LORBG;
or
std::vector< RadioButtonGroup > LORBG;
?

If you want the former, can you explain the advantage you seek?


Perhaps the instances of RBs already exist on the stack or the heap and
all you want to do is associate them with pointers in these vectors?

But that would probably be something like..

RB aButton, bButton, cButton, dButton, eButton;
std::vector< std::vector< RB* > > LORBG;

std::vector<RB*> group1, group2;
group1.push_back(&aButton);
group1.push_back(&bButton);

group2.push_back(&cButton);
group2.push_back(&dButton);
group2.push_back(&eButton);

LORGB.push_back(group1);
LORGB.push_back(group2);

and now you don't have to worry about deleting stuff, because that will
happen when you go out of scope.


But I still feel that I don't understand what it is you're trying to
accomplish. Perhaps you could expand on that?

LR

 

[James Kanze]

We'll see. From the names, I'm guessing that RadioButtonGroup
is a GUI component; GUI components usually have identity and an
arbitrary lifetime, can't be copied, and have to be allocated
dynamically. (There are doubtlessly exceptions, but the "Java"
model happens to work well for GUI components, even if it is
less than optimal for a lot of other things.)

BTW, should you insist on doing something like
typedef std::vector<RadioButton> RadioButtonGroup;
std::vector< RadioButtonGroup* > ListOfRadioButtonGroup;
and then
ListOfRadioButtonGroup.push_back( new RadioButtonGroup );

remember to delete everything in ListOfRadioButtonGroup before
it goes out of scope.

Or not. Without knowing the intended semantics of the list,
it's hard to say.

The important thing here is to remember to delete the elements
when they are removed from the display. If you're using
ListOfRadioButtonGroup for this purpose (e.g. to hold all of the
radio button groups in a panel), then its destructor should take
care of deleting the contained elements. If the list is used
for some other purpose, however, then it should be an observer
of the buttons, and remove them from itself when they are
deleted. (Or you could make the previous deletion of the list a
precondition to deleting the buttons.)

Because unlike,
typedef std::vector<RB> RBG;
std::vector< RBG > LORBG;
and then
LORBG.push_back( RBG() );

the code with pointers may result in memory leaks,

The memory leaks are easily handled by a garbage collector, but
GUI components often have deterministic lifetimes, and require
the destructor to be called even if there were no memory
management problems. (Probably the biggest single problem in
Java's Swing is that JWindow.dispose() doesn't propagate to the
contained elements. Which can cause serious memory leaks in
Java, unless you explicitly work around it.)

if you don't delete what you newed, either by doing it
yourself explicitly, or by use of some smart pointer. If you
do it yourself, then beware exceptions that might take you out
of scope.

But what is it you're trying to do?

Do you want
std::vector< RadioButtonGroup* > LORBG;
or
std::vector< RadioButtonGroup > LORBG;
?

If you want the former, can you explain the advantage you seek?

If the latter, can you explain how it's going to work if
RadioButtonGroup is not copiable (which is usually the case for
well designed GUI components)?

Perhaps the instances of RBs already exist on the stack or the
heap and all you want to do is associate them with pointers in
these vectors?

I don't think that there is ever a case where you would
construct a GUI component on the stack. Normally, they have to
be constructed (or at least used) in the GUI event thread, and
you can't sit around there waiting until they are no longer
needed; you have to return in order to handle new events, where
as the GUI component has to live as long as it is displayed on
the screen. (For that matter, there's a good chance that it
can't be displayed until you return from the function, since
display, which affects many different components, is triggered
by an event which can only be processed after you've returned
from the function.)

 

[James Kanze]

You must not attempt to use parentheses for the default
constructor when calling the new operator.

Why not?

Observe:

ListOfRadioButton.push_back(new RadioButtonGroup); // does what you want

If RadioButtonGroup has a default constructor. If
RadioButtonGroup is a POD, it creates an uninitialized
RadioButtonGroup, whereas new RadioButtonGroup() creates a
default (zero) initialized one, which is almost always
preferable.

 

[LR]

If the latter, can you explain how it's going to work if
RadioButtonGroup is not copiable

No, I can't.

(which is usually the case for
well designed GUI components)?

I don't think that RadioButtonGroup is a GUI component, but a typedef
that the OP is making.

1) typedef std::vector<RadioButtonNode*> RBG;
2) typedef std::vector<RadioButtonNode> RBG;

I think the OP in thread "Is it possible to create a vector of vector?"
asked about (2). So your question is a good one.

But I don't know what a RadioButtonNode is. So I'd still like to find
out more about what the OP intends.



LR

 

[Puppet_Sock]

You could, of course, do

     ListOfRadioButton.push_back(* (new RadioButtonGroup()));

or simply

     ListOfRadioButton.push_back(RadioButtonGroup());

(no need for 'new').  I guess you need to unlearn some habits Java
pushed on you, like the desire to stick 'new' all over the place.

I like the second form much better than the first.

With the second, dtors will get called automatically
when the collection goes out of scope. (Well, I presume
that ListOfRadioButton behaves the way the STD list does.)

With the first, in order to avoid a resource leak,
each member of the collection will have
to have its address taken, and that address passed to
delete. And the code better not have any mixture of
the two, or there's going to be a call to delete on mem
that wasn't gotten with new.
Socks