Construct On First Use Idiom example from FAQ

[k.w.]

The FAQ gives the following example:

Fred& x()
{
static Fred* ans = new Fred();
return *ans;
}

My question is:
What will happen if this function is called more than once?
Will a new object be created?
Will new memory be allocated?
Will the memory for the first object be leaked? (we no longer have pointer
to it)

 

[Victor Bazarov]

The FAQ gives the following example:

Fred& x()
{
static Fred* ans = new Fred();
return *ans;
}

My question is:
What will happen if this function is called more than once?

What exactly do you mean?

Will a new object be created?

Only the first time.

Will new memory be allocated?

Again, only the first time.

Will the memory for the first object be leaked? (we no longer have
pointer to it)

If you never deallocate it (which is probably true, it's hard to
pick the right time to call 'delete'), then yes, the first (and
the only) object represents a memory leak. Probably insignificant
in the whole schema of things.

V

 

[k.w.]

The FAQ gives the following example:

What exactly do you mean?

It seems that the FAQ says that this function can be called a couple of
times and it will create only one object and return a reference to it. How
is this possible? Cause every time this function is called there is a call
to operator new also.

 

[Victor Bazarov]

It seems that the FAQ says that this function can be called a couple
of times and it will create only one object and return a reference to
it. How is this possible? Cause every time this function is called
there is a call to operator new also.

A static object is *initialised* at most once during the execution
of the program. That's how static object work. What book are you
reading that doesn't explain that?

V

 

[Frank Birbacher]

Hi!

If you never deallocate it (which is probably true, it's hard to
pick the right time to call 'delete'), then yes, the first (and
the only) object represents a memory leak. Probably insignificant
in the whole schema of things.

Anyway, you can make it better:

Fred& x()
{
static Fred ans;
return ans;
}

The static instance will only be constructed once. And it will
automatically destructed at the end of the program. No leakage. No
possible failure of allocation.

Frank

 

[Victor Bazarov]

Hi!




Anyway, you can make it better:

Fred& x()
{
static Fred ans;
return ans;
}

The static instance will only be constructed once. And it will
automatically destructed at the end of the program. No leakage. No
possible failure of allocation.

In a multithreaded program (and although currently C++ does not
even acknowledge the existence of those, they do exists, you know),
destruction of static instances is not well-ordered. That's why
converting a static pointer to a dynamic object is not necessarily
making it better. If there is a failure of allocation in the 'new'
case, it's going to happen [elsewhere] in your code as well, most
likely, since the amount of memory used is only marginally less.

Now, the dynamic creation actually has additional advantages: the
possibility to use a Factory or [virtual] cloning, for example.

V

 

[k.w.]

A static object is *initialised* at most once during the execution

of the program. That's how static object work. What book are you
reading that doesn't explain that?

Thanks, I'm learning C++ from Visual Studio documentation. I prefere some
reference rather than book.
So the initialization code for static variable will simply be ignored in
subsequent calls?

 

[Victor Bazarov]

Thanks, I'm learning C++ from Visual Studio documentation. I prefere
some reference rather than book.

Sorry to be harsh like this, but that's utterly foolish. You should
get yourself a decent book and learn the principles and concepts.

So the initialization code for static variable will simply be ignored
in subsequent calls?

Yes. And there are more concepts of C++ like that that you simply
won't find in a reference manual. Do not waste your time, go get
a copy of "Accelerated C++" *now*, while some technical bookstore
is still open, if not, do it tomorrow.

V

 

[k.w.]

A static object is *initialised* at most once during the execution

Sorry to be harsh like this, but that's utterly foolish. You should
get yourself a decent book and learn the principles and concepts.


Yes. And there are more concepts of C++ like that that you simply
won't find in a reference manual. Do not waste your time, go get
a copy of "Accelerated C++" *now*, while some technical bookstore
is still open, if not, do it tomorrow.

V

OK, I'll do that thank you

 

[Pete Becker]

Hi!




Anyway, you can make it better:

Fred& x()
{
static Fred ans;
return ans;
}

The static instance will only be constructed once. And it will
automatically destructed at the end of the program. No leakage. No
possible failure of allocation.

And the possibility that the object will be accessed after it has been
destroyed.

struct S
{
~S();
};

S::~S()
{
x().do_something();
}

S s;

int main()
{
x().do_something();
return 0;
}

The static object s gets constructed before entry into main. Inside
main, the call to x() creates the internal object. After exit from
main, static objects are destroyed in reverse order of their
construction. So the internal object gets destroyed, then the
destructor for s runs, accessing the object after its destruction.

 

[Frank Birbacher]

Hi!

The static object s gets constructed before entry into main. Inside
main, the call to x() creates the internal object. After exit from main,
static objects are destroyed in reverse order of their construction. So
the internal object gets destroyed, then the destructor for s runs,
accessing the object after its destruction.

Yes. And if you place s and x in different translation units you don't
even know in which order they are destructed.

I'dont know if there is a final solution to this problem. Anyway I
dislike not deallocating objects even at the end of the program, because
destructor will not be run.

Frank

 

[BobR]

OK, I'll do that thank you

While you are looking for a book, this may interest you:

Get "Thinking in C++", 2nd ed. Volume 1&2 by Bruce Eckel
(available for free here. You can buy it in hardcopy too.):
http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html

 

[James Kanze]

[...]

If you never deallocate it (which is probably true, it's hard to
pick the right time to call 'delete'), then yes, the first (and
the only) object represents a memory leak. Probably insignificant
in the whole schema of things.

That really depends on your definition of a "leak". The
definition I've always heard is memory which isn't freed, but
that can't be accessed. By that definition, this isn't a leak,
at least not as long as you can call x.

 

[Victor Bazarov]

The FAQ gives the following example:
Fred& x()
{
static Fred* ans = new Fred();
return *ans;
}
My question is:
What will happen if this function is called more than once?

[...]

Will the memory for the first object be leaked? (we no longer have
pointer to it)

If you never deallocate it (which is probably true, it's hard to
pick the right time to call 'delete'), then yes, the first (and
the only) object represents a memory leak. Probably insignificant
in the whole schema of things.

That really depends on your definition of a "leak". The
definition I've always heard is memory which isn't freed, but
that can't be accessed. By that definition, this isn't a leak,
at least not as long as you can call x.

That's within the same program. What if the hosting environment does
not reclaim dynamic (free store) memory unless it's explicitly 'freed'?
If 'delete' is never called, the hosting environment has no idea that
the memory is accessible and will never reuse it. That's a leak. And
if there exists a definition of a leak that is legitimate, then in
general, there is a leak, at least in my book.

V

 

[James Kanze]

k.w. wrote:
The FAQ gives the following example:
Fred& x()
{
static Fred* ans = new Fred();
return *ans;
}
My question is:
What will happen if this function is called more than once?

[...]

Will the memory for the first object be leaked? (we no longer have
pointer to it)
If you never deallocate it (which is probably true, it's hard to
pick the right time to call 'delete'), then yes, the first (and
the only) object represents a memory leak. Probably insignificant
in the whole schema of things.

That really depends on your definition of a "leak". The
definition I've always heard is memory which isn't freed, but
that can't be accessed. By that definition, this isn't a leak,
at least not as long as you can call x.

That's within the same program.

I didn't say that.

What if the hosting environment does
not reclaim dynamic (free store) memory unless it's explicitly 'freed'?

Then the hosting environment is broken, and you can't use a
number of useful idioms on it. I don't know of any "hosted"
environment where this is the case, however.

If 'delete' is never called, the hosting environment has no idea that
the memory is accessible and will never reuse it. That's a leak. And
if there exists a definition of a leak that is legitimate, then in
general, there is a leak, at least in my book.

I'm having trouble parsing that last sentence. If the hosting
environment doesn't reclaim all of the resources used by your
program when the program exits, then the hosting environment
leaks resources. No disagreement there.