Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Implicit Destructor Names (AST)

In the example 'C c= f();' both the constructor and the function call are part of the
AST. The constructor is bound to the declarator via an implicit name.
Markus.

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alena Laskavaia
> Sent: Tuesday, September 14, 2010 8:06 PM
> To: Doug Schaefer
> Cc: CDT General developers list.
> Subject: Re: [cdt-dev] Implicit Destructor Names (AST)
> Importance: Low
> 
> 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
> >>
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> 


Back to the top