[interfacekit] Re: oddish?

> > On Mon, 16 Feb 2004, Adi Oanca wrote:
> > 
> > > int main()
> > > {
> > > [...]
> > > lay->Invalidate(BRect(225,10,350,400));//BRegion(lay->Bounds()));
> > > [...]
> > > }
> > >
> 
>  As Ingo pointed out, this is perfectly valid C++.  I'd like to point out
> that this the above is an example of something you should try to avoid.
> Not because of the BRect->BRegion thing, but because some compilers
> (like ours) have an issue with the scope of temporaries that are used as
> arguments.  This only happens sometimes and I'm not really sure under
> what circumstances this turns into an error.  (runtime error! :-( )  But it
> is safer to do the following:
> 
> BRect rect(225,10,350,400);
> lay->Invalidate(rect);

According to Stroustrup, this is complicated. 
Explicit calling of the constructor of an Object that 
is used to initialize a const reference is allowed.

Like in this example:

void foo(const BString &);

foo(BString("test"));

As long as a temporary object is bound to a const reference,
it won't be destroyed.

But if the temporary opject is only used inside an expression,
it will be destroyed at the end of the expression. Example:

const char * str = BString("test).String();

At the end of the "BString("test).String()" expression, the
temporary BString object is destroyed, and the pointer
that was returned by String() is no longer valid, as the
object is missing.

The same applies if such a temporary object is used as
a function parameter, as long as the temporary object
is not bound to a const reference parameter.

Here the object is only temporary, and since it is used in a
full expression, it will be destroyed after the end of the full
expression. Consider this example:

void bar(const char *);

bar(BString("test").String());

A temporary BString object is created, initalized with "test".
Then a pointer to the (copy) of the string inside the BString
object is returned by the String() function, and pushed on the
stack. Now the expression is evaluated, and the temporary
BString object is destroyed. Now the function bar() is executed,
using the pointer that is on the stack, but no longer valid since
the temporary object was already destroyed.


Hope that helps!

Marcus

Other related posts: