This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: C++ Evaluation Order


On Tue, 19 Dec 2000 15:26:52 -0500, you wrote:

>My GCC version:
>
>mlepage@kafka:/tmp/bug$ gcc -v
>Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
>gcc version 2.95.2 19991024 (release)
>
>This line of code crashes at runtime:
>
>    g_map[pFoo->getIdentifier()].reset(pFoo.release());
>
>Important type details:
>
>    gmap is std::map<int, boost::shared_ptr<Foo> >
>    pFoo is std::auto_ptr<Foo>
>
>Therefore, the above line of code gets the map item keyed with the
>appropriate identifier (creating it if necessary), then resets its
>shared pointer (deleting any existing Foo if its reference count reaches
>zero) to the released auto_ptr (taking ownership of that Foo object).
>
>My understanding is that pFoo->getIdentifier() should be called before
>pFoo.release(). However, I am finding that pFoo.release() is being
>called before pFoo->getIdentifier(), prematurely deleting the object, so
>that the call to pFoo->getIdentifier() crashes with a SIGSEGV.

Your understanding is wrong. In C++, operator . doesn't require any
particular order of evaluation of its operands.

>Marc A. Lepage

Dima

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]