There is no problem, you seem to use wrong things in your private code
and are assuming there is bugs in the pubic code.
Adriano
Em 07/05/2016 05:36, Dimitry Sibiryakov escreveu:
> 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.
>
------------------------------------------------------------------------------
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
