Re: Is this a shortcoming of the compiler or the C++ language?
On Jun 4, 2:43 am, LR <lr...@superlink.net> wrote:
Ramon F Herrera wrote:
On Jun 3, 5:41 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
Ramon F Herrera wrote:
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?
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.
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.)
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.
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 (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34