opencxx-users

Re: [Opencxx-users] Reverse-engineered architecture docs

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

Raphael Yokoingawa de Camargo wrote:
> How can I find this document?
> 
> I used the CVS browser from SF, but I didn't find it there.
> http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/doc/
> 
> Am I looking in the correct place?

Yes. On SF anonymous CVS (and webcvs) have a propagation delay of ~6 
hours wrt. to the main CVS. The files are visible already, but most 
likely were not when you first checked.

> 
> thanks,
> Raphael
> 
> OBS: Grzegorz Jakacki, sorry for double email. The first was wrongly sent only
> to you...

No problem.

Best regardz
Grzegorz

> 
> Citando Grzegorz Jakacki <ja...@ac...>:
> 
> 
>>Hi,
>>
>>I checked in my attempt at reverse-engineering docs of OpenC++ 
>>architecture on the class level. The document is incomplete and most 
>>likely in flux, since architecture is changing now, but at least it 
>>describes status quo. Please review, fix, give feedback.
>>
>>The docs are in opencxx/doc/architecture.html
>>
>>BR
>>Grzegorz
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>FREE Java Enterprise J2EE developer tools!
>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>_______________________________________________
>>Opencxx-users mailing list
>>Ope...@li...
>>https://lists.sourceforge.net/lists/listinfo/opencxx-users
>>
> 
> 
> Raphael Yokoingawa de Camargo <rca...@im...>
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

[Opencxx-users] Adding new function statatements

[Raphael Y. de C. <rca...@im...>]

Hi, 

I am writing a C++ precompiler to modify an application to automatically save
its state periodically. For doing this, I need to insert new statements in
function bodies. The problem i am encountering is how to insert these new
statements. In the first version of this precompiler I am using the command
Ptree::Make. The problem of using this command, is that all the original
statements after the insert ones appear on the same line, and not on different
lines as before. For example:

ckp_save_stack_data("temp.dat"); // Added by the precompiler
printf ( "testInt    =   1: %d\n" , testInt ) ; printf ( "testDouble = 2.1:
%f\n" , testDouble ) ; ckp_npop_data(5);

The modifications are being done at the function ClassWalker::TranslateBlock.
Does anyone know how to solve this?

Thanks,
Raphael


Raphael Yokoingawa de Camargo <rca...@im...>

[Opencxx-users] OpenCXX and Windows

[Luke P. <lu...@pe...>]

Do any of the releases of opencxx build and run on windows?  I'm using 
Windows XP with Visual C++ 7.1.  I also have the latest version of 
cygwin installed.

I've tried building opencxx-2.7 using cygwin.  I've added the main() to 
lbtl.c to get lbtl to link but I can't run the occ.exe executable 
without it crashing.

I've also tried building from the head of the CVS tree but configure 
doesn't even run.

Suggestions?  Should I try an earlier release?

Luke

Re: [Opencxx-users] Reverse-engineered architecture docs

[Raphael Y. de C. <rca...@im...>]

How can I find this document?

I used the CVS browser from SF, but I didn't find it there.
http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/doc/

Am I looking in the correct place?

thanks,
Raphael

OBS: Grzegorz Jakacki, sorry for double email. The first was wrongly sent only
to you...

Citando Grzegorz Jakacki <ja...@ac...>:

> Hi,
> 
> I checked in my attempt at reverse-engineering docs of OpenC++ 
> architecture on the class level. The document is incomplete and most 
> likely in flux, since architecture is changing now, but at least it 
> describes status quo. Please review, fix, give feedback.
> 
> The docs are in opencxx/doc/architecture.html
> 
> BR
> Grzegorz
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
> 

Raphael Yokoingawa de Camargo <rca...@im...>

[Opencxx-users] Reverse-engineered architecture docs

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

Hi,

I checked in my attempt at reverse-engineering docs of OpenC++ 
architecture on the class level. The document is incomplete and most 
likely in flux, since architecture is changing now, but at least it 
describes status quo. Please review, fix, give feedback.

The docs are in opencxx/doc/architecture.html

BR
Grzegorz

Re: [Opencxx-users] parse error on valid code

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

Stefan Seefeld wrote:
> Grzegorz Jakacki wrote:
> 
>> Hi all,
>>
>> Shigeru Chiba wrote:
>>
>> [...]
>>
>>> Yes, parsing C++ code should not need backward references with 
>>> respect to
>>> types.
>>
>> AFAIK with this exception:
>>
>> struct A
>> {
>>     void f(B);
>>     typedef B int;
>> };
> 
> 
> huh ? 

Well, please ignore. If I wasn't answering in the morning I could 
pretend I was too tired.

[...]
>> I think we can keep the OpenC++ parser clean with this design:
>>
>>                  <<iface>>
>> +--------+     +--------------+
>> | Parser |---->| TypeResolver |
>> +--------+     +--------------+
>>
>> Where TypeResolver instance provides all the functionality requiring
>> maintaining the type name table. Perhaps ClassWalker or Environment can
>> be made an implementation of TypeResolver. That way code would stay not
>> tangled (i.e. Parser still does not implement type name table, nor does
>> it depend on concrete classes from the next layers, like Environment or
>> ClassWalker).
> 
> 
> yes, agreed. The Parser is complex enough as it is right now. What is
> needed (and what the Parser will have to interact with) is a symbol
> resolver that can report whether a symbol is known, and what its (meta) 
> type
> is, i.e. one of 'type', 'variable', 'compile-time const'.
> This symbol resolver needs to know the rules for symbol lookup with 
> multiple
> scopes. That's quite hairy in itself.
> 
> However, I don't see how ClassWalker relates to that. 

Currently it is an entry point to the symbol table.

> Well, if ClassWalker
> currently serves to report back known symbols, that's one thing. However,
> symbol lookup mustn't be done in a second AST traversal parse, but (as
> we now seem to agree) as soon as information about new symbols gets
> available. Parser and Symbol resolver really need to work hand in hand.
> Just think about declarations such as
 >
> template <size_t FOOBAR> struct Baz {};
> 
> where the parser needs to know that FOOBAR is a compile-time constant.
> It's not even a type !

I don't get this example, but I think that in general I agree with you.

BR
Grzegorz

Re: [Opencxx-users] parse error on valid code

[Stefan S. <se...@sy...>]

Grzegorz Jakacki wrote:
> Hi all,
> 
> Shigeru Chiba wrote:
> 
> [...]
> 
>>Yes, parsing C++ code should not need backward references with respect to
>>types.
> 
> 
> AFAIK with this exception:
> 
> struct A
> {
>     void f(B);
>     typedef B int;
> };

huh ? Make that

struct A
{
   typedef int B;
   void f(B);
};

and everything is fine (and covered by what was already said).


> I think we can keep the OpenC++ parser clean with this design:
> 
>                  <<iface>>
> +--------+     +--------------+
> | Parser |---->| TypeResolver |
> +--------+     +--------------+
> 
> Where TypeResolver instance provides all the functionality requiring
> maintaining the type name table. Perhaps ClassWalker or Environment can
> be made an implementation of TypeResolver. That way code would stay not
> tangled (i.e. Parser still does not implement type name table, nor does
> it depend on concrete classes from the next layers, like Environment or
> ClassWalker).

yes, agreed. The Parser is complex enough as it is right now. What is
needed (and what the Parser will have to interact with) is a symbol
resolver that can report whether a symbol is known, and what its (meta) type
is, i.e. one of 'type', 'variable', 'compile-time const'.
This symbol resolver needs to know the rules for symbol lookup with multiple
scopes. That's quite hairy in itself.

However, I don't see how ClassWalker relates to that. Well, if ClassWalker
currently serves to report back known symbols, that's one thing. However,
symbol lookup mustn't be done in a second AST traversal parse, but (as
we now seem to agree) as soon as information about new symbols gets
available. Parser and Symbol resolver really need to work hand in hand.
Just think about declarations such as

template <size_t FOOBAR> struct Baz {};

where the parser needs to know that FOOBAR is a compile-time constant.
It's not even a type !

Regards,
		Stefan

Re: [Opencxx-users] parse error on valid code

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

Hi all,

Shigeru Chiba wrote:

[...]
> 
> Yes, parsing C++ code should not need backward references with respect to
> types.

AFAIK with this exception:

struct A
{
    void f(B);
    typedef B int;
};

> So now I must say that I cannot remember why I chose the approach
> currently used in OpenC++.  However, there should be some examples in
> which the lexical analyzer must help the parser to record all the
> declared type names etc.  Thus, as far as I remember, the code of the
> lexical analyzer of gcc 2.x(?) was quite tangled with the code of the
> parser.  I didn't like to make the OpenC++ code tangled.  Hope this info
> helps you guys.  I think the parser needs to maintain the type name
> table for completely supporting templates.

I think we can keep the OpenC++ parser clean with this design:

                 <<iface>>
+--------+     +--------------+
| Parser |---->| TypeResolver |
+--------+     +--------------+

Where TypeResolver instance provides all the functionality requiring
maintaining the type name table. Perhaps ClassWalker or Environment can
be made an implementation of TypeResolver. That way code would stay not
tangled (i.e. Parser still does not implement type name table, nor does
it depend on concrete classes from the next layers, like Environment or
ClassWalker).

Best regards
Grzegorz



> 
> Chiba
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] parse error on valid code

[Christophe A. <chr...@la...>]

Well, more precisely :

in C you always need the prefix "struct" for a struct name.

for example :

struct object { ... };

struct object *new_object();
void init_object(struct object *object);

if you want to avoit to prefix "struct" you must use a typedef declaration :

typedef struct object { ... } object;

Now, in C++, you are not forced to prefix "struct", just give the name and
it knows whether it is a struct name, but indeed I noticed that g++ is okay
when using the prefix "struct" explicitly (prefix "class" also works most
time). My opinion is that it should be standard. Anyway if you want OpenC++
to be able to parse C source, you absolutely need to have this prefix,
because using "object" without its typedef declaration would lead a normal C
compiler to think it is an unknown type, whereas a C++ compiler would
recognize as a "struct object".

Regards



----- Original Message ----- 
From: "Stefan Seefeld" <se...@sy...>
To: <ope...@li...>
Sent: Wednesday, July 21, 2004 1:17 PM
Subject: Re: [Opencxx-users] parse error on valid code


> Christophe Avoinne wrote:
> > Forward declaration is not necessary with pointer (always a 4-byte
unsigned
> > integer for ia32), but you must use a tag name for the structure to
resolve
> > this lack of information :
> >
> > typedef struct Link_s {
> >     struct Link_s *next;
> >     int value;
> > } Link;
>
> interesting. I wasn't sure how standard compliant such a construct is
> (knowing that it comes from C...).
> Anyways, the important point here seems to be that the 'struct' tag
> serves the same purpose as the 'typename' keyword, i.e. it provides
> a hint to the parser to disambiguate the expression.
>
> Regards,
> Stefan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] parse error on valid code

[Shigeru C. <ch...@is...>]

Hi Stefan,

From: Stefan Seefeld <se...@sy...>
Subject: Re: [Opencxx-users] parse error on valid code
Date: Tue, 20 Jul 2004 14:10:40 -0400

> > (sorry if the syntax above is wrong.  I haven't written C++ code for
> > years. :<)
> 
> the syntax is wrong precisely because at the point where a variable of
> 'Link *'　is generated nothing is known about 'Link'. The solution is
> to first issue a forward declaration of 'Link'.

Ahh.... my good days as a C++ programmer has been over....

> I believe that this is true in general for C++: either a type has previously
> been declared (forward declaration counts), or we have to provide hints
> (isn't that why the language contains the 'typename' keyword ?)

Yes, parsing C++ code should not need backward references with respect to
types.

So now I must say that I cannot remember why I chose the approach
currently used in OpenC++.  However, there should be some examples in
which the lexical analyzer must help the parser to record all the
declared type names etc.  Thus, as far as I remember, the code of the
lexical analyzer of gcc 2.x(?) was quite tangled with the code of the
parser.  I didn't like to make the OpenC++ code tangled.  Hope this info
helps you guys.  I think the parser needs to maintain the type name
table for completely supporting templates.

Chiba

Re: [Opencxx-users] parse error on valid code

[Stefan S. <se...@sy...>]

Christophe Avoinne wrote:
> Forward declaration is not necessary with pointer (always a 4-byte unsigned
> integer for ia32), but you must use a tag name for the structure to resolve
> this lack of information :
> 
> typedef struct Link_s {
>     struct Link_s *next;
>     int value;
> } Link;

interesting. I wasn't sure how standard compliant such a construct is
(knowing that it comes from C...).
Anyways, the important point here seems to be that the 'struct' tag
serves the same purpose as the 'typename' keyword, i.e. it provides
a hint to the parser to disambiguate the expression.

Regards,
		Stefan

Re: [Opencxx-users] parse error on valid code

[Christophe A. <chr...@la...>]

Forward declaration is not necessary with pointer (always a 4-byte unsigned
integer for ia32), but you must use a tag name for the structure to resolve
this lack of information :

typedef struct Link_s {
    struct Link_s *next;
    int value;
} Link;

Anyway, having a typedefed structure without a tag name is something
permissible but bad because we are not sure how each compiler (gcc, vc++,
etc.) would be able to mangle the name of the structure for a parameter in a
global function for example. If someone knows, I would be glad to know it.

Regards.

----- Original Message ----- 
From: "Stefan Seefeld" <se...@sy...>
To: "Shigeru Chiba" <ch...@is...>
Cc: <ope...@li...>
Sent: Tuesday, July 20, 2004 8:10 PM
Subject: Re: [Opencxx-users] parse error on valid code


> Hi Chiba,
>
> thanks for joining in !
>
> Shigeru Chiba wrote:
>
> >>well, but as we just discovered, this doesn't work for C++ in general
where
> >>certain ambiguities have to be resolved using the knowledge about
previously
> >>declared types, variables, etc.
> >
> >
> > Yes, but maintaining the table of type and template names is really
> > complicated.  For example, the parser must be able to recognize Link
> > as a type name in this code snippet:
> >
> > typedef struct {
> >     Link* next;
> >     int value;
> > } Link;
> >
> > (sorry if the syntax above is wrong.  I haven't written C++ code for
> > years. :<)
>
> the syntax is wrong precisely because at the point where a variable of
'Link *'
> is generated nothing is known about 'Link'. The solution is to first issue
a forward
> declaration of 'Link'. And that would indeed solve our problem, too (as
all we
> want to know is that 'Link' is indeed a type, not what kind of type).
>
> I believe that this is true in general for C++: either a type has
previously
> been declared (forward declaration counts), or we have to provide hints
(isn't
> that why the language contains the 'typename' keyword ?)
>
> Kind regards,
> Stefan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] parse error on valid code

[Christophe A. <chr...@la...>]

Forward declaration is not necessary with pointer (always a 4-byte unsigned
integer for ia32), but you must use a tag name for the structure to resolve
this lack of information :

typedef struct Link_s {
    struct Link_s *next;
    int value;
} Link;

Anyway, having a typedefed structure without a tag name is something
permissible but bad because we are not sure how each compiler (gcc, vc++,
etc.) would be able to mangle the name of the structure for a parameter in a
global function for example. If someone knows, I would be glad to know it.

Regards.

----- Original Message ----- 
From: "Stefan Seefeld" <se...@sy...>
To: "Shigeru Chiba" <ch...@is...>
Cc: <ope...@li...>
Sent: Tuesday, July 20, 2004 8:10 PM
Subject: Re: [Opencxx-users] parse error on valid code


> Hi Chiba,
>
> thanks for joining in !
>
> Shigeru Chiba wrote:
>
> >>well, but as we just discovered, this doesn't work for C++ in general
where
> >>certain ambiguities have to be resolved using the knowledge about
previously
> >>declared types, variables, etc.
> >
> >
> > Yes, but maintaining the table of type and template names is really
> > complicated.  For example, the parser must be able to recognize Link
> > as a type name in this code snippet:
> >
> > typedef struct {
> >     Link* next;
> >     int value;
> > } Link;
> >
> > (sorry if the syntax above is wrong.  I haven't written C++ code for
> > years. :<)
>
> the syntax is wrong precisely because at the point where a variable of
'Link *'
> is generated nothing is known about 'Link'. The solution is to first issue
a forward
> declaration of 'Link'. And that would indeed solve our problem, too (as
all we
> want to know is that 'Link' is indeed a type, not what kind of type).
>
> I believe that this is true in general for C++: either a type has
previously
> been declared (forward declaration counts), or we have to provide hints
(isn't
> that why the language contains the 'typename' keyword ?)
>
> Kind regards,
> Stefan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] parse error on valid code

[Christophe A. <chr...@la...>]

Forward declaration is not necessary with pointer (always a 4-byte unsigned
integer for ia32), but you must use a tag name for the structure to resolve
this lack of information :

typedef struct Link_s {
    struct Link_s *next;
    int value;
} Link;

Anyway, having a typedefed structure without a tag name is something
permissible but bad because we are not sure how each compiler (gcc, vc++,
etc.) would be able to mangle the name of the structure for a parameter in a
global function for example. If someone knows, I would be glad to know it.

Regards.

----- Original Message ----- 
From: "Stefan Seefeld" <se...@sy...>
To: "Shigeru Chiba" <ch...@is...>
Cc: <ope...@li...>
Sent: Tuesday, July 20, 2004 8:10 PM
Subject: Re: [Opencxx-users] parse error on valid code


> Hi Chiba,
>
> thanks for joining in !
>
> Shigeru Chiba wrote:
>
> >>well, but as we just discovered, this doesn't work for C++ in general
where
> >>certain ambiguities have to be resolved using the knowledge about
previously
> >>declared types, variables, etc.
> >
> >
> > Yes, but maintaining the table of type and template names is really
> > complicated.  For example, the parser must be able to recognize Link
> > as a type name in this code snippet:
> >
> > typedef struct {
> >     Link* next;
> >     int value;
> > } Link;
> >
> > (sorry if the syntax above is wrong.  I haven't written C++ code for
> > years. :<)
>
> the syntax is wrong precisely because at the point where a variable of
'Link *'
> is generated nothing is known about 'Link'. The solution is to first issue
a forward
> declaration of 'Link'. And that would indeed solve our problem, too (as
all we
> want to know is that 'Link' is indeed a type, not what kind of type).
>
> I believe that this is true in general for C++: either a type has
previously
> been declared (forward declaration counts), or we have to provide hints
(isn't
> that why the language contains the 'typename' keyword ?)
>
> Kind regards,
> Stefan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

[Opencxx-users] ANN: Synopsis 0.7 - a source code inspection tool

[Stefan S. <se...@sy...>]

Synopsis 0.7 released
=====================


I'm happy to announce the release of Synopsis 0.7.
This is a major feature enhancement and bug fix release.
Among the more important new features:

* refactored Cpp processor (now a stand-alone processor)
* new C processor
* feature enhancements and bug fixes in the C++ processor
* cleanup and bug fixes in the HTML formatter (now generates
   valid XHTML)
* new SXR cross referencer (see http://synopsis.fresco.org/sxr/files/
   for an example)
* new C++ API for easier C++ backend programming
* Synopsis has been ported to (native) windows

An ongoing efford is to produce correct (and useful) documentation
for the boost libraries (http://boost.org). You may have a look at
the current status of this efford at http://synopsis.fresco.org/boost,
containing a reference manual for boost::python (this site is quite
large !).

For information, see http://synopsis.fresco.org
For (developer) documentation, see http://synopsis.fresco.org/docs.html
To contact the developers, see http://synopsis.fresco.org/mailinglists.html
To report bugs, see http://synopsis.fresco.org/issues/bug

About Synopsis
==============

Synopsis is a source code inspection framework supporting a variety
of languages (right now C++, C, IDL, and Python). Its main focus is
source code documentation, but effords are being made to support other
forms of introspection such as code generation.
Synopsis provides a framework of processors that can (via a simple and
straight-forward scripting interface) be used to construct sophisticated
pipelines to process abstract syntax trees (ASTs).

Regards,
		Stefan

Re: [Opencxx-users] parse error on valid code

[Stefan S. <se...@sy...>]

Hi Chiba,

thanks for joining in !

Shigeru Chiba wrote:

>>well, but as we just discovered, this doesn't work for C++ in general where
>>certain ambiguities have to be resolved using the knowledge about previously
>>declared types, variables, etc.
> 
> 
> Yes, but maintaining the table of type and template names is really
> complicated.  For example, the parser must be able to recognize Link
> as a type name in this code snippet:
> 
> typedef struct {
>     Link* next;
>     int value;
> } Link;
> 
> (sorry if the syntax above is wrong.  I haven't written C++ code for
> years. :<)

the syntax is wrong precisely because at the point where a variable of 'Link *'
is generated nothing is known about 'Link'. The solution is to first issue a forward
declaration of 'Link'. And that would indeed solve our problem, too (as all we
want to know is that 'Link' is indeed a type, not what kind of type).

I believe that this is true in general for C++: either a type has previously
been declared (forward declaration counts), or we have to provide hints (isn't
that why the language contains the 'typename' keyword ?)

Kind regards,
		Stefan

Re: [Opencxx-users] parse error on valid code

[Shigeru C. <ch...@is...>]

Hi,

Just a short comment.

From: Stefan Seefeld <se...@sy...>
Date: Sun, 18 Jul 2004 11:00:48 -0400

> > So, Environment does not know about Int or IntVector until the parsing 
> > of the whole namespace ends.
> 
> well, but as we just discovered, this doesn't work for C++ in general where
> certain ambiguities have to be resolved using the knowledge about previously
> declared types, variables, etc.

Yes, but maintaining the table of type and template names is really
complicated.  For example, the parser must be able to recognize Link
as a type name in this code snippet:

typedef struct {
    Link* next;
    int value;
} Link;

(sorry if the syntax above is wrong.  I haven't written C++ code for
years. :<)

So my solution was to avoid maintaining such a table.  Instead, the
parser tries to parse given code in different ways till it gets a
syntax tree without errors.  So the parser does a lot of backtracking.
However, I'm not sure that this approach still works with the current
specifications of C++.  Remember that C++ had not supported templates
yet when I wrote the parser.

Chiba

Re: [Opencxx-users] parse error on valid code

[Stefan S. <se...@sy...>]

Grzegorz Jakacki wrote:

>> what does 'ClassWalker' do ? The name suggests it is only inspecting
>> class definitions, but not you are suggesting it deals with arbitrary
>> type recovery.
> 
> 
> AFAIK it traverses the AST and registers all definitions and 
> declarations in the Environment it maintains.
> 
>>> This is fair enough when there is no namespaces or nested templates. 
>>> However, if top-level construct is a namespace, then Environment does 
>>> not have a clue about anything defined in it until it is fully parsed.
>>
>>
>>
>> hmm, I don't understand the design of Environment et al. yet. Why doesn't
>> it 'have a clue' until it is 'fully parsed' ? In the example
>>
>> namespace Foo
>> {
>> typedef int Int;
>> typedef std::vecor<Int> IntVector;
>> }
>>
>> Shouldn't it know 'Int' when it sees the typedef for IntVector ?
> 
> 
> The top-level loop will call parser. Parser will return AST representing 
> all the above text. At this moment the text is already parsed, but 
> Environment object still does not know anything about Int or IntVector. 
> Only now the main loop calls ClassWalker, which begins to traverse the 
> AST. The traversal reaches first typedef and registers Int in top-level 
> Environment, then second typedef and registers IntVector.
> 
> So, Environment does not know about Int or IntVector until the parsing 
> of the whole namespace ends.

well, but as we just discovered, this doesn't work for C++ in general where
certain ambiguities have to be resolved using the knowledge about previously
declared types, variables, etc.

>> Please document the current design and the solutions you envision. It 
>> will
>> help a lot to work out the remaining issues to make opencxx a very 
>> powerful
>> tool that supports all standard C++.
> 
> 
> I am putting it really high on my TODO list, I will try to post it this 
> week. As for existing design, however, my knowledge is limited to what I 
> absorbed or figured out, so I am afraid there are going to be some dark 
> corners.

Yeah. But if we have very specific questions I'm sure we can always get
back to Chiba to help us out.

>> More and more people use synopsis, and the bug reports about parse errors
>> I get become more and more sophisticated, indicating that it becomes more
>> and more important to make the parser work correct not only for the most
>> used C++ features, but really covering the full standard.
> 
> 
> That's great news. There is still a lot of work, but let's keep moving 
> forward.

Sure. I'm aiming for a new synopsis release within the coming week, and
after that I'll start working on a refactoring of the opencxx code synopsis
uses. I'm sure I'll have lots of questions in the process...

Regards,
		Stefan

Re: [Opencxx-users] parse error on valid code

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

Stefan Seefeld wrote:
> Grzegorz Jakacki wrote:
> 
>>> Ah, now I understand again ! So, the solution is to add a type 
>>> dictionary
>>> ('Environment' ?) to the Parser and then let the 'isTypeSpecifier' 
>>> use that
>>> instead of just detecting built-in types. Right ?
>>
>>
>>
>> For many cases this should work. However in general it will not.
> 
> 
> understood. Putting a type dictionary right into the parser means
> that the type recovery can't be done in a second pass, but instead
> has to be done as soon as a new type declaration has been detected.
> 
> The separation between parser and mop libraries doesn't make sense
> in that context any more...

I think it still does. First of all, Parser should not depend on 
Environment, just on an interface that would allow to get what it needs 
from environment:

                     (iface)
+---------+     +--------------------+
| Parser  |---->| TemplatesResolver  |
+---------+     +--------------------+
                         |
                        /_\
                         |
                     +---------------+
                     | Environment   |
                     +---------------+

It would allow at least to test parser in separation from the MOP.
Moreover, observe, that this interface needs to cover only a part of 
Environment functionality, in particular it does not have to deal with 
variable declarations at all.

Even if we move all processing to one-pass model, I would strongly 
recommend that parser do not depend on concrete MOP classes, but only on 
interfaces. It gives a chance to reuse parser in another context, also 
to test it without touching the rest of the system. Good example of such 
parser design is XercesC++ (XML parser from Apache Foundation).

> 
>> The top-level environment is maintained by ClassWalker. Driver in the 
>> main loop runs Parser::rProgram() and feeds the obtained AST into 
>> ClassWalker. Parser::rProgram() returns AST representing one top-level 
>> construct (definition or declaration), so one iteration analyzes one 
>> top-level construct. Only when ClassWalker traverses the AST, the 
>> information about types defined in it are stuffed into Environment.
> 
> 
> what does 'ClassWalker' do ? The name suggests it is only inspecting
> class definitions, but not you are suggesting it deals with arbitrary
> type recovery.

AFAIK it traverses the AST and registers all definitions and 
declarations in the Environment it maintains.

>> This is fair enough when there is no namespaces or nested templates. 
>> However, if top-level construct is a namespace, then Environment does 
>> not have a clue about anything defined in it until it is fully parsed.
> 
> 
> hmm, I don't understand the design of Environment et al. yet. Why doesn't
> it 'have a clue' until it is 'fully parsed' ? In the example
> 
> namespace Foo
> {
> typedef int Int;
> typedef std::vecor<Int> IntVector;
> }
> 
> Shouldn't it know 'Int' when it sees the typedef for IntVector ?

The top-level loop will call parser. Parser will return AST representing 
all the above text. At this moment the text is already parsed, but 
Environment object still does not know anything about Int or IntVector. 
Only now the main loop calls ClassWalker, which begins to traverse the 
AST. The traversal reaches first typedef and registers Int in top-level 
Environment, then second typedef and registers IntVector.

So, Environment does not know about Int or IntVector until the parsing 
of the whole namespace ends.

> 
>> I don't think there is an easy and complete solution. I have one 
>> solution in mind, but it is neither cheap, nor easy.
> 
> 
> Please document the current design and the solutions you envision. It will
> help a lot to work out the remaining issues to make opencxx a very powerful
> tool that supports all standard C++.

I am putting it really high on my TODO list, I will try to post it this 
week. As for existing design, however, my knowledge is limited to what I 
absorbed or figured out, so I am afraid there are going to be some dark 
corners.

> More and more people use synopsis, and the bug reports about parse errors
> I get become more and more sophisticated, indicating that it becomes more
> and more important to make the parser work correct not only for the most
> used C++ features, but really covering the full standard.

That's great news. There is still a lot of work, but let's keep moving 
forward.

BR
Grzegorz

Re: [Opencxx-users] parse error on valid code

[Stefan S. <se...@sy...>]

Grzegorz Jakacki wrote:

>> Ah, now I understand again ! So, the solution is to add a type dictionary
>> ('Environment' ?) to the Parser and then let the 'isTypeSpecifier' use 
>> that
>> instead of just detecting built-in types. Right ?
> 
> 
> For many cases this should work. However in general it will not.

understood. Putting a type dictionary right into the parser means
that the type recovery can't be done in a second pass, but instead
has to be done as soon as a new type declaration has been detected.

The separation between parser and mop libraries doesn't make sense
in that context any more...

> The top-level environment is maintained by ClassWalker. Driver in the 
> main loop runs Parser::rProgram() and feeds the obtained AST into 
> ClassWalker. Parser::rProgram() returns AST representing one top-level 
> construct (definition or declaration), so one iteration analyzes one 
> top-level construct. Only when ClassWalker traverses the AST, the 
> information about types defined in it are stuffed into Environment.

what does 'ClassWalker' do ? The name suggests it is only inspecting
class definitions, but not you are suggesting it deals with arbitrary
type recovery.

> This is fair enough when there is no namespaces or nested templates. 
> However, if top-level construct is a namespace, then Environment does 
> not have a clue about anything defined in it until it is fully parsed.

hmm, I don't understand the design of Environment et al. yet. Why doesn't
it 'have a clue' until it is 'fully parsed' ? In the example

namespace Foo
{
typedef int Int;
typedef std::vecor<Int> IntVector;
}

Shouldn't it know 'Int' when it sees the typedef for IntVector ?

> I don't think there is an easy and complete solution. I have one 
> solution in mind, but it is neither cheap, nor easy.

Please document the current design and the solutions you envision. It will
help a lot to work out the remaining issues to make opencxx a very powerful
tool that supports all standard C++.
More and more people use synopsis, and the bug reports about parse errors
I get become more and more sophisticated, indicating that it becomes more
and more important to make the parser work correct not only for the most
used C++ features, but really covering the full standard.

Regards,
		Stefan

Re: [Opencxx-users] parse error on valid code

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

Stefan Seefeld wrote:
> Grzegorz Jakacki wrote:
> 
>> It is worse. 'f<1>(0)' will always parse as a template, even if 'f' is 
>> an int variable. :-(
>>
>>> Could I simply add ';'
>>> and ',' to the list of symbols potentially following the template args ?
>>
>>
>>
>> AFAICS it will not break things further.
>>
>>> May be I should have a look into the new C++ parser used in gcc 3.4...
>>
>>
>>
>> Honest parsing of templates requires parser to be able to tell if an 
>> identifier is a template in current scope and this is how gcc does it
>> (gcc/gcc/cp/parser.c, see cp_parser_lookup_name()).
> 
> 
> Ah, now I understand again ! So, the solution is to add a type dictionary
> ('Environment' ?) to the Parser and then let the 'isTypeSpecifier' use that
> instead of just detecting built-in types. Right ?

For many cases this should work. However in general it will not.

The top-level environment is maintained by ClassWalker. Driver in the 
main loop runs Parser::rProgram() and feeds the obtained AST into 
ClassWalker. Parser::rProgram() returns AST representing one top-level 
construct (definition or declaration), so one iteration analyzes one 
top-level construct. Only when ClassWalker traverses the AST, the 
information about types defined in it are stuffed into Environment.

This is fair enough when there is no namespaces or nested templates. 
However, if top-level construct is a namespace, then Environment does 
not have a clue about anything defined in it until it is fully parsed.

I don't think there is an easy and complete solution. I have one 
solution in mind, but it is neither cheap, nor easy.

BR
Grzegorz

> 
> Stefan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] parse error on valid code

[Stefan S. <se...@sy...>]

Grzegorz Jakacki wrote:

> It is worse. 'f<1>(0)' will always parse as a template, even if 'f' is 
> an int variable. :-(
> 
>> Could I simply add ';'
>> and ',' to the list of symbols potentially following the template args ?
> 
> 
> AFAICS it will not break things further.
> 
>> May be I should have a look into the new C++ parser used in gcc 3.4...
> 
> 
> Honest parsing of templates requires parser to be able to tell if an 
> identifier is a template in current scope and this is how gcc does it
> (gcc/gcc/cp/parser.c, see cp_parser_lookup_name()).

Ah, now I understand again ! So, the solution is to add a type dictionary
('Environment' ?) to the Parser and then let the 'isTypeSpecifier' use that
instead of just detecting built-in types. Right ?

Stefan

Re: [Opencxx-users] libtool, libltdl, libtoolize

[<se...@in...>]

On Sat, 2004-07-17 at 04:58, Grzegorz Jakacki wrote:
> Hi,
> 
> Based on recent discussion about libtool and libltdl I suggest to:
> 
>    * add 'libtoolize' to 'bootstrap'

No, 'bootstrap' check for
$SHELL $EXECDIR/check-autotools \
        --automake=1.6.2 \
        --autoconf=2.53 \
        --libtool=1.5.2 \
|| exit 1

'configure' will check if compiling works.

we need to give a error message "compiling from source
require functional libtool package" or investigate why your
recent version of libtool is rejected by configure script.

we need to check that install from binary require
libtool-libs, that is, 'occ' is dynamically link to libltdl.so .


developer may require this functionality, that is
$ libtoolize --copy --automake --ltdl
before running './bootstrap',
but I expect they know what they are doing.

For platform using cygwin, we must ensure that we still have not
hardcoded '-lltdl' option to link command,
I suspect it is .

Even without previous problem with cygwin platform,
developer and tester may require this functionality,
that is, no hardcoded -lltdl .
For example, we want to verify that opencxx still perform as
expected on next available libtool version 1.9.0 .
In that case, we want 'make check' to work.

>    * remove bundled libltdl, rely on system-wide libltdl
>      (or cygltdl.dll).

Yes.

>      and add version check to 'configure' to make sure that
>      recent enough libltdl's version is installed.

We are already doing this, see above check-autotools.

> 
> Opinions/suggestions are welcome.

on cygwin Grigorenko Dmitriy has provided following information:

My opinion is that the configure script must stop right there.
Fix this.

configure:2886: checking for main in -lltdl
configure:2911: gcc -o conftest.exe -g -O2   conftest.c -lltdl   >&5
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/
../../../../i686-pc-cygwin/bin/ld: cannot find -lltdl
collect2: ld returned 1 exit status
configure:2914: $? = 1

we need information, where are the two following macros,
under linux it is
/usr/share/aclocal/libtool.m4
/usr/share/aclocal/ltdl.m4
The ltdl.m4 macro teach to the configure script what to do,
Why does it do a bad job ?

Questions,
Why the configure script want -lltdl ?
If such thing exist, what is the path ?
Why this path is not on the default ?
try gcc option
  -print-libgcc-file-name  Display the name of the compiler's
                           companion library
  -print-file-name=<lib>   Display the full path to library <lib>
Can you list files from libtool package ?
My understanding is that we want to link with 'cygltdl-3.dll',
Can you show a successfull compile
and link against 'cygltdl-3.dll' ?

> BR
> Grzegorz

Re: [Opencxx-users] parse error on valid code

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

Hi,

Stefan Seefeld wrote:
[...]
> 
> A little follow-up: after '&Foo' has been parsed, 'Parser::isTemplateArgs'
> is been called. However, as the comment above that method indicates:
> 
> /*
>   template.args : '<' any* '>'
> 
>   template.args must be followed by '(' or '::'
> */
> 
> which obviously doesn't account for this case where a function pointer
> is passed, i.e. no terminating '('. Now I'm a bit lost. I guess the '('
> constraint is used to disambigate from a relational expression, i.e. if
> we drop it, we'll misinterpret other expressions. 

It is worse. 'f<1>(0)' will always parse as a template, even if 'f' is 
an int variable. :-(

> Could I simply add ';'
> and ',' to the list of symbols potentially following the template args ?

AFAICS it will not break things further.

> May be I should have a look into the new C++ parser used in gcc 3.4...

Honest parsing of templates requires parser to be able to tell if an 
identifier is a template in current scope and this is how gcc does it
(gcc/gcc/cp/parser.c, see cp_parser_lookup_name()).

BR
Grzegorz




> 
> Any ideas ? Chiba ?
> 
> Kind regards,
>         Stefan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

[Opencxx-users] libtool, libltdl, libtoolize

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

Hi,

Based on recent discussion about libtool and libltdl I suggest to:

   * add 'libtoolize' to 'bootstrap'
   * remove bundled libltdl, rely on system-wide libltdl (or cygltdl.dll)
     and add version check to 'configure' to make sure that
     recent enough libltdl's version is installed.

Opinions/suggestions are welcome.

BR
Grzegorz