opencxx-users

[Opencxx-users] Code reorganization, Win32 compiler

[Marc O. i L. <mar...@tr...>]

Hi,

We are going to use OpenC++ in a project, but we need to have a working 
Win32 version. Creating a driver for use in VisualStudio.NET is not 
easy, as the editor does not allow changing the compiler executable. So 
I've had to separate OpenC++ in two parts, a library and a driver. This 
requires very small modifications to the project, and can be a step 
towards having a more modular code organization.

I send you a patch (taken using cvs diff -u) with the required changes, 
and I plan on having a Windows driver in short time.

Regards,

Marc Ordinas i Llopis

Re: [Opencxx-users] About to merge

[Grzegorz J. <ja...@he...>]

On Wed, 17 Sep 2003, Alexandre Tolmos wrote:

> Merge completed. Champagne ! :-)

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] Makefile.am fixes

[Grzegorz J. <ja...@he...>]

My last e-mail requires a fix. Sorry:

On Wed, 17 Sep 2003, Grzegorz Jakacki wrote:

[...]
> With decomposition into 'Walker' (abstract iface) and 'OpencxxWalker'
> (implementation) I can can be sure that whatever (derived) object is at
> the end of 'OpencxxWalker*' pointer, it behaves just like 'OpencxxWalker'
> object.
>
> On the other hand (new) 'Walker' is abstract, so there is nothing
> like "Walker object", consequently 'OpencxxWalker*' pointer does not

like "Walker object", consequently 'Walker*' pointer does not

> imply any assumptions about the pointee behaviour.

BR
Grzegorz

>
> Surely current walker hierarchy in OpenC++ violates LSP, but it should
> not take much to get it straight.
>
> Have I convinced you?
>
> Greetings
> Grzegorz
>
> ##################################################################
> # Grzegorz Jakacki                       Huada Electronic Design #
> # Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
> # tel. +86-10-64365577 x2074               Beijing 100015, China #
> # Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
> ##################################################################
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
>

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] About to merge

[Alexandre T. <kt...@fr...>]

Merge completed. Champagne ! :-)

Le mercredi, 17 sep 2003, =E0 10:57 Europe/Paris, Grzegorz Jakacki a =20
=E9crit :

> On Wed, 17 Sep 2003, Alexandre Tolmos wrote:
>
>> Hello all,
>>
>> I'm about to merge my work, so please don't branch from the main =20
>> branch
>> or modify it.
>
> It is safe to branch/checkout, but only from the timepoints before =
Alex
> first commit, e.g.:
>
>     cvs update -D '17 Sep 2003 09:57:21 +0200'
>     cvs tag -b YOUR_SANDBOX_TAG
>
> until Alex lets us know that he is done.
>
> I am very glad to see this commit happening. Apart of other fixes and
> clean-ups it includes MacOSX port, a project that Alex kept pushing
> despite towering obstacles. Thanks for your contribution, Alex!
>
> Best regards
> Grzegorz

------------------------------------------------------------------------=20=

-
Alexandre Tolmos
E-mail:=A0...@fr...
ICQ: 92964905
------------------------------------------------------------------------=20=

-
"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
------------------------------------------------------------------------=20=

-

Re: [Opencxx-users] About to merge

[Grzegorz J. <ja...@he...>]

On Wed, 17 Sep 2003, Alexandre Tolmos wrote:

> Hello all,
>
> I'm about to merge my work, so please don't branch from the main branch
> or modify it.

It is safe to branch/checkout, but only from the timepoints before Alex
first commit, e.g.:

    cvs update -D '17 Sep 2003 09:57:21 +0200'
    cvs tag -b YOUR_SANDBOX_TAG

until Alex lets us know that he is done.

I am very glad to see this commit happening. Apart of other fixes and
clean-ups it includes MacOSX port, a project that Alex kept pushing
despite towering obstacles. Thanks for your contribution, Alex!

Best regards
Grzegorz

>
> Thanks.
>
> ------------------------------------------------------------------------
> -
> Alexandre Tolmos
> E-mail:=A0...@fr...
> ICQ: 92964905
> ------------------------------------------------------------------------
> -
> "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
> ------------------------------------------------------------------------
> -
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
>

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] About to merge

[Alexandre T. <kt...@fr...>]

Hello all,

I'm about to merge my work, so please don't branch from the main branch =20=

or modify it.

Thanks.

------------------------------------------------------------------------=20=

-
Alexandre Tolmos
E-mail:=A0...@fr...
ICQ: 92964905
------------------------------------------------------------------------=20=

-
"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
------------------------------------------------------------------------=20=

-

Re: [Opencxx-users] Makefile.am fixes

[Grzegorz J. <ja...@he...>]

On Tue, 16 Sep 2003, Yann Dirson wrote:

> On Tue, Sep 16, 2003 at 09:30:18AM +0800, Grzegorz Jakacki wrote:
> > > Yes, but that makes a modified copy of the original code, and will require
> > > updating to take advantage of any changes in the original...
> >
> > You are right. I would say that this is acceptable on this scale, but that's
> > maybe because I am getting old. Let's try again.
>
> On the scale of TranslateCast() I tend to agree (so perhaps I'm getting old
> myself as well ;), but I only used this one as an example of what I'd see
> useful with most Walker::Translate*() methods.

I see.

> > I understand that you would like to add BeforeTransalteCast(),
> > AfterTranslateCastedExpression(), BeforeTransalteCastedExpression(),
> > TranslateCastType() and TranslateCastType() to the public interface of
> > Walker. I would like to be careful about it, as changes to interfaces are
> > difficult to reverse.
> >
> > First reservation is: why do we need FIVE new interface functions? It
> > seems to me that at most two should be enough.
>
> Your demonstration below is convincing to me :)
>
> > Too many functions makes interface diffucult to comprehend.
>
> Sure, and furthermore I think the resulting code would be much slower.

I agree, but I don't think we should worry about the performance unless
this becomes an issue (e.g. somebody presents an example that runs
unacceptably slow).

> > Second: function like 'BeforeTranslateCast()' seems to be a bad candidate for public
> > iface function, as it has very complicated postcondition. If you do not
> > return some very specific Ptree, the remaining code will fail. This has to
> > be documented and understood by the client, so I would like to avoid it if
> > possible.
>
> Yes, probably its call would need to be wrapped in a check that would raise
> an exception if the postcondition is violated.  And that again would make
> the code much slower.
>
> > >From what I can see the problem originates from the fact, that
> > 'TranslateCast()' violates Single Responsibility Principle.
> [...]
> > So maybe we can go on with something like this:
> [...]
>
> That looks fine to me.  Probably most other Translate*() methods would
> benefit from such a change.

I understand that you have some specific requirements in your project that
expose a need for certain functionality in Walker and that
'TranslateCast()' is an just one example. Could you post the list of
extensions that you would like to introduce?

> > Perhaps we also can give more meaningful types to arguments of
> > TranslateCastedExpression() and TranslateCastedType().
> >
> > What do you think?
>
> That may make sense as well.  Looks like it could help to catch silly
> mistakes when writing a custom walker.
>
> > > > Looks like we came to similar conclusions.
> > > >
> > > > The code that I wrote above works, but it violates Liskov Substitution
> > > > Principle --- the user cannot be sure about the behaviour of member
> > > > function 'TranslateCast()' when it is called via Walker*.
> > >
> > > Hm - what assumptions of Walker would this code break ?
> >
> > See
> [...]
>
> I already looked up the lsp to be sure about what you meant.  As I
> understand it it refers to derivative classes causing assumptions about the
> base class not to be valid any more on the derivative class.  What I fail to
> see is which assumptions about the Walker class would the
> MyWalker::TranslateCast method as described break.

E.g. "Walker::TranslateCast() does not modify the type in a cast".

As I understand it, LSP requires that object behaviour is determined by a
type of pointer to it. With 'Walker : public MyWalker' given the 'Walker*'
pointer I cannot be sure about the behaviour of pointee --- it may happen,
that it is a 'MyWalker' object, which differs wrt. the semantics of
'TranslateCast()'.

With decomposition into 'Walker' (abstract iface) and 'OpencxxWalker'
(implementation) I can can be sure that whatever (derived) object is at
the end of 'OpencxxWalker*' pointer, it behaves just like 'OpencxxWalker'
object.

On the other hand (new) 'Walker' is abstract, so there is nothing
like "Walker object", consequently 'OpencxxWalker*' pointer does not
imply any assumptions about the pointee behaviour.

Surely current walker hierarchy in OpenC++ violates LSP, but it should
not take much to get it straight.

Have I convinced you?

Greetings
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] Makefile.am fixes

[Yann D. <yd...@us...>]

On Tue, Sep 16, 2003 at 09:30:18AM +0800, Grzegorz Jakacki wrote:
> > Yes, but that makes a modified copy of the original code, and will require
> > updating to take advantage of any changes in the original...
> 
> You are right. I would say that this is acceptable on this scale, but that's
> maybe because I am getting old. Let's try again.

On the scale of TranslateCast() I tend to agree (so perhaps I'm getting old
myself as well ;), but I only used this one as an example of what I'd see
useful with most Walker::Translate*() methods.


> I understand that you would like to add BeforeTransalteCast(),
> AfterTranslateCastedExpression(), BeforeTransalteCastedExpression(),
> TranslateCastType() and TranslateCastType() to the public interface of
> Walker. I would like to be careful about it, as changes to interfaces are
> difficult to reverse.
> 
> First reservation is: why do we need FIVE new interface functions? It
> seems to me that at most two should be enough.

Your demonstration below is convincing to me :)

> Too many functions makes interface diffucult to comprehend.

Sure, and furthermore I think the resulting code would be much slower.

> Second: function like 'BeforeTranslateCast()' seems to be a bad candidate for public
> iface function, as it has very complicated postcondition. If you do not
> return some very specific Ptree, the remaining code will fail. This has to
> be documented and understood by the client, so I would like to avoid it if
> possible.

Yes, probably its call would need to be wrapped in a check that would raise
an exception if the postcondition is violated.  And that again would make
the code much slower.

> >From what I can see the problem originates from the fact, that
> 'TranslateCast()' violates Single Responsibility Principle.
[...]
> So maybe we can go on with something like this:
[...]

That looks fine to me.  Probably most other Translate*() methods would
benefit from such a change.

> Perhaps we also can give more meaningful types to arguments of
> TranslateCastedExpression() and TranslateCastedType().
> 
> What do you think?

That may make sense as well.  Looks like it could help to catch silly
mistakes when writing a custom walker.

> > > Looks like we came to similar conclusions.
> > >
> > > The code that I wrote above works, but it violates Liskov Substitution
> > > Principle --- the user cannot be sure about the behaviour of member
> > > function 'TranslateCast()' when it is called via Walker*.
> >
> > Hm - what assumptions of Walker would this code break ?
> 
> See
[...]

I already looked up the lsp to be sure about what you meant.  As I
understand it it refers to derivative classes causing assumptions about the
base class not to be valid any more on the derivative class.  What I fail to
see is which assumptions about the Walker class would the
MyWalker::TranslateCast method as described break.

Regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
Debian-related: <di...@de...> |   Support Debian GNU/Linux:
Pro:    <yan...@fr...> |  Freedom, Power, Stability, Gratuity
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: [Opencxx-users] Makefile.am fixes

[Grzegorz J. <ja...@he...>]

On Mon, 15 Sep 2003, Yann Dirson wrote:

> On Mon, Sep 15, 2003 at 08:53:28AM +0800, Grzegorz Jakacki wrote:
> > Why not something like this:
> >
> > class MyWalker : public Walker
> > {
> > public:
> >      Ptree* TranslateCast(Ptree* exp)
> >      {
> >          Ptree exp2 = BeforeTranslateCast(exp);
> >          Ptree* e = exp2->Nth(3);
> >          Ptree* e2 = AfterTranslateCastedExpression(Translate(BeforeTranslateCastedExpression(e)));
> >          return AfterTranslateCast(new PtreeCastExpr(TranslateCastType(exp2->First()),
> >      	       	   		                Ptree::ShallowSubst(e2, e, exp2->Cdr())));
> >      }
> >
> >      ... BeforeTranslateCast(...) { ... }
> >      ... AfterTranslateCastedExpression(...) { ... }
> >      ... AfterTranslateCast(...) { ... }
> > };
> >
> > AFAIU you get the same result without adding a hook.
>
> Yes, but that makes a modified copy of the original code, and will require
> updating to take advantage of any changes in the original...

You are right. I would say that this is acceptable on this scale, but that's
maybe because I am getting old. Let's try again.

I understand that you would like to add BeforeTransalteCast(),
AfterTranslateCastedExpression(), BeforeTransalteCastedExpression(),
TranslateCastType() and TranslateCastType() to the public interface of
Walker. I would like to be careful about it, as changes to interfaces are
difficult to reverse.

First reservation is: why do we need FIVE new interface functions? It
seems to me that at most two should be enough. Too many functions makes
interface diffucult to comprehend.

Second: function like 'BeforeTranslateCast()' seems to be a bad candidate for public
iface function, as it has very complicated postcondition. If you do not
return some very specific Ptree, the remaining code will fail. This has to
be documented and understood by the client, so I would like to avoid it if
possible.

From what I can see the problem originates from the fact, that
'TranslateCast()' violates Single Responsibility Principle. It not only
calls 'Translate()' on the expression under cast, but also takes care
of copying the resulting expression if necessary. Moreover, you would like
to extend its functionality to allow cast type customization.

So maybe we can go on with something like this:

    Ptree* OpencxxWalker::TranslateCast(Ptree* exp)
    {
        Ptree* castedExp   = exp->Nth(3);
        Ptree* castedType  = exp-> ??? ;
        Ptree* castedExp1  = TranslateCastedExpression(castedExp);
        Ptree* castedType  = TranslateCastedType(castedType);

        if (castedExp == castedExp1) ...
        /* the code that creates a copy with appropariate nodes */
        /* substituted if necessary */
        /* BTW: similar code appears in many plaeces; can we factor it out? */
    }

    Ptree* OpencxxWalker::TranslateCastedExpression(Ptree* e) //new iface function
    {
        return Translate(e);
    }

    Ptree* OpencxxWalker::TranslateCastedType(Ptree* e)  //new iface function
    {
        return e;
    }

In your walker:

    class MyWalker : virtual public Walker, private OpencxxWalker
    {
    public:

        Ptree* MyWalker::TranslateCast(Ptree* e)
        {
            return AfterTranslateCast(
                       OpencxxWalker::TranslateCast(
                           BeforeTranslateCast(e)));
        }

        Ptree* MyWalker::TranslateCastedExpression(Ptree* e)
        {
            return BeforeTranslateCastedExpression(
                       OpencxxWalker::TranslateCastedExpression(
                           AfterTranslateCastedExpression(e)));
        }

        Ptree* MyWalker::TranslateCastedType(Ptree* e)
        {
            ... // things you want to do with TranslateCastType().
            ... // Rely on OpencxxWalker::TranslateCastedType() if you
            ... // want to take advantage of future changes
            ... // in Walker.
        }

    private:
        ... BeforeTranslateCast(...) { ... }
        ... AfterTranslateCastedExpression(...) { ... }
        ... AfterTranslateCast(...) { ... }

    };

Perhaps we also can give more meaningful types to arguments of
TranslateCastedExpression() and TranslateCastedType().

What do you think?

>
>
> > Looks like we came to similar conclusions.
> >
> > The code that I wrote above works, but it violates Liskov Substitution
> > Principle --- the user cannot be sure about the behaviour of member
> > function 'TranslateCast()' when it is called via Walker*.
>
> Hm - what assumptions of Walker would this code break ?

See

  * Sutter "Exceptional C++" chapter 24

  * http://www.gotw.ca/gotw/014.htm

  * http://www.objectmentor.com/resources/articles/lsp.pdf

Regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] Makefile.am fixes

[Yann D. <yd...@us...>]

On Mon, Sep 15, 2003 at 08:53:28AM +0800, Grzegorz Jakacki wrote:
> Why not something like this:
> 
> class MyWalker : public Walker
> {
> public:
>      Ptree* TranslateCast(Ptree* exp)
>      {
>          Ptree exp2 = BeforeTranslateCast(exp);
>          Ptree* e = exp2->Nth(3);
>          Ptree* e2 = AfterTranslateCastedExpression(Translate(BeforeTranslateCastedExpression(e)));
>          return AfterTranslateCast(new PtreeCastExpr(TranslateCastType(exp2->First()),
>      	       	   		                Ptree::ShallowSubst(e2, e, exp2->Cdr())));
>      }
> 
>      ... BeforeTranslateCast(...) { ... }
>      ... AfterTranslateCastedExpression(...) { ... }
>      ... AfterTranslateCast(...) { ... }
> };
> 
> AFAIU you get the same result without adding a hook.

Yes, but that makes a modified copy of the original code, and will require
updating to take advantage of any changes in the original...


> Looks like we came to similar conclusions.
> 
> The code that I wrote above works, but it violates Liskov Substitution
> Principle --- the user cannot be sure about the behaviour of member
> function 'TranslateCast()' when it is called via Walker*.

Hm - what assumptions of Walker would this code break ?

Regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
Debian-related: <di...@de...> |   Support Debian GNU/Linux:
Pro:    <yan...@fr...> |  Freedom, Power, Stability, Gratuity
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: [Opencxx-users] Makefile.am fixes

[Grzegorz J. <ja...@he...>]

On Thu, 11 Sep 2003, Yann Dirson wrote:

> On Thu, Sep 11, 2003 at 09:16:37AM +0800, Grzegorz Jakacki wrote:
> > I see. Go ahead and implement it if you think it is important, but to be
> > honest I don't think it is a cruicial feature. Implementing it involves
> > some maintenance burden (now anybody writting '$libdir' in docs should add
> > a link to directories.html to be consistient; and most likely that person
> > will not do it, because there is no mechanism or process that would
> > require him/her to do so), but we don't change docs often, so I don't see
> > a problem. I would encourage you to rather invest your time in
> > implementing your ideas about walkers, but if you think 'directories.html'
> > is a good thing, go ahead. Provided you get down to walkers afterwards :-)
>
> That's not so much work, so I can do this while we're discussing walker
> issues :)

OK

> > > > > All of this seems to be easily achieved if we can add hooks to the
> > > > > translation of arbitrary language constructs (casts, statements...)
> > > >
> > > > Right. However after you expand the existing walker you need to have a way
> > > > to coerce it back into the old functionality, so that the occ itself and
> > > > legacy applications compile. However this seems doable.
> > >
> > > Hm.  My idea was that without any hooks the behaviour would be the current
> > > one.  But it's surely both more flexible and less intrusive to provide my
> > > own walker in many cases.
> >
> > I think I did not understand what you mean by "adding hooks". Could you
> > elaborate on this?
>
> In the case of TranslateCast what I'd have needed would be a call to some
> user-defined code within TranslateCast().  AFAICT, since TranslateCast()
> calls cannot be tied to a particular class, it could not be done with the
> metaclass mechanism.  I originally thought it could probably be done if we
> could access from the metaprogram, and derive something like the Program
> instance for the file being translated.

I think this would require quite a lot design work. Current MOP models
just classes and barely touches templates and free functions. Program
metaobject is not available to metaprogram via MOP.

> But I now realize that it would be
> mostly similar, but probably less flexible than deriving the walker, so
> let's assume the latter.

I think so.

> In this case, once we're able to use a custom walker, we could add to
> TranslateCast() a call to a BeforeTranslateCast(), which the default walker
> would implement as a no-op, therefore being non-intrusive.  In the case of
> TranslateCast I don't see myself the need for running an additional
> translation, but I'll still use this example, since this is a much simpler
> method that TranslateFunctionImplementation().  A fully hooked TranslateCast
> (simplified by not avoiding useless copies, and probably missing some calls
> to ShallowSubst or similar) would give something like:
>
> Ptree* Walker::TranslateCast(Ptree* exp)
> {
>     Ptree exp2 = BeforeTranslateCast(exp);
>     Ptree* e = exp2->Nth(3);
>     Ptree* e2 = AfterTranslateCastedExpression(Translate(BeforeTranslateCastedExpression(e)));
>     return AfterTranslateCast(new PtreeCastExpr(TranslateCastType(exp2->First()),
>     	       	   		                Ptree::ShallowSubst(e2, e, exp2->Cdr())));
> }
>
> As you see that'd cause in the case of the default walker a large number of
> calls to methods just returning their argument, but that's the simplest way
> of adding hooks that I can see.

Why not something like this:

class MyWalker : public Walker
{
public:
     Ptree* TranslateCast(Ptree* exp)
     {
         Ptree exp2 = BeforeTranslateCast(exp);
         Ptree* e = exp2->Nth(3);
         Ptree* e2 = AfterTranslateCastedExpression(Translate(BeforeTranslateCastedExpression(e)));
         return AfterTranslateCast(new PtreeCastExpr(TranslateCastType(exp2->First()),
     	       	   		                Ptree::ShallowSubst(e2, e, exp2->Cdr())));
     }

     ... BeforeTranslateCast(...) { ... }
     ... AfterTranslateCastedExpression(...) { ... }
     ... AfterTranslateCast(...) { ... }
};

AFAIU you get the same result without adding a hook.

>
>
> > > or to call the current one and manipulate the result Ptree
> > > again (useless copy of (part of) the Ptree).
> >
> > What if you provide your own walker, which derives or delegates to the
> > existing walker? In your implementation of
> > 'YourWalker::TranslateFunctionImplementation()' you could either call the
> > original walker (and possibly postprocess the result) or not call it and
> > do all processing by yourself. Is this what you are looking for?
>
> Yes, the same could possibly be done by pre-processing and post-processing
> the Ptrees manipulated by the default walker, and I now realize that it
> would be much more lightweight to do so than to add all those hooks.

Looks like we came to similar conclusions.

The code that I wrote above works, but it violates Liskov Substitution
Principle --- the user cannot be sure about the behaviour of member
function 'TranslateCast()' when it is called via Walker*.

The better approach requires separating implementation and interface of
Walker, e.g.:

    class Walker
    {
        ... interface only, all functions pure virtual, no ctor, virtual dtor
    };

    class OpencxxWalker : public Walker
    {
        ... guts of present Walker
    };

(this was suggested some time ago by guys from VFiasco project, whom BTW I
still own a long reply to very insighful e-mail).

With this in place we could do:

    class MyWalker : public Walker
    {
    private:
        OpencxxWalker impl_;
    public:
        ... delegate all functions to impl_ except TranslateCast
    };

This agrees with LSP, but requires lots of work to delegate all the member
functions. However this should work OK:

    class OpencxxWalker : virtual public Walker { ... }
                          ^^^^^^^

    class MyWalker : virtual public Walker
                   , private OpencxxWalker
    {
        Ptree* TranslateCast(Ptree*) { ... }
    };


I think this change would go along well with Walker factory being
implemented by Vladimir --- after the code is fixed to use factory, the only
place where we need to make it aware of OpencxxWalker is the factory class.

BR
GJ

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] Makefile.am fixes

[Yann D. <yd...@us...>]

On Thu, Sep 11, 2003 at 09:16:37AM +0800, Grzegorz Jakacki wrote:
> I see. Go ahead and implement it if you think it is important, but to be
> honest I don't think it is a cruicial feature. Implementing it involves
> some maintenance burden (now anybody writting '$libdir' in docs should add
> a link to directories.html to be consistient; and most likely that person
> will not do it, because there is no mechanism or process that would
> require him/her to do so), but we don't change docs often, so I don't see
> a problem. I would encourage you to rather invest your time in
> implementing your ideas about walkers, but if you think 'directories.html'
> is a good thing, go ahead. Provided you get down to walkers afterwards :-)

That's not so much work, so I can do this while we're discussing walker
issues :)


> > > > All of this seems to be easily achieved if we can add hooks to the
> > > > translation of arbitrary language constructs (casts, statements...)
> > >
> > > Right. However after you expand the existing walker you need to have a way
> > > to coerce it back into the old functionality, so that the occ itself and
> > > legacy applications compile. However this seems doable.
> >
> > Hm.  My idea was that without any hooks the behaviour would be the current
> > one.  But it's surely both more flexible and less intrusive to provide my
> > own walker in many cases.
> 
> I think I did not understand what you mean by "adding hooks". Could you
> elaborate on this?

In the case of TranslateCast what I'd have needed would be a call to some
user-defined code within TranslateCast().  AFAICT, since TranslateCast()
calls cannot be tied to a particular class, it could not be done with the
metaclass mechanism.  I originally thought it could probably be done if we
could access from the metaprogram, and derive something like the Program
instance for the file being translated.  But I now realize that it would be
mostly similar, but probably less flexible than deriving the walker, so
let's assume the latter.

In this case, once we're able to use a custom walker, we could add to
TranslateCast() a call to a BeforeTranslateCast(), which the default walker
would implement as a no-op, therefore being non-intrusive.  In the case of
TranslateCast I don't see myself the need for running an additional
translation, but I'll still use this example, since this is a much simpler
method that TranslateFunctionImplementation().  A fully hooked TranslateCast
(simplified by not avoiding useless copies, and probably missing some calls
to ShallowSubst or similar) would give something like:

Ptree* Walker::TranslateCast(Ptree* exp)
{
    Ptree exp2 = BeforeTranslateCast(exp);
    Ptree* e = exp2->Nth(3);
    Ptree* e2 = AfterTranslateCastedExpression(Translate(BeforeTranslateCastedExpression(e)));
    return AfterTranslateCast(new PtreeCastExpr(TranslateCastType(exp2->First()),
    	       	   		                Ptree::ShallowSubst(e2, e, exp2->Cdr())));
}

As you see that'd cause in the case of the default walker a large number of
calls to methods just returning their argument, but that's the simplest way
of adding hooks that I can see.


> > or to call the current one and manipulate the result Ptree
> > again (useless copy of (part of) the Ptree).
> 
> What if you provide your own walker, which derives or delegates to the
> existing walker? In your implementation of
> 'YourWalker::TranslateFunctionImplementation()' you could either call the
> original walker (and possibly postprocess the result) or not call it and
> do all processing by yourself. Is this what you are looking for?

Yes, the same could possibly be done by pre-processing and post-processing
the Ptrees manipulated by the default walker, and I now realize that it
would be much more lightweight to do so than to add all those hooks.


> > I'm under the impression that if we were given translator hooks within each
> > call to Translate(), with the default implementation just returning its
> > Ptree* argument, that would be sufficient.  I noticed a
> > TranslateFunctionBody(), but a quick code browsing does not make it obvious
> > to me that it's be taken into account here.  Clearly I'd need to experiment.
> 
> I am not sure: are you talking about accessing the code from user-defined
> metaclass methods or about writting your own derivative of Walker?

Just the code of methods and functions in standard code.

Regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
Debian-related: <di...@de...> |   Support Debian GNU/Linux:
Pro:    <yan...@fr...> |  Freedom, Power, Stability, Gratuity
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: [Opencxx-users] Makefile.am fixes

[Grzegorz J. <ja...@he...>]

On Wed, 10 Sep 2003, Yann Dirson wrote:

> On Wed, Sep 10, 2003 at 08:38:09AM +0800, Grzegorz Jakacki wrote:
> > > > Thous I would discourage you
> > > > from moving the docs to .in files etc.
> > >
> > > Some possibility would be to generate a directories.html from a .in and get
> > > that linked from $libdir ?
> >
> > I don't get it. How would this work?
>
> Put a directories.html.in in CVS and shipped tarball, with something like
> "on your system $libdir is @LIBDIR@" in it, and add this file to the list of
> files to be generated by ./configure.  Then say <a
> href="directories.html>$libdir</a> in man.html and possibly other places.

I see. Go ahead and implement it if you think it is important, but to be
honest I don't think it is a cruicial feature. Implementing it involves
some maintenance burden (now anybody writting '$libdir' in docs should add
a link to directories.html to be consistient; and most likely that person
will not do it, because there is no mechanism or process that would
require him/her to do so), but we don't change docs often, so I don't see
a problem. I would encourage you to rather invest your time in
implementing your ideas about walkers, but if you think 'directories.html'
is a good thing, go ahead. Provided you get down to walkers afterwards :-)

> > I think they are just well-suited for APIs. In some packages APIs are
> > internal, in OpenC++ much of its APIs goes to user's docs.
>
> Sure.  But then only the part of the doc which is the API reference can be
> generated that way.  Granted, it's surely already better than maintaining a
> separate document.

I don't know about Synopsis, but in Doxygen you can also provide input in
free-form text, so you can combine code annotations with epic docs.

>
> I also wonder if it's easy to tell those tools to only generate a reference
> for a given subset of the code - since we probably don't need to expose the
> whole internals to users.

Yes, you can do this.

> > > All of this seems to be easily achieved if we can add hooks to the
> > > translation of arbitrary language constructs (casts, statements...)
> >
> > Right. However after you expand the existing walker you need to have a way
> > to coerce it back into the old functionality, so that the occ itself and
> > legacy applications compile. However this seems doable.
>
> Hm.  My idea was that without any hooks the behaviour would be the current
> one.  But it's surely both more flexible and less intrusive to provide my
> own walker in many cases.

I think I did not understand what you mean by "adding hooks". Could you
elaborate on this?

> However, say I want to instrument functions.  I'll have to provide a
> replacement Walker::TranslateFunctionImplementation(), and it'd not be
> comfortable to either override it with a copy-paste-modify version (code
> maintainance),

Sure.

> or to call the current one and manipulate the result Ptree
> again (useless copy of (part of) the Ptree).

What if you provide your own walker, which derives or delegates to the
existing walker? In your implementation of
'YourWalker::TranslateFunctionImplementation()' you could either call the
original walker (and possibly postprocess the result) or not call it and
do all processing by yourself. Is this what you are looking for?

>
> I'm under the impression that if we were given translator hooks within each
> call to Translate(), with the default implementation just returning its
> Ptree* argument, that would be sufficient.  I noticed a
> TranslateFunctionBody(), but a quick code browsing does not make it obvious
> to me that it's be taken into account here.  Clearly I'd need to experiment.

I am not sure: are you talking about accessing the code from user-defined
metaclass methods or about writting your own derivative of Walker?

Best regards
Grzegorz


##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] Makefile.am fixes

[Yann D. <yd...@al...>]

On Wed, Sep 10, 2003 at 08:38:09AM +0800, Grzegorz Jakacki wrote:
> > > Thous I would discourage you
> > > from moving the docs to .in files etc.
> >
> > Some possibility would be to generate a directories.html from a .in and get
> > that linked from $libdir ?
> 
> I don't get it. How would this work?

Put a directories.html.in in CVS and shipped tarball, with something like
"on your system $libdir is @LIBDIR@" in it, and add this file to the list of
files to be generated by ./configure.  Then say <a
href="directories.html>$libdir</a> in man.html and possibly other places.


> I think they are just well-suited for APIs. In some packages APIs are
> internal, in OpenC++ much of its APIs goes to user's docs.

Sure.  But then only the part of the doc which is the API reference can be
generated that way.  Granted, it's surely already better than maintaining a
separate document.

I also wonder if it's easy to tell those tools to only generate a reference
for a given subset of the code - since we probably don't need to expose the
whole internals to users.


> > All of this seems to be easily achieved if we can add hooks to the
> > translation of arbitrary language constructs (casts, statements...)
> 
> Right. However after you expand the existing walker you need to have a way
> to coerce it back into the old functionality, so that the occ itself and
> legacy applications compile. However this seems doable.

Hm.  My idea was that without any hooks the behaviour would be the current
one.  But it's surely both more flexible and less intrusive to provide my
own walker in many cases.

However, say I want to instrument functions.  I'll have to provide a
replacement Walker::TranslateFunctionImplementation(), and it'd not be
comfortable to either override it with a copy-paste-modify version (code
maintainance), or to call the current one and manipulate the result Ptree
again (useless copy of (part of) the Ptree).

I'm under the impression that if we were given translator hooks within each
call to Translate(), with the default implementation just returning its
Ptree* argument, that would be sufficient.  I noticed a
TranslateFunctionBody(), but a quick code browsing does not make it obvious
to me that it's be taken into account here.  Clearly I'd need to experiment.

Regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
Debian-related: <di...@de...> |   Support Debian GNU/Linux:
Pro:    <yan...@fr...> |  Freedom, Power, Stability, Gratuity
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: [Opencxx-users] Makefile.am fixes

[Grzegorz J. <ja...@he...>]

On Tue, 9 Sep 2003, Yann Dirson wrote:

> On Mon, Sep 08, 2003 at 09:54:29AM +0800, Grzegorz Jakacki wrote:
> > Great. You have been added to the project.
>
> Cool, thanks.  Committed.
>
> Additionally, I've added the opencxx and tools modules to CVSROOT/modules,
> for "cvs co -c" to be useful.

Thanks.

> > I am afraid this may cause confusion to the users, because some of them
> > reading the (installed version of) documentation may not notice, that the
> > library path can vary. My personal opinion is that it is much safer to
> > just say '$libdir/libocc.a' in docs, as it clearly indicates that the path
> > may vary, also giving a hint on what the path depends (the name "libdir"
> > occures verbatim in './configure --help').
>
> Well, $libdir is clearly better than the current situation :)
>
> > Thous I would discourage you
> > from moving the docs to .in files etc.
>
> Some possibility would be to generate a directories.html from a .in and get
> that linked from $libdir ?

I don't get it. How would this work?

> > However, if you have some time to
> > donate to documentation cleanup, then there is a long outstanding project
> > of integrating documentation with code, so that it can be generated with
> > Doxygen and/or Synopsis (which I hope would contribute to better
> > maintenance of documentation).
>
> I'll wait till I know the tool better before doing big doc things :)
>
> Anyway I'd have to look at how Doxygen and Synopsis can help with user
> documentation - I thought they were only useful for internals.

I think they are just well-suited for APIs. In some packages APIs are
internal, in OpenC++ much of its APIs goes to user's docs.

> > Also there are coding tasks (both in core
> > and infrastructure) if you would like to get involved.
>
> There is one thing I'd like to do, but this needs to be discussed first to
> find a way to integrate that in the occ design.  Here are 3 tasks which are
> not currently possibly with stock occ - maybe with Vladimir's patch however:
>
> - I currently had to find a way to spot all casts to a
> pointer-to-class-instance in a large project.  I did that by patching the
> Walker::TranslateCast method to simply add some code there.

  * Derive (or delegate to) existing walker
  * Provide a factory that returns your walker (factories are currently
    being implemented by Vladimir)

> - TAU is a profiling toolkit, which currently depends on PDT for automatic
> code instrumentation, the latter depending on a parser based on a
> proprietary compiler for the extraction of program information (location of
> definitions, statements, etc).  I'd like to make a completely free parser
> instead, but currently it does not seem possible to bind actions to the
> translation of a global function definition, or of a statement.
>
> - Use occ to produce a tagging facility (think etags), but based on real
> code parsing instead of ad-hoc regexps applied to unpreprocessed code
>
> All of this seems to be easily achieved if we can add hooks to the
> translation of arbitrary language constructs (casts, statements...)

Right. However after you expand the existing walker you need to have a way
to coerce it back into the old functionality, so that the occ itself and
legacy applications compile. However this seems doable.

> > PS: Haven't we met at BLUG meeting?
>
> No, I was not there :)

Sorry, that was some other Yann.

Regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] Makefile.am fixes

[Yann D. <yd...@us...>]

On Mon, Sep 08, 2003 at 09:54:29AM +0800, Grzegorz Jakacki wrote:
> Great. You have been added to the project.

Cool, thanks.  Committed.

Additionally, I've added the opencxx and tools modules to CVSROOT/modules,
for "cvs co -c" to be useful.


> I am afraid this may cause confusion to the users, because some of them
> reading the (installed version of) documentation may not notice, that the
> library path can vary. My personal opinion is that it is much safer to
> just say '$libdir/libocc.a' in docs, as it clearly indicates that the path
> may vary, also giving a hint on what the path depends (the name "libdir"
> occures verbatim in './configure --help').

Well, $libdir is clearly better than the current situation :)

> Thous I would discourage you
> from moving the docs to .in files etc.

Some possibility would be to generate a directories.html from a .in and get
that linked from $libdir ?

> However, if you have some time to
> donate to documentation cleanup, then there is a long outstanding project
> of integrating documentation with code, so that it can be generated with
> Doxygen and/or Synopsis (which I hope would contribute to better
> maintenance of documentation).

I'll wait till I know the tool better before doing big doc things :)

Anyway I'd have to look at how Doxygen and Synopsis can help with user
documentation - I thought they were only useful for internals.

> Also there are coding tasks (both in core
> and infrastructure) if you would like to get involved.

There is one thing I'd like to do, but this needs to be discussed first to
find a way to integrate that in the occ design.  Here are 3 tasks which are
not currently possibly with stock occ - maybe with Vladimir's patch however:

- I currently had to find a way to spot all casts to a
pointer-to-class-instance in a large project.  I did that by patching the
Walker::TranslateCast method to simply add some code there.

- TAU is a profiling toolkit, which currently depends on PDT for automatic
code instrumentation, the latter depending on a parser based on a
proprietary compiler for the extraction of program information (location of
definitions, statements, etc).  I'd like to make a completely free parser
instead, but currently it does not seem possible to bind actions to the
translation of a global function definition, or of a statement.

- Use occ to produce a tagging facility (think etags), but based on real
code parsing instead of ad-hoc regexps applied to unpreprocessed code

All of this seems to be easily achieved if we can add hooks to the
translation of arbitrary language constructs (casts, statements...)

> PS: Haven't we met at BLUG meeting?

No, I was not there :)

Regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
Debian-related: <di...@de...> |   Support Debian GNU/Linux:
Pro:    <yan...@fr...> |  Freedom, Power, Stability, Gratuity
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: [Opencxx-users] T++ -> (C++,TSS) converter needs

[Yann D. <yd...@us...>]

Vladimir,

> New classes CustomClassWalker and CustomClassBodyWalker are used
> to support redefinition of ones by metaclass modules;

This description makes me think the feature may be useful to me, but I could
not infer the patch how it should be used ?  Maybe you could provide a small
example for the sample/ directory ?

Regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
Debian-related: <di...@de...> |   Support Debian GNU/Linux:
Pro:    <yan...@fr...> |  Freedom, Power, Stability, Gratuity
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: [Opencxx-users] T++ -> (C++,TSS) converter needs

[Grzegorz J. <ja...@he...>]

On Mon, 8 Sep 2003, Vladimir Roganov wrote:

[...]
> > > Last is about typeof
> > > It is used in RedHat9 STL (?) but missed in opencxx parser.
> > > It is good idea to support this extension.
> > > Currently just a hack to make it working - so it is wrong.
> > > Code for typeof must be changed.
> >
> > But where is the problem exactly? OpenC++ can do type elaboration (at least
> > in theory), so what is the deal?
>
>
> `*typeof' tokens!  They just absend in token list :-(

Oh, I see. But why do you call it a "hack"?

BTW: As typeof is not in the standard C++, I would suggest putting it under
a command-line switch.

> > [...]
> > > > Everything looks very interesting. The main question is will you have time
> > > > to work with me on on adding your changes to the repository?
> > >
> > > Yes, at this and next week I like to work with this topic.
> > > We need to complete converter.
> >
> > Great. Please send me your SourceForge id.
>
> login = vladimir_ar
> Something else required ?

No. You are in.

Best regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] installation failed

[Yann D. <yd...@us...>]

On Sun, Sep 07, 2003 at 10:13:21PM -0500, Long Fei wrote:
> Linux 9

Hm, I thought the latest version of Linux was not 2.6 yet...

>, with gcc 3.2.2

2.6.1 is known not to build with gcc 3.X, you'll have to take the source
from CVS, or get a snapshot tarball from
http://opencxx.sourceforge.net/snapshots/index.shtml

Alternatively, you can safely use gcc 2.95.x

Regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
Debian-related: <di...@de...> |   Support Debian GNU/Linux:
Pro:    <yan...@fr...> |  Freedom, Power, Stability, Gratuity
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

[Opencxx-users] installation failed

[Long F. <lf...@ec...>]

Linux 9, with gcc 3.2.2

I guess some syntax is not compatible with gcc (current version).
If you successfully installed it, could you tell me your settings ? (i.e.
versions of Linux, gcc)

thanks,
--Long

Re: [Opencxx-users] Makefile.am fixes

[Grzegorz J. <ja...@he...>]

On Thu, 4 Sep 2003, Yann Dirson wrote:

> On Thu, Sep 04, 2003 at 09:04:26AM +0800, Grzegorz Jakacki wrote:
> > Thanks for your contribution, I reviewed it shortly below. Will you have
> > time to commit those changes to CVS on SF?
>
> I can find the time :)

Great. You have been added to the project.

> > > - a test for an allocation, which I inserted some time ago when
> > > investigating a problem (dont remember the details)
> >
> > Is this necessary? Standard mandates exception when 'new' cannot allocate
> > memory, so on conforming compiler the execution should never make it to
> > the test.
>
> OK, I can drop it.
>
> > > -<DT><TT><B>opencxx.a</B></TT>
> > > +<DT><TT><B>/usr/lib/libopenc++.a</B></TT>
> >
> > (1) I am under impression that library names is 'libocc.a'
>
> Right, fixed.
>
> > (2) The library is not necessarily intalled in /usr/lib
>
> Right as well.  To be correct the doc should be generated from an .in
> file by configure, who can then substitute the path matching the local
> installation.  I can arrange to do that if there are no objections.
> Gasp, I always hated file renamings in CVS...

I am afraid this may cause confusion to the users, because some of them
reading the (installed version of) documentation may not notice, that the
library path can vary. My personal opinion is that it is much safer to
just say '$libdir/libocc.a' in docs, as it clearly indicates that the path
may vary, also giving a hint on what the path depends (the name "libdir"
occures verbatim in './configure --help'). Thous I would discourage you
from moving the docs to .in files etc. However, if you have some time to
donate to documentation cleanup, then there is a long outstanding project
of integrating documentation with code, so that it can be generated with
Doxygen and/or Synopsis (which I hope would contribute to better
maintenance of documentation). Also there are coding tasks (both in core
and infrastructure) if you would like to get involved.

Best regards
Grzegorz

PS: Haven't we met at BLUG meeting?

> Regards,
> --
> Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
> Debian-related: <di...@de...> |   Support Debian GNU/Linux:
> Pro:    <yan...@fr...> |  Freedom, Power, Stability, Gratuity
>      http://ydirson.free.fr/        | Check <http://www.debian.org/>
>
>

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

Re: [Opencxx-users] Makefile.am fixes

[Yann D. <yd...@us...>]

On Thu, Sep 04, 2003 at 09:04:26AM +0800, Grzegorz Jakacki wrote:
> Thanks for your contribution, I reviewed it shortly below. Will you have
> time to commit those changes to CVS on SF?

I can find the time :)

> > - a test for an allocation, which I inserted some time ago when
> > investigating a problem (dont remember the details)
> 
> Is this necessary? Standard mandates exception when 'new' cannot allocate
> memory, so on conforming compiler the execution should never make it to
> the test.

OK, I can drop it.

> > -<DT><TT><B>opencxx.a</B></TT>
> > +<DT><TT><B>/usr/lib/libopenc++.a</B></TT>
> 
> (1) I am under impression that library names is 'libocc.a'

Right, fixed.

> (2) The library is not necessarily intalled in /usr/lib

Right as well.  To be correct the doc should be generated from an .in
file by configure, who can then substitute the path matching the local
installation.  I can arrange to do that if there are no objections.
Gasp, I always hated file renamings in CVS...

Regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
Debian-related: <di...@de...> |   Support Debian GNU/Linux:
Pro:    <yan...@fr...> |  Freedom, Power, Stability, Gratuity
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: [Opencxx-users] Makefile.am fixes

[Grzegorz J. <ja...@he...>]

Hi,

Thanks for your contribution, I reviewed it shortly below. Will you have
time to commit those changes to CVS on SF?

Regards
Grzegorz

On Wed, 3 Sep 2003, Yann Dirson wrote:

> Hello,
>
> Here is a patch fixing a couple of things:
>
> - a number of targets defined in Makefile.am's override the default
> ones instead of appending to them

Right, I fixed one of those recently, but others are left.

> - some documentation updates

Thanks.

>
> - a test for an allocation, which I inserted some time ago when
> investigating a problem (dont remember the details)

Is this necessary? Standard mandates exception when 'new' cannot allocate
memory, so on conforming compiler the execution should never make it to
the test.

> diff -ruN /disc5/dwitch/deb/openc++/opencxx-snapshot-HEAD-2003-03-25/html/man.html opencxx-2.6.1/html/man.html
> --- /disc5/dwitch/deb/openc++/opencxx-snapshot-HEAD-2003-03-25/html/man.html	2001-12-14 16:28:30.000000000 +0100
> +++ opencxx-2.6.1/html/man.html	2003-09-02 16:28:27.000000000 +0200
[...]
> @@ -225,7 +225,7 @@
>  <DT><TT>file<B>.so</B></TT>
>  <DD>shared library dynamically loaded by <B>occ</B>.
>
> -<DT><TT><B>opencxx.a</B></TT>
> +<DT><TT><B>/usr/lib/libopenc++.a</B></TT>

(1) I am under impression that library names is 'libocc.a'

(2) The library is not necessarily intalled in /usr/lib

>  <DD>library to link with meta-level program.
>
>  </DL>



##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Makefile.am fixes

[Yann D. <yd...@al...>]

Hello,

Here is a patch fixing a couple of things:

- a number of targets defined in Makefile.am's override the default
ones instead of appending to them

- some documentation updates

- a test for an allocation, which I inserted some time ago when
investigating a problem (dont remember the details)

-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
Debian-related: <di...@de...> |   Support Debian GNU/Linux:
Pro:    <yan...@fr...> |  Freedom, Power, Stability, Gratuity
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

[Opencxx-users] T++ -> (C++,TSS) converter needs

[Vladimir R. <va...@sk...>]

Hello Friends!
Sorry for long pause - a lot of other work...

Just now I got a little modified opencxx tree which is working well
for our purposes: convert T++ program source to target C++ w/ TSS
calls (TSS = Open T-Superstructure, dynamic parallelization technology
for multicomputers; T++ is it's input language, simple C++ extension)

Please find result diff at http://dm.botik.ru/~var/opencxx-3sep2003.diff 
and notes about changes below
(may be some things are already fixed - I used month-old cvs tree):

1. Include --disable-gc option to configure (available in templates branch);

2. New classes CustomClassWalker and CustomClassBodyWalker are used
   to support redefinition of ones by metaclass modules;

3. Add possibility to register new suffixes for extension language files
   (.tc, .tcc, .txx, .tpp in our application)

4. Again increase hash table :-)

5. Remove deprecated C++ lib calls (to avoid warnings under fresh gcc)

6. Add some calls for function prototype replacement
   (may be removed if point 2 will be applied here)

7. Some _improper_ hacks to accept member modifiers as a storage class
   (incomplete, non-ready values in our application)

8. Some  _improper_ hack to support 'typeof'

9. Some fixes to make it working under RedHat9 


Please feel free to ask me if something is interesting !  


P.S.

I very like Lisp-style code, used in opencxx 
Really good technique broken in recent days


-- 
Best regards,
Vladimir