Construct On First Use Idiom example from FAQ

Discussion in 'C++' started by k.w., Aug 10, 2007.

  1. k.w.

    k.w. Guest

    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)
    k.w., Aug 10, 2007
    #1
    1. Advertising

  2. 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?


    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
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Aug 10, 2007
    #2
    1. Advertising

  3. k.w.

    k.w. Guest

    >> 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?



    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.
    k.w., Aug 10, 2007
    #3
  4. 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?

    >>
    >> 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.


    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
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Aug 10, 2007
    #4
  5. Hi!

    Victor Bazarov schrieb:
    > 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
    Frank Birbacher, Aug 10, 2007
    #5
  6. Frank Birbacher wrote:
    > Hi!
    >
    > Victor Bazarov schrieb:
    >> 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.


    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
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Aug 10, 2007
    #6
  7. k.w.

    k.w. Guest

    > 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?
    k.w., Aug 10, 2007
    #7
  8. k.w. wrote:
    >> 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.


    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
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Aug 10, 2007
    #8
  9. k.w.

    k.w. Guest

    >>> 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.

    >
    > 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



    OK, I'll do that :) thank you
    k.w., Aug 10, 2007
    #9
  10. k.w.

    Pete Becker Guest

    On 2007-08-10 09:45:07 -0400, Frank Birbacher <> said:

    > Hi!
    >
    > Victor Bazarov schrieb:
    >> 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.
    >


    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.

    --
    Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
    Standard C++ Library Extensions: a Tutorial and Reference
    (www.petebecker.com/tr1book)
    Pete Becker, Aug 10, 2007
    #10
  11. Hi!

    Pete Becker schrieb:
    > 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
    Frank Birbacher, Aug 10, 2007
    #11
  12. k.w.

    BobR Guest

    k.w. <> wrote in message...
    > >
    > > 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


    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

    --
    Bob R
    POVrookie
    BobR, Aug 10, 2007
    #12
  13. k.w.

    James Kanze Guest

    On Aug 10, 3:17 pm, "Victor Bazarov" <> wrote:
    > 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.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 11, 2007
    #13
  14. James Kanze wrote:
    > On Aug 10, 3:17 pm, "Victor Bazarov" <> wrote:
    >> 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. 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
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Aug 12, 2007
    #14
  15. k.w.

    James Kanze Guest

    On Aug 12, 5:21 pm, "Victor Bazarov" <> wrote:
    > James Kanze wrote:
    > > On Aug 10, 3:17 pm, "Victor Bazarov" <> wrote:
    > >> 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.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 12, 2007
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sonali
    Replies:
    2
    Views:
    4,887
    Ryan Stewart
    Mar 3, 2004
  2. Chris  Cahoon
    Replies:
    3
    Views:
    882
    James Kanze
    Jun 13, 2007
  3. Replies:
    30
    Views:
    815
    Eduardo O. Padoan
    Feb 5, 2008
  4. Mukesh
    Replies:
    4
    Views:
    606
    Paul N
    Mar 26, 2010
  5. Sam Roberts
    Replies:
    15
    Views:
    277
    Sam Roberts
    Feb 7, 2005
Loading...

Share This Page