12.04.2016 15:31, Dimitry Sibiryakov wrote:
> On the other hand we can restore logic described in declaration of
> system_error and
> eliminate using of dynamic strings inside of this class. In this case
> StaticStatusVector
> should be fine.
I will commit a different solution. Testing it now.
On the other hand we can restore logic described in declaration of
system_error and
eliminate using of dynamic strings inside of this class. In this case
StaticStatusVector
should be fine.
--
WBR, SD.
--
Find a
12.04.2016 13:56, Dmitry Yemanov wrote:
> Alex, can you suggest anything better than DynamicStatusVector in that
> place?
May be status_exception can have move constructor that will transfer
ownership of
dynamic strings to "more global" object letting them survive destruction of
temporary
o
12.04.2016 11:01, Dimitry Sibiryakov wrote:
>> I believe some other kind of status holder should be used there.
>> DynamicStatusVector maybe?
>
> Probably. I don't know status hierarchy well. DynamicStatusVector seems to be
> obvious
> candidate, but I don't like its overhead.
Alex, can you sugg
12.04.2016 7:30, Dmitry Yemanov wrote:
> Do you know other places where this bug exists too?
I glanced through StaticStatusVector instances and it seems that this is the
only
affected place.
--
WBR, SD.
--
Find
12.04.2016 7:30, Dmitry Yemanov wrote:
> I believe some other kind of status holder should be used there.
> DynamicStatusVector maybe?
Probably. I don't know status hierarchy well. DynamicStatusVector seems to
be obvious
candidate, but I don't like its overhead.
> Do you know other places wh