new of an object without assigning it to any variable

[Jeff Flinn]

Why would a new of object be created without assigning it to any of variable?

new A;

Microsoft MFC uses this approach, as does many of the myriad of controls on
sites like codeguru and code project. The resultant lack of clearly
specified ownership IMO, contributes to many of the difficulties in
implementing MFC apps.

Jeff F

 

[Stephen M. Webb]

Why would a new of object be created without assigning it to any of variable?

new A;

You see something similar in a lot of code built on the Qt and KDE
frameworks, because the frameworks themselves provide a replacement
for language facilities such as RTTI and object lifetime control. You
will see code such as

new QListItem(this, "data");

which dynamically creates a QListItem object and adds it to "this,"
which is a QList object and will delete the QListItem at the
appropriate time.

It is not a memory leak, but it takes a lot of self-control to use
since it requires a slightly different mindset than conventional
idiomatic C++ use.

 

[Claudio Puviani]

It's a memory leak in C++.

That's a premature assumption. The object could delete itself after doing
something or it might register itself with an object manager or an event
dispatcher (and later receive a 'delete self' event). Or it may not be
intended to be deleted. Objects that are meant to live until the expiration
of the program are not considered to be a memory leak.

Claudio Puviani

 

[Kevin Goodsell]

Or if it just needs to hang around until the program completes for some
reason.

In that case, don't do it this way. It's best to never write code that
relies on the environment to clean up after your program terminates, for
a number of reasons. Not all environments do clean-up (in a reasonable
way), objects don't get destructed, you may have problems later when
your program becomes a subroutine of a larger system, etc.

If you want the object to live until the end of the program, there are a
number of possible schemes. For example, just make it an auto object in
main(), or a global object. Or a static object in a function, which
allows you more control over when it is created.

-Kevin

 

[Nils Petter Vaskinn]

In that case, don't do it this way. It's best to never write code that
relies on the environment to clean up after your program terminates, for
a number of reasons. Not all environments do clean-up (in a reasonable
way), objects don't get destructed, you may have problems later when
your program becomes a subroutine of a larger system, etc.

Not to mention that it clutters up the logs horribly if you're searching
for any other (unintentional) leak.

 

[Siemel Naran]

I use it when adding items to a hashtable that I've made. The hastable
requires a class that inherits MyNullClass. To add to the hastable I use
this:

MyHt->Put(key, new FooDataItem(ABC));

The last line calls new but doesnt assign it to any variable (it actually
doeswithin the hash table, but it doesnt appear to).

Yes, this is perfectly valid. The original post seems to be about "new
X();" without anything else. In general, it looks like a memory leak, but
as others point it need not be, as when you overload X:perator new or
operator new, or in the constructor of X store the address of X somewhere.
And of course, the original code may have been a typo for placement new.

FooDataItem *lFDI = new FooDataItem(ABC);
MyHt->Put(key, lFDI);

Which is a bit messier in my opinion. I guess this comes from writing
programs in java.

Second way is safer in general as (but you also have to use smart pointers),
but either is fine for your specific example. In the expression Put(key(),
new Foo()) the compiler may evaluate the new Foo() first and suppose that
works, then it will evaluate key() and suppose that throws an exception,
then the new Foo is never deleted. So the safe way is

std::auto_ptr<FooDataItem> lFDI ( new FooDataItem(ABC) );
MyHt->Put(key, lFDI);

and the Put function receives an auto_ptr. The use of auto_ptr or any smart
pointer in the signature of Put implies that Put takes ownership of the
object, which is good documentation.

 

[Michiel Salters]

You see something similar in a lot of code built on the Qt and KDE
frameworks, because the frameworks themselves provide a replacement
for language facilities such as RTTI and object lifetime control. You
will see code such as

new QListItem(this, "data");

which dynamically creates a QListItem object and adds it to "this,"
which is a QList object and will delete the QListItem at the
appropriate time.

It is not a memory leak, but it takes a lot of self-control to use
since it requires a slightly different mindset than conventional
idiomatic C++ use.

QList is a display widget, by the way, not a container like std::list.
Another example would be
new QMessageBox( arguments..., parent_window, ... ,
Qt::WDestructiveClose );

The reason is that in a GUI, lifetime is somewhat complicated. For
instance, the QMessageBox needs to be deleted when the OK button is
pressed, but also when the parent_window is closed. The
parent_window must somehow know whether it has a QMessageBox child.
Qt will handle this memory management for you if you use its
ownership model. A typical dialog constructor will create the layout
by creating a number of widgets, and simply throw away the return
value of the new's of all fixed widgets (e.g. labels, lines).

Regards,
Michiel Salters

 

[Bill Seurer]

In that case, don't do it this way. ...

I agree. But back to the start of this subthread it's not necessarily a
memory leak.