opencxx-users

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

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

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

[Opencxx-users] OpenC++ with MSVC

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

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 or should i just get
the latest and try to cram it into msvc???

thanks

Re: [Opencxx-users] [OpenC++ Core] core dump while walking through valid code

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

Altac Edena wrote:
> Hi,
> By the way, I think there is another bug in
> ClassWalker::TranslateInfix(), which leads to core
> dump in some cases:
> 
[...]
> 
> As you can see there is no 'return' if (metaobject ==
> 0). Why GCC isn't complaining about that, it's another
> question...
> I don't understand all the semantic, but I think there
> are too many 'else'.

Fixed.

> I've found this because you left two debug lines in
> the code of Walker::TranslateDeclarators() :
> 
> 		    exp->Display();
> 		    exp2->Display();

Removed.

> The second one core dump where walking through a code
> like :
> 
> class A {
>     void f() {
>         int r = 1+(int)8;
>     }
> };

Added as a test.

Thanks!

Grzegorz

Re: [Opencxx-users] [OpenC++ Core] core dump while walking through valid code

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

> Makefile: All occurences of '$?' should probably be replaced by '$^'.
>           Using '$?' make will only consider modified files, which is
>           wrong as you need always all for linking.
> 
> BUILDING: The line

Thanks, fixed.

> 
> 1. change to directory opencxx/parser and execute ptree-gen.sh
>
> should read
> 
> 1. change to directory occ-core/parser and execute ptree-gen.sh

Thanks, fixed.

BR
Grzegorz

Re: [Opencxx-users] [OpenC++ Core] core dump while walking through valid code

[Altac E. <al...@ya...>]

Hi,
By the way, I think there is another bug in
ClassWalker::TranslateInfix(), which leads to core
dump in some cases:

Ptree* ClassWalker::TranslateInfix(Ptree* exp)
{
    using namespace PtreeUtil;
    
    TypeInfo type;

    Ptree* left = First(exp);
    Ptree* right = Third(exp);
    Typeof(right, type);
    Class* metaobject = GetClassMetaobject(type);
    if(metaobject == 0){
	Typeof(left, type);
	metaobject = GetClassMetaobject(type);
    }

    else{ <<<==== !!!!
	Ptree* left2 = Translate(left);
	Ptree* right2 = Translate(right);
	if(left == left2 && right == right2)
	    return exp;
	else
	    return new PtreeInfixExpr(left2,
PtreeUtil::List(PtreeUtil::Second(exp),
							 right2));
    }
}

As you can see there is no 'return' if (metaobject ==
0). Why GCC isn't complaining about that, it's another
question...
I don't understand all the semantic, but I think there
are too many 'else'.

I've found this because you left two debug lines in
the code of Walker::TranslateDeclarators() :

		    exp->Display();
		    exp2->Display();

The second one core dump where walking through a code
like :

class A {
    void f() {
        int r = 1+(int)8;
    }
};

Regards,
Emmanuel

 --- Grzegorz Jakacki <ja...@ac...> a écrit : 
> Hi,
> 
> Altac Edena wrote:
> > Hi,
> > FYI, the 'elaboration-test-glue' test program core
> > dump when fed with the following code :
> > 
> > class A {
> >   void f() {
> >     int x(*this);
> >   }
> > };
> > 
> > * I've reduced the test case as much as possible,
> but
> > it's originating from STL stuff.
> > * The occ-core source is taken from CVS HEAD,
> today.
> > * The backtrace is :
> 
> Thanks for your great input, it helped a lot. This
> was a bug in 
> translation of unary operator (here dereferencing).
> I have fixed it, 
> added your file to unit tests and comitted, should
> work now.
> 
> BR
> Grzegorz
> 
> 
> > 
> > #0  0x0049d1bd in Opencxx::Ptree::Cdr() (this=0x0)
> at
> > occ-core/parser/Ptree.h:113
> > #1  0x00473d81 in
> > Opencxx::PtreeUtil::SubstSublist(Opencxx::Ptree*,
> > Opencxx::Ptree*, Opencxx::Ptree*)
> (newsub=0xa05c3b0,
> > oldsub=0xa05a790, lst=0x0) at
> > occ-core/parser/PtreeUtil.cc:613
> > #2  0x00473dac in
> > Opencxx::PtreeUtil::SubstSublist(Opencxx::Ptree*,
> > Opencxx::Ptree*, Opencxx::Ptree*)
> (newsub=0xa05c3b0,
> > oldsub=0xa05a790, lst=0xa05a7c0) at
> > occ-core/parser/PtreeUtil.cc:613
> > #3  0x0040dd62 in
> >
>
Opencxx::Walker::TranslateDeclarators(Opencxx::Ptree*,
> > bool) (this=0x22e730, decls=0xa05a810,
> record=true) at
> > occ-core/analyzer/Walker.cc:493
> > #4  0x0040d861 in
> >
>
Opencxx::Walker::TranslateDeclarators(Opencxx::Ptree*)
> > (this=0x22e730, decls=0xa05a810) at
> > occ-core/analyzer/Walker.cc:453
> > #5  0x0040d513 in
> >
>
Opencxx::Walker::TranslateDeclaration(Opencxx::Ptree*)
> > (this=0x22e730, def=0xa05a820) at
> > occ-core/analyzer/Walker.cc:429
> > #6  0x0046fce2 in
> >
>
Opencxx::PtreeDeclaration::Translate(Opencxx::AbstractTranslatingWalker*)
> > (this=0xa05a820, w=0x22e734) at
> > occ-core/parser/PtreeDeclaration.cc:59
> > #7  0x0040b6f4 in
> > Opencxx::Walker::Translate(Opencxx::Ptree*)
> > (this=0x22e730, p=0xa05a820) at
> > occ-core/analyzer/Walker.cc:178
> > #8  0x00406061 in
> >
>
Opencxx::ClassWalker::TranslateBlock(Opencxx::Ptree*)
> > (this=0x22e730, block=0xa05a880) at
> > occ-core/analyzer/ClassWalker.cc:627
> > #9  0x0046fc6b in
> >
>
Opencxx::PtreeBlock::Translate(Opencxx::AbstractTranslatingWalker*)
> > (this=0xa05a880, w=0x22e734) at
> > occ-core/parser/PtreeBlock.cc:53
> > #10 0x0040b6f4 in
> > Opencxx::Walker::Translate(Opencxx::Ptree*)
> > (this=0x22e730, p=0xa05a880) at
> > occ-core/analyzer/Walker.cc:178
> > #11 0x00405c9e in
> >
>
Opencxx::ClassWalker::TranslateFunctionBody(Opencxx::Ptree*)
> > (this=0x22e730, body=0xa05a880) at
> > occ-core/analyzer/ClassWalker.cc:599
> > #12 0x004240c4 in
> >
>
Opencxx::ClassBodyWalker::TranslateFunctionImplementation(Opencxx::Ptree*)
> > (this=0x22eaa0, impl=0xa05a8d0) at
> > occ-core/analyzer/ClassBodyWalker.cc:220
> > #13 0x0040d3df in
> >
>
Opencxx::Walker::TranslateDeclaration(Opencxx::Ptree*)
> > (this=0x22eaa0, def=0xa05a8d0) at
> > occ-core/analyzer/Walker.cc:418
> > #14 0x0046fce2 in
> >
>
Opencxx::PtreeDeclaration::Translate(Opencxx::AbstractTranslatingWalker*)
> > (this=0xa05a8d0, w=0x22eaa4) at
> > occ-core/parser/PtreeDeclaration.cc:59
> > #15 0x0040b6f4 in
> > Opencxx::Walker::Translate(Opencxx::Ptree*)
> > (this=0x22eaa0, p=0xa05a8d0) at
> > occ-core/analyzer/Walker.cc:178
> > #16 0x00422984 in
> >
>
Opencxx::ClassBodyWalker::TranslateClassBody(Opencxx::Ptree*,
> > Opencxx::Ptree*, Opencxx::Class*) (this=0x22eaa0,
> > block=0xa05a920, metaobject=0xa05a9b0)
> >     at occ-core/analyzer/ClassBodyWalker.cc:51
> > #17 0x0040235d in
> >
>
Opencxx::ClassWalker::TranslateClassSpec(Opencxx::Ptree*,
> > Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Class*)
> > (this=0x22ed80, spec=0xa05a568, userkey=0x0,
> > class_def=0xa05a568, 
> >     metaobject=0xa05a9b0) at
> > occ-core/analyzer/ClassWalker.cc:174
> > #18 0x00410116 in
> >
> Opencxx::Walker::TranslateClassSpec(Opencxx::Ptree*)
> > (this=0x22ed80, spec=0xa05a568) at
> > occ-core/analyzer/Walker.cc:799
> > #19 0x0047741e in
> >
>
Opencxx::PtreeClassSpec::Translate(Opencxx::AbstractTranslatingWalker*)
> > (this=0xa05a568, w=0x22ed84) at
> > occ-core/parser/PtreeClassSpec.cc:73
> > #20 0x0040b6f4 in
> > Opencxx::Walker::Translate(Opencxx::Ptree*)
> > (this=0x22ed80, p=0xa05a568) at
> > occ-core/analyzer/Walker.cc:178
> > #21 0x00412d7d in
> >
>
Opencxx::Walker::TranslateTypespecifier(Opencxx::Ptree*)
> > (this=0x22ed80, tspec=0xa05a568) at
> > occ-core/analyzer/Walker.cc:1108
> > #22 0x0040d4aa in
> >
>
Opencxx::Walker::TranslateDeclaration(Opencxx::Ptree*)
> > (this=0x22ed80, def=0xa05a970) at
> > occ-core/analyzer/Walker.cc:425
> > #23 0x0046fce2 in
> >
>
Opencxx::PtreeDeclaration::Translate(Opencxx::AbstractTranslatingWalker*)
> > (this=0xa05a970, w=0x22ed84) at
> > occ-core/parser/PtreeDeclaration.cc:59
> > #24 0x0040b6f4 in
> > Opencxx::Walker::Translate(Opencxx::Ptree*)
> > (this=0x22ed80, p=0xa05a970) at
> > occ-core/analyzer/Walker.cc:178
> > 
> > I'm not familiar enough with OpenC++ to
> investigate
> > further. 
> > Best regards,
> > Emmanuel
> > 
> > 
> > 
> > 	
> > 
> > 	
> > 		
> > Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace
> de stockage pour vos mails ! 
> > Créez votre Yahoo! Mail sur
> http://fr.mail.yahoo.com/
> > 
> > 
> >
>
-------------------------------------------------------
> > This SF.Net email is sponsored by: IntelliVIEW --
> Interactive Reporting
> > Tool for open source databases. Create drag-&-drop
> reports. Save time
> > by over 75%! Publish reports on the web. Export to
> DOC, XLS, RTF, etc.
> > Download a FREE copy at
> http://www.intelliview.com/go/osdn_nl
> > _______________________________________________
> > Opencxx-users mailing list
> > Ope...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/opencxx-users
> 
>  


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

[Opencxx-users] Undefined Reference Messages

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

Hello,

    I am having trouble using OpenC++ version 2.8.  I am trying to run OpenC++ on linux using the compiler gcc/g++.  Whenever I try to compile a OpenC++ program, I get a lot of undefined reference messages such as:


: undefined reference to `Opencxx::TheMetaclassRegistry()'
/tmp/cc3GEgkb.o(.gnu.linkonce.t._ZN7Opencxx21MetaclassRegistrationC1EPKcPFPNS_5ClassEPNS_5PtreeES6_EPFbvEPFS6_vE+0x62): In function `Opencxx::MetaclassRegistration::MetaclassRegistration[in-charge](char const*, Opencxx::Class* (*)(Opencxx::Ptree*, Opencxx::Ptree*), bool (*)(), Opencxx::Ptree* (*)())':
: undefined reference to `Opencxx::MetaclassRegistry::Add(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, Opencxx::Class* (*)(Opencxx::Ptree*, Opencxx::Ptree*), bool (*)(), Opencxx::Ptree* (*)())'
/tmp/cc3GEgkb.o(.gnu.linkonce.d._ZTI8JNIClass+0x8): undefined reference to `typeinfo for Opencxx::Class'
/tmp/cc3GEgkb.o(.gnu.linkonce.t._ZN7Opencxx5ClassC2Ev+0x8): In function `Opencxx::Class::Class[not-in-charge]()':

I think this is happening because there is a problem with linking files.  Another reason I think there is a problem with linking files is because whenever I pass an object file to occ, I get the following message:  "linker input file unused because linking not done".  So I was wondering what can be done to allow appropriate linking.  Thanks.

John Altidor

Re: [Opencxx-users] Encoding ambiguities

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

Shigeru Chiba wrote:
> This encoding scheme was copied from the method encoding scheme of
> the standard C++.  So, how does the current C++ compiler deal with
> A<1>?  We can follow.

For the record, here is a link to the 'mangling' spec that is
part of the C++ ABI: http://www.codesourcery.com/cxx-abi/abi.html#mangling

Thanks again for the quick reply !

Regards,
		Stefan

Re: [Opencxx-users] Encoding ambiguities

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

This encoding scheme was copied from the method encoding scheme of
the standard C++.  So, how does the current C++ compiler deal with
A<1>?  We can follow.

Regards,

Chiba

On 2005/ 2/2 , at 0:38, Stefan Seefeld wrote:

> [I sent this mail originally last summer (08/2004), but
>  didn't get any response. Hoping that this time someone
>  will listen I send it again.]
>
>
> hi there,
>
> while trying to enhance the Encoding API I'm looking
> at examples of encoded names I'll have to deal with.
> Doing that I find that
>
> ::A::B<A::Int, 2>::type
>
> maps to
>
> Q[4][0][1]AT[1]B[9]Q[2][1]A[3]Int*[4]type
>
> The point that worries me is the '*', which, according
> to the docs refers to a 'non-type template parameter'.
>
> That means types aren't represented unambiguously, as
> 'A<1>' will generate the same symbol as 'A<2>'. However,
> when doing symbol lookup, I obviously have to distinguish the
> two.
>
> Was that an oversight in OpenCxx ? Or was that deliberately
> left out as full symbol lookup wasn't done anyways ?
> Any ideas as to how to fix this ? Chiba ?
>
> Speaking of ambiguities in the Encoding class, I earlier
> this year reported the missing array dimensions, but didn't
> get feedback on this. Is there any interest into a fix ?
>
> Regards,
> 		Stefan

[Opencxx-users] Encoding ambiguities

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

[I sent this mail originally last summer (08/2004), but
  didn't get any response. Hoping that this time someone
  will listen I send it again.]


hi there,

while trying to enhance the Encoding API I'm looking
at examples of encoded names I'll have to deal with.
Doing that I find that

::A::B<A::Int, 2>::type

maps to

Q[4][0][1]AT[1]B[9]Q[2][1]A[3]Int*[4]type

The point that worries me is the '*', which, according
to the docs refers to a 'non-type template parameter'.

That means types aren't represented unambiguously, as
'A<1>' will generate the same symbol as 'A<2>'. However,
when doing symbol lookup, I obviously have to distinguish the
two.

Was that an oversight in OpenCxx ? Or was that deliberately
left out as full symbol lookup wasn't done anyways ?
Any ideas as to how to fix this ? Chiba ?

Speaking of ambiguities in the Encoding class, I earlier
this year reported the missing array dimensions, but didn't
get feedback on this. Is there any interest into a fix ?

Regards,
		Stefan

Re: [Opencxx-users] [OpenC++ Core] core dump while walking through valid code

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

Grzegorz Jakacki wrote:
> Stefan Seefeld wrote:
> 
>> I'v just tried compiling occ-core myself (on fedora core 3)
>> but got a bunch of errors during the build. So I can't
>> even reproduce your test :-(
> 
> 
> I have just built on fedora core 2. Maybe you missed instructions in 
> BUILDING ? I have just added ./configure to streamline the process, HTH.

The main problem stems from the use of '-fprofile-arcs -ftest-coverage'
during compilation. If I add '-fprofile-arcs' to the link command everything
works fine (ommitting that option during linking will result in unresolved
symbols, as some profiler library needs to be linked in).
If you intend the toplevel Makefile to be generic you probably want to
left the above options out alltogether to be safe.
Else an additional configure step may be in order so you can check what
is and is not available on the current platform.

Some nit-picking:

Makefile: All occurences of '$?' should probably be replaced by '$^'.
           Using '$?' make will only consider modified files, which is
           wrong as you need always all for linking.

BUILDING: The line

1. change to directory opencxx/parser and execute ptree-gen.sh

should read

1. change to directory occ-core/parser and execute ptree-gen.sh

Regards,
		Stefan

Re: [Opencxx-users] [OpenC++ Core] core dump while walking through valid code

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

Stefan Seefeld wrote:
> I'v just tried compiling occ-core myself (on fedora core 3)
> but got a bunch of errors during the build. So I can't
> even reproduce your test :-(

I have just built on fedora core 2. Maybe you missed instructions in 
BUILDING ? I have just added ./configure to streamline the process, HTH.

BR
Grzegorz


> 
> Regards,
>         Stefan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] [OpenC++ Core] core dump while walking through valid code

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

Hi,

Altac Edena wrote:
> Hi,
> FYI, the 'elaboration-test-glue' test program core
> dump when fed with the following code :
> 
> class A {
>   void f() {
>     int x(*this);
>   }
> };
> 
> * I've reduced the test case as much as possible, but
> it's originating from STL stuff.
> * The occ-core source is taken from CVS HEAD, today.
> * The backtrace is :

Thanks for your great input, it helped a lot. This was a bug in 
translation of unary operator (here dereferencing). I have fixed it, 
added your file to unit tests and comitted, should work now.

BR
Grzegorz


> 
> #0  0x0049d1bd in Opencxx::Ptree::Cdr() (this=0x0) at
> occ-core/parser/Ptree.h:113
> #1  0x00473d81 in
> Opencxx::PtreeUtil::SubstSublist(Opencxx::Ptree*,
> Opencxx::Ptree*, Opencxx::Ptree*) (newsub=0xa05c3b0,
> oldsub=0xa05a790, lst=0x0) at
> occ-core/parser/PtreeUtil.cc:613
> #2  0x00473dac in
> Opencxx::PtreeUtil::SubstSublist(Opencxx::Ptree*,
> Opencxx::Ptree*, Opencxx::Ptree*) (newsub=0xa05c3b0,
> oldsub=0xa05a790, lst=0xa05a7c0) at
> occ-core/parser/PtreeUtil.cc:613
> #3  0x0040dd62 in
> Opencxx::Walker::TranslateDeclarators(Opencxx::Ptree*,
> bool) (this=0x22e730, decls=0xa05a810, record=true) at
> occ-core/analyzer/Walker.cc:493
> #4  0x0040d861 in
> Opencxx::Walker::TranslateDeclarators(Opencxx::Ptree*)
> (this=0x22e730, decls=0xa05a810) at
> occ-core/analyzer/Walker.cc:453
> #5  0x0040d513 in
> Opencxx::Walker::TranslateDeclaration(Opencxx::Ptree*)
> (this=0x22e730, def=0xa05a820) at
> occ-core/analyzer/Walker.cc:429
> #6  0x0046fce2 in
> Opencxx::PtreeDeclaration::Translate(Opencxx::AbstractTranslatingWalker*)
> (this=0xa05a820, w=0x22e734) at
> occ-core/parser/PtreeDeclaration.cc:59
> #7  0x0040b6f4 in
> Opencxx::Walker::Translate(Opencxx::Ptree*)
> (this=0x22e730, p=0xa05a820) at
> occ-core/analyzer/Walker.cc:178
> #8  0x00406061 in
> Opencxx::ClassWalker::TranslateBlock(Opencxx::Ptree*)
> (this=0x22e730, block=0xa05a880) at
> occ-core/analyzer/ClassWalker.cc:627
> #9  0x0046fc6b in
> Opencxx::PtreeBlock::Translate(Opencxx::AbstractTranslatingWalker*)
> (this=0xa05a880, w=0x22e734) at
> occ-core/parser/PtreeBlock.cc:53
> #10 0x0040b6f4 in
> Opencxx::Walker::Translate(Opencxx::Ptree*)
> (this=0x22e730, p=0xa05a880) at
> occ-core/analyzer/Walker.cc:178
> #11 0x00405c9e in
> Opencxx::ClassWalker::TranslateFunctionBody(Opencxx::Ptree*)
> (this=0x22e730, body=0xa05a880) at
> occ-core/analyzer/ClassWalker.cc:599
> #12 0x004240c4 in
> Opencxx::ClassBodyWalker::TranslateFunctionImplementation(Opencxx::Ptree*)
> (this=0x22eaa0, impl=0xa05a8d0) at
> occ-core/analyzer/ClassBodyWalker.cc:220
> #13 0x0040d3df in
> Opencxx::Walker::TranslateDeclaration(Opencxx::Ptree*)
> (this=0x22eaa0, def=0xa05a8d0) at
> occ-core/analyzer/Walker.cc:418
> #14 0x0046fce2 in
> Opencxx::PtreeDeclaration::Translate(Opencxx::AbstractTranslatingWalker*)
> (this=0xa05a8d0, w=0x22eaa4) at
> occ-core/parser/PtreeDeclaration.cc:59
> #15 0x0040b6f4 in
> Opencxx::Walker::Translate(Opencxx::Ptree*)
> (this=0x22eaa0, p=0xa05a8d0) at
> occ-core/analyzer/Walker.cc:178
> #16 0x00422984 in
> Opencxx::ClassBodyWalker::TranslateClassBody(Opencxx::Ptree*,
> Opencxx::Ptree*, Opencxx::Class*) (this=0x22eaa0,
> block=0xa05a920, metaobject=0xa05a9b0)
>     at occ-core/analyzer/ClassBodyWalker.cc:51
> #17 0x0040235d in
> Opencxx::ClassWalker::TranslateClassSpec(Opencxx::Ptree*,
> Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Class*)
> (this=0x22ed80, spec=0xa05a568, userkey=0x0,
> class_def=0xa05a568, 
>     metaobject=0xa05a9b0) at
> occ-core/analyzer/ClassWalker.cc:174
> #18 0x00410116 in
> Opencxx::Walker::TranslateClassSpec(Opencxx::Ptree*)
> (this=0x22ed80, spec=0xa05a568) at
> occ-core/analyzer/Walker.cc:799
> #19 0x0047741e in
> Opencxx::PtreeClassSpec::Translate(Opencxx::AbstractTranslatingWalker*)
> (this=0xa05a568, w=0x22ed84) at
> occ-core/parser/PtreeClassSpec.cc:73
> #20 0x0040b6f4 in
> Opencxx::Walker::Translate(Opencxx::Ptree*)
> (this=0x22ed80, p=0xa05a568) at
> occ-core/analyzer/Walker.cc:178
> #21 0x00412d7d in
> Opencxx::Walker::TranslateTypespecifier(Opencxx::Ptree*)
> (this=0x22ed80, tspec=0xa05a568) at
> occ-core/analyzer/Walker.cc:1108
> #22 0x0040d4aa in
> Opencxx::Walker::TranslateDeclaration(Opencxx::Ptree*)
> (this=0x22ed80, def=0xa05a970) at
> occ-core/analyzer/Walker.cc:425
> #23 0x0046fce2 in
> Opencxx::PtreeDeclaration::Translate(Opencxx::AbstractTranslatingWalker*)
> (this=0xa05a970, w=0x22ed84) at
> occ-core/parser/PtreeDeclaration.cc:59
> #24 0x0040b6f4 in
> Opencxx::Walker::Translate(Opencxx::Ptree*)
> (this=0x22ed80, p=0xa05a970) at
> occ-core/analyzer/Walker.cc:178
> 
> I'm not familiar enough with OpenC++ to investigate
> further. 
> Best regards,
> Emmanuel
> 
> 
> 
> 	
> 
> 	
> 		
> Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
> Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] [OpenC++ Core] core dump while walking through valid code

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

Altac Edena wrote:
> Hi,
> FYI, the 'elaboration-test-glue' test program core
> dump when fed with the following code :
> 
> class A {
>   void f() {
>     int x(*this);
>   }
> };
> 
> * I've reduced the test case as much as possible, but
> it's originating from STL stuff.
> * The occ-core source is taken from CVS HEAD, today.
> * The backtrace is :
> 
> #0  0x0049d1bd in Opencxx::Ptree::Cdr() (this=0x0) at
> occ-core/parser/Ptree.h:113
> #1  0x00473d81 in
> Opencxx::PtreeUtil::SubstSublist(Opencxx::Ptree*,
> Opencxx::Ptree*, Opencxx::Ptree*) (newsub=0xa05c3b0,
> oldsub=0xa05a790, lst=0x0) at
> occ-core/parser/PtreeUtil.cc:613
> #2  0x00473dac in
> Opencxx::PtreeUtil::SubstSublist(Opencxx::Ptree*,
> Opencxx::Ptree*, Opencxx::Ptree*) (newsub=0xa05c3b0,
> oldsub=0xa05a790, lst=0xa05a7c0) at
> occ-core/parser/PtreeUtil.cc:613

[...]

the above snippet shows that the SubstSublist() function
dereferences a nil ptree node, i.e. it finds a parse
tree it doesn't expect.
The simplest thing to do is probably to call the 'Display()'
member of one of the immediate parents to print out
the content of the relevant portion of the parse tree.
Then you have to search for 'nil' elements and figure
out whether there are any which occ doesn't expect.
At least that may help you reproducing a smaller
test case that still lets occ fall over.

I'v just tried compiling occ-core myself (on fedora core 3)
but got a bunch of errors during the build. So I can't
even reproduce your test :-(

Regards,
		Stefan

[Opencxx-users] [OpenC++ Core] core dump while walking through valid code

[Altac E. <al...@ya...>]

Hi,
FYI, the 'elaboration-test-glue' test program core
dump when fed with the following code :

class A {
  void f() {
    int x(*this);
  }
};

* I've reduced the test case as much as possible, but
it's originating from STL stuff.
* The occ-core source is taken from CVS HEAD, today.
* The backtrace is :

#0  0x0049d1bd in Opencxx::Ptree::Cdr() (this=0x0) at
occ-core/parser/Ptree.h:113
#1  0x00473d81 in
Opencxx::PtreeUtil::SubstSublist(Opencxx::Ptree*,
Opencxx::Ptree*, Opencxx::Ptree*) (newsub=0xa05c3b0,
oldsub=0xa05a790, lst=0x0) at
occ-core/parser/PtreeUtil.cc:613
#2  0x00473dac in
Opencxx::PtreeUtil::SubstSublist(Opencxx::Ptree*,
Opencxx::Ptree*, Opencxx::Ptree*) (newsub=0xa05c3b0,
oldsub=0xa05a790, lst=0xa05a7c0) at
occ-core/parser/PtreeUtil.cc:613
#3  0x0040dd62 in
Opencxx::Walker::TranslateDeclarators(Opencxx::Ptree*,
bool) (this=0x22e730, decls=0xa05a810, record=true) at
occ-core/analyzer/Walker.cc:493
#4  0x0040d861 in
Opencxx::Walker::TranslateDeclarators(Opencxx::Ptree*)
(this=0x22e730, decls=0xa05a810) at
occ-core/analyzer/Walker.cc:453
#5  0x0040d513 in
Opencxx::Walker::TranslateDeclaration(Opencxx::Ptree*)
(this=0x22e730, def=0xa05a820) at
occ-core/analyzer/Walker.cc:429
#6  0x0046fce2 in
Opencxx::PtreeDeclaration::Translate(Opencxx::AbstractTranslatingWalker*)
(this=0xa05a820, w=0x22e734) at
occ-core/parser/PtreeDeclaration.cc:59
#7  0x0040b6f4 in
Opencxx::Walker::Translate(Opencxx::Ptree*)
(this=0x22e730, p=0xa05a820) at
occ-core/analyzer/Walker.cc:178
#8  0x00406061 in
Opencxx::ClassWalker::TranslateBlock(Opencxx::Ptree*)
(this=0x22e730, block=0xa05a880) at
occ-core/analyzer/ClassWalker.cc:627
#9  0x0046fc6b in
Opencxx::PtreeBlock::Translate(Opencxx::AbstractTranslatingWalker*)
(this=0xa05a880, w=0x22e734) at
occ-core/parser/PtreeBlock.cc:53
#10 0x0040b6f4 in
Opencxx::Walker::Translate(Opencxx::Ptree*)
(this=0x22e730, p=0xa05a880) at
occ-core/analyzer/Walker.cc:178
#11 0x00405c9e in
Opencxx::ClassWalker::TranslateFunctionBody(Opencxx::Ptree*)
(this=0x22e730, body=0xa05a880) at
occ-core/analyzer/ClassWalker.cc:599
#12 0x004240c4 in
Opencxx::ClassBodyWalker::TranslateFunctionImplementation(Opencxx::Ptree*)
(this=0x22eaa0, impl=0xa05a8d0) at
occ-core/analyzer/ClassBodyWalker.cc:220
#13 0x0040d3df in
Opencxx::Walker::TranslateDeclaration(Opencxx::Ptree*)
(this=0x22eaa0, def=0xa05a8d0) at
occ-core/analyzer/Walker.cc:418
#14 0x0046fce2 in
Opencxx::PtreeDeclaration::Translate(Opencxx::AbstractTranslatingWalker*)
(this=0xa05a8d0, w=0x22eaa4) at
occ-core/parser/PtreeDeclaration.cc:59
#15 0x0040b6f4 in
Opencxx::Walker::Translate(Opencxx::Ptree*)
(this=0x22eaa0, p=0xa05a8d0) at
occ-core/analyzer/Walker.cc:178
#16 0x00422984 in
Opencxx::ClassBodyWalker::TranslateClassBody(Opencxx::Ptree*,
Opencxx::Ptree*, Opencxx::Class*) (this=0x22eaa0,
block=0xa05a920, metaobject=0xa05a9b0)
    at occ-core/analyzer/ClassBodyWalker.cc:51
#17 0x0040235d in
Opencxx::ClassWalker::TranslateClassSpec(Opencxx::Ptree*,
Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Class*)
(this=0x22ed80, spec=0xa05a568, userkey=0x0,
class_def=0xa05a568, 
    metaobject=0xa05a9b0) at
occ-core/analyzer/ClassWalker.cc:174
#18 0x00410116 in
Opencxx::Walker::TranslateClassSpec(Opencxx::Ptree*)
(this=0x22ed80, spec=0xa05a568) at
occ-core/analyzer/Walker.cc:799
#19 0x0047741e in
Opencxx::PtreeClassSpec::Translate(Opencxx::AbstractTranslatingWalker*)
(this=0xa05a568, w=0x22ed84) at
occ-core/parser/PtreeClassSpec.cc:73
#20 0x0040b6f4 in
Opencxx::Walker::Translate(Opencxx::Ptree*)
(this=0x22ed80, p=0xa05a568) at
occ-core/analyzer/Walker.cc:178
#21 0x00412d7d in
Opencxx::Walker::TranslateTypespecifier(Opencxx::Ptree*)
(this=0x22ed80, tspec=0xa05a568) at
occ-core/analyzer/Walker.cc:1108
#22 0x0040d4aa in
Opencxx::Walker::TranslateDeclaration(Opencxx::Ptree*)
(this=0x22ed80, def=0xa05a970) at
occ-core/analyzer/Walker.cc:425
#23 0x0046fce2 in
Opencxx::PtreeDeclaration::Translate(Opencxx::AbstractTranslatingWalker*)
(this=0xa05a970, w=0x22ed84) at
occ-core/parser/PtreeDeclaration.cc:59
#24 0x0040b6f4 in
Opencxx::Walker::Translate(Opencxx::Ptree*)
(this=0x22ed80, p=0xa05a970) at
occ-core/analyzer/Walker.cc:178

I'm not familiar enough with OpenC++ to investigate
further. 
Best regards,
Emmanuel



	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

Re: [Opencxx-users] Re: type of ptree nodes

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

Grzegorz Jakacki wrote:

>  > Licenses cover code, not design nor ideas. I'm talking about sharing
>  > insight and ideas. And, as I'v suggested before, I have absolutely no
>  > problem sending in patches to OpenCxx under any Free License you choose
>  > to use.
> 
> Does it mean that you agree that your changes to OpenC++ (currently 
> published as a part of Synopsis under LGPL) are merged into OpenC++ 
> under OpenC++ license?

I'm talking about patches which I'd happily distribute under any free license
you feel comfortable with.
I think that if you would look at the Synopsis code you would agree that there
isn't any set of patches I could sensibly produce against the current OpenC++
code base.
So the question you are really asking (again) is whether I would relicense
Synopsis code under an OpenC++ license. The answer to that question is still no.
(For reasons please use the OpenC++ ML archive.)

Regards,
		Stefan

Re: [Opencxx-users] Re: type of ptree nodes

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

Stefan Seefeld wrote:
 > Grzegorz Jakacki wrote:
 >
 >> Stefan Seefeld wrote:
 >>
 >>> As I'd like to work on this in the context of synopsis, I'd definitely
 >>> prefer to collaborate, i.e. at least try to design (and document) the
 >>> missing pieces of the parse tree together with OpenCxx developers.
 >>
 >>
 >>
 >> You would like to collaborate but you oppose sharing the results with
 >> OpenC++ under its license. Such "collaboration" does not bring any
 >> value to OpenC++ project and I suggest that you don't distract people
 >> on OpenC++ list with it. I am under impression that I told you that
 >> already.
 >
 > Licenses cover code, not design nor ideas. I'm talking about sharing
 > insight and ideas. And, as I'v suggested before, I have absolutely no
 > problem sending in patches to OpenCxx under any Free License you choose
 > to use.

Does it mean that you agree that your changes to OpenC++ (currently 
published as a part of Synopsis under LGPL) are merged into OpenC++ 
under OpenC++ license?

BR
Grzegorz

[Opencxx-users] Re: questions on openC++

[sdflemin <sdf...@cs...>]

Hi Sheng,
The problem you describe here looks like an occ bug found in version 2.8. 
Basically, certain occ command-line options are not passed to the C++ 
preprocessor as they should be (in your case, the -I option). A fix for this 
problem was described in:

http://sourceforge.net/mailarchive/message.php?msg_id=9785370

I have used this fix myself, and it has been quite helpful.
Cheers, Scott


 > Hi,
 >
 > I got some problems while tying using it.
 >
 > I tried to run the Verbose example, at
 > examples/verbose,
 > but I got :
 >
 > [sheng@truth opencxx-2.8]$ ./occ
 > -I/home/sheng/software/opencxx-2.8 -m
 > examples/verbose/VerboseClass.mc
 > EXECUTING: g++ g++ -D__opencxx -E -o VerboseClass.occ
 > -x c++ examples/verbose/VerboseClass.mc
 > examples/verbose/VerboseClass.mc:38:25: opencxx/mop.h:
 > No such file or directory
 >
 > [sheng@truth opencxx-2.8]$ ./occ2
 > -I/home/sheng/software/opencxx-2.8 -m
 > examples/verbose/VerboseClass.mc
 > libtool: unrecognized option `--tag=CXX"
 > Try `libtool --help" for more information.
 > occ2: command failed: libtool --tag=CXX --mode=compile
 > --silent g++ -c VerboseClass.2.ii -o VerboseClass.lo
 >
 > I checked ./opencxx directory, mop.h is there. Is
 > there something wrong with my usage?
 >
 > Here is another question about openC++, does it
 > support  all features of ISO/C++ standard? I am
 > thinking whether I can use it to check some large C++
 > source repostories  such as Mozilla or KDE.
 >
 > Thanks a lot!
 >
 > Best wishes,
 > Sheng
 >

Re: [Opencxx-users] questions on openC++

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

Sheng Wang wrote:
> Hi,
> 
> I got some problems while tying using it. 
> 
> I tried to run the Verbose example, at
> examples/verbose,
> but I got : 
> 
> [sheng@truth opencxx-2.8]$ ./occ
> -I/home/sheng/software/opencxx-2.8 -m
> examples/verbose/VerboseClass.mc
> EXECUTING: g++ g++ -D__opencxx -E -o VerboseClass.occ
> -x c++ examples/verbose/VerboseClass.mc
> examples/verbose/VerboseClass.mc:38:25: opencxx/mop.h:
> No such file or directory
> 
> [sheng@truth opencxx-2.8]$ ./occ2
> -I/home/sheng/software/opencxx-2.8 -m
> examples/verbose/VerboseClass.mc
> libtool: unrecognized option `--tag=CXX'
> Try `libtool --help' for more information.
> occ2: command failed: libtool --tag=CXX --mode=compile
> --silent g++ -c VerboseClass.2.ii -o VerboseClass.lo

Looks like you are using old libtool, which does not understand '--tag' 
option.

> I checked ./opencxx directory, mop.h is there. Is
> there something wrong with my usage? 

Should be fine after upgrading libtool. If not, pls. let me know.

> Here is another question about openC++, does it
> support  all features of ISO/C++ standard? I am
> thinking whether I can use it to check some large C++
> source repostories  such as Mozilla or KDE.

No, it does not. It will not correctly identify all overloadings and 
templates. We are aiming at it, but it requires lots of resources to 
cover all the features.

BR
Grzegorz

Re: [Opencxx-users] Re: type of ptree nodes

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

Grzegorz Jakacki wrote:
> Stefan Seefeld wrote:
> 
>> As I'd like to work on this in the context of synopsis, I'd definitely
>> prefer to collaborate, i.e. at least try to design (and document) the
>> missing pieces of the parse tree together with OpenCxx developers.
> 
> 
> You would like to collaborate but you oppose sharing the results with 
> OpenC++ under its license. Such "collaboration" does not bring any value 
> to OpenC++ project and I suggest that you don't distract people on 
> OpenC++ list with it. I am under impression that I told you that already.

Licenses cover code, not design nor ideas. I'm talking about sharing
insight and ideas. And, as I'v suggested before, I have absolutely no
problem sending in patches to OpenCxx under any Free License you choose
to use.
These patches would be OpenCxx-specific anyways, as synopsis' code base
has evolved quite a bit, so there is very little common code now.

My offer still stands.

Regards,
		Stefan

[Opencxx-users] questions on openC++

[Sheng W. <she...@ya...>]

Hi,

I got some problems while tying using it. 

I tried to run the Verbose example, at
examples/verbose,
but I got : 

[sheng@truth opencxx-2.8]$ ./occ
-I/home/sheng/software/opencxx-2.8 -m
examples/verbose/VerboseClass.mc
EXECUTING: g++ g++ -D__opencxx -E -o VerboseClass.occ
-x c++ examples/verbose/VerboseClass.mc
examples/verbose/VerboseClass.mc:38:25: opencxx/mop.h:
No such file or directory

[sheng@truth opencxx-2.8]$ ./occ2
-I/home/sheng/software/opencxx-2.8 -m
examples/verbose/VerboseClass.mc
libtool: unrecognized option `--tag=CXX'
Try `libtool --help' for more information.
occ2: command failed: libtool --tag=CXX --mode=compile
--silent g++ -c VerboseClass.2.ii -o VerboseClass.lo

I checked ./opencxx directory, mop.h is there. Is
there something wrong with my usage? 

Here is another question about openC++, does it
support  all features of ISO/C++ standard? I am
thinking whether I can use it to check some large C++
source repostories  such as Mozilla or KDE.

Thanks a lot!

Best wishes,
Sheng


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

Re: [Opencxx-users] Re: type of ptree nodes

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

Stefan Seefeld wrote:
> As I'd like to work on this in the context of synopsis, I'd definitely
> prefer to collaborate, i.e. at least try to design (and document) the
> missing pieces of the parse tree together with OpenCxx developers.

You would like to collaborate but you oppose sharing the results with 
OpenC++ under its license. Such "collaboration" does not bring any value 
to OpenC++ project and I suggest that you don't distract people on 
OpenC++ list with it. I am under impression that I told you that already.

> Is there any interest into this from OpenCxx users / developers ? Is
> OpenCxx still being developped at this point ?

Yes, there are two developers working currently on better demos and 
Environment class (Vinzenz Feenstra and Chen Bilong).

BR
Grzegorz

[Opencxx-users] Re: type of ptree nodes

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

Hi Chiba,

thanks for the quick response !

Shigeru Chiba wrote:

> The implementation of the using declaration is quite temporal.  It was 
> added
> to OpenC++ when the using declaration was introduced in the C++ standard.
> It should be reimplemented as you wrote.

Thank you, that confirms my impression.

>> A similar situation is with 'typedef' declarations. The type specifier,
>> too, is just a list of atoms, instead of something with an encoded 
>> name / type.
>> Why is that ?
> 
> 
> That is because I didn't need the encoded name/type when I was writing 
> OpenC++.
> If you need it, sure, you should extend the type specifier.  The program 
> includes
> a number of things that have not been implemented since I didn't have 
> time to do
> it.  I carefully prioritized what I should implement first to maximize 
> my productivity!

As I'd like to work on this in the context of synopsis, I'd definitely
prefer to collaborate, i.e. at least try to design (and document) the
missing pieces of the parse tree together with OpenCxx developers.
Is there any interest into this from OpenCxx users / developers ? Is
OpenCxx still being developped at this point ?

Kind regards,
		Stefan

[Opencxx-users] Re: type of ptree nodes

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

Hi,

On 2005/ 1/27 , at 14:42, Stefan Seefeld wrote:

> Hello,
>
> I'm currently working on a new symbol lookup module using the parse 
> tree and
> the parser originally developed as part of OpenCxx. In this context, 
> I'v
> ran into a couple of contexts where I don't understand why the parse 
> tree
> is structured the way it is, and I'd like to know whether it could be 
> changed.
> For example, the name in a 'using' declaration / directive will simply 
> be
> a list of atoms, instead of a 'Name' (say), so it is impossible to 
> extract
> the encoded name from it.
> However, as the Using type is currently not used at all (the Walker 
> returns
> it unchanged, and Environment doesn't know about it either) it seems 
> as if
> this could be easily changed, if there is no other reason for the 
> current
> layout.

The implementation of the using declaration is quite temporal.  It was 
added
to OpenC++ when the using declaration was introduced in the C++ 
standard.
It should be reimplemented as you wrote.

> A similar situation is with 'typedef' declarations. The type specifier,
> too, is just a list of atoms, instead of something with an encoded 
> name / type.
> Why is that ?

That is because I didn't need the encoded name/type when I was writing 
OpenC++.
If you need it, sure, you should extend the type specifier.  The 
program includes
a number of things that have not been implemented since I didn't have 
time to do
it.  I carefully prioritized what I should implement first to maximize 
my productivity!

Chiba

[Opencxx-users] type of ptree nodes

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

Hello,

I'm currently working on a new symbol lookup module using the parse tree and
the parser originally developed as part of OpenCxx. In this context, I'v
ran into a couple of contexts where I don't understand why the parse tree
is structured the way it is, and I'd like to know whether it could be changed.
For example, the name in a 'using' declaration / directive will simply be
a list of atoms, instead of a 'Name' (say), so it is impossible to extract
the encoded name from it.
However, as the Using type is currently not used at all (the Walker returns
it unchanged, and Environment doesn't know about it either) it seems as if
this could be easily changed, if there is no other reason for the current
layout.
A similar situation is with 'typedef' declarations. The type specifier,
too, is just a list of atoms, instead of something with an encoded name / type.
Why is that ?

Thanks for any help,
		Stefan

Re: [Opencxx-users] Re: parsing, manipulating, regenerating c++ code

[<ib...@co...>]

We are using an XML representation of C/C++ (srcML) to manipulate C/C++ s=
ource
code. SrcML preserves all layout and preprocessor information of the orig=
inal
code and therefore is able to produce an exact copy of the original code.=
 You
can find more information about srcML here:

http://www.sdml.info/projects/srcml/

We are using srcML and XSLT to build a weaver for C/C++ (Java is planned =
too).
The aim of the weaver (XWeaver) is to produce code that looks like manual=
ly
written code. It is designed to be extensible (writing your own weaving r=
ules),
so you're maybe interested in using XWeaver for your task (XWeaver is Ope=
n
Source and under a GPL License). For more information see the XWeaver Hom=
epage:

http://www.pnp-software.com/XWeaver/

Regards,
Iwan


Andrew Delong wrote:

> Regarding the message from Maarten de Boer:
>
>> I am looking for an application that can parse c++, store it in a AST,
>> and regenerate the original c++ code.
>
> I also could use this exact functionality. I want to use OpenC++ as a
> source-to-source translation tool that operates on both hpp and cpp
> files, but it must preserve #include etc in the final output. In the
> end, the final headers will be used by other source files without occ.
>
> If OpenC++ still cannot provide this ability, I'd be happy to
> contribute as long as it's a relatively small thing to do (I only have
> two weeks to finish my project :~)
>
> This is a great project by the way, nice work Volunteers...
>
>     Andrew
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users