07.05.2016 0:17, Adriano dos Santos Fernandes wrote:
> Define the problem.
>
> I do not see this unpredictable behavior.
Usual code for such methods are:
XXX YYY:toXXX()
{
return XXX(*this);
}
Note that constructor here uses default pool.
Now look at calling code:
XXX a(anyPool);
a = z.toXXX();
Here, on contrary, constructor with a pool is used.
Now there are three possibilities:
1) Compiler is dumb and we have overhead of two allocations;
2) Compiler use copy elision and do it right - we have one allocation from
anyPool;
3) Compiler use copy elision and do it wrong - we have in 'a' buffer allocated
from
default pool and this is a bug waiting for time X.
> There is already now methods returning:
>
> const string&
> string
> PathName
Yes, and because of possibility 3) they are dangerous and should be avoided.
--
WBR, SD.
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
