On Mon, Sep 7, 2015 at 3:54 PM, Jose Fonseca <jfons...@vmware.com> wrote:
> On 07/09/15 10:17, Jean-Sébastien Pédron wrote:
>>
>> On 04.09.2015 01:37, Matt Turner wrote:
>>>
>>> You need to test for this support in configure.ac. It's as simple as
>>> adding a call to AX_GCC_FUNC_ATTRIBUTE in the existing alphabetized
>>> list and then a little bit of preprocessor in src/util/macros.h.
>>
>>
>> Should the code fallbacks on atexit(3) if the attribute is not
>> supported?
>
>
> At least on Windows, with MSVC, atexit should be the right thing to do,
> since we statically link MSVC RunTime,
>
>
>> Can I use the HAVE_FUNC_ATTRIBUTE_DESTRUCTOR macro in
>>
>> ralloc.c for this purpose?
>
>
>
>
>
> For the record, another alternative (way more portable), is you have a
> simple .cpp file with a static destructior:
>
>
> class AtExit
> {
> public:
> ~AtExit() {
> // do what must be done
> }
> };
>
> AtExit atExit();
>
>
> After all, it seems wrong to use non-standard C to replicate what standard
> C++ can do.
That sounds nice and all, until you stumble over problems like
STB_GNU_UNIQUE, which makes renders C++ static destructors completely
unusable on Linux if you have even a single static variable in a
method in your C++ code.
Read up on it on Read
http://gcc.gnu.org/ml/gcc-help/2011-05/msg00450.html if you feel like
being depressed.
Unfortunately, C++ and it's many questionable implementations make up
an unpredictable beast that keeps on throwing curve-balls that makes
it no fun at all for library development.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
