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

[Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx>]

I am not sure what is you point. We are talking about actual AST and
actual calls.
If I have to write an extra semantics analyzer to determine what
constructors are called and where descructor is called it is fine as
long as we know that it is not part of an AST.
Btw why was it needed originally? If we follow same logic that it is
defined in standard why even bother having it?

On Tue, Sep 14, 2010 at 1:07 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
> That should be defined in the C++ spec, no?
>
> On Tue, Sep 14, 2010 at 12:53 PM, Alena Laskavaia
> <elaskavaia.cdt@xxxxxxxxx> wrote:
>> And how do I suppose to know the order?
>>
>> On Tue, Sep 14, 2010 at 12:51 PM, Schorn, Markus
>> <Markus.Schorn@xxxxxxxxxxxxx> wrote:
>>> The function references in the AST will not occur in the order they are
>>> actually executed. A simple example is 'C c= f();', where the function call
>>> is executed before the call to the constructor. The same holds basically for
>>> any overloaded binary operator.
>>> Therefore I don't see the requirement that the implicit names in the ast have
>>> to reflect the order of execution.
>>> Markus.
>>>
>>>
>>>> -----Original Message-----
>>>> From: laskava@xxxxxxxxx [mailto:laskava@xxxxxxxxx] On Behalf
>>>> Of Alena Laskavaia
>>>> Sent: Tuesday, September 14, 2010 6:42 PM
>>>> To: Schorn, Markus
>>>> Cc: CDT General developers list.
>>>> Subject: Re: [cdt-dev] Implicit Destructor Names (AST)
>>>>
>>>> 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
>>>> >>
>>>> >
>>>>
>>> _______________________________________________
>>> 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
>>
>