Re: [cdt-dev] Implicit Destructor Names (AST)

[Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx>]

Asides from that is intention to add just definition of the destructor
or the implicit call also?
Implicit call should be attached to the end of the block if case we
are building control flow, it should not be at the definition.

On Tue, Sep 14, 2010 at 12:31 PM, Schorn, Markus
<Markus.Schorn@xxxxxxxxxxxxx> wrote:
> The destructors will be called as a result of returning from main and as a
> result of calling std::exit.
> Markus.
>
>> -----Original Message-----
>> From: cdt-dev-bounces@xxxxxxxxxxx
>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alena Laskavaia
>> Sent: Tuesday, September 14, 2010 6:30 PM
>> To: Doug Schaefer
>> Cc: CDT General developers list.
>> Subject: Re: [cdt-dev] Implicit Destructor Names (AST)
>>
>> Contructors are, destructors are not called (or called atexit?)
>>
>> On Tue, Sep 14, 2010 at 12:04 PM, Doug Schaefer
>> <cdtdoug@xxxxxxxxx> wrote:
>> > I thought for globals they were called at the global
>> constructor time
>> > before main?
>> >
>> > On Tue, Sep 14, 2010 at 11:58 AM, Alena Laskavaia
>> > <elaskavaia.cdt@xxxxxxxxx> wrote:
>> >> Disadvantage is it is good to know when destructor is
>> actually called
>> >> for static analysis.
>> >> For globals it never actually called...
>> >> Are we adding definition only or implicit call into the AST?
>> >>
>> >> On Tue, Sep 14, 2010 at 11:53 AM, Schorn, Markus
>> >> <Markus.Schorn@xxxxxxxxxxxxx> wrote:
>> >>> My first thought was, that they should be attached to the
>> compound
>> >>> statement.
>> >>> However, that does not work for global variables. Therefore, for
>> >>> simplicity I suggest to add them to the declarator. I don't see a
>> >>> disadvantage with this approach.
>> >>>
>> >>> Markus.
>> >>>
>> >>>> -----Original Message-----
>> >>>> From: cdt-dev-bounces@xxxxxxxxxxx
>> >>>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lukas Felber
>> >>>> Sent: Tuesday, September 14, 2010 11:29 AM
>> >>>> To: CDT General developers list.
>> >>>> Subject: [cdt-dev] Implicit Destructor Names (AST)
>> >>>> Importance: Low
>> >>>>
>> >>>> Hi
>> >>>>
>> >>>> Since CDT 7.0 (I think), in code statements like 'X x;'
>> >>>> (where X is a type containing a constructor declaration) the
>> >>>> declarator x contains an implicit name which refers to X's
>> >>>> constructor. This is a very useful and also necessary feature!
>> >>>>
>> >>>> However, when considering the following code {
>> >>>>   X x;
>> >>>> }
>> >>>> one misses, beside the reference to the constructor of X, also a
>> >>>> reference to X's destructor, which, for completeness,
>> should also
>> >>>> be part of the AST.
>> >>>>
>> >>>> The question which arises here, is, where this name
>> should best be
>> >>>> contained.
>> >>>>  - The simples, but also a bit incorrect option is to
>> put the name
>> >>>> into the declarator x. This is not really the place where the
>> >>>> destructor is called, but it is the origin which causes the
>> >>>> destructor to be called at the end of the enclosing compound
>> >>>> statement
>> >>>>  - The more precise place to place the name is the end
>> of the end
>> >>>> of the enclosing compound statement (which would mean to let the
>> >>>> interface IASTCompoundStatement extend IASTImpliciteNameOwner).
>> >>>>
>> >>>> What is your opinion on this matter?
>> >>>>
>> >>>>
>> >>>> Best regards
>> >>>> Lukas Felber
>> >>>>
>> >>>> _______________________________________________
>> >>>> cdt-dev mailing list
>> >>>> cdt-dev@xxxxxxxxxxx
>> >>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> >>>>
>> >>> _______________________________________________
>> >>> cdt-dev mailing list
>> >>> cdt-dev@xxxxxxxxxxx
>> >>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> >>>
>> >> _______________________________________________
>> >> cdt-dev mailing list
>> >> cdt-dev@xxxxxxxxxxx
>> >> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> >>
>> >
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>