opencxx-users

Fw: [Opencxx-users] Throw Clause Fix

[John A. <jal...@st...>]

Hello Mr. Grzegorz Jakacki,

Last summer I sent an email about OpenC++ not being able to parse throw 
clauses; specifically, whenever I had a throw clause for a method, OpenC++ 
would report a parse error.  For instance,
the following code would generate a parse error:

class Person
{
public:
    int age;
    Person(int a);
    int getAge() throw (int);
}

The throw clause for the method getAge() would cause a parse error.  I sent 
code to fix this problem (which reimplements the method Parser::optThrowDecl 
in the Parser class) for OpenC++ version 2.5.12, but I got a response (which 
is the message being forwarded) saying that my code doesn't really fix the 
problem.  However, I never had any problems when I used the code I sent; 
I've attached a text file that contains the code I used to deal with the 
problem for version 2.5.12 and 2.8.  So I was wondering, will this problem 
be dealt with for the next version or will OpenC++ be able to give 
information about what exception a method throws if the method has a throw 
declaration?  Thanks.

John Altidor

----- Original Message ----- 
From: "Stefan Seefeld" <se...@sy...>
To: <jal...@st...>
Cc: <ope...@li...>
Sent: Thursday, September 02, 2004 10:55 PM
Subject: Re: [Opencxx-users] Throw Clause Fix


> jal...@st... wrote:
>> Hello Everyone again,
>>
>> I have fixed the throw clause problem that was in my previous email by 
>> changing the body of the method bool Parser::optThrowDecl(Ptree*& 
>> throw_decl) in the parser.cc file (for OpenC++ 2.5.12 but each version of 
>> OpenC++ has the same implementation for this method).  Here is what I 
>> changed this method to:
>
> [...]
>
> Thanks for the bug report, and thanks for trying to fix it !
> I don't think your code really solves the problem, though.
> Here is my understanding of the problem:
>
> First note that the ptree fragment that results from parsing the 
> declaration
> is never used as of now. (Grzegorz: we should add new ptree nodes for 
> this,
> shouldn't we ?)
> optThrowDecl uses 'rName' in a loop, i.e. it assumes the throw specifier
> contains a list of identifiers. That is probably so because in most cases
> what you throw is a class, and as non-builtin types are not looked up 
> during
> this stage of the parsing, optThrowDecl simply has to look for 
> identifiers.
> Now you put a builtin type there, which the lexer reports as a special 
> token,
> which the parser doesn't expect (it expects identifiers !). Boom !!
>
> You have replaced the loop involving 'rName' with 'rTempArgList'.
> That's a method that parses template arguments, which is probably not what
> you thought what it does :-)
>
> Anyways I believe as this wasn't really a problem until now we should just
> keep a record of this bug (a good case for a unit test to remind us until
> we fix it !) and fix it when we can. That is, I believe, as soon as we
> have a symbol lookup mechanism integrated into the parser, and thus we can
> look for a 'list of types'.
>
> Makes sense ?
>
> Thanks for your your help !
>
> 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=5047&alloc_id=10808&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
> 

Re: [Opencxx-users] OpenC++ core ClassWalker::TranslateTemplateFunction

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

Hi Gunther,

Gunther Laure wrote:

> template<typename _CharT>
> template<class Foo>
> void basic_string<_CharT>::test(Foo a)
> {
>   cout << "Foo" << endl;
> }
> 
> In this case the impl parameter of TranslateTemplateFunction does not
> contain the valid implementation:
> Dump: [0 [void] [[test ( [[Foo [a]]] )]] ;]
> 
> The cast to PtreeDeclarator fails in this case...

It is quite possible that you have hit one of the limitations of the
OpenC++ parser, which are all symptoms of the same fundamental issue:
As it doesn't lookup symbols during the parsing, it can't disambiguate
certain constructs and thus has to guess whether it is looking at
a type-id or an expression (whether '>' marks the end of a template-id
or is the relational operator), etc., etc.

> Another question:
> Whats the difference between PTreeDeclaration and PTreeDeclarator?

To see what the difference between 'declaration' and 'declarator' is,
you should look up these terms in the C++ grammar (which is listed
in Stroustrup's book, in case you don't have access to the spec itself).

In short, a single declaration may contain multiple declarators:

char *a, b;

for example is a single declaration, with declarators '*a' and 'b'.
There are also cases where a declarator is not part of a declaration.

HTH,
		Stefan

[Opencxx-users] [Fwd: bug correction again]

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

Gunther,

You may want to see if the version from Mathieu's branch works OK for 
you, he has just comitted some fixes in the area of the bug you expose.

BR
Grzegorz

-------- Original Message --------
Subject: bug correction again
Date: Sun, 05 Jun 2005 13:10:03 +0200
From: Mathieu ROGER <rog...@fr...>
Reply-To: rog...@fr...
To: Grzegorz Jakacki <ja...@ac...>

Hi,
I have commited a "corrected" version of openc++ on my branch
this version have better support for scoped templates (both for template
class and template parameters)
I have added a backbox test that demonstrate the functionnality
(typescope-test)

I will now have a rest :) and then I will test usage for that correction
for my prject application

regards

-- 
Mathieu Roger
icq 		: 330924173
tel 		: 08 71 72 59 11
msn 		: rog...@ho...

[Opencxx-users] OpenC++ core ClassWalker::TranslateTemplateFunction

[Gunther L. <gun...@gm...>]

Hi,

I think I found a bug in TranslateTemplateFunction. I tried to parse a
file that included <string> and was already preprocessed. In this case
basic_string declares member template functions with the implementation
given later. Example:

template<typename _CharT>
class basic_string
{
public:
  template<class Foo>
  void test(Foo a);
};

template<typename _CharT>
template<class Foo>
void basic_string<_CharT>::test(Foo a)
{
  cout << "Foo" << endl;
}

In this case the impl parameter of TranslateTemplateFunction does not
contain the valid implementation:
Dump: [0 [void] [[test ( [[Foo [a]]] )]] ;]

The cast to PtreeDeclarator fails in this case...

Another question:
Whats the difference between PTreeDeclaration and PTreeDeclarator?

By Gunther

[Opencxx-users] Parsing of class and member comments?

[Gunther L. <gun...@gm...>]

Hi!

I try to use OpenC++ to dynamically insert assertions into translated
source code to implement Design by Contract for C++ (Someone in this
list talked about something like that last year.)
Well my problem is the parsing of method and class comments. I took the
verbose example to build a basic prototype. A customized
"VerboseClass.exe" is generated which I use. It seems to work fine, but
the "-C" commandline option is ignored (== dont remove comments). All
comments are removed by the preprocessor :(, therefore calls to
Class::Comments() return a null pointer ...

Well is this a bug, or is comment parsing not implemented until now?

Thanks in advance,

Gunther

Re: [Opencxx-users] trunk/Synopsis/Parsers/Cxx/occ/TypeInfo.cc

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

Gilles J. Seguin wrote:
> trunk/Synopsis/Parsers/Cxx/occ/TypeInfo.cc
> 
> line 464 missing return

Hi Gilles,

was that mail to the OpenC++ list instead of synopsis
intentional ? As far as the synopsis code is concerned,
thanks for the report, I'll fix it. I don't think this
particular code is actually used. It will soon be
obsoleted by new SymbolLookup and TypeAnalysis modules
anyways.

Regards,
		Stefan

[Opencxx-users] trunk/Synopsis/Parsers/Cxx/occ/TypeInfo.cc

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

trunk/Synopsis/Parsers/Cxx/occ/TypeInfo.cc

line 464 missing return

PTree::Node *TypeInfo::make_ptree(PTree::Node *name)
{
  normalize();
  if(my_metaobject != 0)
  {
    PTree::Node *decl;
    if(!name) decl = 0;
    else decl = PTree::list(name);
    return PTree::list(full_type_name(), decl);
  }
  else if(!my_encoding.empty())
    return my_encoding.make_ptree(name);
  else
    return 0;
}

[Opencxx-users] trunk/Synopsis/Parsers/Cxx/occ/TypeInfo.cc

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

trunk/Synopsis/Parsers/Cxx/occ/TypeInfo.cc
line 569 missing return

PTree::Encoding TypeInfo::skip_name(const PTree::Encoding &encode,
Environment *e)
{
  if(!e) throw std::runtime_error("TypeInfo::skip_name(): nil
environment");

  Environment *e2 = e;
  PTree::Encoding ptr = Environment::get_base_name(encode, e2);
  if (ptr.empty()) {
    return PTree::Encoding(); // missing return
  }
  else {
    return PTree::Encoding(encode.begin() + ptr.size(), encode.end());
  }
}

Re: [Opencxx-users] how get the control graph!

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

zhaoqinglan wrote:
> Hello!
> Thank you for your time !
> I  have studied your Open C++ for a long time ,and is surprised by its 
> powerful function.It is so recondite that I have some difficulties in 
> using it.
> I want to use it to get the control-flow graph of the program . Usually 
> the control-flow graph can be got by analyzing the abstract syntax 
> tree(AST).Is it feasible to get it through analyzing the parse tree in 
> Open C++?

You may want to look at the Walker class to see how to traverse the parse
tree. You should write your own Walker subclass and reimplement those
methods you are interested in (i.e. for PTreeIfStatement, PTreeSwitchStatement,
etc.) to generate a control graph from the parse tree.

Regards,
		Stefan

[Opencxx-users] how get the control graph!

[zhaoqinglan <ql...@sn...>]

SGVsbG8hDQpUaGFuayB5b3UgZm9yIHlvdXIgdGltZSAhDQpJICBoYXZlIHN0dWRpZWQgeW91ciBP
cGVuIEMrKyBmb3IgYSBsb25nIHRpbWUgLGFuZCBpcyBzdXJwcmlzZWQgYnkgaXRzIHBvd2VyZnVs
IGZ1bmN0aW9uLkl0IGlzIHNvIHJlY29uZGl0ZSB0aGF0IEkgaGF2ZSBzb21lIGRpZmZpY3VsdGll
cyBpbiB1c2luZyBpdC4NCkkgd2FudCB0byB1c2UgaXQgdG8gZ2V0IHRoZSBjb250cm9sLWZsb3cg
Z3JhcGggb2YgdGhlIHByb2dyYW0gLiBVc3VhbGx5IHRoZSBjb250cm9sLWZsb3cgZ3JhcGggY2Fu
IGJlIGdvdCBieSBhbmFseXppbmcgdGhlIGFic3RyYWN0IHN5bnRheCB0cmVlKEFTVCkuSXMgaXQg
ZmVhc2libGUgdG8gZ2V0IGl0IHRocm91Z2ggYW5hbHl6aW5nIHRoZSBwYXJzZSB0cmVlIGluIE9w
ZW4gQysrPw0KSSBhbSBhbnhpb3VzIHRvIGdldCB0aGVzZSBpbmZvcm1hdGlvbiAuSSBjb3JkaWFs
bHkgaG9wZSB5b3Ugd291bGQgZ2l2ZSBtZSBzb21lIGd1aWRhbmNlLg0KQmVzdCB3aXNoZXMgdG8g
eW91IGFuZCB5b3VyIGZhbWlseSENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg
ICAgICAgICAgICAgICBZb3VycyByZXNwZWN0ZnVsbHksIFpoYW8gUWluZ2xhbg==

Re: [Opencxx-users] scriptable code generation

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

Brian Kahne wrote:

 >  From my point of view, the scripting extensions you're suggesting sound
 > interesting, but I'm a little concerned with performance.  After all, a
 > seemingly small C++ file that includes a few STL headers quickly grows
 > to be tens of thousands of lines long.

Right. Well, there is more than one answer to this. It is true that walking
over a huge parse tree calling back and forth between C++ and python on each
node may be costly. I haven't done any profiling to measure / compare the
performance.
An alternative approach not requiring a walker implemented entirely in python
would be to code a new walker in C++ that is configured flexibly (again, using
some form of scripting). What I have in mind here is some kind of pattern
matcher akin to XPath/DOM, so you can express what nodes in the parse tree
to apply your callback on. Doing this 'pattern matching' in C++ may be more
efficient. This pattern matching is unrelated to the actual callbacks being
invoked, so the callbacks could still be written in python (say).

 > One other question I had was whether you're using SWIG for generating
 > the interface.  Python isn't my favorite language, but if you're using
 > SWIG then I could conceivably use Bigloo or Ocaml as my main
 > implementation language while using occ as the parser.

That's an interesting question. I do use C++ and python a lot, and the
prototype I have right now uses boost.python, as it makes the reflection
of C++ into python a very straight forward and easy exercise.

However, as the parser can certainly inspect its own code, it could also
be used to generate its own language bindings, whether that's python,
ocaml, or any other language compatible with a C++ backend.

Grzegorz, have you tried to run OpenC++ over its own code ? As OpenC++
doesn't make much use of templates it should even work as it is
now, shouldn't it ?

Regards,
		Stefan

Re: [Opencxx-users] scriptable code generation

[Brian K. <bk...@fr...>]

Hi,

I've been using OpenC++ for about a year to implement some extensions to C++ to 
enable parallel programming.  My usage model has been to link my metaclass 
directly with libocc.  So, the user never uses the `metaclass` syntax, just the 
syntax extensions that I've added.

 From my point of view, the scripting extensions you're suggesting sound 
interesting, but I'm a little concerned with performance.  After all, a 
seemingly small C++ file that includes a few STL headers quickly grows to be 
tens of thousands of lines long.

One other question I had was whether you're using SWIG for generating the 
interface.  Python isn't my favorite language, but if you're using SWIG then I 
could conceivably use Bigloo or Ocaml as my main implementation language while 
using occ as the parser.

Brian Kahne
PowerPC Design Center
Freescale Semiconductor Inc.


Stefan Seefeld wrote:
> Grzegorz Jakacki wrote:
> 
>> Stefan Seefeld wrote:
> 
> 
>>> I'm not bashing the OpenC++ programming model in any way. As you say,
>>> it has served its useres very well over the years. However, when it
>>> was first developed, alternative techniques such as hybrid programming
>>> (http://www.boost-consulting.com/writing/bpl.html) weren't really 
>>> available.
>>> Now they are, and so I'm comparing these new possibilities.
>>
>>
>>
>> You do, by suggesting that existing model has disadvantages, which it 
>> in fact does not have. It is orthogonal to the question if pythonic 
>> API would be useful (it would, IMHO).
> 
> 
> Suggesting that I bash OpenC++ and that I spread 'FUD' just because I
> ask you to take a fresh look at metaprogramming is quite a
> misrepresentation.
> My question was not about whether or not to export an API to python,
> but to compare advantages and disadvantates of using language extensions
> for metaprogramming as opposed to scripting.
> 
> I appreciate you replying you don't find the existing model having
> disadvantages. What are the reasons for your thinking ? If you think
> the scripting approach I suggest is a good alternative, how would you
> compare both ?
> 
>> You took OpenC++ code and you put it in your project. You solicited 
>> substantial time and work from OpenC++ community (e.g. I wrote 
>> architecture docs per your request). This helped you to improve 
>> Synopsis's branch of OpenC++.
> 
> 
> Indeed it did. Any good discussion will trigger new development. I'm
> quite sorry that you see this very one-sided, though, as I would hope
> that you, too, would have enjoyed the exchange. The may be single most
> valuable aspect in Free Software is that by construction you can't prohibit
> anybody from using the work of others. It thus stresses the collective
> aspect of knowledge. I totally fail to understand how you experienced
> this as if I had taken away something from you ('substantial time and 
> work').
> 
>> Your license lock resulted in a situation, where the improved version 
>> of Synopsis's OpenC++ is more attractive than the original version, 
>> yet the improvements cannot be backported. This attracts developers 
>> away from OpenC++ to Synopsis.
> 
> 
> If that is indeed the case it may be a good time to rethink your licensing
> terms then.
> 
>> Also for some reason you refused to build both Synopsis and 
>> OpenC++framework on an independent common core library, being an 
>> intersection of Synopsis and OpenC++. In particular you were opposing 
>> the idea of making such a library an independently buildable package. 
>> Clearly such core library would get most attention, since it would be 
>> in a focal point of both Synopsis and OpenC++ developers. Perhaps you 
>> were afraid that as a standalone package it will distract manpower 
>> from Synopsis proper. 
> 
> 
> Certainly not, as I had to do the work anyways. It was, as you may 
> remember,
> a matter of project management.
> 
> I'm still trying to get this discussion back to where I started it, i.e.
> to compare various approaches to metaprogramming. The fact that I draw
> my current design ideas from my experience with synopsis does by no means
> imply that this is a 'synopsis-centric' discussion.
> 
> In particular, if you find the ideas I bring forward valuable, I'd 
> certainly
> be more than happy to help apply them to OpenC++.
> 
> What do other OpenC++ developers and users think ?
> 
> Regards,
>         Stefan
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] scriptable code generation

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

Grzegorz Jakacki wrote:
> Stefan Seefeld wrote:

>> I'm not bashing the OpenC++ programming model in any way. As you say,
>> it has served its useres very well over the years. However, when it
>> was first developed, alternative techniques such as hybrid programming
>> (http://www.boost-consulting.com/writing/bpl.html) weren't really 
>> available.
>> Now they are, and so I'm comparing these new possibilities.
> 
> 
> You do, by suggesting that existing model has disadvantages, which it in 
> fact does not have. It is orthogonal to the question if pythonic API 
> would be useful (it would, IMHO).

Suggesting that I bash OpenC++ and that I spread 'FUD' just because I
ask you to take a fresh look at metaprogramming is quite a
misrepresentation.
My question was not about whether or not to export an API to python,
but to compare advantages and disadvantates of using language extensions
for metaprogramming as opposed to scripting.

I appreciate you replying you don't find the existing model having
disadvantages. What are the reasons for your thinking ? If you think
the scripting approach I suggest is a good alternative, how would you
compare both ?

> You took OpenC++ code and you put it in your project. You solicited 
> substantial time and work from OpenC++ community (e.g. I wrote 
> architecture docs per your request). This helped you to improve 
> Synopsis's branch of OpenC++.

Indeed it did. Any good discussion will trigger new development. I'm
quite sorry that you see this very one-sided, though, as I would hope
that you, too, would have enjoyed the exchange. The may be single most
valuable aspect in Free Software is that by construction you can't prohibit
anybody from using the work of others. It thus stresses the collective
aspect of knowledge. I totally fail to understand how you experienced
this as if I had taken away something from you ('substantial time and work').

> Your license lock resulted in a situation, where the improved version of 
> Synopsis's OpenC++ is more attractive than the original version, yet the 
> improvements cannot be backported. This attracts developers away from 
> OpenC++ to Synopsis.

If that is indeed the case it may be a good time to rethink your licensing
terms then.

> Also for some reason you refused to build both Synopsis and 
> OpenC++framework on an independent common core library, being an 
> intersection of Synopsis and OpenC++. In particular you were opposing 
> the idea of making such a library an independently buildable package. 
> Clearly such core library would get most attention, since it would be in 
> a focal point of both Synopsis and OpenC++ developers. Perhaps you were 
> afraid that as a standalone package it will distract manpower from 
> Synopsis proper. 

Certainly not, as I had to do the work anyways. It was, as you may remember,
a matter of project management.

I'm still trying to get this discussion back to where I started it, i.e.
to compare various approaches to metaprogramming. The fact that I draw
my current design ideas from my experience with synopsis does by no means
imply that this is a 'synopsis-centric' discussion.

In particular, if you find the ideas I bring forward valuable, I'd certainly
be more than happy to help apply them to OpenC++.

What do other OpenC++ developers and users think ?

Regards,
		Stefan

Re: [Opencxx-users] scriptable code generation

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

Stefan Seefeld wrote:
> Grzegorz,
> 
>>> With such a scripting approach, I'm seriously wondering
>>> whether there is still a need to 'augment' the code in-place,
>>> essentially changing the programming language.
>>
>>
>>
>> I see a lot of confusion here. There is no need to use any language 
>> extensions in order to use OpenC++ framework or OpenC++Core library.
> 
> 
> I'm not talking about using OpenC++ in general, I'm talking about
> code generation.
> 
> Users have to know both, C++ as well as certain syntax extensions
> (http://opencxx.sourceforge.net/opencxx/html/base.html) in order
> to manipulate the code.

This is false. Cf. Class::ChangeDefaultMetaclass() or see occ-core.

>>> I have got quite positive comments from users who expressed
>>> concern that the form of metaprogramming promoted by OpenC++
>>> would require users not only to be expert in C++, but also
>>> to know the additional dialects to use to drive the code
>>> generation.
>>
>>
>>
>> It is a pity that you do not give names and quotes. I also wonder why 
>> I am not seeing these concerns on this list. Chiba designed really 
>> sound model that serves many people well over many years, perhaps your 
>> users are missing something. I am expressing the concern that you are 
>> spreading FUD about OpenC++ model.
> 
> 
> I'm not bashing the OpenC++ programming model in any way. As you say,
> it has served its useres very well over the years. However, when it
> was first developed, alternative techniques such as hybrid programming
> (http://www.boost-consulting.com/writing/bpl.html) weren't really 
> available.
> Now they are, and so I'm comparing these new possibilities.

You do, by suggesting that existing model has disadvantages, which it in 
fact does not have. It is orthogonal to the question if pythonic API 
would be useful (it would, IMHO).

> I don't understand your hostility and aggression. You seem to be
> annoyed by me working on Synopsis instead of OpenC++.

Of course not. Work on what you want to work, just play fair.

You took OpenC++ code and you put it in your project. You solicited 
substantial time and work from OpenC++ community (e.g. I wrote 
architecture docs per your request). This helped you to improve 
Synopsis's branch of OpenC++. However, despite many requests, you refuse 
to share your improvements under Open++ license -- you locked it under 
LGPL, which is much more restrictive.

Your license lock resulted in a situation, where the improved version of 
Synopsis's OpenC++ is more attractive than the original version, yet the 
improvements cannot be backported. This attracts developers away from 
OpenC++ to Synopsis.

Also for some reason you refused to build both Synopsis and 
OpenC++framework on an independent common core library, being an 
intersection of Synopsis and OpenC++. In particular you were opposing 
the idea of making such a library an independently buildable package. 
Clearly such core library would get most attention, since it would be in 
a focal point of both Synopsis and OpenC++ developers. Perhaps you were 
afraid that as a standalone package it will distract manpower from 
Synopsis proper.

> While I find the incompatibilities of our visions quite unfortunate,
> I still think there is room for conceptual / design discussions that
> doesn't lock any of us into either project specifics. You are
> asking for collaboration, but you are the first one to shut down any
> attempt I make to get a constructive discussion going. I think you are
> painting yourself into a corner.

I don't trust in your honest intentions any more. I think you just want 
to attract more manpower to your project, period. Let me remind you that 
when I was pointing out that your LGPL-lockin is unfair to OpenC++ you 
were moderating my posts out, to prevent them from appearing on Synopsis 
mailing list. How can I trust you now? Why should I invest time in 
discussing architecture with you, just to find out that my project 
cannot reap any benefits from it?

Having said that, I view your Synopsis-centered postings on this list 
just as a way of attracting manpower to your LGPL-locked project.

Regards,
Grzegorz

Re: [Opencxx-users] scriptable code generation

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

Grzegorz,

>> With such a scripting approach, I'm seriously wondering
>> whether there is still a need to 'augment' the code in-place,
>> essentially changing the programming language.
> 
> 
> I see a lot of confusion here. There is no need to use any language 
> extensions in order to use OpenC++ framework or OpenC++Core library.

I'm not talking about using OpenC++ in general, I'm talking about
code generation.

Users have to know both, C++ as well as certain syntax extensions
(http://opencxx.sourceforge.net/opencxx/html/base.html) in order
to manipulate the code.

>> I have got quite positive comments from users who expressed
>> concern that the form of metaprogramming promoted by OpenC++
>> would require users not only to be expert in C++, but also
>> to know the additional dialects to use to drive the code
>> generation.
> 
> 
> It is a pity that you do not give names and quotes. I also wonder why I 
> am not seeing these concerns on this list. Chiba designed really sound 
> model that serves many people well over many years, perhaps your users 
> are missing something. I am expressing the concern that you are 
> spreading FUD about OpenC++ model.

I'm not bashing the OpenC++ programming model in any way. As you say,
it has served its useres very well over the years. However, when it
was first developed, alternative techniques such as hybrid programming
(http://www.boost-consulting.com/writing/bpl.html) weren't really available.
Now they are, and so I'm comparing these new possibilities.

I don't understand your hostility and aggression. You seem to be
annoyed by me working on Synopsis instead of OpenC++.
While I find the incompatibilities of our visions quite unfortunate,
I still think there is room for conceptual / design discussions that
doesn't lock any of us into either project specifics. You are
asking for collaboration, but you are the first one to shut down any
attempt I make to get a constructive discussion going. I think you are
painting yourself into a corner.

Regards,
		Stefan

Re: [Opencxx-users] scriptable code generation

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

Stefan Seefeld wrote:
> hi there,
> 
> many moons ago we have discussed whether or not it would
> be useful to expose the OpenC++ API to python and thus
> to allow to drive the process of parsing and code generation
> to be scripted.
> 
> As part of synopsis I'v done some experimentation, and
> attached to this mail are some first results. The file
> is a python script that uses python modules 'PTree',
> 'SymbolLookup', and 'Processor' to access the respective
> APIs directly (this implements the design I posted earlier
> last summer).
> This particular example looks for function definitions
> and inserts comments containing the function's name
> at the beginning of each function block.
> 
> Beside the advantage we had discussed earlier to remove
> the need for (portable) management of sub-processes, dynamic
> modules, etc., there are also other advantages I can see:
> 
> With such a scripting approach, I'm seriously wondering
> whether there is still a need to 'augment' the code in-place,
> essentially changing the programming language.

I see a lot of confusion here. There is no need to use any language 
extensions in order to use OpenC++ framework or OpenC++Core library.

> Why not store the rules that drive the code manipulation
> outside the code, as part of the script that drives the
> processor ?

This is what OpenC++ framework does today, except that it uses (vanila) 
C++ instead of scripting languages.

> I have got quite positive comments from users who expressed
> concern that the form of metaprogramming promoted by OpenC++
> would require users not only to be expert in C++, but also
> to know the additional dialects to use to drive the code
> generation.

It is a pity that you do not give names and quotes. I also wonder why I 
am not seeing these concerns on this list. Chiba designed really sound 
model that serves many people well over many years, perhaps your users 
are missing something. I am expressing the concern that you are 
spreading FUD about OpenC++ model.

> What is the advantage
> of this form of metaprogramming as opposed to scriptable
> code manipulation driven by external rules ?

Very nice idea. If you want to go ahead and add it to OpenC++ that would 
be great. But the code you are posting is not usable with OpenC++ as far 
as I can see, only with Synopsis. And Synopsis has locked its 
OpenC++-derived code under the license that makes it impossible for 
OpenC++ to leverage the code etc. etc. This issue has been beaten to 
death on this forum. Your posting is Synopsis-specific material (not to 
mention the fact that by spreading FUD clearly harms OpenC++ project). I 
asked you several times not to post messages of this kind here, but you 
seem not to understand. This is the last time I am asking you.

Regards
Grzegorz

[Opencxx-users] scriptable code generation

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

hi there,

many moons ago we have discussed whether or not it would
be useful to expose the OpenC++ API to python and thus
to allow to drive the process of parsing and code generation
to be scripted.

As part of synopsis I'v done some experimentation, and
attached to this mail are some first results. The file
is a python script that uses python modules 'PTree',
'SymbolLookup', and 'Processor' to access the respective
APIs directly (this implements the design I posted earlier
last summer).
This particular example looks for function definitions
and inserts comments containing the function's name
at the beginning of each function block.

Beside the advantage we had discussed earlier to remove
the need for (portable) management of sub-processes, dynamic
modules, etc., there are also other advantages I can see:

With such a scripting approach, I'm seriously wondering
whether there is still a need to 'augment' the code in-place,
essentially changing the programming language.

Why not store the rules that drive the code manipulation
outside the code, as part of the script that drives the
processor ?

I have got quite positive comments from users who expressed
concern that the form of metaprogramming promoted by OpenC++
would require users not only to be expert in C++, but also
to know the additional dialects to use to drive the code
generation.

What do other OpenC++ users think ? What is the advantage
of this form of metaprogramming as opposed to scriptable
code manipulation driven by external rules ?

I'd appreciate any feedback,

		Stefan

Re: [Opencxx-users] template keyword cause parse error

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

>> has anyone thought about integrating boosts spirit/wave with openc++
>> wave is a fully ansi compliant preprocessor as far as i understand
> 
> No, but the author of wave expressed interest in adding wave support
> to synopsis, which is somewhat based on OpenC++ (note that synopsis
> currently uses ucpp as preprocessor library).

Word of caution: Synopsis is has much more restrictive license than 
OpenC++, think twice before investing your time.

BR
Grzegorz

Re: [Opencxx-users] template keyword cause parse error

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

Hello,

J Duncan wrote:
> has anyone thought about integrating boosts spirit/wave with openc++
> wave is a fully ansi compliant preprocessor as far as i understand

Curently preprocessing is out of the scope of OpenC++. OpenC++ works on 
preprocessed stream. It uses external preprocessor, so feel free to use 
Wave (or more precisely Wave CLI wrapper) as the preprocessor for 
OpenC++ if you like.

Another story is that some time ago there were proposals to incorporate 
preprocessing into OpenC++ flow to enable deparsing without expansion of 
preprocessor constructs. Wave would fit this space well, but there are 
nontrivial problems with interposing preprocessor structure over the 
AST. The initiative is on hold now, if you want to go in this direction 
I can provide help with orientation in OpenC++ architecture.

> Ive been thinking about adding metaobjects to a modified wave 
> preprocessor, openc++ just doesnt have a powerfull enough parser

Sorry, I don't understand your point here. In what aspects is OpenC++ 
preprocessor too weak? What kind of metaobjects would you like to add? Why?

Best regards
Grzegorz

> 
> 
> Stefan Seefeld wrote:
> 
>> Alexander Vodomerov wrote:
>>
>>> Recently, I've found that OpenC++ (2.8) can not parse following code:
>>>
>>> class X
>>> {
>>> public:
>>>   template <typename T> int g() { return 123; }
>>> };
>>>
>>> template <typename T> class A
>>> {
>>> public:
>>>   X x;
>>>   X& getx() { return x; }
>>>   void f() { getx().g<T>(); }
>>> };
>>>
>>> int main()
>>> {
>>>   A<int> a;
>>>   a.f();
>>> }
>>>
>>> It says:
>>> [alex@lorien ~]$ ./occ -c 1.cpp
>>> 1.cpp: In member function `void A<T>::f()':
>>> 1.cpp:12: error: parse error before `;' token
>>>
>>> The 12th line corresponds to getx().g<T>()
>>>
>>> Is this a correct code? I have 4 compilers on my machine (gcc 3.3.5,
>>> gcc 3.4.3, gcc 4.0.0 snapshot, Intel C/C++ 8.1). All of them
>>> compile this code cleanly.
>>
>>
>>
>> The OpenC++ parser is indeed not powerful enough to understand that line.
>> The reason is that to be able to decide whether '<' is a relational 
>> operator
>> or the start of a template parameter spec, it has to figure out what 'g'
>> is. That requires symbol lookup, which OpenC++ doesn't do during parsing.
>>
>> Regards,
>>         Stefan
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Opencxx-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>>
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] template keyword cause parse error

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

J Duncan wrote:
> has anyone thought about integrating boosts spirit/wave with openc++
> wave is a fully ansi compliant preprocessor as far as i understand

No, but the author of wave expressed interest in adding wave support
to synopsis, which is somewhat based on OpenC++ (note that synopsis
currently uses ucpp as preprocessor library).

> Ive been thinking about adding metaobjects to a modified wave 
> preprocessor, openc++ just doesnt have a powerfull enough parser

I'm not sure what you mean. We are talking about parsing C++ here,
not preprocessing, right ? And while OpenC++ doesn't support some
important aspects of C++ parsing, wave doesn't either (if only
because that is not its scope).
You still need symbol lookup, overload resolution, template
instantiation, etc., etc.

Regards,
		Stefan

Re: [Opencxx-users] template keyword cause parse error

[J D. <ja...@ja...>]

has anyone thought about integrating boosts spirit/wave with openc++
wave is a fully ansi compliant preprocessor as far as i understand
Ive been thinking about adding metaobjects to a modified wave 
preprocessor, openc++ just doesnt have a powerfull enough parser


Stefan Seefeld wrote:

> Alexander Vodomerov wrote:
>
>> Recently, I've found that OpenC++ (2.8) can not parse following code:
>>
>> class X
>> {
>> public:
>>   template <typename T> int g() { return 123; }
>> };
>>
>> template <typename T> class A
>> {
>> public:
>>   X x;
>>   X& getx() { return x; }
>>   void f() { getx().g<T>(); }
>> };
>>
>> int main()
>> {
>>   A<int> a;
>>   a.f();
>> }
>>
>> It says:
>> [alex@lorien ~]$ ./occ -c 1.cpp
>> 1.cpp: In member function `void A<T>::f()':
>> 1.cpp:12: error: parse error before `;' token
>>
>> The 12th line corresponds to getx().g<T>()
>>
>> Is this a correct code? I have 4 compilers on my machine (gcc 3.3.5,
>> gcc 3.4.3, gcc 4.0.0 snapshot, Intel C/C++ 8.1). All of them
>> compile this code cleanly.
>
>
> The OpenC++ parser is indeed not powerful enough to understand that line.
> The reason is that to be able to decide whether '<' is a relational 
> operator
> or the start of a template parameter spec, it has to figure out what 'g'
> is. That requires symbol lookup, which OpenC++ doesn't do during parsing.
>
> Regards,
>         Stefan
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>

Re: [Opencxx-users] template keyword cause parse error

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

Alexander Vodomerov wrote:

> Recently, I've found that OpenC++ (2.8) can not parse following code:
> 
> class X
> {
> public:
>   template <typename T> int g() { return 123; }
> };
> 
> template <typename T> class A
> {
> public:
>   X x;
>   X& getx() { return x; }
>   void f() { getx().g<T>(); }
> };
> 
> int main()
> {
>   A<int> a;
>   a.f();
> }
> 
> It says:
> [alex@lorien ~]$ ./occ -c 1.cpp
> 1.cpp: In member function `void A<T>::f()':
> 1.cpp:12: error: parse error before `;' token
> 
> The 12th line corresponds to getx().g<T>()
> 
> Is this a correct code? I have 4 compilers on my machine (gcc 3.3.5,
> gcc 3.4.3, gcc 4.0.0 snapshot, Intel C/C++ 8.1). All of them
> compile this code cleanly.

The OpenC++ parser is indeed not powerful enough to understand that line.
The reason is that to be able to decide whether '<' is a relational operator
or the start of a template parameter spec, it has to figure out what 'g'
is. That requires symbol lookup, which OpenC++ doesn't do during parsing.

Regards,
		Stefan

[Opencxx-users] template keyword cause parse error

[Alexander V. <al...@se...>]

  Hello!

We are using OpenC++ in our project for some intellectual C++ code
preprocessing.
Recently, I've found that OpenC++ (2.8) can not parse following code:

class X
{
public:
  template <typename T> int g() { return 123; }
};

template <typename T> class A
{
public:
  X x;
  X& getx() { return x; }
  void f() { getx().g<T>(); }
};

int main()
{
  A<int> a;
  a.f();
}

It says:
[alex@lorien ~]$ ./occ -c 1.cpp
1.cpp: In member function `void A<T>::f()':
1.cpp:12: error: parse error before `;' token

The 12th line corresponds to getx().g<T>()

Is this a correct code? I have 4 compilers on my machine (gcc 3.3.5,
gcc 3.4.3, gcc 4.0.0 snapshot, Intel C/C++ 8.1). All of them
compile this code cleanly.

I will be glad to provide any additional information about my
problem or opencxx configuration.

May be there is also some CVS, SVN or other "bleeding-edge" source that
I can try?

With best regards,
   Alexander.

Re: [Opencxx-users] OpenC++ with MSVC

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

Hi,

Sorry for the late reply, I was traveling and unable to access my e-mail.

Dr Gorilla wrote:
> Ok Im building the two occ core libs in visual studio - but i had to
> drop down to cygwin to build the ptree-generated file.

The plan is to rewrite this part in Python. Should be very 
straighforward, pls. do it if you have time and interest.

> anyway im finding an odd problem:
> 
> if I code -
> 
>     Opencxx::ProgramString* ps = new Opencxx::ProgramString;
>     *ps << "{}";
> 
>     Opencxx::Program* program = ps;
> 
>     Lex lexer(program);
>     Parser parser(&lexer, errorLog);
>     
>     // parse tree
>     Ptree* result;
>     parser.rDefinition(result);
> 
> 
> 
> no matter what i place into the source string its getting into an
> infinite loop inside the Lex ctor
> 
>     do
>     {
>         kind = ReadToken(pos, len);
>         tokens_.push_back(Token(kind, pos, len));
>     }
>     while (kind);
> 
> when ReadToken hits an end of string (0 terminator) its just backing
> up and returning the last character....
> 
> 
> am i doing something wrong ?

Nope. It was a bug, which I have hopefully fixed. Some code in Lex.cc 
erroneously assumed that Program::Get() can always be undone by 
Program::Unget(). This is not true if Program::Get() returns EOF. See 
last postings on opencxx-commits mailing list for detailed account of 
what I have changed. My fixes went into occ-lib, so if you want them in
opencxx proper, please backport (and ideally commit to our CVS).

Best regards
Grzegorz

Re: [Opencxx-users] OpenC++ with MSVC

[Dr G. <drg...@gm...>]

Ok Im building the two occ core libs in visual studio - but i had to
drop down to cygwin to build the ptree-generated file.
anyway im finding an odd problem:

if I code -

    Opencxx::ProgramString* ps = new Opencxx::ProgramString;
    *ps << "{}";

    Opencxx::Program* program = ps;

    Lex lexer(program);
    Parser parser(&lexer, errorLog);
    
    // parse tree
    Ptree* result;
    parser.rDefinition(result);



no matter what i place into the source string its getting into an
infinite loop inside the Lex ctor

    do
    {
        kind = ReadToken(pos, len);
        tokens_.push_back(Token(kind, pos, len));
    }
    while (kind);

when ReadToken hits an end of string (0 terminator) its just backing
up and returning the last character....


am i doing something wrong ?



On Mon, 07 Feb 2005 14:43:24 +0800, Grzegorz Jakacki <ja...@ac...> wrote:
> Dr Gorilla wrote:
> > Hello all,
> >
> > Is there any build that currently supports msvc? I would like to get
> > occ working in msvc, can anyone point me in the right direction? Im an
> > experienced programmer with a rather complex game engine and I was
> > thinking about writing a custom preprocessor in order to simplify the
> > use of my engine with a few extensions to c++. then I came across
> > OpenC++. I think its a pretty amazing concept and I think it will do
> > everything I want plus its giving me a lot more possibilities. So I
> > would really like to get it working on msvc and possibly contribute to
> > the project if you like.
> >
> > so is there source working with msvc somewhere
> 
> None that I know of. You may have a look at this list archives, because
> several people tried this throughout the last year, but the patches
> never made it into a mainstream.
> 
> > or should i just get
> > the latest and try to cram it into msvc???
> 
> That's what I recommend. We would also welcome any contributions.
> 
> Moreover, depending on your needs you may want to focus on a smaller
> subject of functionality factored out into OpenC++Core library. It has
> significantly simplified build process, so if its functionality is
> enough for you (parser, DOM, analyzer + you can define translation by
> deriving from AST visitors; basically the framework top that calls
> different compilers is stripped off), I would recommend approaching
> OpenC++Core instead.
> 
> BR
> Grzegorz
>