[llvm-dev] "Do not use Static Constructors" LLVM Coding Standard rule question

[valery pykhtin via llvm-dev]

Thanks, this is a good reasoning, will avoid static local objects.

Valery
9 марта 2016 г. 1:31 PM пользователь "mats petersson" <
mats at planetcatfish.com> написал:

> These type of constructs are less than ideal if you have something that
> uses LLVM as a library in a "long running" application (e.g. imagine
> something like photo editor that compiles "filters", and a user that loads
> the application on monday, and closes it on the following thursday) , as
> there is no (trivial) way to know that this stringmap exists, or that it
> may need cleaning out between two compilations, for example. The risk with
> such constructs is that they build up over time, and appear to be "memory
> leaks".
>
> --
> Mats
>
> On 9 March 2016 at 09:45, valery pykhtin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Right, but it produces a mem leak, I'm not sure what is worse :-)
>>
>> On Wed, Mar 9, 2016 at 10:49 AM, David Blaikie <dblaikie at gmail.com>
>> wrote:
>>
>>> a static local still produces a static dtor, though
>>>
>>> One of the ways you can get around this is with a deliberate non-cleanup:
>>>
>>> const foo &getFoo() {
>>>   static const foo &f = *new foo();
>>>   return f;
>>> }
>>>
>>> that way no global dtor runs. Obviously only works if you don't need
>>> foo's dtor to run.
>>>
>>> On Tue, Mar 8, 2016 at 11:42 PM, Craig Topper via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> I believe the rule is only for global variables. At least that's what
>>>> the first sentence in the section says.
>>>>
>>>> "Static constructors and destructors (e.g. global variables whose types
>>>> have a constructor or destructor) should not be added to the code base, and
>>>> should be removed wherever possible."
>>>>
>>>> On Tue, Mar 8, 2016 at 10:52 PM, valery pykhtin via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm new here and have a question about the rule in title. Is the
>>>>> following use case also prohibited?
>>>>>
>>>>> int findNameId(StringRef Name)
>>>>> {
>>>>>    static StringMap<int> Map = createSomeIDMap();
>>>>>    return Map.lookup(Name);
>>>>> };
>>>>>
>>>>> It seems it isn't influence startup time and doesn't create
>>>>> initialization order problems. Clang isn't complaining about it with
>>>>> -Wglobal-constructor flag.
>>>>>
>>>>> I'm asking because under some interpretation of rule wording it can be
>>>>> called static constructor too.
>>>>>
>>>>> Thanks,
>>>>> Valery
>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ~Craig
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160309/d599e985/attachment-0001.html>