On 4/15/21 2:33 PM, Adriano dos Santos Fernandes wrote:

I have tested with common/classes/init.cpp and this solved the specific
problem I had with Boost.Test:

Cleanup global __attribute__ ((init_priority (2000)));
As far as I can see from documentation init_priority works only inside
simgle file. It might affect global order as side effect but (correct me
if I'm wrong) nobody guarantees cross-file order of ctors (and dtors -
actually we care about it).

As I said, documentation is very brief (bad) and I had the same doubts.

But tested with clang, it works across translation units.

What about gcc?


I had defined objects with init_priority 5000, 5500 and 5400 (in this
order) in two different .cpp files (one in common library, another in
yvalve specific code).

Order of construction was:

5000 (yvalve)
5000 (common)
5400 (yvalve)
5400 (common)
5500 (yvalve)
5500 (common)

Just to make sure - if you change 5000 to 6000 will that object move to the end?
If yes - that's getting really interesting.

What seems undefined here seems only yvalve/common order of same priority.

That's OK for same priority.

Can you send me full test (or patch)? I want ot test on Android.

>>>
>>> It uses global std objects which in this case have theirs destructors
>>> called after Firebird default pool are already cleaned up.
>>
>> Yes, that's really a problem. And must say that even forgetting about
>> MemPool implementation details I hardly understand how is it supposed to >> work with redefined new / delete. One can have global objects in a unit, >> implementing new and delete, but Ido not know how does standard suppose >> to have working new/delete before constructors and after destructors of
>> that objects are executed.
>>
>
> Could you give more details of what you mean?
>

I had new segfaults which may be related to what you were saying.

Boost.Test code calling new operator before init.cpp/init() was called.

That's good that it happened sooner, not later.


To make that also work, I had used this instead of relying on
InstanceControl calling init():


Certainly one should not rely on that when regular globals in use, not GlobalPtr.

----
class Init
{
public:
    Init()
    {
        init();
    }
};

Init initGlobal __attribute__ ((init_priority (2000)));

It should be given init_priority 0 or 1, that code must execute very-very first.




Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to