opencxx-users

Re: [Opencxx-users] MSVC branche

[Asen K. <kov...@tr...>]

What I did was I created an empty project and dragged the files in it.
I guess I should compile a list of the files being used.

Basically this sandbox is different than the new version that has =
different filenames, etc.
I will most likely wait for the current version to mature before I try =
and integrate it again.
(Besides my schedule doesn't really provide enough time for me to do it =
right now)

In any case these should be the files that are being used (list of what =
I have in my project):

buffer.cc
cbodywalk.cc
classwalk.cc
driver.cc
driver2.cpp
encoding.cc
env.cc
hash.cc
main-con.cc
member.cc
metaclass.cc
mop.cc
parse.cc
pattern.cc
ptree-core.cc
ptree.cc
quote-class.cc
token.cc
typeinfo.cc
walker.cc
buffer.h
cbodywalk.h
classwalk.h
encoding.h
env.h
hash.h
member.h
metaclass.h
mop.h
parse.h
ptree-core.h
ptree.h
quote-class.h
token.h
type_info.h
types.h
walker.h

  ----- Original Message -----=20
  From: Grzegorz Jakacki=20
  To: mr...@im...=20
  Cc: OpenC++ ; Asen Kovachev ; Ferdinand Prantl=20
  Sent: Saturday, May 08, 2004 6:34 PM
  Subject: Re: [Opencxx-users] MSVC branche


  On Fri, 7 May 2004, Mathieu Roger wrote:

  > Hi,
  > I have downloaded the msvc branche "sandbox_asen_kovachev_msvc" but =
now
  > I am wondering how to compile it...

  All branches whose names start with 'sandbox_' are developers' private
  working areas, so don't expect that they will build out-of-the-box.

  There is no official MSVC branch. Asen and Ferdinand are OpenC++-MSVC
  gurus, hopefully they can help you to build on MSVC (you may also =
search
  the list archive for their postings).

  > does it mean that it can be compiled with MSVC or that it can be =
used as
  > the underlying compiler for MSVC ?

  Both.

  > another question about compiling openc++ under windows is that =
compiling
  > with cygwin fails for me...

  It is difficult to provide any help unless you specify how it fails =
and
  what versions of tools you are using (gcc, autoconf, libtool, =
automake,
  make).

  BR
  Grzegorz

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




  -------------------------------------------------------
  This SF.Net email is sponsored by Sleepycat Software
  Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to =
deliver
  higher performing products faster, at low TCO.
  http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3
  _______________________________________________
  Opencxx-users mailing list
  Ope...@li...
  https://lists.sourceforge.net/lists/listinfo/opencxx-users

[Opencxx-users] Implementing a iContract like tool for C++ with OpenC++

[Aitor Garay-R. <ter...@gm...>]

Hi there!,

	Lately I have been thinking on how it could be possible to implement an
iContract like tool for C++.  iContract is a Design by Contract tool for
Java.  The basic idea is to parse the C++ source code looking for special
comment blocks that specify the precondition/postcondition/invariants of the
class.  Then the input source code is extended with code that check the
contracts at runtime.
	There are a few options for implementing such a DbC tool for C++.  I have
come to OpenC++ and believe that is the most promising way to implement it
"easily".  Other alternatives I'm considering are implementing a standalone
application that uses some freely available grammar or may be extending the
AspectC compiler.
	I have no experience at all with OpenC++ and I have a few doubts.

	- do OpenC++ meta-programs have access to the source code comments?
	- are the meta-programs able to transverse the inheritance hierarchy of a
given class?
	- how well does OpenC++ handle macros?  And namespaces?
	- is it possible to introduce new methods in the generated classes?  Is it
possible to do arbitrary transformations like nesting the body of a method
inside some try/catch blocks?

	Sorry for the long list of questions, it would be very helpful if I can get
a rough idea of OpenC++ possibilities before getting deep into it.  Has
someone hear about some similar effort of implementing DbC for C++?  Any
ideas?

	Thanks!,

	/AITOR

Re: [Opencxx-users] MSVC branche

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

On Fri, 7 May 2004, Mathieu Roger wrote:

> Hi,
> I have downloaded the msvc branche "sandbox_asen_kovachev_msvc" but now
> I am wondering how to compile it...

All branches whose names start with 'sandbox_' are developers' private
working areas, so don't expect that they will build out-of-the-box.

There is no official MSVC branch. Asen and Ferdinand are OpenC++-MSVC
gurus, hopefully they can help you to build on MSVC (you may also search
the list archive for their postings).

> does it mean that it can be compiled with MSVC or that it can be used as
> the underlying compiler for MSVC ?

Both.

> another question about compiling openc++ under windows is that compiling
> with cygwin fails for me...

It is difficult to provide any help unless you specify how it fails and
what versions of tools you are using (gcc, autoconf, libtool, automake,
make).

BR
Grzegorz

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

[Opencxx-users] MSVC branche

[Mathieu R. <mat...@im...>]

Hi,
I have downloaded the msvc branche "sandbox_asen_kovachev_msvc" but now 
I am wondering how to compile it...
does it mean that it can be compiled with MSVC or that it can be used as 
the underlying compiler for MSVC ?
another question about compiling openc++ under windows is that compiling 
with cygwin fails for me...

Thanks

Re: [Opencxx-users] template data member

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

On Thu, 29 Apr 2004, Russell Balest wrote:

>
>  I have a template data member:
>
> class Foo {
>  vector<int> bar;
> }
>
> FullTypeName() returns  "vector"
> If I qualify vector with "std" then it only returns "std".
>
> With Grzegorz direction I tracked this down to the following:
>
> The encoding looks correct.   It is this:
> "T\206vector\201i"
>
> The trouble is that FullTypeName() calls MakeLeaf() which just returns
> the first 6 characters "vector".
>
> Is the bug in calling MakeLeaf()  or should MakeLeaf() continue parsing
> after vector and add more info?

Looks like a bug in FullTypeName().

BR
GJ

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

Re: [Opencxx-users] template data member

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

Russell Balest wrote:
> 
> I have a template data member:
> 
> class Foo {
> vector<int> bar;
> }
> 
> FullTypeName() returns  "vector"
> If I qualify vector with "std" then it only returns "std".
> 
> With Grzegorz direction I tracked this down to the following:
> 
> The encoding looks correct.   It is this:
> "T\206vector\201i"
> 
> The trouble is that FullTypeName() calls MakeLeaf() which just returns 
> the first 6 characters "vector".
> 
> Is the bug in calling MakeLeaf()  or should MakeLeaf() continue parsing 
> after vector and add more info?

I believe opencxx' support for templates is quite limitted right now.
We had to hack it quite a bit to get a little more template support
into synopsis (a tool that uses an opencxx fork), and even that is
by far not complete.
I can't tell how much of that work got backported into opencxx, though,

Regards,
		Stefan

[Opencxx-users] template data member

[Russell B. <ru...@ba...>]

 I have a template data member:

class Foo {
 vector<int> bar;
}

FullTypeName() returns  "vector"
If I qualify vector with "std" then it only returns "std".

With Grzegorz direction I tracked this down to the following:

The encoding looks correct.   It is this:
"T\206vector\201i"

The trouble is that FullTypeName() calls MakeLeaf() which just returns 
the first 6 characters "vector".

Is the bug in calling MakeLeaf()  or should MakeLeaf() continue parsing 
after vector and add more info?


   Thanks,
    Russ Balest

Re: [Opencxx-users] template members

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

On Fri, 23 Apr 2004, Russell Balest wrote:

>
> Given:
>
> class Foo {
>          std::vector<int> bars;
> }
>
> I was expecting FullTypeName() on the bars member to give me
> "std::vector<int>".
> Instead it gives me: "std::"
>
> Is that a bug or by design?

Bug.

> Is there any way I can get the full typename and parse it myself into [
> [std::] [vector] [int] ] ?

Fixing the bug.

First place to look at is if TypeInfo::encode. It is a mangled type name,
do 'grep "This encoding" *.cc' to find the description of the manging
scheme. If TypeInfo::encode is buggy, have a look at the place in parser
where the node is parsed, AFAIR the mangling is worked out there.

BR
Grzegorz

>
>   Thanks,
>    Russell Balest
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
>

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

[Opencxx-users] template members

[Russell B. <ru...@ba...>]

 
Given:

class Foo {
         std::vector<int> bars;
}

I was expecting FullTypeName() on the bars member to give me 
"std::vector<int>".
Instead it gives me: "std::"

Is that a bug or by design? 
Is there any way I can get the full typename and parse it myself into [ 
[std::] [vector] [int] ] ?

  Thanks,
   Russell Balest

Re: [Opencxx-users] newbie question

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

On Tue, 20 Apr 2004, Russell Balest wrote:

>
>   I'm trying to figure out if opencxx is suitable for the following task:
>
>   I want to utilize opencxx to translate existing C++ class definitions
> ( plus an opencxx annotation such as "metaclass Serializable") to C++
> code and then compile with g++ in the end.  In the process of
> translation I want to generate 'serialize' or 'marshall' methods on my
> "Serializable" classes.   Very similar to what you get in Java when you
> declare that a class implements serializable.
>   Has anyone done this?

I think I can recall somebody talking about it on this list. You may want
to search archives.

> Does this sound like something that opencxx can do?

Yes.

> In particular, I must compile the transformed code with g++ as
> I'm part of a larger build process that I don't control.
>
>   I get the impression that opencxx doesn't actually emit translated
> code that can then be compiled with g++.

Where does this impression come from?

> Am I wrong about that?

The code emitted by occ should compile fine with g++. If you find
otherwise, please report it here.

BR
Grzegorz

>   Thanks for any information or examples,
>   Russell Balest
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
>

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

[Opencxx-users] newbie question

[Russell B. <ru...@ba...>]

  I'm trying to figure out if opencxx is suitable for the following task:

  I want to utilize opencxx to translate existing C++ class definitions 
( plus an opencxx annotation such as "metaclass Serializable") to C++ 
code and then compile with g++ in the end.  In the process of 
translation I want to generate 'serialize' or 'marshall' methods on my 
"Serializable" classes.   Very similar to what you get in Java when you 
declare that a class implements serializable.
  Has anyone done this?   Does this sound like something that opencxx 
can do?  In particular, I must compile the transformed code with g++ as 
I'm part of a larger build process that I don't control.

  I get the impression that opencxx doesn't actually emit translated 
code that can then be compiled with g++.
Am I wrong about that?

  Thanks for any information or examples,
  Russell Balest

Re: [Opencxx-users] Usage of OpenC++ to generate a documentation from managed C++

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

Hi Ferdinand,

On Fri, 16 Apr 2004, Ferdinand Prantl wrote:

> Hi,
>
> firstly, thank you for publishing such a great framework. I could understand
> it really fast.
>
> I need to create a documentation for a .NET assembly written in managed C++
> (extension for writing .NET assemblies in C++). Unfortunately the native
> documenting tool will exist in 2005 (from Microsoft) for the new syntax only
> and there is still no OSS tool to compile or document managed C++ (for
> example in the Mono project).
>
> Here we are an example of a source code in the syntax version 1.0:
>
> namespace Test {
>     /// <summary>
>     /// Summary description for Class.
>     /// </summary>
>     public __gc class Class : public AbstractClass, public Interface {
>         public:
>             /// <summary>
>             /// Summary description for Class::MethodFromInterface.
>             /// </summary>
>             virtual System::Object * MethodFromInterface.(System::Object *);
>     };
> }
>
> And here of a target, which I need to generate:
>
> <?xml version="1.0"?>
> <doc>
>   <members>
>     <member name="T:Test.Class">
>       <summary>
>       Summary description for Class.
>       </summary>
>     </member>
>     <member name="M:Test.Class.MethodFromInterface.(System::Object)">
>       <summary>
>       Summary description for Class::MethodFromInterface.
>       </summary>
>     </member>
>   </members>
> </doc>
>
> I tried to evaluate some more solutions (doxygen, synopsis, ctool,
> self-written solution) and find the least expensive one, and also a one,
> which I liked to implement... ;-)
>
> Currently I think the best would be to use OpenC++. I took opencxx 2.7 and
> did the first version of the tool, which now works. Actually, I only needed
> to create a base metaclass for the type modifier __gc and to play with the
> class and its members in FinalizeInstance().
>
> What I did:
> * created makefiles and projects/solutions for MSVCs producing exe, dll and
> static library
> * modified sources to compile in MSVCs and also accept headers from MSVCs
> (STL)
> * extended the lexer and parser to accept managed C++ syntax (not fully yet)
> * created documenting mc module writing a XML from comments of parsed
> classes
>
> However I needed also to extend the model (only a bit, really... :-),
> because of the managed C++ extensions, which I did not want to simply ignore
> as some keywords or context-important words (generally, I think that
> ignoring is not good because someone else could need do more with the model
> than me).
>
> I will have the first fully usable version during this weekend. I would like
> to offer the sources (changes) as a contribution to your project and help
> with the maintenance, if you liked. I will publish also the documentatin
> tool.
>
> What do you think?

Help and contributions are always welcome. The main issue now is that as I
understand you worked from 2.7, and soon I will be merging huge changes
from sandbox_jakacki_frontend1 branch.

I would suggest that you have a look at sandbox_jakacki_frontend1 and
try to decide, if you can merge your changes there. If not, then
perhaps we will have to open concurent branch for MSVC and keep two
versions of OpenC++ at least until MSVC branch does not catch up with UNIX
branch.

My opinion on compiler-specific keywords is that we should support them,
but it should be possible to switch them off with command line option.

Plases have a look at sandbox_jakacki_frontend1 and let me know what you
think. AFAIK Asen tried to compile it on Cygwin, but there were problems
which we have not solved yet.

BR
Grzegorz


> Ferda
>
> P.S. By the way, some of you guys really must've used LISP just before
> writing OpenC++ :-)
>
>

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

Re: [Opencxx-users] RE: OpenC++ for .NET 2003

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

Hi,

On Fri, 16 Apr 2004, Ferdinand Prantl wrote:

>
> > Also mind you that typeinfo.h is a header file included in .NET 2003
> >  so at some point <typeinfo> is being included which includes <typeinfo.h>
> >  but if you have the includes set to the occ folder it will include the
> wrong one.
> > I renamed typeinfo.h to type_info.h on mine. I think it might be worth
> changing it
> > altogether in the repository.

AFAIK this was discussed here already along with solution that does not
require renaming.

In the latest version in sandbox_jakacki_frontend1 (to be merged to MAIN
soon) each class has its own file, so class TypeInfo has its file
TypeInfo.h; we cannot rename this file without breaking a rule, that the
file name is constructed from class name. We cannot rename class without
breaking backward compatibility. So that's why I don't like renaming.

> The other solution, which I did is not to put the directory with opencxx
> headers inti the include path.
>
> .../opencxx-2.7/src/... (you know this, here are the sources)
> .../opencxx-2.7/include/opencxx/... (I copied the published and externally
> used headers)
>
> Then only .../opencxx-2.7/include to path and:
>
> #include <opencxx/typeinfo.h>

This will break if you are building new version of OpenC++, but have the
old one installed in directory, that is early in include path (e.g. if you
installed in /usr/local), as this directive will pull in the old header.
Also remember about issues when building with srcdir!=builddir (I am not
sure if they hit here, I have no time to analyze it at the moment, sorry.)
The solution I used in sandbox_jakacki_frontend1 is:

#include "../opencxx/typeinfo.h"

BR
Grzegorz

> It is actually better way how to do includes, which is also more used in OSS
> world. But no big problem with renaming, indeed.
>
> F.
>
>
> 	_____________________________________________
> 	From: 	Ferdinand Prantl
> 	Sent:	Friday, April 16, 2004 13:01
> 	To:	ope...@li...
> 	Subject:	RE: OpenC++ for .NET 2003
>
> 	Hi Asen,
>
> 	> I have gotten OpenC++ to work in a Visual Studio .NET 2003
> solution.
>
> 	Oops, me too,I should have read the list before I started top
> evaluate opencxx... :-)
>
> 	>  However I am still trying to figure out problems compiling the
> .mc metaclasses.
>
> 	I myself do it only statically now but to build and load a dll
> should not be problem too.
>
> 	> How do I submit changes that fix new MSVC specific things?
> 	> For example the new operator is defined as throw(...) and I have a
> fix for this.
> 	> (I don't know if that's new ANSI or just another Microsoft
> Specific stuff)
>
> 	That's MSVC specific. However, its STL is full of this, so opencxx
> must cope with it, if it wants to win MSVC customers :-)
>
> 	Standard:
> 	 (no specification) The function can throw any exception.
> 	 throw(type), throw(type1, type2), ... The function can throw an
> exception of type1, type2, ...
> 	 throw() The function does not throw an exception.
>
> 	MSVC:
> 	 (no specification) The function can throw any exception.
> 	 throw(...) The function can throw any exception.
> 	 throw(type), throw(type1, type2), ... The function can throw an
> exception of type1, type2, ... However, in Visual C++ .NET, this is
> interpreted as throw(...).
> 	 throw() The function does not throw an exception.
>
> 	> Also there is a new type __w64 which has to be added as a keyword.
>
> 	Yep, and more, which I must have added. Currently I did it as Ignore
> but it is no the best way; I lost the information about the type...
>
> 	typedef __w64 unsigned int size_t;
>
> 	It makes better port to 64 bits in MSVC because it causes a special
> warning by such an assignment:
>
> 	size_t foo = ...;
> 	unsigned int bar = foo; // warning
>
>
> 	Ferda
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
>

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

Re: [Opencxx-users] RE: Is it possible to create Visual Studio Project

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

On Fri, 16 Apr 2004, Ferdinand Prantl wrote:

> Hi Asen,
>
> > Has anyone tried it?
>
> Yes, I have. I have makefiles and also solutions/projects for all vc6, vc7,
> vc71 and vc8, producing occ.exe and libopencxx.dll.
> If the authors would like, I will contribute it here and can help with the
> maintenance.

Sure, it would be welcome. As I understand you have Makefiles for 2.7,
right?

BR
GJ

>
> >  I also noticed that instead of .so files under cygwin I am getting a new
> .exe instead.
> > I'm trying to use the ANSI #line definition instead of the bogus # <num>
> "file" <many
> >numbers>...
>
> Hmmm, here I am confused a little... What platform do you use? Cygwin or
> MSVC? can you describe your scenario better?
>
> > However when I defined _PARSE_VCC the .mc metaclass files stopped
> compiling properly
> > because
> > it's passing them to the g++.
>
> _PARSE_VCC is internal for MSVC (in fact, I do not like it there :-), not
> for gcc. I am confused more, you have to express yourself better...
>
> Ferda
>
> >  -A.K.
>
>

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

Re[3]: [LLVMdev] Re: [Opencxx-users] LLVM and OpenC++

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

Hi,

On Fri, 16 Apr 2004, [koi8-r] "Valery A.Khamenya[koi8-r] "  wrote:

> Hi all, hi Grzegorz
>
> > Valery, IMO your reply is slightly agressive.
>
> oh, there was no aggression implied in any form!
> i am sorry for inducing feelings like that :(

Sorry if I misread anything.

> > If you think JIT is imporant for OpenC++ project, please explain why.
>
> sure i'll try.
> below.
>
> Point 1. (C++ is static language, but some dynamics is possible via "new")
>
> Although C++ standard does not push implementer towards
> compiler-only language implementations still AFAIK all C++
> implementations are de facto  *compilers* and not
> iterpreters/JITs.

I know of at least one C++ interpretter, I don't remember the name now,
perhaps 'cint' ??? Let me know if you cannot find it with google (AFAIR it
has been announced at comp.compilers), I will try to dig it up.

> There is no things in C++ standards
> today, which might demand compilation in run-time.
> In practice, all run-time demands might be resolved with operator
> "new", i.e. dynamic object allocation. With C++ in
> run-time one can not create new types or new functions.

Sorry, this passage is unclear to me.

>
> Point 2. (OpenC++ is fully static, no dynamic is possible)
>
> Instantiation of metaclass object is not possible in run-time.
> Indeed this should demand run-time compilation of corresponding
> base level class and linking the code to already running code,
> which is not feasible with gcc.

Besides you hit problems with static typing. If a program can create a
metaobject during the run-time, then effectively it can add new class to
itself. Now how can the program use this class and how calls to this
class's methods can be typechecked?

> Point 3. (dynamics in OpenC++ would be a useful thing)
>
> Imagine that one has some command-line tool, where the *behaviour*
> of the running code is changing massively with options
> like "--verbose" or "--debug". Let's consider option
> "--debug" which tells us about every member function call
> and turns on some additional checks.
> A metaclass VerboseClass is a nice approach to
> introduce these different types of application's behaviour.
> But if for "--debug" and non "--debug" option we have the
> same code then non "--debug" version will never show
> perfect performance. Indeed, with every member function call
> one will obtain implicitly an extra statement like:
>
> SomeClass::SomeFunc
> {
>   if(debug_option_is_set)
>     // do output and additional checks
>   ...
> }
>
> which will cause (many) redundant checks in non "--debug"
> program invokation. And will disallow nice optimisations.
> One could say here: "why not to create at
> compile time all needed classes and then in run-time
> just invoke the corresponding one?".

What do you mean by "invoking a class" ?

> Well, it is a solution,
> but creating a code instance for an every command line
> option combination will blow up the code enormously.
>
> Point 4. (metaclasses are adequate to change class behaviour in run-time)
>
> Let's look into example above. The metaclass VerboseClass
> is a nice place to switch on/off verbose output.
> Even in run-time as well.
> But the problem is that VerboseClass will not make
> performance of non "--debug" invocation as good as
> possible. Because the code for  --debug  can t be recompiled.
>
> Point 5. (creating classes in run-time needs JITing/interpreter)
>
> Quite clear, that creating of new types/functions in
> run-time needs JITing/interpretation in run-time.
> Even worse: the recently compiled ready for execution
> modules should be bound somehow to already
> running code.
>
> Point 6. (LLVM could help to introduce JITing to OpenC++)
>
> what is LLVM one could read at this page:
> http://llvm.cs.uiuc.edu/
>
> Important here is that LLVM can also generate and manage
> code in run-time. In example above, after starting command line
> tool the corresponding classes might be created and *compiled*
> according to option like "--debug".
> Id est, compiled in run-time. Thus, one could expect that
> invocation without "--debug" will be as quick as possible,
> because classes instantiated without "--debug" option
> do *not* have any debug related code anymore.
>
> > A question: I can see you have an idea, but do you also have resources to
> > implement it?
>
> No.
> But at least I'd be happy to invest the idea and motivation.
>
>
> >  We (at least myself) can guide you through OpenC++
> > architecture, help with infrastructure, but that's it. In particular, do
> > you want to contribute your time into implementation of your idea?
>
> I just don't have enough free time for such a monster job :(

Cut off a smaller piece, set a reasonably small goal, write a prototype.

> Only such a brilliant guys like Chris Lattner, Moshe Bar,
> Linus Torvalds, ..., ...,  could bring such ideas to the
> life being full-time involved in that though.

If you create interesting technology, you can make it your check-paying
job at some point.

> > It
> > takes lots of advocacy work to make other people implement your ideas.
>
> You are right, but I should try at least to clear my conscience.
>
> > Unless you are a university professor, of course :-)
>
> hehe, not yet, not yet.

Valery!

For me it looks like you have a vision, but what you are proposing is a
huge project, much bigger than OpenC++ itself. I would be happy if you
build this project using OpenC++ or its components.

Your arguments make sense to me, however I feel that this discussion
becomes off-topic on this list. I suggest that you set up a separate
project on SF and let's move this discussion there. It would also be
helpful if you make your e-mail into a wrap-up and post on your project's
website as a kind of manifest. Perhaps you also would like your ideas
reviewed by posting to other forums, say, comp.compilers, if you haven't
already done it.

> > PS: I am not posting this e-mail to llvm dev list, as I find it to be OT
> >     there.
>
> right.
>
> BTW, as OpenC++ team the team of Chris Lattner makes
> a lot of changes to gcc and tracks gcc' versions.
> Maybe some communication between both teams might
> be fruitful?

What exactly do you have in mind?

>
> Have a nice day anyway!
>
> P.S. if this long letter will be lost again while sending process
> as its long predecessor then one will find again some
> traces of "aggression" in my short posts :)

:-)

BR
Grzegorz


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

Re: [Opencxx-users] OpenC++ feature question

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

Brian,

On Thu, 15 Apr 2004, Brian Kahne wrote:

>
> Hi,
>
>   I was wondering whether there was any way, using OpenC++, to create a new
>   control structure without a class modifier, e.g.
>
>   	par {
>   	  ...
>   	}
>
>   where par is the new control structure.

Do you want to use OpenC++ as a whole to translate "par { ... }"
into some other code, or you just want to reuse OpenC++ parser, but your
requirement is that is also parser "par { ... }" ?

In any case construct like this is not supported. See "Base-level
Language" in docs about similar user-defined constructs, which perhaps you
can use for the same purpose while slightly compromising your syntax.

If you insist on your syntax, you will have to extend parser. The parser is a
recursive descent parser, quite well documented in terms of what function
parses what, adding your construct should not be difficult.

Please let me know if you need more help.

BR
Grzegorz


>   Is that possible?
>   If not, would it be
>   difficult for me to add that feature?
>
>   Thanks for any info,
>
>   Brian Kahne
>   Austin PowerPC Design Center
>   Motorola
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
>

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

[Opencxx-users] Usage of OpenC++ to generate a documentation from managed C++

[Ferdinand P. <fer...@ix...>]

Hi,

firstly, thank you for publishing such a great framework. I could understand
it really fast.

I need to create a documentation for a .NET assembly written in managed C++
(extension for writing .NET assemblies in C++). Unfortunately the native
documenting tool will exist in 2005 (from Microsoft) for the new syntax only
and there is still no OSS tool to compile or document managed C++ (for
example in the Mono project).

Here we are an example of a source code in the syntax version 1.0:

namespace Test {
    /// <summary>
    /// Summary description for Class.
    /// </summary>
    public __gc class Class : public AbstractClass, public Interface {
        public:
            /// <summary>
            /// Summary description for Class::MethodFromInterface.
            /// </summary>
            virtual System::Object * MethodFromInterface.(System::Object *);
    };
}

And here of a target, which I need to generate:

<?xml version="1.0"?>
<doc>
  <members>
    <member name="T:Test.Class">
      <summary>
      Summary description for Class.
      </summary>
    </member>
    <member name="M:Test.Class.MethodFromInterface.(System::Object)">
      <summary>
      Summary description for Class::MethodFromInterface.
      </summary>
    </member>
  </members>
</doc>

I tried to evaluate some more solutions (doxygen, synopsis, ctool,
self-written solution) and find the least expensive one, and also a one,
which I liked to implement... ;-)

Currently I think the best would be to use OpenC++. I took opencxx 2.7 and
did the first version of the tool, which now works. Actually, I only needed
to create a base metaclass for the type modifier __gc and to play with the
class and its members in FinalizeInstance().

What I did:
* created makefiles and projects/solutions for MSVCs producing exe, dll and
static library
* modified sources to compile in MSVCs and also accept headers from MSVCs
(STL)
* extended the lexer and parser to accept managed C++ syntax (not fully yet)
* created documenting mc module writing a XML from comments of parsed
classes

However I needed also to extend the model (only a bit, really... :-),
because of the managed C++ extensions, which I did not want to simply ignore
as some keywords or context-important words (generally, I think that
ignoring is not good because someone else could need do more with the model
than me).

I will have the first fully usable version during this weekend. I would like
to offer the sources (changes) as a contribution to your project and help
with the maintenance, if you liked. I will publish also the documentatin
tool.

What do you think?

Ferda

P.S. By the way, some of you guys really must've used LISP just before
writing OpenC++ :-)

Re[3]: [LLVMdev] Re: [Opencxx-users] LLVM and OpenC++

[<kha...@ma...>]

Hi all, hi Grzegorz 

> Valery, IMO your reply is slightly agressive. 

oh, there was no aggression implied in any form!
i am sorry for inducing feelings like that :(

> If you think JIT is imporant for OpenC++ project, please explain why.

sure i'll try. 
below.


> I am sorry, I am unfamiliar with LLVM and JIT. Perhaps you could give a
> brief intro?

JITing is nothing more then ability to compile, link and 
manage code in general in run-time. 
JIT means Just-In-Time compilation.
The most popular JITers are JIT from Java, LLVM and Parrot.
JIT compilations makes Java implementations as quick as 
C++ implementations are. Every Lisp is JITer in a way too.
Look at Bigloo as Java JIT Scheme implementation. 
Bigloo is as quick as gcc.

LLVM is a great back-end solution for languages
like Lisp, C#, for the interpreter languages, and
languages, which use computational reflection extensively.

> To make sure people are motivated you need to explain your idea first, and
> motivate people next.

that exactly what i have meant.

Point 1. (C++ is static language, but some dynamics is possible via "new")

Although C++ standard does not push implementer towards 
compiler-only language implementations still AFAIK all C++ 
implementations are de facto  *compilers* and not 
iterpreters/JITs. There is no things in C++ standards 
today, which might demand compilation in run-time. 
In practice, all run-time demands might be resolved with operator 
"new", i.e. dynamic object allocation. With C++ in 
run-time one can not create new types or new functions.

Point 2. (OpenC++ is fully static, no dynamic is possible)

Instantiation of metaclass object is not possible in run-time.
Indeed this should demand run-time compilation of corresponding
base level class and linking the code to already running code, 
which is not feasible with gcc.

Point 3. (dynamics in OpenC++ would be a useful thing)

Imagine that one has some command-line tool, where the *behaviour*
of the running code is changing massively with options
like "--verbose" or "--debug". Let's consider option 
"--debug" which tells us about every member function call
and turns on some additional checks. 
A metaclass VerboseClass is a nice approach to 
introduce these different types of application's behaviour. 
But if for "--debug" and non "--debug" option we have the 
same code then non "--debug" version will never show
perfect performance. Indeed, with every member function call
one will obtain implicitly an extra statement like:

SomeClass::SomeFunc
{
  if(debug_option_is_set) 
    // do output and additional checks
  ...
}

which will cause (many) redundant checks in non "--debug" 
program invokation. And will disallow nice optimisations.
One could say here: "why not to create at
compile time all needed classes and then in run-time 
just invoke the corresponding one?". Well, it is a solution,
but creating a code instance for an every command line 
option combination will blow up the code enormously.

Point 4. (metaclasses are adequate to change class behaviour in run-time)

Let's look into example above. The metaclass VerboseClass
is a nice place to switch on/off verbose output. 
Even in run-time as well.
But the problem is that VerboseClass will not make 
performance of non "--debug" invocation as good as 
possible. Because the code for  --debug  can t be recompiled.

Point 5. (creating classes in run-time needs JITing/interpreter)

Quite clear, that creating of new types/functions in 
run-time needs JITing/interpretation in run-time.
Even worse: the recently compiled ready for execution 
modules should be bound somehow to already
running code.

Point 6. (LLVM could help to introduce JITing to OpenC++)

what is LLVM one could read at this page:
http://llvm.cs.uiuc.edu/

Important here is that LLVM can also generate and manage
code in run-time. In example above, after starting command line 
tool the corresponding classes might be created and *compiled*
according to option like "--debug". 
Id est, compiled in run-time. Thus, one could expect that
invocation without "--debug" will be as quick as possible, 
because classes instantiated without "--debug" option
do *not* have any debug related code anymore.

 
> A question: I can see you have an idea, but do you also have resources to
> implement it?

No. 
But at least I'd be happy to invest the idea and motivation.


>  We (at least myself) can guide you through OpenC++
> architecture, help with infrastructure, but that's it. In particular, do
> you want to contribute your time into implementation of your idea? 

I just don't have enough free time for such a monster job :(
Only such a brilliant guys like Chris Lattner, Moshe Bar, 
Linus Torvalds, ..., ...,  could bring such ideas to the 
life being full-time involved in that though.

> It
> takes lots of advocacy work to make other people implement your ideas.

You are right, but I should try at least to clear my conscience. 


> Unless you are a university professor, of course :-)

hehe, not yet, not yet. 


> PS: I am not posting this e-mail to llvm dev list, as I find it to be OT
>     there.

right. 

BTW, as OpenC++ team the team of Chris Lattner makes 
a lot of changes to gcc and tracks gcc' versions. 
Maybe some communication between both teams might 
be fruitful?

Have a nice day anyway!

P.S. if this long letter will be lost again while sending process 
as its long predecessor then one will find again some 
traces of "aggression" in my short posts :)

--
Valery

[Opencxx-users] RE: OpenC++ for .NET 2003

[Ferdinand P. <fer...@ix...>]

> Also mind you that typeinfo.h is a header file included in .NET 2003
>  so at some point <typeinfo> is being included which includes <typeinfo.h>
>  but if you have the includes set to the occ folder it will include the
wrong one.
> I renamed typeinfo.h to type_info.h on mine. I think it might be worth
changing it
> altogether in the repository.

The other solution, which I did is not to put the directory with opencxx
headers inti the include path.

.../opencxx-2.7/src/... (you know this, here are the sources)
.../opencxx-2.7/include/opencxx/... (I copied the published and externally
used headers)

Then only .../opencxx-2.7/include to path and:

#include <opencxx/typeinfo.h>

It is actually better way how to do includes, which is also more used in OSS
world. But no big problem with renaming, indeed.

F.


	_____________________________________________ 
	From: 	Ferdinand Prantl  
	Sent:	Friday, April 16, 2004 13:01
	To:	ope...@li...
	Subject:	RE: OpenC++ for .NET 2003

	Hi Asen,

	> I have gotten OpenC++ to work in a Visual Studio .NET 2003
solution.

	Oops, me too,I should have read the list before I started top
evaluate opencxx... :-)

	>  However I am still trying to figure out problems compiling the
.mc metaclasses.

	I myself do it only statically now but to build and load a dll
should not be problem too.
	 
	> How do I submit changes that fix new MSVC specific things?
	> For example the new operator is defined as throw(...) and I have a
fix for this.
	> (I don't know if that's new ANSI or just another Microsoft
Specific stuff)

	That's MSVC specific. However, its STL is full of this, so opencxx
must cope with it, if it wants to win MSVC customers :-)

	Standard:
	 (no specification) The function can throw any exception.
	 throw(type), throw(type1, type2), ... The function can throw an
exception of type1, type2, ...
	 throw() The function does not throw an exception.

	MSVC:
	 (no specification) The function can throw any exception.
	 throw(...) The function can throw any exception.
	 throw(type), throw(type1, type2), ... The function can throw an
exception of type1, type2, ... However, in Visual C++ .NET, this is
interpreted as throw(...).
	 throw() The function does not throw an exception.

	> Also there is a new type __w64 which has to be added as a keyword.

	Yep, and more, which I must have added. Currently I did it as Ignore
but it is no the best way; I lost the information about the type...

	typedef __w64 unsigned int size_t;

	It makes better port to 64 bits in MSVC because it causes a special
warning by such an assignment:

	size_t foo = ...;
	unsigned int bar = foo; // warning


	Ferda

[Opencxx-users] RE: OpenC++ for .NET 2003

[Ferdinand P. <fer...@ix...>]

Hi Asen,

> I have gotten OpenC++ to work in a Visual Studio .NET 2003 solution.

Oops, me too,I should have read the list before I started top evaluate
opencxx... :-)

>  However I am still trying to figure out problems compiling the .mc
metaclasses.

I myself do it only statically now but to build and load a dll should not be
problem too.
 
> How do I submit changes that fix new MSVC specific things?
> For example the new operator is defined as throw(...) and I have a fix for
this.
> (I don't know if that's new ANSI or just another Microsoft Specific stuff)

That's MSVC specific. However, its STL is full of this, so opencxx must cope
with it, if it wants to win MSVC customers :-)

Standard:
 (no specification) The function can throw any exception.
 throw(type), throw(type1, type2), ... The function can throw an exception
of type1, type2, ...
 throw() The function does not throw an exception.

MSVC:
 (no specification) The function can throw any exception.
 throw(...) The function can throw any exception.
 throw(type), throw(type1, type2), ... The function can throw an exception
of type1, type2, ... However, in Visual C++ .NET, this is interpreted as
throw(...).
 throw() The function does not throw an exception.

> Also there is a new type __w64 which has to be added as a keyword.

Yep, and more, which I must have added. Currently I did it as Ignore but it
is no the best way; I lost the information about the type...

typedef __w64 unsigned int size_t;

It makes better port to 64 bits in MSVC because it causes a special warning
by such an assignment:

size_t foo = ...;
unsigned int bar = foo; // warning


Ferda

[Opencxx-users] RE: Is it possible to create Visual Studio Project

[Ferdinand P. <fer...@ix...>]

Hi Asen,

> Has anyone tried it?

Yes, I have. I have makefiles and also solutions/projects for all vc6, vc7,
vc71 and vc8, producing occ.exe and libopencxx.dll.
If the authors would like, I will contribute it here and can help with the
maintenance.

>  I also noticed that instead of .so files under cygwin I am getting a new
.exe instead.
> I'm trying to use the ANSI #line definition instead of the bogus # <num>
"file" <many
>numbers>...

Hmmm, here I am confused a little... What platform do you use? Cygwin or
MSVC? can you describe your scenario better?

> However when I defined _PARSE_VCC the .mc metaclass files stopped
compiling properly
> because
> it's passing them to the g++.

_PARSE_VCC is internal for MSVC (in fact, I do not like it there :-), not
for gcc. I am confused more, you have to express yourself better...

Ferda

>  -A.K.

Re: [Opencxx-users] parse errors on valid C++

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

On Thu, 15 Apr 2004, Stefan Seefeld wrote:

> Stefan Seefeld wrote:
>  > Grzegorz Jakacki wrote:
>
>  >> You hacked OpenC++ already, perhaps you could invest some time in this
>  >> fix. Please contact me for arrangements if you decide to do so.
>  >
>  >
>  > Fair enough. Attached is a patch that:
>
> Grzegorz,
>
> did you have the time to have a look into the patch ?

Yes, looks very good, but I had no time to apply it yet, sorry.

> I'm willing to do
> further work with some guidance, as I understand you are quite busy.
> I still have write permissions to the opencxx repository, though I'd
> prefer to have somebody with better opencxx understanding review my
> patches first.

That's great, Stefan. I have just mailed you privately with more info on
that.

> May be at some point I'm also able to help with other issues on your
> todo list, such as the refactoring / modularization.

Fantastic.

BR
Grzegorz

>
> Kind regards,
> 		Stefan
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
>

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

Re: [Opencxx-users] Function body processing

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

On Wed, 14 Apr 2004, Lev Assinovsky wrote:

> Hi all!
> Could you please tell me how could I analyze function body?
> Thanks in advance!

Lev,

Please look at docs on Class::TranslateFunctionBody() and
Class::SetMetaclassForFunctions(). If you still need more help, please
post most details on what exactly you would like to do.

Good luck
Grzegorz


>
> ----
> Lev Assinovsky
> Aelita Software Corporation
> (now is a part of Quest Software)
> O&S InTrust Framework Division, Team Leader
> ICQ# 165072909
>
>
>
>

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

[Opencxx-users] OpenC++ feature question

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

Hi,

  I was wondering whether there was any way, using OpenC++, to create a new
  control structure without a class modifier, e.g.

  	par {
  	  ...
  	}

  where par is the new control structure.  Is that possible?  If not, would it be
  difficult for me to add that feature?

  Thanks for any info,

  Brian Kahne
  Austin PowerPC Design Center
  Motorola

Re: [Opencxx-users] parse errors on valid C++

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

Stefan Seefeld wrote:
 > Grzegorz Jakacki wrote:

 >> You hacked OpenC++ already, perhaps you could invest some time in this
 >> fix. Please contact me for arrangements if you decide to do so.
 >
 >
 > Fair enough. Attached is a patch that:

Grzegorz,

did you have the time to have a look into the patch ? I'm willing to do
further work with some guidance, as I understand you are quite busy.
I still have write permissions to the opencxx repository, though I'd
prefer to have somebody with better opencxx understanding review my
patches first.

May be at some point I'm also able to help with other issues on your
todo list, such as the refactoring / modularization.

Kind regards,
		Stefan