David Blaikie via llvm-dev
2016-Mar-09 07:49 UTC
[llvm-dev] "Do not use Static Constructors" LLVM Coding Standard rule question
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/20160308/3350673a/attachment.html>
valery pykhtin via llvm-dev
2016-Mar-09 09:45 UTC
[llvm-dev] "Do not use Static Constructors" LLVM Coding Standard rule question
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>
mats petersson via llvm-dev
2016-Mar-09 10:31 UTC
[llvm-dev] "Do not use Static Constructors" LLVM Coding Standard rule question
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/0020f262/attachment.html>