You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(9) |
Oct
(16) |
Nov
(14) |
Dec
(24) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(14) |
Feb
(57) |
Mar
(72) |
Apr
(37) |
May
(21) |
Jun
(12) |
Jul
(16) |
Aug
(33) |
Sep
(24) |
Oct
|
Nov
(10) |
Dec
(8) |
2004 |
Jan
(6) |
Feb
(14) |
Mar
(47) |
Apr
(41) |
May
(16) |
Jun
(31) |
Jul
(78) |
Aug
(62) |
Sep
(99) |
Oct
(43) |
Nov
(35) |
Dec
(9) |
2005 |
Jan
(19) |
Feb
(22) |
Mar
(7) |
Apr
|
May
(5) |
Jun
(4) |
Jul
(2) |
Aug
(9) |
Sep
(15) |
Oct
(23) |
Nov
(2) |
Dec
(20) |
2006 |
Jan
|
Feb
(2) |
Mar
(7) |
Apr
|
May
|
Jun
(8) |
Jul
(15) |
Aug
(1) |
Sep
(4) |
Oct
|
Nov
(9) |
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(11) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Grzegorz J. <ja...@he...> - 2004-02-16 01:36:05
|
On Sat, 14 Feb 2004, Ivan Dubrov wrote: > What's the situation with support of the GCC-3 headers? Does anybody > plan to do this? Yes, however it seems nontrivial and definitely is over the manpower budget that we have available at the moment. Currently I am in the process of building the team to tackle this issue, but this takes manpower also... > Great tool, but with lack of new GCC support it's quite limited. :( If you would like to help getting OpenC++ closer to parsing gcc-3.x STL headers, please send me an e-mail with a brief description of your softeng experience (I recall reading through your iostream logging utility posted on Boost some month ago) and how much time per week you could contribute. Hope to hear from you Grzegorz ################################################################## # Grzegorz Jakacki Huada Electronic Design # # Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang # # tel. +86-10-64365577 x2074 Beijing 100015, China # # Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
From: Ivan D. <WF...@ya...> - 2004-02-14 03:06:44
|
What's the situation with support of the GCC-3 headers? Does anybody plan to do this? Great tool, but with lack of new GCC support it's quite limited. :( |
From: Grzegorz J. <ja...@he...> - 2004-01-19 00:48:40
|
On Sun, 18 Jan 2004, Shishir Ramam wrote: > > While compiling OpenCxx + cygwin, kept running > into a link error when compiling libltdl. > > An earlier post mentioned reinstalling cygwin. > This did not solve me problem, and after a bit > of hunting, found > http://www.cygwin.com/faq/faq_4.html#SEC95 > > To fix, open opencxx-2.7/libltdl/ltdl.c and add > > void main(void) {}; > > seems to have solved my problem. > Hoping it helps others. Thanks! Can it be accomplished without touching libltdl? E.g. would that be enough to just add a dummy library containing just empty main() on the link line? If so, then should I add it before or after -lltdl ? Regards Grzegorz > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > http://hotjobs.sweepstakes.yahoo.com/signingbonus > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > 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) 2003 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
From: Shishir R. <sr...@ya...> - 2004-01-18 22:50:29
|
While compiling OpenCxx + cygwin, kept running into a link error when compiling libltdl. An earlier post mentioned reinstalling cygwin. This did not solve me problem, and after a bit of hunting, found http://www.cygwin.com/faq/faq_4.html#SEC95 To fix, open opencxx-2.7/libltdl/ltdl.c and add void main(void) {}; seems to have solved my problem. Hoping it helps others. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
From: Grzegorz J. <ja...@he...> - 2004-01-15 01:34:56
|
Hi, I checked in new a revised code into 'jakacki_sandbox_frontend1' branch. The changes/additions include: 'occ2' --- shell script that uses libtool for all linking and compilation needs. This is an implementation of a solution that has been discussed long time ago. This script is my candidate for the main occ command-line interface point. (In fact occ2's iface tries to mimic occ's iface as closely as possible.) My plan is to migrate toward this solution and remove platform-specific lining/compilation code from driver.cc and driver2.cc (possibly leaving Windows support, since occ2 being a bash script will not work with vanila VC++). 'occ2-test' --- shell script that tests functionality of 'occ2'. 'tester2' --- new much much simpler test script. I decided that existing solution proved to be way overengineered. The new one has the same functionality but less code. It is also easier to add and/or disable testcases. --disable-gc configure options (this was suggested either on the list on in private e-mails) --enable-opt=[none,medium,high] configure option --- sets optimization level, default is medium (-O2 on gcc). Currently works for gcc only, all other compilers must go with default level. If you know how to specify other levels on your compiler, please add this knowledge to configure.in (this was suggested either on the list or in private e-mails) 'make test' now runs 'make install' and runs tests against the installed headers and executables. This should solve a couple of problems with libtool linking, that Alex Tolmos hit on MacOS X. 'make tests' makes sure that ${prefix} is equal to ${builddir}/testbed, so that 'make test' does not install in e.g. system-wide directory. Source code is broken into smaller pieces, roughly one component per class or a set of a few tightly coupled classes (e.g. container and iterator). Some upward and superfluous dependencies have been removed (e.g. dependency of Ptree on ProgramString). Most of the items in a patch submitted by Marc Ordinas i Llopis have been applied. 'MetaclassRegistry' singleton class that does not rely on static initialization has been introduced in place of 'opcxx_ListOfMetaclass'. 'ErrorLog' abstract base has been introduced as universal error reporing mechanism along with hierarchy derived from (abstract) Msg class. This enables writting unit tests that capture error messages using mock implementation of ErrorLog. Standard implementation 'CerrErrorLog' prints the error messages to stderr. As interim solution the singleton object conforming to ErrorLog interface is accessible through namespace-level function 'TheErrorLog()'. Responsibility for stopping compilation in case of too many errors has been moved into ErrorLog, which can throw exception if it thinks it had too much. Foo-init.so now does not rely on static initialization of dlopened libraries (which does not work on all platforms). Metaclass has to be initialized explicitly and metaclass loading code does it no matter what the platform is. As many filenames changed (due to breakdown) and the CVS continuity has been lost anyway, I decided to do two things at once and move sources from 'src/' to 'opencxx/'. This makes it easier to install all the sources in ${includedir}/opencxx and at the same time use '#include <opencxx/...>' internally within OpenC++. Consequently it isolates OpenC++ from accidentally including a file that has the same name as OpenC++ component, but is located earlier in inclusion search path. For every blackbox testcase a corresponding testcase has been added to check the same functionality using compilation via dlopenable metaclass module. The ultimate goals of the changes are: * moving platform-awarness from driver{,2}.cc to libtool * isolating parser, so that it can be tested independently from the rest of the system. The latter goal has not been accomplished yet, see TODO for the list of things that need to be done. Independent testing of parser makes it easier to implement and test correct tempalate parsing (e.g. 'x < 1 > (2)'), which is a step towards better templates support. A nice side-effect is parser reusability. I would very much appreciate any comments and/or criticism of the code in 'sandbox_jakacki_frontend1'. If there are no huge objections I will merge it to MAIN. The source code was tested with gcc-2.95 on Linux. Best regards Grzegorz ################################################################## # Grzegorz Jakacki Huada Electronic Design # # Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang # # tel. +86-10-64365577 x2074 Beijing 100015, China # # Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
From: Grzegorz J. <ja...@he...> - 2004-01-05 09:19:19
|
Hi, On Mon, 29 Dec 2003, Shishir Ramam wrote: > I am interested in any recommendations for > intermediate forms that folks have used with > open-cxx. > My interest is in determining control & data > flow graphs. I used OpenC++ to extract some form of data dependency graph for C++ expressions, but I am not sure if this is what you have in mind when you say data flow graph. Also I am not sure what you mean asking about intermediate forms. Perhaps you could add a little bit more details? If you are looking for recommendation on how to implement certain compiler data structures in general (i.e. not necessarily in the context of OpenC++), then comp.compilers newsgroup seems to be the right place to ask the question. Best regards Grzegorz > > Thanks in advance for all help. > -shishir > > > __________________________________ > Do you Yahoo!? > New Yahoo! Photos - easier uploading and sharing. > http://photos.yahoo.com/ > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&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) 2003 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
From: Dominic H. <dom...@re...> - 2004-01-03 11:57:02
|
After seeing similar symptoms not involving opencxx, I re-installed cygwin and the problem went away. Please disregard previous posting. Dominic Herity Red Plain Technology (www.redplain.com) T:+353-87-2208233 F: +353-42-9351412 E: dom...@re... > >From: "Dominic Herity" <dom...@re...> > To: <ope...@li...> > Date: Fri, 2 Jan 2004 13:21:16 -0000 > Organization: Red Plain Technology > Subject: [Opencxx-users] Make error on Cygwin > > When I downloaded Open C++ and tried to build it on Cygwin, > configure ran ok, but make resulted in the output below. > libcmain.o has an unresolved reference to _WinMain@16. > > Environment: Open C++ Version 2.7, Cygwin version 1.5.5-1, > Windows XP Professional. > > I tried hacking libcygwin.a, adding libscrnsave.a, which > defines the symbol, but this, not surprisingly, resulted in > even more unresolved references. > > Has anyone seen this error? > > Dominic Herity > Red Plain Technology (www.redplain.com) > T:+353-87-2208233 F: +353-42-9351412 E: dom...@re... |
From: Dominic H. <dom...@re...> - 2004-01-02 13:21:46
|
When I downloaded Open C++ and tried to build it on Cygwin, configure ran ok, but make resulted in the output below. libcmain.o has an unresolved reference to _WinMain@16. Environment: Open C++ Version 2.7, Cygwin version 1.5.5-1, Windows XP Professional. I tried hacking libcygwin.a, adding libscrnsave.a, which defines the symbol, but this, not surprisingly, resulted in even more unresolved references. Has anyone seen this error? Dominic Herity Red Plain Technology (www.redplain.com) T:+353-87-2208233 F: +353-42-9351412 E: dom...@re... bash-2.05b$ make make all-recursive make[1]: Entering directory `/c/opencxx/opencxx-2.7' Making all in gc make[2]: Entering directory `/c/opencxx/opencxx-2.7/gc' Making all in doc make[3]: Entering directory `/c/opencxx/opencxx-2.7/gc/doc' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/c/opencxx/opencxx-2.7/gc/doc' Making all in include make[3]: Entering directory `/c/opencxx/opencxx-2.7/gc/include' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/c/opencxx/opencxx-2.7/gc/include' make[3]: Entering directory `/c/opencxx/opencxx-2.7/gc' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/c/opencxx/opencxx-2.7/gc' make[2]: Leaving directory `/c/opencxx/opencxx-2.7/gc' Making all in libltdl make[2]: Entering directory `/c/opencxx/opencxx-2.7/libltdl' make all-am make[3]: Entering directory `/c/opencxx/opencxx-2.7/libltdl' /bin/bash ./libtool --mode=link gcc -g -O2 -o libltdl.la -rpath /usr/local/li b -no-undefined -version-info 4:0:1 ltdl.lo rm -fr .libs/libltdl.la .libs/libltdl.* .libs/libltdl.* generating symbol list for `libltdl.la' dlltool --export-all --exclude-symbols DllMain@12,_cygwin_dll_entry@12,_cygwin_ noncygwin_dll_entry@12,DllMainCRTStartup@12,DllEntryPoint@12 --output-def .libs/ cygltdl-3.dll-def ltdl.lo sed -e "1,/EXPORTS/d" -e "s/ @ [0-9]*//" -e "s/ *;.*$//" < .libs/cygltdl-3.dll- def > .libs/libltdl.exp if test "x`head -1 .libs/libltdl.exp`" = xEXPORTS; then cp .libs/libltdl.exp .li bs/cygltdl-3.dll-def; else echo EXPORTS > .libs/cygltdl-3.dll-def; _lt_hint=1; c at .libs/libltdl.exp | while read symbol; do set dummy $symbol; case $# in 2) ec ho " $2 @ $_lt_hint ; " >> .libs/cygltdl-3.dll-def;; *) echo " $2 @ $_lt_hint $3 ; " >> .libs/cygltdl-3.dll-def;; esac; _lt_hint=`expr 1 + $_lt_hint`; done; fi gcc -Wl,--base-file,.libs/cygltdl-3.dll-base -Wl,-e,__cygwin_dll_entry@12 -o .l ibs/cygltdl-3.dll ltdl.lo /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libcygwin.a(libcmain.o)(.text +0x7 c): undefined reference to `_WinMain@16' collect2: ld returned 1 exit status make[3]: *** [libltdl.la] Error 1 make[3]: Leaving directory `/c/opencxx/opencxx-2.7/libltdl' make[2]: *** [all] Error 2 make[2]: Leaving directory `/c/opencxx/opencxx-2.7/libltdl' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/opencxx/opencxx-2.7' make: *** [all] Error 2 bash-2.05b$ |
From: Grzegorz J. <ja...@he...> - 2003-12-30 03:46:46
|
OpenC++ 2.7 is out! I would like to thank all volunteers who contributed to this release. Special thanks go to Alexandre Tolmos for bringing OpenC++ to MacOSX. I also would like to thank Larry Evans, Carsten Pfeiffer, Michael Hohmuth, Stefan Seefeld and Yann Dirson (hopefully I did not miss anybody). The roadmap for 2.8 includes: * templates (better support in parser and metamodel), * wrapper script that employs libtool for linking/compiling (already in sandbox), * application of Factory pattern to insulate walkers from the rest of the application (patches already in queue), * better modularization. Also I would like to take advantage of this opportunity to wish everybody happy and successful New Year! Best regards Grzegorz (OpenC++ Project Admin) |
From: Shishir R. <sr...@ya...> - 2003-12-29 19:52:48
|
Hi, I am interested in any recommendations for intermediate forms that folks have used with open-cxx. My interest is in determining control & data flow graphs. Thanks in advance for all help. -shishir __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ |
From: Grzegorz J. <ja...@he...> - 2003-12-16 02:22:28
|
Hi, More info solicited: * occ version * gcc version * does static build work ok? * output of 'nm VerboseClass2.so' * output of 'ldd VerboseClass2.so' (read on) On Sun, 14 Dec 2003, [iso-8859-2] Miko=B3aj Dawidowski wrote: > Hi! > I compiled OpenCxx under cygwin (latest). I got the occ.exe with and with= out > GC (DONT_GC uncommented). I tried to compile examples, i stared with > VerboseClass and VerboseClass2. I set the LD_LIBRARY_PATH to the current, > ofcourse. VerboseClass-init.so is made but there are errors when tried to > make VerboseClass.so. > I get the following: > > $ occ -m -v -I../src -I../gc/include -I../gc -- -I../src -I../gc/include > -I../gc VerboseClass2.mc > [Preprocess... g++ -I../src -I../gc/include -I../gc -D__opencxx -E -o > VerboseCl > ass2.occ -x c++ VerboseClass2.mc] > [Translate... VerboseClass2.occ into: VerboseClass2.ii] > MOP warning: The hash table is full. Expanded... > Produce VerboseClass2-init.cc .. > [Compile... g++ -fPIC -shared -o VerboseClass2-init.so > VerboseClass2-init.cc] > cc1plus: warning: -fPIC ignored for target (all code is position > independent) > [Compile... g++ -I../src -I../gc/include -I../gc -fPIC -shared -o > VerboseClass2 > .so VerboseClass2.ii] This looks strange to me. Perhaps '-c' is missing from this commandline (that would mean a bug in OpenC++). You can try to add '-c' by hand to this command line and run it by hand. I am now working on a wrapper script that uses occ just for translation and implements remaining functionality (compilation and linking) via libtool. That should solve this problem. The prototype can be checked out from sandbox_jakacki_frontend1 branch. Pozdrowienia Grzegorz > cc1plus: warning: -fPIC ignored for target (all code is position > independent) > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text+0x10e):VerboseCla= ss2 > .mc: > undefined reference to `Opencxx::Class::RegisterMetaclass(char*, char*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text+0x113):VerboseCla= ss2 > .mc: > undefined reference to `Opencxx::Class::Initialize()' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text+0x160):VerboseCla= ss2 > .mc: > undefined reference to > `Opencxx::Class::TranslateMemberCall(Opencxx::Environmen > t*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text+0x177):VerboseCla= ss2 > .mc: > undefined reference to `Opencxx::Ptree::Make(char const*, ...)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text+0x1fb):VerboseCla= ss2 > .mc: > undefined reference to > `Opencxx::opcxx_ListOfMetaclass::opcxx_ListOfMetaclass[i > n-charge](char*, Opencxx::Class* (*)(Opencxx::Ptree*, Opencxx::Ptree*), b= ool > (*) > (), Opencxx::Ptree* (*)())' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text+0x2ae):VerboseCla= ss2 > .mc: > undefined reference to > `Opencxx::opcxx_ListOfMetaclass::opcxx_ListOfMetaclass[i > n-charge](char*, Opencxx::Class* (*)(Opencxx::Ptree*, Opencxx::Ptree*), b= ool > (*) > (), Opencxx::Ptree* (*)())' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x8 > ):VerboseClass2.mc: undefined reference to > `Opencxx::Class::InitializeInstance(O > pencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x1 > 8):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateClass(Open > cxx::Environment*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x1 > c):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateMemberFunc > tion(Opencxx::Environment*, Opencxx::Member&)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x2 > 0):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateInitialize > r(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x2 > 4):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateNew(Opencx > x::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*, > Opencxx::Ptr > ee*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x2 > 8):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateDelete(Ope > ncxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x2 > c):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateAssign(Ope > ncxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x3 > 0):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateBinary(Ope > ncxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x3 > 4):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateUnary(Open > cxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x3 > 8):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateSubscript( > Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x3 > c):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslatePostfix(Op > encxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x4 > 0):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateFunctionCa > ll(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x4 > 8):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateMemberCall > (Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x4 > c):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateMemberRead > (Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*= )' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x5 > 0):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateMemberRead > (Opencxx::Environment*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x5 > 4):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateMemberWrit > e(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree= *, > Open > cxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x5 > 8):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateMemberWrit > e(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree= *)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x5 > c):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateUnaryOnMem > ber(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, > Opencxx::Ptree*, Op > encxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x6 > 0):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateUnaryOnMem > ber(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x6 > 4):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslatePostfixOnM > ember(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, > Opencxx::Ptree*, > Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x6 > 8):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslatePostfixOnM > ember(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x6 > c):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslatePointer(Op > encxx::Environment*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x7 > 0):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateUserStatem > ent(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, > Opencxx::Ptree*, Op > encxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x7 > 4):VerboseClass2.mc: undefined reference to > `Opencxx::Class::TranslateStaticUser > Statement(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x7 > 8):VerboseClass2.mc: undefined reference to > `Opencxx::Class::AcceptTemplate()' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x7 > c):VerboseClass2.mc: undefined reference to > `Opencxx::Class::FinalizeInstance()' > > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 > +0x8 > 0):VerboseClass2.mc: undefined reference to `Opencxx::Class::Finalize()' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text$_ZN13VerboseClass= 2D1 > Ev+0 > x16):VerboseClass2.mc: undefined reference to `Opencxx::Class::~Class > [not-in-ch > arge]()' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text$_ZN13VerboseClass= 2D0 > Ev+0 > x16):VerboseClass2.mc: undefined reference to `Opencxx::Class::~Class > [not-in-ch > arge]()' > /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text$_ZN7Opencxx5Class= C2E > v+0x > 16):VerboseClass2.mc: undefined reference to `vtable for Opencxx::Class' > collect2: ld returned 1 exit status > > > Any hints ?? > I would appreciate it. > > Thanks in advance > Nick Davidovsky > ################################################################## # Grzegorz Jakacki Huada Electronic Design # # Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang # # tel. +86-10-64365577 x2074 Beijing 100015, China # # Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
From: Grzegorz J. <ja...@he...> - 2003-12-16 01:59:47
|
Hi, On Thu, 11 Dec 2003, Julius Gunthorp wrote: > Hi, first I'd like to quickly congratulate and thank everyone who's > contributed to OpenC++, what a genuinely useful and cool project! Wow! > Previously Yang Qu sent an email to the list asking about generating Ptree's > (via TypeInfo::MakePtree) for encodings of templated types that have value > parameters (e.g. template_arg<16>, the "16" might be any non-type > epxression, so e.g. template_arg<(myconst + 7) / 8> is possible). Currently > OpenC++ is unable to generate a Ptree from an encoding for such a template > type. I took a quick look at the templates branch and it also doesn't appear > to handle this. > > I'm new to OpenC++ so don't understand its intricacies, but I'm fairly sure > my quick personal hack of this feature is the wrong way of doing it and > wanted to ask what a correct way would be. All I did was store the value of > the pointer to the template argument's Ptree (generated in > Parser::rTemplateArgs) in the encoded type string after the '*', then > changed Encoding::MakePtree to retrieve the pointer from the string when it > reads a '*'. Sounds good, but unfortunately I don't think it is *that* easy. With your approach 'templ<5>' and 'templ<1+4>' are not the same type, because they have different encodings. Also 'templ<5>' from one place in the code is not the same type as 'templ<5>' from another place in the code, because most likely both '5's are represented by individual ptrees (and consequently they yield different pointer value in the encoding). > Although it appears to work in my test case there's some obvious potential > issues with it: > 1. Might be unsafe with the garbage collector (which I've turned off > in my test case). I think so. I don't remember the details of how GC scans memory for pointers, but I would expect GC will ignore the pointer at least on platforms where you cannot store integers (pointers) at, say, odd addresses (AFAIK sun-sparc is such a platform). > 2. Might insert bytes equalling zero in the > middle of the encoded string (although I did a quick unthorough search for > string operations on encodings where zero bytes would matter and couldn't > find any). Perhaps this is not a huge issue. > 3. Precludes the possibility of serializing and unserializing > encoded type strings (which I don't attempt in my test case). Type encoding is an implementation detail and is not published in any interface, so I don't think this is a big issue either. The design problem I can see is mixing two approaches, namely tree-based type representation and serialized type representation. I think it is better to stick to one of them. > Instead of inserting the value of the pointer to the template paramater's > Ptree, it could be changed to insert the string from ptree->ToString() (with > the length of that string prepended). There is an issue here again. ToString() returns text as it appears in the source file, so in this case types "templ<5>" and "templ< 5 >" will not be recognized equal. > Then Encoding::MakePtree could call > Ptree::Make with the template parameter's string as the pattern. Would that > be the functionally correct? Unless there's issues with converting Ptree's > to strings and back again, To recap, the problem is not with converting Ptree to string, but rather with converting Ptree to *canonical* string (so that equality of strings implies equality of expressions (or types) represented by respective Ptrees). Neither pointer trick, nor ToString() provide canonical representation. Also I don't think Yang Qu's problem can be easily solved that way, because it is not enough to store just the expression used at template instantiation site, e.g. "templ<n>". Here you would also have to store the value of static constant n (which perhaps will not be visible in the scope where Yang Qu wants to create a variable of type "templ<n>") or preferably just an encoding of "templ<...>" with appropriate numeric value in place of '...'. > the only potential problem I see is exceeding the > 256 byte encoding char limit. This is an issue. Most likely before any serious work on templates we should remove this limitation (preferably by the means of string or vector<char>). > Alternatively, any object that stores an encoding string could be changed to > also store the Ptree that represents the type (from the parser). That seems > like a more drastic change, and I don't think it would handle substituting > typedefs with their original type the same way that the current encoding > system does. I am a little bit confused here, can you elaborate what would it break? Cheers Grzegorz ################################################################## # Grzegorz Jakacki Huada Electronic Design # # Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang # # tel. +86-10-64365577 x2074 Beijing 100015, China # # Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
From: <da...@te...> - 2003-12-14 17:27:27
|
Hi! I compiled OpenCxx under cygwin (latest). I got the occ.exe with and = without GC (DONT_GC uncommented). I tried to compile examples, i stared with VerboseClass and VerboseClass2. I set the LD_LIBRARY_PATH to the = current, ofcourse. VerboseClass-init.so is made but there are errors when tried = to make VerboseClass.so. I get the following: =20 $ occ -m -v -I../src -I../gc/include -I../gc -- -I../src -I../gc/include -I../gc VerboseClass2.mc [Preprocess... g++ -I../src -I../gc/include -I../gc -D__opencxx -E -o VerboseCl ass2.occ -x c++ VerboseClass2.mc] [Translate... VerboseClass2.occ into: VerboseClass2.ii] MOP warning: The hash table is full. Expanded... Produce VerboseClass2-init.cc .. [Compile... g++ -fPIC -shared -o VerboseClass2-init.so VerboseClass2-init.cc] cc1plus: warning: -fPIC ignored for target (all code is position independent) [Compile... g++ -I../src -I../gc/include -I../gc -fPIC -shared -o VerboseClass2 .so VerboseClass2.ii] cc1plus: warning: -fPIC ignored for target (all code is position independent) /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text+0x10e):VerboseCla= ss2 .mc: undefined reference to `Opencxx::Class::RegisterMetaclass(char*, = char*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text+0x113):VerboseCla= ss2 .mc: undefined reference to `Opencxx::Class::Initialize()' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text+0x160):VerboseCla= ss2 .mc: undefined reference to `Opencxx::Class::TranslateMemberCall(Opencxx::Environmen t*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text+0x177):VerboseCla= ss2 .mc: undefined reference to `Opencxx::Ptree::Make(char const*, ...)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text+0x1fb):VerboseCla= ss2 .mc: undefined reference to `Opencxx::opcxx_ListOfMetaclass::opcxx_ListOfMetaclass[i n-charge](char*, Opencxx::Class* (*)(Opencxx::Ptree*, Opencxx::Ptree*), = bool (*) (), Opencxx::Ptree* (*)())' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text+0x2ae):VerboseCla= ss2 .mc: undefined reference to `Opencxx::opcxx_ListOfMetaclass::opcxx_ListOfMetaclass[i n-charge](char*, Opencxx::Class* (*)(Opencxx::Ptree*, Opencxx::Ptree*), = bool (*) (), Opencxx::Ptree* (*)())' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x8 ):VerboseClass2.mc: undefined reference to `Opencxx::Class::InitializeInstance(O pencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x1 8):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateClass(Open cxx::Environment*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x1 c):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateMemberFunc tion(Opencxx::Environment*, Opencxx::Member&)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x2 0):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateInitialize r(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x2 4):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateNew(Opencx x::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptr ee*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x2 8):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateDelete(Ope ncxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x2 c):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateAssign(Ope ncxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x3 0):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateBinary(Ope ncxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x3 4):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateUnary(Open cxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x3 8):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateSubscript( Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x3 c):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslatePostfix(Op encxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x4 0):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateFunctionCa ll(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x4 8):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateMemberCall (Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x4 c):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateMemberRead (Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, = Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x5 0):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateMemberRead (Opencxx::Environment*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x5 4):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateMemberWrit e(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, = Opencxx::Ptree*, Open cxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x5 8):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateMemberWrit e(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, = Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x5 c):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateUnaryOnMem ber(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*, Op encxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x6 0):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateUnaryOnMem ber(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x6 4):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslatePostfixOnM ember(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x6 8):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslatePostfixOnM ember(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x6 c):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslatePointer(Op encxx::Environment*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x7 0):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateUserStatem ent(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*, Opencxx::Ptree*, Op encxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x7 4):VerboseClass2.mc: undefined reference to `Opencxx::Class::TranslateStaticUser Statement(Opencxx::Environment*, Opencxx::Ptree*, Opencxx::Ptree*)' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x7 8):VerboseClass2.mc: undefined reference to `Opencxx::Class::AcceptTemplate()' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x7 c):VerboseClass2.mc: undefined reference to `Opencxx::Class::FinalizeInstance()' =20 /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.rdata$_ZTV13VerboseCla= ss2 +0x8 0):VerboseClass2.mc: undefined reference to `Opencxx::Class::Finalize()' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text$_ZN13VerboseClass= 2D1 Ev+0 x16):VerboseClass2.mc: undefined reference to `Opencxx::Class::~Class [not-in-ch arge]()' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text$_ZN13VerboseClass= 2D0 Ev+0 x16):VerboseClass2.mc: undefined reference to `Opencxx::Class::~Class [not-in-ch arge]()' /cygdrive/c/DOCUME~1/mik/USTAWI~1/Temp/cc5XkxtC.o(.text$_ZN7Opencxx5Class= C2E v+0x 16):VerboseClass2.mc: undefined reference to `vtable for Opencxx::Class' collect2: ld returned 1 exit status =20 =20 Any hints ?? I would appreciate it. =20 Thanks in advance Nick Davidovsky |
From: Julius G. <jgu...@ho...> - 2003-12-11 22:41:51
|
Hi, first I'd like to quickly congratulate and thank everyone who's contributed to OpenC++, what a genuinely useful and cool project! Previously Yang Qu sent an email to the list asking about generating Ptree's (via TypeInfo::MakePtree) for encodings of templated types that have value parameters (e.g. template_arg<16>, the "16" might be any non-type epxression, so e.g. template_arg<(myconst + 7) / 8> is possible). Currently OpenC++ is unable to generate a Ptree from an encoding for such a template type. I took a quick look at the templates branch and it also doesn't appear to handle this. I'm new to OpenC++ so don't understand its intricacies, but I'm fairly sure my quick personal hack of this feature is the wrong way of doing it and wanted to ask what a correct way would be. All I did was store the value of the pointer to the template argument's Ptree (generated in Parser::rTemplateArgs) in the encoded type string after the '*', then changed Encoding::MakePtree to retrieve the pointer from the string when it reads a '*'. Although it appears to work in my test case there's some obvious potential issues with it: 1. Might be unsafe with the garbage collector (which I've turned off in my test case). 2. Might insert bytes equalling zero in the middle of the encoded string (although I did a quick unthorough search for string operations on encodings where zero bytes would matter and couldn't find any). 3. Precludes the possibility of serializing and unserializing encoded type strings (which I don't attempt in my test case). Instead of inserting the value of the pointer to the template paramater's Ptree, it could be changed to insert the string from ptree->ToString() (with the length of that string prepended). Then Encoding::MakePtree could call Ptree::Make with the template parameter's string as the pattern. Would that be the functionally correct? Unless there's issues with converting Ptree's to strings and back again, the only potential problem I see is exceeding the 256 byte encoding char limit. Alternatively, any object that stores an encoding string could be changed to also store the Ptree that represents the type (from the parser). That seems like a more drastic change, and I don't think it would handle substituting typedefs with their original type the same way that the current encoding system does. Thanks in advance, JG _________________________________________________________________ Shop online for kids toys by age group, price range, and toy category at MSN Shopping. No waiting for a clerk to help you! http://shopping.msn.com |
From: Grzegorz J. <ja...@he...> - 2003-12-09 00:27:55
|
On Mon, 8 Dec 2003, Vijay Patil wrote: > Hi , > > I am new to this use of tool. I was wondering if I can use this to parse a > C++ header file and get all the public methods info(like function signature > and other info) as an output(may be like in a parse tree). Redefine default metaclass just like samples/GraphClass.mc does. In TranslateClass() use NthMethod() to enumerate methods. Use Member::IsPublic() to filter out non-public members. Write if you need more help. BR Grzegorz > > Any help is appreciated. > > Regards, > Vijay > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > 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) 2003 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
From: Vijay P. <vi...@ap...> - 2003-12-08 23:44:57
|
Hi , I am new to this use of tool. I was wondering if I can use this to parse a C++ header file and get all the public methods info(like function signature and other info) as an output(may be like in a parse tree). Any help is appreciated. Regards, Vijay |
From: Grzegorz J. <ja...@he...> - 2003-11-14 03:08:11
|
Hi, Sorry for the late answer. On Mon, 10 Nov 2003, Marc Ordinas i Llopis wrote: > Grzegorz Jakacki wrote: > > >Hi Marc, > > > >Thanks much for your contribution. I fully agree with your point of view > >about separation of driver from the rest of the code. > > > >This is not the way to go on Windows however, since as I understand the > >requirement is that occ runs at compiles under vanila VC++ with no bash > >etc. > > > > > > > In Visual Studio, there is no easy way of launching a C++ file with a > different preprocessor, as all the executables are rolled into one, and > even then, VS just loads the C compiler as a DLL using COM. A real mess... > > >One solution i have been thinking of was translating the script into C > >with a tool (sh2c), but I am not sure if details really work out. > > > >Another solution is the one that you are proposig. > > > >The main problem however is that nobody is currently maintaining OpenC++ > >on Windows. Windows is very different that oter unix-like systems---for > >many platforms we can build and test on CompileFarm, unfortunately not for > >VC++. > > > >To wrap it up, I cannot reliably apply your patch, because I cannot > >reliably test the code afterwards. Would you find time to apply the patch > >and test yourself? Testing may require installing cygwin (bash). > > > > > I tried it under cygwin and with SUSE 8.2, which is what we have on our > internal server. I got the same results as with the CVS version, which > is... None at all. Recent CVS head has a small bug in testsuite, Alex Tolmos and myself are stabilizing it right now. > In Suse both versions (mine and CVS) build, but fail > to compile anything as the parser chokes on a system header. Could you send logs? (output of './configure; make; make test' and './testsuite/tester.log') > Using -n > works, though, and correctly translates the code. In Cygwin neither can > load any library due to problems with libtool (i even tried to > re-libtoolize it, as per an older message in this list, to no avail). I would very much appreciate if you could send more info on that. > As I don't have any idea on how autoconf/automake works (I just know > that it's immensely difficult to understand, with all those m4 macros > all over the place :), I can't really change the build scripts. Come on, it's only ones and zeros... > But I think you can just apply my patch and check that it works exactly > as the version in CVS right now. My patch was just a proposal on how a > small change could be the first step into separating OpenC++ into a > library and different drivers for different needs, keeping 'occ' as the > gcc-substitute on Unix systems. In fact the changes are very small: > > 1. Remove parser depency on global variable wcharSupport, which is now > passed as an argument to the Parser contructor. Agreed. > 2. Put QuoteClass code in quote-class.cc. It was in metaclass.cc before, > I don't really know why. Agreed. > 3. Set all the dloader #defines in metaclass.h, because it's the > metaclass code that defines how metaclasses are created, and therefore, > loaded. Good enough for now (eventually I want to get rid of this stuff). > 4. Change the Walker so that it does not depend on a particular > metaclass implementation. When it needs a metaclass, it just calls the > driver-exported LoadMetaclass function. Agreed. > > Think about this: You don't want to build a code transformer, but just a > small app that counts how many times a member function is called. So you > really don't need all that metaclass-compile code, and certainly not the > part were occ tries to behave like a compiler driver (calling the > preprocessor, then transform, then compiler, etc.). Exactly. > So you develop a > small app that just registers a metaclass, calls the OpenC++ lib and > writes the results. > > The important point to notice is that the core code does not depend at > all on Opencxx::Metaclass. As long as there is some way of signaling > that a 'Opencxx::Class'-derived class is needed to translate a > particular class, the parser and the walker work perfectly. > Opencxx::Metaclass is just one way of designing metaclasses (using > DLLs), but others could be designed. In fact it's easy to build a driver > that does not depend at all on Opencxx::Metaclass, and has it's own > metaclasses compiled in. Of course it needs to touch > opcxx_ListOfMetaclass, which is clearly an ugly hack. > > The solution, I think, is to make the whole Class loading/registry > protocol public. We'd have a library with two public interfaces, one for > drivers and another for metaclass builders. I call these interfaces > 'opencxx.h' and 'mop.h', respectively. In 'opencxx.h' we'd have: > > - Access to buffer.h, for loading source files. > - Access to Lexer, Parser and Walker. > - The definition of a Class registry (now implemented using > opcxx_ListOfMetaclasses), which the driver would have to subclass and > pass to the Walker (and probably the parser too). This class would have > functions for loading/creating Class-derived classes (be it from DLLs or > anything else) and for creating new instances for those. "Factory" design pattern. I was talking very similar approach over with Alex Tolmos wrt. way for creating metaobjects for templates. > Or maybe we > could integrate those functions in Opencxx::Class, but that would > require that all drivers subclass Opencxx::Class, an dI don't know which > system is worse. I would go for separating registration/creation from Class. No reasons to bundle it. Moreover, "factory" in natural way may be extended on other kinds of metaobjects (e.g. metaobjects representing templates; or free functions). > 'mop.h' would be the interface for > building those OpenCxx::Class derived classes, I don't understand this statement. > and it would include all the functionality in there right now > except the opcxx_ListOfMetaclasses stuff. > > The exact protocol on loading/creating metaclasses, that is, everything > that is right now in metaclass.cc would not be in the library, as it's > really a driver-dependent thing. Fine, but one thing is unclear to me. I assume that "the library" means parser+lexer+walkers. Do you mean to leave definition of metaclass in the library, but remove implementation (so that the library's object file has undefined symbols)? Perhaps it would be cleaner to make 'Metaclass' abstract or introduce an abstract class ("AbstractMetaclass" ???) obove it, and make "the library" depend on this class? I also fail to see why your "registry" or "factory" should produce objects of type "Class", not "Metaclass". > Of course, the 'occ' driver that just > camouflages itself as a standard C++ compiler could continue using that > way of creating/loading Classes, using libtool, etc. But any other > driver can do it another way. Sure. > Right now, as we use TCL to drive our > build system, I'm tempted of implementing a TCL-based driver, but I > still don't know how difficult that would be. I think I do not clearly understand what do you mean by "driver" here. Is a "driver" * something that runs lexer+parser+walker+user_defined_metaclass * something that runs lexer+parser+walker+Metaclass and misc. tools around it (preprocessor, compiler, linker) ? If you mean the latter, you may want to take look at my driver written in sh. It is a script that tries to implement current occ functionality using occ just for translation (occ -n -E -S). > > > Will you > >be interested in maintaining the VC++ build afterwards? > > > > > I am currently working in a very large project (game development), and > I'm pushing really hard for using OpenC++ to make it easier to control > the run-time part of the engine (that is, intefacing the C++ classes to > scripted events, etc.). I'm not sure yet on whether we'll be using it, > it all depends on how can I integrate it with our current tools (which > are, unfortunately, based on MS Windows). > > I'm now going to implement all the changes I have described, trying to > keep the 'occ' driver working on SuSE. In fact, it's just a refactoring. > The only thing I won't have time for is dealing with autoconf. OK. > So, if > it's OK with you all, I'll publish those changes and then you can decide > what to do with them. I think that your changes are very reasonable. Why don't you commit them to the sandbox branch? In order to do this, please send me your SourceForge id to get added to developers. Then you do export CVS_RSH=ssh export CVSROOT=:ext:ja...@cv...:/cvsroot/opencxx cvs rtag -b sandbox_YOURUSERID cvs co -r sandbox_YOURUSERID opencxx # copy over your changes cvs commit This would help to manage your changes efficiently. > Sorry if I've been a little verbose, but I'm really interested in using > OpenC++ in our project, which will not be possible if we don't make it a > little more flexible. I very much support it. Looking forward to hear from you Grzegorz > > Best regards and thanks for listening, > > Marc Ordinas i Llopis > > >Best regards > >Grzegorz > > > >On Fri, 7 Nov 2003, Marc Ordinas i Llopis wrote: > > > > > > > >>Alexandre Tolmos wrote: > >> > >> > >> > >>>Hi Marc, > >>> > >>>There is already a driver for Win32 called "driver2.cpp" in "src" but > >>>I don't know if it's up to date and suitable for VS.NET. > >>> > >>> > >>> > >>No, it's not up to date, unfortunately. > >> > >> > >> > >>>Btw, which version of OpenC++ did you use ? I commited a patch on the > >>>1st of November which completes the MacOS X port and upgrades the > >>>garbage collector to version 6.3alpha2. I recommend you to upgrade to > >>>the latest HEAD revision. > >>> > >>> > >>> > >>Yes, I'm aware of your patches, and I generated the patch with CVS. > >> > >>The point is that in Win32 you need to generate the DLLs for the > >>compile-time classes in a very different way from Unix. And in Visual > >>Studio you can't just tell it to call occ.exe instead of cl.exe (MS' > >>compiler). So you need a different Metaclass implementation and a > >>different driver. Fortunately, it's easy to separate concerns: > >> > >>The library > >>1) Parses C++. > >>2) Transforms it according to some metaclasses. > >> > >>And the driver > >>a) Provides a way of creating metaclasses. > >>b) Loads those and passes them to the library (when the library demands > >>them). > >>c) Offers some kind of interface to the outside, be it substituting the > >>usual call to the compiler, be it another different way. > >> > >>Of course, a and b can be independent, as long as there is a common > >>protocol. It's possible to create a driver that has all metaclasses > >>already compiled in, for example. Or the driver could use some scripting > >>language to implement the metaclasses. > >> > >>Anyway, I think patching driver2.cpp so that it works under Win32 is > >>wrong, what should be done is separating concerns and allowing an easier > >>way to create drivers. Of course, occ should be kept as the included > >>driver, because it works perfectly on Unix as a command-line substitute > >>of gcc. > >> > >>Regards, > >> > >>Marc Ordinas i Llopis > >> > >> > >> > >>>Alex > >>> > >>>Le jeudi, 6 nov 2003, ? 16:42 Europe/Paris, Marc Ordinas i Llopis a > >>>?crit : > >>> > >>> > >>> > >>>>Hi, > >>>> > >>>>We are going to use OpenC++ in a project, but we need to have a > >>>>working Win32 version. Creating a driver for use in VisualStudio.NET > >>>>is not easy, as the editor does not allow changing the compiler > >>>>executable. So I've had to separate OpenC++ in two parts, a library > >>>>and a driver. This requires very small modifications to the project, > >>>>and can be a step towards having a more modular code organization. > >>>> > >>>>I send you a patch (taken using cvs diff -u) with the required > >>>>changes, and I plan on having a Windows driver in short time. > >>>> > >>>>Regards, > >>>> > >>>>Marc Ordinas i Llopis > >>>> > >>>> > >>>------------------------------------------------------------------------ > >>>- > >>>Alexandre Tolmos > >>>E: ktulu at free.fr > >>>ICQ: 92964905 > >>>------------------------------------------------------------------------ > >>>- > >>>"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." > >>>------------------------------------------------------------------------ > >>>- > >>> > >>> > >> > >> > >> > >> > >>------------------------------------------------------- > >>This SF.net email is sponsored by: SF.net Giveback Program. > >>Does SourceForge.net help you be more productive? Does it > >>help you create better code? SHARE THE LOVE, and help us help > >>YOU! Click Here: http://sourceforge.net/donate/ > >>_______________________________________________ > >>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) 2003 Grzegorz Jakacki, HED. All Rights Reserved. # > >################################################################## > > > > > > > >------------------------------------------------------- > >This SF.Net email sponsored by: ApacheCon 2003, > >16-19 November in Las Vegas. Learn firsthand the latest > >developments in Apache, PHP, Perl, XML, Java, MySQL, > >WebDAV, and more! http://www.apachecon.com/ > >_______________________________________________ > >Opencxx-users mailing list > >Ope...@li... > >https://lists.sourceforge.net/lists/listinfo/opencxx-users > > > > > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > 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) 2003 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
From: Marc O. i L. <mar...@tr...> - 2003-11-10 11:08:04
|
Grzegorz Jakacki wrote: >Hi Marc, > >Thanks much for your contribution. I fully agree with your point of view >about separation of driver from the rest of the code. > >This is not the way to go on Windows however, since as I understand the >requirement is that occ runs at compiles under vanila VC++ with no bash >etc. > > > In Visual Studio, there is no easy way of launching a C++ file with a different preprocessor, as all the executables are rolled into one, and even then, VS just loads the C compiler as a DLL using COM. A real mess... >One solution i have been thinking of was translating the script into C >with a tool (sh2c), but I am not sure if details really work out. > >Another solution is the one that you are proposig. > >The main problem however is that nobody is currently maintaining OpenC++ >on Windows. Windows is very different that oter unix-like systems---for >many platforms we can build and test on CompileFarm, unfortunately not for >VC++. > >To wrap it up, I cannot reliably apply your patch, because I cannot >reliably test the code afterwards. Would you find time to apply the patch >and test yourself? Testing may require installing cygwin (bash). > > I tried it under cygwin and with SUSE 8.2, which is what we have on our internal server. I got the same results as with the CVS version, which is... None at all. In Suse both versions (mine and CVS) build, but fail to compile anything as the parser chokes on a system header. Using -n works, though, and correctly translates the code. In Cygwin neither can load any library due to problems with libtool (i even tried to re-libtoolize it, as per an older message in this list, to no avail). As I don't have any idea on how autoconf/automake works (I just know that it's immensely difficult to understand, with all those m4 macros all over the place :), I can't really change the build scripts. But I think you can just apply my patch and check that it works exactly as the version in CVS right now. My patch was just a proposal on how a small change could be the first step into separating OpenC++ into a library and different drivers for different needs, keeping 'occ' as the gcc-substitute on Unix systems. In fact the changes are very small: 1. Remove parser depency on global variable wcharSupport, which is now passed as an argument to the Parser contructor. 2. Put QuoteClass code in quote-class.cc. It was in metaclass.cc before, I don't really know why. 3. Set all the dloader #defines in metaclass.h, because it's the metaclass code that defines how metaclasses are created, and therefore, loaded. 4. Change the Walker so that it does not depend on a particular metaclass implementation. When it needs a metaclass, it just calls the driver-exported LoadMetaclass function. Think about this: You don't want to build a code transformer, but just a small app that counts how many times a member function is called. So you really don't need all that metaclass-compile code, and certainly not the part were occ tries to behave like a compiler driver (calling the preprocessor, then transform, then compiler, etc.). So you develop a small app that just registers a metaclass, calls the OpenC++ lib and writes the results. The important point to notice is that the core code does not depend at all on Opencxx::Metaclass. As long as there is some way of signaling that a 'Opencxx::Class'-derived class is needed to translate a particular class, the parser and the walker work perfectly. Opencxx::Metaclass is just one way of designing metaclasses (using DLLs), but others could be designed. In fact it's easy to build a driver that does not depend at all on Opencxx::Metaclass, and has it's own metaclasses compiled in. Of course it needs to touch opcxx_ListOfMetaclass, which is clearly an ugly hack. The solution, I think, is to make the whole Class loading/registry protocol public. We'd have a library with two public interfaces, one for drivers and another for metaclass builders. I call these interfaces 'opencxx.h' and 'mop.h', respectively. In 'opencxx.h' we'd have: - Access to buffer.h, for loading source files. - Access to Lexer, Parser and Walker. - The definition of a Class registry (now implemented using opcxx_ListOfMetaclasses), which the driver would have to subclass and pass to the Walker (and probably the parser too). This class would have functions for loading/creating Class-derived classes (be it from DLLs or anything else) and for creating new instances for those. Or maybe we could integrate those functions in Opencxx::Class, but that would require that all drivers subclass Opencxx::Class, an dI don't know which system is worse. 'mop.h' would be the interface for building those OpenCxx::Class derived classes, and it would include all the functionality in there right now except the opcxx_ListOfMetaclasses stuff. The exact protocol on loading/creating metaclasses, that is, everything that is right now in metaclass.cc would not be in the library, as it's really a driver-dependent thing. Of course, the 'occ' driver that just camouflages itself as a standard C++ compiler could continue using that way of creating/loading Classes, using libtool, etc. But any other driver can do it another way. Right now, as we use TCL to drive our build system, I'm tempted of implementing a TCL-based driver, but I still don't know how difficult that would be. > Will you >be interested in maintaining the VC++ build afterwards? > > I am currently working in a very large project (game development), and I'm pushing really hard for using OpenC++ to make it easier to control the run-time part of the engine (that is, intefacing the C++ classes to scripted events, etc.). I'm not sure yet on whether we'll be using it, it all depends on how can I integrate it with our current tools (which are, unfortunately, based on MS Windows). I'm now going to implement all the changes I have described, trying to keep the 'occ' driver working on SuSE. In fact, it's just a refactoring. The only thing I won't have time for is dealing with autoconf. So, if it's OK with you all, I'll publish those changes and then you can decide what to do with them. Sorry if I've been a little verbose, but I'm really interested in using OpenC++ in our project, which will not be possible if we don't make it a little more flexible. Best regards and thanks for listening, Marc Ordinas i Llopis >Best regards >Grzegorz > >On Fri, 7 Nov 2003, Marc Ordinas i Llopis wrote: > > > >>Alexandre Tolmos wrote: >> >> >> >>>Hi Marc, >>> >>>There is already a driver for Win32 called "driver2.cpp" in "src" but >>>I don't know if it's up to date and suitable for VS.NET. >>> >>> >>> >>No, it's not up to date, unfortunately. >> >> >> >>>Btw, which version of OpenC++ did you use ? I commited a patch on the >>>1st of November which completes the MacOS X port and upgrades the >>>garbage collector to version 6.3alpha2. I recommend you to upgrade to >>>the latest HEAD revision. >>> >>> >>> >>Yes, I'm aware of your patches, and I generated the patch with CVS. >> >>The point is that in Win32 you need to generate the DLLs for the >>compile-time classes in a very different way from Unix. And in Visual >>Studio you can't just tell it to call occ.exe instead of cl.exe (MS' >>compiler). So you need a different Metaclass implementation and a >>different driver. Fortunately, it's easy to separate concerns: >> >>The library >>1) Parses C++. >>2) Transforms it according to some metaclasses. >> >>And the driver >>a) Provides a way of creating metaclasses. >>b) Loads those and passes them to the library (when the library demands >>them). >>c) Offers some kind of interface to the outside, be it substituting the >>usual call to the compiler, be it another different way. >> >>Of course, a and b can be independent, as long as there is a common >>protocol. It's possible to create a driver that has all metaclasses >>already compiled in, for example. Or the driver could use some scripting >>language to implement the metaclasses. >> >>Anyway, I think patching driver2.cpp so that it works under Win32 is >>wrong, what should be done is separating concerns and allowing an easier >>way to create drivers. Of course, occ should be kept as the included >>driver, because it works perfectly on Unix as a command-line substitute >>of gcc. >> >>Regards, >> >>Marc Ordinas i Llopis >> >> >> >>>Alex >>> >>>Le jeudi, 6 nov 2003, ? 16:42 Europe/Paris, Marc Ordinas i Llopis a >>>?crit : >>> >>> >>> >>>>Hi, >>>> >>>>We are going to use OpenC++ in a project, but we need to have a >>>>working Win32 version. Creating a driver for use in VisualStudio.NET >>>>is not easy, as the editor does not allow changing the compiler >>>>executable. So I've had to separate OpenC++ in two parts, a library >>>>and a driver. This requires very small modifications to the project, >>>>and can be a step towards having a more modular code organization. >>>> >>>>I send you a patch (taken using cvs diff -u) with the required >>>>changes, and I plan on having a Windows driver in short time. >>>> >>>>Regards, >>>> >>>>Marc Ordinas i Llopis >>>> >>>> >>>------------------------------------------------------------------------ >>>- >>>Alexandre Tolmos >>>E: ktulu at free.fr >>>ICQ: 92964905 >>>------------------------------------------------------------------------ >>>- >>>"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." >>>------------------------------------------------------------------------ >>>- >>> >>> >> >> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: SF.net Giveback Program. >>Does SourceForge.net help you be more productive? Does it >>help you create better code? SHARE THE LOVE, and help us help >>YOU! Click Here: http://sourceforge.net/donate/ >>_______________________________________________ >>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) 2003 Grzegorz Jakacki, HED. All Rights Reserved. # >################################################################## > > > >------------------------------------------------------- >This SF.Net email sponsored by: ApacheCon 2003, >16-19 November in Las Vegas. Learn firsthand the latest >developments in Apache, PHP, Perl, XML, Java, MySQL, >WebDAV, and more! http://www.apachecon.com/ >_______________________________________________ >Opencxx-users mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opencxx-users > > |
From: Grzegorz J. <ja...@he...> - 2003-11-10 02:53:25
|
On Sun, 9 Nov 2003, Roberto Huelga wrote: > > I'm a new OpenC++ user, and I have troubles with Automake dependency. > > My system is a "Jaguar" Mac os x 10.2.6, I download the CVS and > install it with no problem, and work really fine. Now I was starting a > new project with Autoconf/Automake and an compiler created with > openc++, and I lose the auto dependency track. I think that Auto-tools > use the compiler with the -M option to get the file dependency and this > option doesn't work on openc++. I think you need to write a wrapper script and tell the Autotools that this is the compiler. The script should separate g++ compilation options from preprocessor options (-M is a preprocessor option) and do roughly this: cpp $PREPROC_OPTS $INFILE >$INFILE.occ.tmp && \ mv $INFILE.occ.tmp $INFILE.occ && \ occ -n -- $COMPILER_OPTIONS $INFILE.occ If you preprocess again after transformation, then you need a little bit more magic here, but it is doable. Let me know if you need more help. Best regards Grzegorz ################################################################## # Grzegorz Jakacki Huada Electronic Design # # Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang # # tel. +86-10-64365577 x2074 Beijing 100015, China # # Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
From: Grzegorz J. <ja...@he...> - 2003-11-10 02:53:14
|
On Sun, 9 Nov 2003, yang qu wrote: > Hi! > I am using Opencxx as a C++ parser in my case. In part > of the code, I need to identify an argument type and > generate a new variable using the same type. for > example, we have a function called "void > test(template_arg<16> a);". I need to find the type of > "a", which is "template_arg<16>" in the code, and > generate a new variable with this type. > I tried to use "TypeInfo" to catch the type and use > "TypeInfo::MakePtree()" to generate a new ptree of the > type. but unfortunately, because of the template > specialization, it doesn't work. I got the following > error "MOP error: in TypeInfo::MakePtree(), sorry, > cannot handle this type". > is there any quick fix to my problem? I don't think there is any quick fix. You may try if templates branch handles it properly, but if not, then it most likely needs some work to be done inside OpenC++. If you want to try to make it work I can help. BR Grzegorz ################################################################## # Grzegorz Jakacki Huada Electronic Design # # Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang # # tel. +86-10-64365577 x2074 Beijing 100015, China # # Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
From: Grzegorz J. <ja...@he...> - 2003-11-10 01:55:09
|
Hi Marc, Thanks much for your contribution. I fully agree with your point of view about separation of driver from the rest of the code. In fact the existing solution is not perfect even on Unix, because different platforms handle shared and dlopenable modules differently. I am currently working on this issue trying to leave only translation to occ and push all other jobs to the wrapper shell script that calls libtool. I recently checked the wrapper solution into the branch 'sandbox_jakacki_frontend1'. This is not the way to go on Windows however, since as I understand the requirement is that occ runs at compiles under vanila VC++ with no bash etc. One solution i have been thinking of was translating the script into C with a tool (sh2c), but I am not sure if details really work out. Another solution is the one that you are proposig. The main problem however is that nobody is currently maintaining OpenC++ on Windows. Windows is very different that oter unix-like systems---for many platforms we can build and test on CompileFarm, unfortunately not for VC++. To wrap it up, I cannot reliably apply your patch, because I cannot reliably test the code afterwards. Would you find time to apply the patch and test yourself? Testing may require installing cygwin (bash). Will you be interested in maintaining the VC++ build afterwards? Best regards Grzegorz On Fri, 7 Nov 2003, Marc Ordinas i Llopis wrote: > Alexandre Tolmos wrote: > > > Hi Marc, > > > > There is already a driver for Win32 called "driver2.cpp" in "src" but > > I don't know if it's up to date and suitable for VS.NET. > > > No, it's not up to date, unfortunately. > > > Btw, which version of OpenC++ did you use ? I commited a patch on the > > 1st of November which completes the MacOS X port and upgrades the > > garbage collector to version 6.3alpha2. I recommend you to upgrade to > > the latest HEAD revision. > > > Yes, I'm aware of your patches, and I generated the patch with CVS. > > The point is that in Win32 you need to generate the DLLs for the > compile-time classes in a very different way from Unix. And in Visual > Studio you can't just tell it to call occ.exe instead of cl.exe (MS' > compiler). So you need a different Metaclass implementation and a > different driver. Fortunately, it's easy to separate concerns: > > The library > 1) Parses C++. > 2) Transforms it according to some metaclasses. > > And the driver > a) Provides a way of creating metaclasses. > b) Loads those and passes them to the library (when the library demands > them). > c) Offers some kind of interface to the outside, be it substituting the > usual call to the compiler, be it another different way. > > Of course, a and b can be independent, as long as there is a common > protocol. It's possible to create a driver that has all metaclasses > already compiled in, for example. Or the driver could use some scripting > language to implement the metaclasses. > > Anyway, I think patching driver2.cpp so that it works under Win32 is > wrong, what should be done is separating concerns and allowing an easier > way to create drivers. Of course, occ should be kept as the included > driver, because it works perfectly on Unix as a command-line substitute > of gcc. > > Regards, > > Marc Ordinas i Llopis > > > Alex > > > > Le jeudi, 6 nov 2003, =E0 16:42 Europe/Paris, Marc Ordinas i Llopis a > > =E9crit : > > > >> Hi, > >> > >> We are going to use OpenC++ in a project, but we need to have a > >> working Win32 version. Creating a driver for use in VisualStudio.NET > >> is not easy, as the editor does not allow changing the compiler > >> executable. So I've had to separate OpenC++ in two parts, a library > >> and a driver. This requires very small modifications to the project, > >> and can be a step towards having a more modular code organization. > >> > >> I send you a patch (taken using cvs diff -u) with the required > >> changes, and I plan on having a Windows driver in short time. > >> > >> Regards, > >> > >> Marc Ordinas i Llopis > > > > > > -----------------------------------------------------------------------= - > > - > > Alexandre Tolmos > > E: ktulu at free.fr > > ICQ: 92964905 > > -----------------------------------------------------------------------= - > > - > > "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." > > -----------------------------------------------------------------------= - > > - > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > 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) 2003 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
From: yang qu <qu...@ya...> - 2003-11-09 22:42:39
|
Hi! I am using Opencxx as a C++ parser in my case. In part of the code, I need to identify an argument type and generate a new variable using the same type. for example, we have a function called "void test(template_arg<16> a);". I need to find the type of "a", which is "template_arg<16>" in the code, and generate a new variable with this type. I tried to use "TypeInfo" to catch the type and use "TypeInfo::MakePtree()" to generate a new ptree of the type. but unfortunately, because of the template specialization, it doesn't work. I got the following error "MOP error: in TypeInfo::MakePtree(), sorry, cannot handle this type". is there any quick fix to my problem? thank you! --yang __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree |
From: Roberto H. <rh...@mu...> - 2003-11-09 11:14:15
|
I'm a new OpenC++ user, and I have troubles with Automake dependency. My system is a "Jaguar" Mac os x 10.2.6, I download the CVS and install it with no problem, and work really fine. Now I was starting a new project with Autoconf/Automake and an compiler created with openc++, and I lose the auto dependency track. I think that Auto-tools use the compiler with the -M option to get the file dependency and this option doesn't work on openc++. Is someone with the same problem? |
From: Marc O. i L. <mar...@tr...> - 2003-11-07 08:46:45
|
Alexandre Tolmos wrote: > Hi Marc, > > There is already a driver for Win32 called "driver2.cpp" in "src" but=20 > I don't know if it's up to date and suitable for VS.NET. > No, it's not up to date, unfortunately. > Btw, which version of OpenC++ did you use ? I commited a patch on the = > 1st of November which completes the MacOS X port and upgrades the =20 > garbage collector to version 6.3alpha2. I recommend you to upgrade to = > the latest HEAD revision. > Yes, I'm aware of your patches, and I generated the patch with CVS. The point is that in Win32 you need to generate the DLLs for the=20 compile-time classes in a very different way from Unix. And in Visual=20 Studio you can't just tell it to call occ.exe instead of cl.exe (MS'=20 compiler). So you need a different Metaclass implementation and a=20 different driver. Fortunately, it's easy to separate concerns: The library 1) Parses C++. 2) Transforms it according to some metaclasses. And the driver a) Provides a way of creating metaclasses. b) Loads those and passes them to the library (when the library demands=20 them). c) Offers some kind of interface to the outside, be it substituting the=20 usual call to the compiler, be it another different way. Of course, a and b can be independent, as long as there is a common=20 protocol. It's possible to create a driver that has all metaclasses=20 already compiled in, for example. Or the driver could use some scripting = language to implement the metaclasses. Anyway, I think patching driver2.cpp so that it works under Win32 is=20 wrong, what should be done is separating concerns and allowing an easier = way to create drivers. Of course, occ should be kept as the included=20 driver, because it works perfectly on Unix as a command-line substitute=20 of gcc. Regards, Marc Ordinas i Llopis > Alex > > Le jeudi, 6 nov 2003, =E0 16:42 Europe/Paris, Marc Ordinas i Llopis a = > =E9crit : > >> Hi, >> >> We are going to use OpenC++ in a project, but we need to have a =20 >> working Win32 version. Creating a driver for use in VisualStudio.NET = >> is not easy, as the editor does not allow changing the compiler =20 >> executable. So I've had to separate OpenC++ in two parts, a library =20 >> and a driver. This requires very small modifications to the project, = >> and can be a step towards having a more modular code organization. >> >> I send you a patch (taken using cvs diff -u) with the required =20 >> changes, and I plan on having a Windows driver in short time. >> >> Regards, >> >> Marc Ordinas i Llopis > > > -----------------------------------------------------------------------= -=20 > - > Alexandre Tolmos > E: ktulu at free.fr > ICQ: 92964905 > -----------------------------------------------------------------------= -=20 > - > "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." > -----------------------------------------------------------------------= -=20 > - |
From: Alexandre T. <kt...@fr...> - 2003-11-06 16:48:13
|
Hi Marc, There is already a driver for Win32 called "driver2.cpp" in "src" but I =20= don't know if it's up to date and suitable for VS.NET. Btw, which version of OpenC++ did you use ? I commited a patch on the =20= 1st of November which completes the MacOS X port and upgrades the =20 garbage collector to version 6.3alpha2. I recommend you to upgrade to =20= the latest HEAD revision. Alex Le jeudi, 6 nov 2003, =E0 16:42 Europe/Paris, Marc Ordinas i Llopis a =20= =E9crit : > Hi, > > We are going to use OpenC++ in a project, but we need to have a =20 > working Win32 version. Creating a driver for use in VisualStudio.NET =20= > is not easy, as the editor does not allow changing the compiler =20 > executable. So I've had to separate OpenC++ in two parts, a library =20= > and a driver. This requires very small modifications to the project, =20= > and can be a step towards having a more modular code organization. > > I send you a patch (taken using cvs diff -u) with the required =20 > changes, and I plan on having a Windows driver in short time. > > Regards, > > Marc Ordinas i Llopis ------------------------------------------------------------------------=20= - Alexandre Tolmos E:=A0ktulu at free.fr ICQ: 92964905 ------------------------------------------------------------------------=20= - "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." ------------------------------------------------------------------------=20= - |