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

[valery pykhtin via llvm-dev]

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160309/c10b192d/attachment.html>