Re: Why people use "new" & "delete" too much?!!
On Jul 6, 8:19 am, "Somebody" <someb...@cox.net> wrote:
<acehr...@gmail.com> wrote in message
news:c0357384-87f2-46c7-a874-3a498f73e4a7@m44g2000hsc.googlegroups.com...
On Jul 5, 1:13 pm, "Somebody" <someb...@cox.net> wrote:
Still, I agree with you, people over use new and delete. I
recently saw a class library written in C++ that tried to
be all C#'ish and required you to write code like:
classa->InsertItem(new classB(param1));
classa->InsertItem(new classC(param2));
*STUPID*...
It's not obvious what you say that. Is it because the
dynamic objects are not handed to smart pointers right away?
Or do you propose something like the following?
classa->InsertItem(&classB(param1));
classa->InsertItem(&classC(param2));
You realize that the temporaries would be terminated too
soon to be useful?
Plus, that hurts performance.
Compared to what? If it's needed, then there is no alternative.
Well, let me de-anonimize the code a bit :)...
They had a bunch of stuff like:
ctrl->InsertItem(new ButtonTypeA(param1, param2));
ctrl->InsertItem(new ButtonTypeB(param3, param4));
ctrl->InsertItem(new ButtonTypeC(param4, param5));
So they had a UI control, and they were inserting items into
it. ButtonTypeX was a class *the class library* defined... not
something that a *user* of the class library would (or could)
define.
But he could almost certainly define a class which derived from
it, and use that instead.
What I was saying... was I failed to see why I should do the
dirty work for the library and not only determine what class
to use, but also to allocate it for them. They should
determine whether to create the internal ButtonTypeA,
ButtonTypeB, ButtonTypeC, etc. in some other way (like a param
for example)...
It's very likely that all three calls above invoke the same
InsertItem. Even if they don't, it's almost certain that the
user code could derive from the different ButtonType's, and pass
an instance of the derived class, rather than the base class.
so I'd rather see something like:
ctrl->InsertItem(param1, param2);
ctrl->InsertItem(param3, param4);
ctrl->InsertItem(param4, param5);
or
ctrl->InsertButtonTypeA(param1, param2);
ctrl->InsertButtonTypeB(param3, param4);
ctrl->InsertButtonTypeC(param4, param5);
or
ctrl->InsertItem(TYPE_A, param1, param2);
ctrl->InsertItem(TYPE_B, param3, param4);
ctrl->InsertItem(TYPE_C, param4, param5);
Like other posters said, that style of code is C#'ish or
Java'ish... it is not typical C++ style.
It's very typical C++ where polymorphism and arbitrary lifetime
is involved, which is almost certainly the case here.
C++ is a multi-paradigm language. There are cases when the
above paradigm is appropriate, C++ supports it, and it should be
used in such cases.
Unless you are doing some type of class factory type
thing.
Allocating memory is slow... which is why this particular UI
library was commonly regarded as having poor performance.
Practically speaking, things like buttons in a GUI must have
arbitrary lifetime; they can't be automatic variables. So if
you don't do the new, the library must. And you immediately
loose the flexibility of deriving from the object. And of
course, things like Button's typically also have identity; if
you attach an event handler to one instance, but a copy receives
the event, then your code isn't going to work.
--
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