CInt and function pointers...

[Tarmik]

Hi !
 
Just out of curiosity I was searching on internet C++ interpretter, and found CINT.
I've managed to try to cross compile it for windows, and even managed to enable open GL / GLUT libraries
cross compiling on windows.
I was really disapponted to see that cint cannot obtain function pointer dynamically from C++ script itself.
Limitation: Precompiled function can not get pointer to interpreted function as
argument my_test.c(55)
Error: Function glutDisplayFunc(display) is not defined in current scope  my_
test.c(55)
!!! return from main() function
What I have checked as well - is that CINT still requires more tuning, related to batch execution
of script, etc...
Do you have many people developing CINT currently ?

--
Have a nice day!
Tarmo.

[Axel Naumann]

Hi Tarmo,

CINT offers a way to address functions whether compiled or interpreted:
G__CallFunc. Would this work for you? Can you maybe (like ROOT does)
wrap the function pointer into a struct that either represents a C++
function pointer or a CINT interpreted function?

Cheers, Axel.


Tarmo Pikaro wrote on 01/08/2012 12:03 AM:

> Hi !
>  
> Just out of curiosity I was searching on internet C++ interpretter, and found CINT.
> I've managed to try to cross compile it for windows, and even managed to enable open GL / GLUT libraries
> cross compiling on windows.
> I was really disapponted to see that cint cannot obtain function pointer dynamically from C++ script itself.
> Limitation: Precompiled function can not get pointer to interpreted function as
> argument my_test.c(55)
> Error: Function glutDisplayFunc(display) is not defined in current scope  my_
> test.c(55)
> !!! return from main() function
> What I have checked as well - is that CINT still requires more tuning, related to batch execution
> of script, etc...
> Do you have many people developing CINT currently ?
>
> --
> Have a nice day!
> Tarmo.
>
>

[gotom]

Dear Tarmo,

Cint used to be developed only by myself alone. And it is mainly maintained by CERN as part of high-energy physics software framework ROOT.

About interpreted function pointer, it could be possible to emulate that function by dynamically compile and link stub function and give compiled code a pointer to the stub code.  Otherwise, we'll have to tweak binary executable on the fly on the memory.
I did not bother to do that because interpreted function can be accessed from compiled code by G__calc("func(args)") API.

Thank you
Masaharu Goto

On 2012/01/08, at 8:03, Tarmo Pikaro wrote:

> Hi !
>  
> Just out of curiosity I was searching on internet C++ interpretter, and found CINT.
> I've managed to try to cross compile it for windows, and even managed to enable open GL / GLUT libraries
> cross compiling on windows.
> I was really disapponted to see that cint cannot obtain function pointer dynamically from C++ script itself.
> Limitation: Precompiled function can not get pointer to interpreted function as
> argument my_test.c(55)
> Error: Function glutDisplayFunc(display) is not defined in current scope  my_
> test.c(55)
> !!! return from main() function
> What I have checked as well - is that CINT still requires more tuning, related to batch execution
> of script, etc...
> Do you have many people developing CINT currently ?
>
> --
> Have a nice day!
> Tarmo.
>

[Tarmik]

Hi !
 
Thanks, this is definitely step forward.
 
I had a lot of problems compiling open gl support, as well as cint modules.
 
I have tried also compile win32api , but it fails with quite many errors. I'm using microsoft visual studio 2008.
 
Do you have in plans to make any support for it ? I could assist you if necessary, need to know bit deeper
design of cint.
 
I've seen also some documentation referring to LLVM compiler - has anyone tried it ?
 
I've really liked the grand big idea behind makecint. On other scripting languages, like perl, python, lua, java - you're
doomed to make your own wrappers. makecint operates on native API's for native API's.

--
Have a nice day!
Tarmo.


----- Original Message -----
From: Masaharu Goto <gotom@...>
To: Tarmo Pikaro <tapika@...>
Cc: "cint@..." <cint@...>
Sent: Tuesday, January 10, 2012 12:53 PM
Subject: Re: [CINT] CInt and function pointers...

Dear Tarmo,

Cint used to be developed only by myself alone. And it is mainly maintained by CERN as part of high-energy physics software framework ROOT.

About interpreted function pointer, it could be possible to emulate that function by dynamically compile and link stub function and give compiled code a pointer to the stub code.  Otherwise, we'll have to tweak binary executable on the fly on the memory.
I did not bother to do that because interpreted function can be accessed from compiled code by G__calc("func(args)") API.

Thank you
Masaharu Goto

On 2012/01/08, at 8:03, Tarmo Pikaro wrote:

> Hi !
> 
> Just out of curiosity I was searching on internet C++ interpretter, and found CINT.
> I've managed to try to cross compile it for windows, and even managed to enable open GL / GLUT libraries
> cross compiling on windows.
> I was really disapponted to see that cint cannot obtain function pointer dynamically from C++ script itself.
> Limitation: Precompiled function can not get pointer to interpreted function as
> argument my_test.c(55)
> Error: Function glutDisplayFunc(display) is not defined in current scope  my_
> test.c(55)
> !!! return from main() function
> What I have checked as well - is that CINT still requires more tuning, related to batch execution
> of script, etc...
> Do you have many people developing CINT currently ?
>
> --
> Have a nice day!
> Tarmo.
>

[gotom]

Hi Tarmo,

Thank you very much for your remark.  
I needed such tool as a user and happened to be the one who actually create it.

I used to support CINT and did a lot of enhancements.
At this moment, I am an active user of CINT and ROOT, however not active for support and enhancement.  Supporting multiple applications + multiple platforms and continuing compiler version up turned out to be too much, together with my other work.  I am still using old Visual C++6.0/7.2 on Windows. gl and Win32API are the most tricky libraries among all.

Instead, I am using ROOT as multiplatform graphics, database and house keeping platform. People in CERN and Fermi-Lab are committed to support ROOT/CINT, at least, as long as they operate LHC experiements at CERN which is beyond 2030, I guess.  ROOT looks quite heavy at the beginning, but it is really nice once you learn.

Thank you
Masaharu Goto

---- Tarmo Pikaro <tapika@...> さんは書きました:
> Hi !
?
Thanks, this is definitely step forward.
?
I had a lot of problems compiling open gl support, as well as cint modules.
?
I have tried also compile win32api , but it fails with quite many errors. I'm using microsoft visual studio 2008.
?
Do you have in plans to make any support for it ? I could assist you if necessary, need to know bit deeper
design of cint.
?
I've seen also some documentation referring to LLVM compiler - has anyone tried it ?
?
I've really liked the grand big idea behind makecint. On other scripting languages, like perl, python, lua, java - you're
doomed to make your own wrappers. makecint operates on native API's for native API's.

--
Have a nice day!
Tarmo.


----- Original Message -----
From: Masaharu Goto <gotom@...>
To: Tarmo Pikaro <tapika@...>
Cc: "cint@..." <cint@...>
Sent: Tuesday, January 10, 2012 12:53 PM
Subject: Re: [CINT] CInt and function pointers...

Dear Tarmo,

Cint used to be developed only by myself alone. And it is mainly maintained by CERN as part of high-energy physics software framework ROOT.

About interpreted function pointer, it could be possible to emulate that function by dynamically compile and link stub function and give compiled code a pointer to the stub code.? Otherwise, we'll have to tweak binary executable on the fly on the memory.
I did not bother to do that because interpreted function can be accessed from compiled code by G__calc("func(args)") API.

Thank you
Masaharu Goto

On 2012/01/08, at 8:03, Tarmo Pikaro wrote:

> Hi !
>?
> Just out of curiosity I was searching on internet C++ interpretter, and found CINT.
> I've managed to try to cross compile it for windows, and even managed to enable open GL / GLUT libraries
> cross compiling on windows.
> I was really disapponted to see that cint cannot obtain function pointer dynamically from C++ script itself.
> Limitation: Precompiled function can not get pointer to interpreted function as
> argument my_test.c(55)
> Error: Function glutDisplayFunc(display) is not defined in current scope? my_
> test.c(55)
> !!! return from main() function
> What I have checked as well - is that CINT still requires more tuning, related to batch execution
> of script, etc...
> Do you have many people developing CINT currently ?
>
> --
> Have a nice day!
> Tarmo.
>
>

[Tarmik]

Hi !

> At this moment, I am an active user of CINT and ROOT, however not active for support and enhancement.  Supporting multiple applications + multiple platforms and continuing compiler version up turned out 
> to be too much, together with my other work.  I am still using old Visual C++6.0/7.2 on Windows. gl and Win32API are the most tricky libraries among all.


This is so typical - you're considering youself as support personnel for all compilers and platforms, meanwhile I think you should take different perspective - 
you're developing master codeline, and visual c++ is a clue to your script. :-)  I would propose to make special kind of define which identifies CINT scripter
and allow developers to patch existing environments to hide incompatibilities. For example:

windows.h:
...
void
#ifdef CINT
    __stdcall
#endif
      myfunc(void);
...

however - this is not always doable - hit already against incompatibilities with call conventions.

Anyway - are you willing to assist / help me if I'll take a swim into cint source code ?
(I'll analyze it for suitability for further development, but after that I don't see any problem).

It would be also good if you could give me good contacts to chat directly - skype id's / etc...

We could use this forum as well, but for moderated information.

 
--
Have a nice day!
Tarmo.


----- Original Message -----
From: "gotom@..." <gotom@...>
To: Tarmo Pikaro <tapika@...>
Cc: cint@...
Sent: Friday, January 13, 2012 6:51 AM
Subject: Re: [CINT] CInt and function pointers...

Hi Tarmo,

Thank you very much for your remark. 
I needed such tool as a user and happened to be the one who actually create it.

I used to support CINT and did a lot of enhancements.
At this moment, I am an active user of CINT and ROOT, however not active for support and enhancement.  Supporting multiple applications + multiple platforms and continuing compiler version up turned out to be too much, together with my other work.  I am still using old Visual C++6.0/7.2 on Windows. gl and Win32API are the most tricky libraries among all.

Instead, I am using ROOT as multiplatform graphics, database and house keeping platform. People in CERN and Fermi-Lab are committed to support ROOT/CINT, at least, as long as they operate LHC experiements at CERN which is beyond 2030, I guess.  ROOT looks quite heavy at the beginning, but it is really nice once you learn.

Thank you
Masaharu Goto

[gotom]

Hello Tarmo,

That is already provided.

#ifdef __CINT__
// CINT specific code
#endif
#ifdef G__ROOT
// CINT used with ROOT specific code
#endif

I can give you information where it is possible.  I am afraid you are probably underestimating amount of effort needed to realize what you'd like to acomplish.

Thank you
Masaharu Goto


---- Tarmo Pikaro <tapika@...> さんは書きました:
> Hi !

> At this moment, I am an active user of CINT and ROOT, however not active for support and enhancement.? Supporting multiple applications + multiple platforms and continuing compiler version up turned out?
> to be too much, together with my other work.? I am still using old Visual C++6.0/7.2 on Windows. gl and Win32API are the most tricky libraries among all.


This is so typical - you're considering youself as support personnel for all compilers and platforms, meanwhile I think you should take different perspective -?
you're developing master codeline, and visual c++ is a clue to your script. :-) ?I would propose to make special kind of define which identifies CINT scripter
and allow developers to patch existing environments to hide incompatibilities. For example:

windows.h:
...
void
#ifdef CINT
? ? __stdcall
#endif
? ? ? myfunc(void);
...

however - this is not always doable - hit already against incompatibilities with call conventions.

Anyway - are you willing to assist / help me if I'll take a swim into cint source code ?
(I'll analyze it for suitability for further development, but after that I don't see any problem).

It would be also good if you could give me good contacts to chat directly - skype id's / etc...

We could use this forum as well, but for moderated information.

?
--
Have a nice day!
Tarmo.


----- Original Message -----
From: "gotom@..." <gotom@...>
To: Tarmo Pikaro <tapika@...>
Cc: cint@...
Sent: Friday, January 13, 2012 6:51 AM
Subject: Re: [CINT] CInt and function pointers...

Hi Tarmo,

Thank you very much for your remark.?
I needed such tool as a user and happened to be the one who actually create it.

I used to support CINT and did a lot of enhancements.
At this moment, I am an active user of CINT and ROOT, however not active for support and enhancement.? Supporting multiple applications + multiple platforms and continuing compiler version up turned out to be too much, together with my other work.? I am still using old Visual C++6.0/7.2 on Windows. gl and Win32API are the most tricky libraries among all.

Instead, I am using ROOT as multiplatform graphics, database and house keeping platform. People in CERN and Fermi-Lab are committed to support ROOT/CINT, at least, as long as they operate LHC experiements at CERN which is beyond 2030, I guess.? ROOT looks quite heavy at the beginning, but it is really nice once you learn.

Thank you
Masaharu Goto

[Tarmik]

Hi !

> I can give you information where it is possible.  I am afraid you are probably underestimating amount of effort needed to realize what you'd like to acomplish. 


That's ok, I'm learning new things and techniques. C++ scripting is only intermediate step for me, at the end I would like to get
new (programming + natural)  language in place - some ideas can be found here:

http://simplelanguage.wikidot.com/local--files/forum:start/NewLanguage_v0_2.ppt


I'm already similar with gcc's abstract syntax trees, and compilers in that sense.

Ok, I'll try to dig up next questions, after I'll hit into problems.

--
Have a nice day!
Tarmo.


----- Original Message -----
From: "gotom@..." <gotom@...>
To: Tarmo Pikaro <tapika@...>
Cc: "cint@..." <cint@...>
Sent: Saturday, January 14, 2012 6:27 PM
Subject: Re: [CINT] CInt and function pointers...

Hello Tarmo,

That is already provided.

#ifdef __CINT__
// CINT specific code
#endif
#ifdef G__ROOT
// CINT used with ROOT specific code
#endif

I can give you information where it is possible.  I am afraid you are probably underestimating amount of effort needed to realize what you'd like to acomplish.

Thank you
Masaharu Goto


---- Tarmo Pikaro <tapika@...> さんは書きました:
> Hi !

> At this moment, I am an active user of CINT and ROOT, however not active for support and enhancement.? Supporting multiple applications + multiple platforms and continuing compiler version up turned out?
> to be too much, together with my other work.? I am still using old Visual C++6.0/7.2 on Windows. gl and Win32API are the most tricky libraries among all.


This is so typical - you're considering youself as support personnel for all compilers and platforms, meanwhile I think you should take different perspective -?
you're developing master codeline, and visual c++ is a clue to your script. :-) ?I would propose to make special kind of define which identifies CINT scripter
and allow developers to patch existing environments to hide incompatibilities. For example:

windows.h:
...
void
#ifdef CINT
? ? __stdcall
#endif
? ? ? myfunc(void);
...

however - this is not always doable - hit already against incompatibilities with call conventions.

Anyway - are you willing to assist / help me if I'll take a swim into cint source code ?
(I'll analyze it for suitability for further development, but after that I don't see any problem).

It would be also good if you could give me good contacts to chat directly - skype id's / etc...

We could use this forum as well, but for moderated information.

?
--
Have a nice day!
Tarmo.


----- Original Message -----
From: "gotom@..." <gotom@...>
To: Tarmo Pikaro <tapika@...>
Cc: cint@...
Sent: Friday, January 13, 2012 6:51 AM
Subject: Re: [CINT] CInt and function pointers...

Hi Tarmo,

Thank you very much for your remark.?
I needed such tool as a user and happened to be the one who actually create it.

I used to support CINT and did a lot of enhancements.
At this moment, I am an active user of CINT and ROOT, however not active for support and enhancement.? Supporting multiple applications + multiple platforms and continuing compiler version up turned out to be too much, together with my other work.? I am still using old Visual C++6.0/7.2 on Windows. gl and Win32API are the most tricky libraries among all.

Instead, I am using ROOT as multiplatform graphics, database and house keeping platform. People in CERN and Fermi-Lab are committed to support ROOT/CINT, at least, as long as they operate LHC experiements at CERN which is beyond 2030, I guess.? ROOT looks quite heavy at the beginning, but it is really nice once you learn.

Thank you
Masaharu Goto

[Tarmik]

Hi !

What I have understood from makecint behavior - it first scans source codes by itself , then executes compiler on the same source codes
- and in my case it's visual studio 2008. For some reason makecint was not able to find it's default include folder - so I have added
extra parameter:
"-I ../../../bin/include"

to makecint command line parameter.

But then microsoft compiler did not like those includes anymore -

C:\projects_prototype\cygwin_cint-5.18.00\cint\lib\win32api>make.exe -f Makewin  
/cygdrive/c/projects_prototype/cygwin_cint-5.18.00/bin/cint.exe  -K -w2 -zwin32api -nG__c_win32api.c  -D__MAKECINT__ -DG__MAKECINT -DG__REDIRECTIO -DG__SHAREDLIB -DG__WIN32 -DWIN32 -D_WIN32 -DG__NEWSTDHEADER -D_CRT_SECURE_NO_DEPRECATE=1 -DG__HAVE_CONFIG -DG__NOMAKEINFO   -c-2  -IC:/cygwin/include/cint -I../../../bin/include -DG__REDIRECTIO -DG__SHAREDLIB -DG__WIN32 -DWIN32 -D_WIN32 -DG__NEWSTDHEADER -D_CRT_SECURE_NO_DEPRECATE=1 -DG__HAVE_CONFIG -DG__NOMAKEINFO  -Z0 +P cintwin.h -P winfunc.h
2930445_cint.c
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\windef.h(124) : warning C4005: 'WINAPI' : macro redefinition
        ../../../bin/include\platform.h(42) : see previous definition of 'WINAPI'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\windef.h(126) : warning C4005: 'APIENTRY' : macro redefinition
        ../../../bin/include\platform.h(48) : see previous definition of 'APIENTRY'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winnt.h(240) : warning C4005: 'NTAPI' : macro redefinition
        ../../../bin/include\platform.h(39) : see previous definition of 'NTAPI'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\wingdi.h(23) : warning C4005: 'WINGDIAPI' : macro redefinition
        ../../../bin/include\platform.h(45) : see previous definition of 'WINGDIAPI'
Warning: Unknown type SA_Parameter in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(69)
Warning: Unknown type SA_Parameter|SA_ReturnValue in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(100)
Warning: Unknown type SA_Parameter in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(131)
Warning: Unknown type SA_ReturnValue in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(143)
Warning: Unknown type SA_Method in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(153)
Warning: Unknown type SA_Parameter in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(164)
Warning: Unknown type SA_Parameter|SA_ReturnValue in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(174)
Warning: Unknown type SA_Parameter in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(184)
Warning: Unknown type SA_Parameter|SA_ReturnValue in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(196)
Note: Bit-field not accessible from interpreter C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winnt.h(3720)
Warning: Unknown type 'PULONG64' in function argument handled as int C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winbase.h(2846)
Warning: Unknown type 'PULONG64' in function argument handled as int C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winbase.h(2854)
Warning: Unknown type 'PULONG64' in function argument handled as int C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winbase.h(2862)
Note: link requested for unknown class tagFILETIME winfunc.h(37)
Note: link requested for unknown class _WIN32_FIND_DATA winfunc.h(63)
Note: link requested for unknown function CreateDIBSction winfunc.h(1009)
cl -IC:/cygwin/include/cint -I../../../bin/include -DG__REDIRECTIO -DG__SHAREDLIB -DG__WIN32 -DWIN32 -D_WIN32 -DG__NEWSTDHEADER -D_CRT_SECURE_NO_DEPRECATE=1 -DG__HAVE_CONFIG -DG__NOMAKEINFO  -O2 -MD  -nologo -wd4996  -EHs    -c G__c_win32api.c
G__c_win32api.c
../../../bin/include\stdio.h(4) : warning C4068: unknown pragma
../../../bin/include\stdio.h(8) : error C2061: syntax error : identifier 'fpos_t'
../../../bin/include\stdio.h(9) : error C2182: 'operator' : illegal use of type 'void'

 where stdio.h declares it as:

#ifndef G__STDIO_H
#define G__STDIO_H
#ifndef NULL
#pragma setstdio
#endif
typedef struct fpos_t {
  long l,u;
  fpos_t(long i=0){l=i;u=0;}                 // < line 8.
  void operator=(long i){l=i;u=0;}
} fpos_t;


How this should be officially handled - makecint should know it's own include folder - or not ?

 
--
Have a nice day!
Tarmo.

[Tarmik]

Hi !

If I don't add this cint include folder - I'm getting error like this:

C:\projects_prototype\cygwin_cint-5.18.00\cint\lib\win32api>makecint  -mk Makewin -dl win32api.dll -h +P cintwin.h -P winfunc.h -cint -Z0 
##########################################################################
# makecint : interpreter-compiler for cint (Windows VisualC++ version)
# Copyright(c) 1995~2010 Masaharu Goto. Mailing list: cint@...
##########################################################################
Run 'make -f Makewin' to compile the object

C:\projects_prototype\cygwin_cint-5.18.00\cint\lib\win32api>make.exe -f Makewin  
/cygdrive/c/projects_prototype/cygwin_cint-5.18.00/bin/cint.exe  -K -w2 -zwin32api -nG__c_win32api.c  -D__MAKECINT__ -DG__MAKECINT -DG__REDIRECTIO -DG__SHAREDLIB -DG__WIN32 -DWIN32 -D_WIN32 -DG__NEWSTDHEADER -D_CRT_SECURE_NO_DEPRECATE=1 -DG__HAVE_CONFIG -DG__NOMAKEINFO   -c-2  -IC:/cygwin/include/cint  -DG__REDIRECTIO -DG__SHAREDLIB -DG__WIN32 -DWIN32 -D_WIN32 -DG__NEWSTDHEADER -D_CRT_SECURE_NO_DEPRECATE=1 -DG__HAVE_CONFIG -DG__NOMAKEINFO  -Z0 +P cintwin.h -P winfunc.h
2886030_cint.c
.\cintwin.h(19) : fatal error C1083: Cannot open include file: 'platform.h': No such file or directory
Error: external preprocessing failed. (0)
!!!Removing G__c_win32api.c G__c_win32api.h !!!
Makewin:70: recipe for target `G__c_win32api.c' failed
make: *** [G__c_win32api.c] Error 1

Is this generated by cint preprocessor or by CL compiler ?

I guess cintwin.h declares it as 

/* cint headers */
#ifdef __CINT__
#include <stdlib.h> 
#include <platform.h>
#endif

and cint should be preprocessing cintwin.h - since only then __CINT__ is defined.



 
--
Have a nice day!
Tarmo.

[gotom]

Hi Tarmo,

Great!  Such a ambition.  You are a right person for the challenge.

Masaharu Goto

---- Tarmo Pikaro <tapika@...> さんは書きました:
> Hi !

> I can give you information where it is possible.? I am afraid you are probably underestimating amount of effort needed to realize what you'd like to acomplish.?


That's ok, I'm learning new things and techniques. C++ scripting is only intermediate step for me, at the end I would like to get
new (programming + natural) ?language in place - some ideas can be found here:

http://simplelanguage.wikidot.com/local--files/forum:start/NewLanguage_v0_2.ppt


I'm already similar with gcc's abstract syntax trees, and compilers in that sense.

Ok, I'll try to dig up next questions, after I'll hit into problems.

--
Have a nice day!
Tarmo.


----- Original Message -----
From: "gotom@..." <gotom@...>
To: Tarmo Pikaro <tapika@...>
Cc: "cint@..." <cint@...>
Sent: Saturday, January 14, 2012 6:27 PM
Subject: Re: [CINT] CInt and function pointers...

Hello Tarmo,

That is already provided.

#ifdef __CINT__
// CINT specific code
#endif
#ifdef G__ROOT
// CINT used with ROOT specific code
#endif

I can give you information where it is possible.? I am afraid you are probably underestimating amount of effort needed to realize what you'd like to acomplish.

Thank you
Masaharu Goto


---- Tarmo Pikaro <tapika@...> さんは書きました:
> Hi !

> At this moment, I am an active user of CINT and ROOT, however not active for support and enhancement.? Supporting multiple applications + multiple platforms and continuing compiler version up turned out?
> to be too much, together with my other work.? I am still using old Visual C++6.0/7.2 on Windows. gl and Win32API are the most tricky libraries among all.


This is so typical - you're considering youself as support personnel for all compilers and platforms, meanwhile I think you should take different perspective -?
you're developing master codeline, and visual c++ is a clue to your script. :-) ?I would propose to make special kind of define which identifies CINT scripter
and allow developers to patch existing environments to hide incompatibilities. For example:

windows.h:
...
void
#ifdef CINT
? ? __stdcall
#endif
? ? ? myfunc(void);
...

however - this is not always doable - hit already against incompatibilities with call conventions.

Anyway - are you willing to assist / help me if I'll take a swim into cint source code ?
(I'll analyze it for suitability for further development, but after that I don't see any problem).

It would be also good if you could give me good contacts to chat directly - skype id's / etc...

We could use this forum as well, but for moderated information.

?
--
Have a nice day!
Tarmo.


----- Original Message -----
From: "gotom@..." <gotom@...>
To: Tarmo Pikaro <tapika@...>
Cc: cint@...
Sent: Friday, January 13, 2012 6:51 AM
Subject: Re: [CINT] CInt and function pointers...

Hi Tarmo,

Thank you very much for your remark.?
I needed such tool as a user and happened to be the one who actually create it.

I used to support CINT and did a lot of enhancements.
At this moment, I am an active user of CINT and ROOT, however not active for support and enhancement.? Supporting multiple applications + multiple platforms and continuing compiler version up turned out to be too much, together with my other work.? I am still using old Visual C++6.0/7.2 on Windows. gl and Win32API are the most tricky libraries among all.

Instead, I am using ROOT as multiplatform graphics, database and house keeping platform. People in CERN and Fermi-Lab are committed to support ROOT/CINT, at least, as long as they operate LHC experiements at CERN which is beyond 2030, I guess.? ROOT looks quite heavy at the beginning, but it is really nice once you learn.

Thank you
Masaharu Goto

[Axel Naumann]

Hi Tarmo,

As you expected, CINT should find platform.h automatically in
cint/include. Do you have it? Did you define the environment variable
CINTSYSDIR to point to cint/?

Cheers, Axel.


Tarmo Pikaro wrote on 01/15/2012 09:01 AM:

> Hi !
>
> If I don't add this cint include folder - I'm getting error like this:
>
> C:\projects_prototype\cygwin_cint-5.18.00\cint\lib\win32api>makecint  -mk Makewin -dl win32api.dll -h +P cintwin.h -P winfunc.h -cint -Z0
> ##########################################################################
> # makecint : interpreter-compiler for cint (Windows VisualC++ version)
> # Copyright(c) 1995~2010 Masaharu Goto. Mailing list: cint@...
> ##########################################################################
> Run 'make -f Makewin' to compile the object
>
> C:\projects_prototype\cygwin_cint-5.18.00\cint\lib\win32api>make.exe -f Makewin  
> /cygdrive/c/projects_prototype/cygwin_cint-5.18.00/bin/cint.exe  -K -w2 -zwin32api -nG__c_win32api.c  -D__MAKECINT__ -DG__MAKECINT -DG__REDIRECTIO -DG__SHAREDLIB -DG__WIN32 -DWIN32 -D_WIN32 -DG__NEWSTDHEADER -D_CRT_SECURE_NO_DEPRECATE=1 -DG__HAVE_CONFIG -DG__NOMAKEINFO   -c-2  -IC:/cygwin/include/cint  -DG__REDIRECTIO -DG__SHAREDLIB -DG__WIN32 -DWIN32 -D_WIN32 -DG__NEWSTDHEADER -D_CRT_SECURE_NO_DEPRECATE=1 -DG__HAVE_CONFIG -DG__NOMAKEINFO  -Z0 +P cintwin.h -P winfunc.h
> 2886030_cint.c
> .\cintwin.h(19) : fatal error C1083: Cannot open include file: 'platform.h': No such file or directory
> Error: external preprocessing failed. (0)
> !!!Removing G__c_win32api.c G__c_win32api.h !!!
> Makewin:70: recipe for target `G__c_win32api.c' failed
> make: *** [G__c_win32api.c] Error 1
>
> Is this generated by cint preprocessor or by CL compiler ?
>
> I guess cintwin.h declares it as
>
> /* cint headers */
> #ifdef __CINT__
> #include <stdlib.h>
> #include <platform.h>
> #endif
>
> and cint should be preprocessing cintwin.h - since only then __CINT__ is defined.
>
>
>
>  
> --
> Have a nice day!
> Tarmo.
>
>

[gotom]

Hello Tarmo,

You have to enclose CINT specific pragma with

#ifndef __CINT__
#pragma  .....
#endif

You need to be aware which part is for CINT and which for compiler.  Many of the files under Cint directory, especially, one that have same name as standard header files are for CINT and not for compiler.  As you observe the makecint behavior almost correctly, when cint reads the header it has to read CINT specific file and when compiler does it, it has to read standard header.  

Thank you
Masaharu Goto


On 2012/01/15, at 7:58, Tarmo Pikaro wrote:

> Hi !
>
> What I have understood from makecint behavior - it first scans source codes by itself , then executes compiler on the same source codes
> - and in my case it's visual studio 2008. For some reason makecint was not able to find it's default include folder - so I have added
> extra parameter:
> "-I ../../../bin/include"
>
> to makecint command line parameter.
>
> But then microsoft compiler did not like those includes anymore -
>
> C:\projects_prototype\cygwin_cint-5.18.00\cint\lib\win32api>make.exe -f Makewin  
> /cygdrive/c/projects_prototype/cygwin_cint-5.18.00/bin/cint.exe  -K -w2 -zwin32api -nG__c_win32api.c  -D__MAKECINT__ -DG__MAKECINT -DG__REDIRECTIO -DG__SHAREDLIB -DG__WIN32 -DWIN32 -D_WIN32 -DG__NEWSTDHEADER -D_CRT_SECURE_NO_DEPRECATE=1 -DG__HAVE_CONFIG -DG__NOMAKEINFO   -c-2  -IC:/cygwin/include/cint -I../../../bin/include -DG__REDIRECTIO -DG__SHAREDLIB -DG__WIN32 -DWIN32 -D_WIN32 -DG__NEWSTDHEADER -D_CRT_SECURE_NO_DEPRECATE=1 -DG__HAVE_CONFIG -DG__NOMAKEINFO  -Z0 +P cintwin.h -P winfunc.h
> 2930445_cint.c
> C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\windef.h(124) : warning C4005: 'WINAPI' : macro redefinition
>         ../../../bin/include\platform.h(42) : see previous definition of 'WINAPI'
> C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\windef.h(126) : warning C4005: 'APIENTRY' : macro redefinition
>         ../../../bin/include\platform.h(48) : see previous definition of 'APIENTRY'
> C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winnt.h(240) : warning C4005: 'NTAPI' : macro redefinition
>         ../../../bin/include\platform.h(39) : see previous definition of 'NTAPI'
> C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\wingdi.h(23) : warning C4005: 'WINGDIAPI' : macro redefinition
>         ../../../bin/include\platform.h(45) : see previous definition of 'WINGDIAPI'
> Warning: Unknown type SA_Parameter in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(69)
> Warning: Unknown type SA_Parameter|SA_ReturnValue in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(100)
> Warning: Unknown type SA_Parameter in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(131)
> Warning: Unknown type SA_ReturnValue in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(143)
> Warning: Unknown type SA_Method in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(153)
> Warning: Unknown type SA_Parameter in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(164)
> Warning: Unknown type SA_Parameter|SA_ReturnValue in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(174)
> Warning: Unknown type SA_Parameter in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(184)
> Warning: Unknown type SA_Parameter|SA_ReturnValue in function argument c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(196)
> Note: Bit-field not accessible from interpreter C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winnt.h(3720)
> Warning: Unknown type 'PULONG64' in function argument handled as int C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winbase.h(2846)
> Warning: Unknown type 'PULONG64' in function argument handled as int C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winbase.h(2854)
> Warning: Unknown type 'PULONG64' in function argument handled as int C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winbase.h(2862)
> Note: link requested for unknown class tagFILETIME winfunc.h(37)
> Note: link requested for unknown class _WIN32_FIND_DATA winfunc.h(63)
> Note: link requested for unknown function CreateDIBSction winfunc.h(1009)
> cl -IC:/cygwin/include/cint -I../../../bin/include -DG__REDIRECTIO -DG__SHAREDLIB -DG__WIN32 -DWIN32 -D_WIN32 -DG__NEWSTDHEADER -D_CRT_SECURE_NO_DEPRECATE=1 -DG__HAVE_CONFIG -DG__NOMAKEINFO  -O2 -MD  -nologo -wd4996  -EHs    -c G__c_win32api.c
> G__c_win32api.c
> ../../../bin/include\stdio.h(4) : warning C4068: unknown pragma
> ../../../bin/include\stdio.h(8) : error C2061: syntax error : identifier 'fpos_t'
> ../../../bin/include\stdio.h(9) : error C2182: 'operator' : illegal use of type 'void'
>
>  where stdio.h declares it as:
>
> #ifndef G__STDIO_H
> #define G__STDIO_H
> #ifndef NULL
> #pragma setstdio
> #endif
> typedef struct fpos_t {
>   long l,u;
>   fpos_t(long i=0){l=i;u=0;}                 // < line 8.
>   void operator=(long i){l=i;u=0;}
> } fpos_t;
>
>
> How this should be officially handled - makecint should know it's own include folder - or not ?
>
>  
> --
> Have a nice day!
> Tarmo.
>

[gotom]

Hi Tarmo,

platform.h exists under %CINTSYSDIR%/include.  In your case  c:¥projects_prototype¥cygwin_cint-5.18.00¥cint¥include
Try setting CINTSYSDIR environment variable as :¥projects_prototype¥cygwin_cint-5.18.00¥cint
Masaharu Goto

On 2012/01/15, at 17:01, Tarmo Pikaro wrote:

> Hi !
>
> If I don't add this cint include folder - I'm getting error like this:
>
> C:\projects_prototype\cygwin_cint-5.18.00\cint\lib\win32api>makecint  -mk Makewin -dl win32api.dll -h +P cintwin.h -P winfunc.h -cint -Z0
> ##########################################################################
> # makecint : interpreter-compiler for cint (Windows VisualC++ version)
> # Copyright(c) 1995~2010 Masaharu Goto. Mailing list: cint@...
> ##########################################################################
> Run 'make -f Makewin' to compile the object
>
> C:\projects_prototype\cygwin_cint-5.18.00\cint\lib\win32api>make.exe -f Makewin  
> /cygdrive/c/projects_prototype/cygwin_cint-5.18.00/bin/cint.exe  -K -w2 -zwin32api -nG__c_win32api.c  -D__MAKECINT__ -DG__MAKECINT -DG__REDIRECTIO -DG__SHAREDLIB -DG__WIN32 -DWIN32 -D_WIN32 -DG__NEWSTDHEADER -D_CRT_SECURE_NO_DEPRECATE=1 -DG__HAVE_CONFIG -DG__NOMAKEINFO   -c-2  -IC:/cygwin/include/cint  -DG__REDIRECTIO -DG__SHAREDLIB -DG__WIN32 -DWIN32 -D_WIN32 -DG__NEWSTDHEADER -D_CRT_SECURE_NO_DEPRECATE=1 -DG__HAVE_CONFIG -DG__NOMAKEINFO  -Z0 +P cintwin.h -P winfunc.h
> 2886030_cint.c
> .\cintwin.h(19) : fatal error C1083: Cannot open include file: 'platform.h': No such file or directory
> Error: external preprocessing failed. (0)
> !!!Removing G__c_win32api.c G__c_win32api.h !!!
> Makewin:70: recipe for target `G__c_win32api.c' failed
> make: *** [G__c_win32api.c] Error 1
>
> Is this generated by cint preprocessor or by CL compiler ?
>
> I guess cintwin.h declares it as
>
> /* cint headers */
> #ifdef __CINT__
> #include <stdlib.h>
> #include <platform.h>
> #endif
>
> and cint should be preprocessing cintwin.h - since only then __CINT__ is defined.
>
>
>
>  
> --
> Have a nice day!
> Tarmo.

[Tarmik]

Hi !
 
I've managed to compile win32api.dll for visual studio 2008 with following tweaking - done after makecint
but before make executes:
 
CXXFLAGS    := -O2 -MD   -nologo -wd4996  -EHs -TP -GR -wd4181 
#CINTIPATH   := -I$(CINTINCDIRW)
CINTIPATH   := -I../../inc
OBJECT      := win32api.dll

What I have understood is that normally you're modifying cint include files just before compilation -
move %cintsysdir%\include\windows.h %cintsysdir%\include\_windows.h
move %cintsysdir%\include\winsock.h %cintsysdir%\include\_winsock.h

 
so that cl.exe compiler won't your special windows.h.
 
windows.h however has a dependency on stdio.h, so if we would want to make it compilable
- we would need to rename not only main .h files, but also dependent .h files.
 
something like:
   move %cintsysdir%\include\stdio.h %cintsysdir%\include\_stdio.h

however - apparently dependencies do change from release to release, may be some more tolerant / elegant
solution could be made.

Now I'm mastering windows.h & open gl api's...

Do you have any sort of more detailed description about makecint autogenerated code - how it generates
wrapped api and how simple it would make to walk through reflected data types, structs, functions ?

--
Have a nice day!
Tarmo.

[gotom]

Hi Tarmo,

Good to hear that you are making progress.

Windows.h is an extraordinary troublesome header file.  Typical header files can be processed more straight forward.
gl header file is better than windows, but it is also troublesome.

How makecint (in fact, cint with special option) generates dictionary (wrapper code), the simplest explanation is
- makecint calls cint with -c -1 or -c -2 option.
- cint reads header files listed after -H or -h options.
- Then, cint has class and function interface information on memory. It generates wrapper code based on it.

Detailed explanation is very complicated.

Thank you
Masaharu Goto


On 2012/01/18, at 0:06, Tarmo Pikaro wrote:

> Hi !
>  
> I've managed to compile win32api.dll for visual studio 2008 with following tweaking - done after makecint
> but before make executes:
>  
> CXXFLAGS    := -O2 -MD   -nologo -wd4996  -EHs -TP -GR -wd4181  
> #CINTIPATH   := -I$(CINTINCDIRW)
> CINTIPATH   := -I../../inc
> OBJECT      := win32api.dll
>
> What I have understood is that normally you're modifying cint include files just before compilation -
> move %cintsysdir%\include\windows.h %cintsysdir%\include\_windows.h
> move %cintsysdir%\include\winsock.h %cintsysdir%\include\_winsock.h
>
>  
> so that cl.exe compiler won't your special windows.h.
>  
> windows.h however has a dependency on stdio.h, so if we would want to make it compilable
> - we would need to rename not only main .h files, but also dependent .h files.
>  
> something like:
>    move %cintsysdir%\include\stdio.h %cintsysdir%\include\_stdio.h
>
> however - apparently dependencies do change from release to release, may be some more tolerant / elegant
> solution could be made.
>
> Now I'm mastering windows.h & open gl api's...
>
> Do you have any sort of more detailed description about makecint autogenerated code - how it generates
> wrapped api and how simple it would make to walk through reflected data types, structs, functions ?
>
> --
> Have a nice day!
> Tarmo.
>

[Dr. Prasad, B.V.L.S.]

Hi all, (Masa, Tarno and Axel)

I have been waiting to understand cint/makecint from a designer perspective.

Please donot break this thread nor moderate it and keep continuing.


It was way too complicated when I was going through src code.

But now through this thread I am learning and same should be the case for many others on this list.


thank you,

Prasad.

 



----- Original Message -----
From: Masaharu Goto <gotom@...>
To: Tarmo Pikaro <tapika@...>
Cc: "cint@..." <cint@...>
Sent: Wednesday, 18 January 2012, 19:34
Subject: Re: [CINT] Re: makecint and include folders...

Hi Tarmo,

Good to hear that you are making progress.

Windows.h is an extraordinary troublesome header file.  Typical header files can be processed more straight forward.
gl header file is better than windows, but it is also troublesome.

How makecint (in fact, cint with special option) generates dictionary (wrapper code), the simplest explanation is
- makecint calls cint with -c -1 or -c -2 option.
- cint reads header files listed after -H or -h options.
- Then, cint has class and function interface information on memory. It generates wrapper code based on it.

Detailed explanation is very complicated.

Thank you
Masaharu Goto


On 2012/01/18, at 0:06, Tarmo Pikaro wrote:

> Hi !
> 
> I've managed to compile win32api.dll for visual studio 2008 with following tweaking - done after makecint
> but before make executes:
> 
> CXXFLAGS    := -O2 -MD   -nologo -wd4996  -EHs -TP -GR -wd4181 
> #CINTIPATH   := -I$(CINTINCDIRW)
> CINTIPATH   := -I../../inc
> OBJECT      := win32api.dll
>
> What I have understood is that normally you're modifying cint include files just before compilation -
> move %cintsysdir%\include\windows.h %cintsysdir%\include\_windows.h
> move %cintsysdir%\include\winsock.h %cintsysdir%\include\_winsock.h
>
> 
> so that cl.exe compiler won't your special windows.h.
> 
> windows.h however has a dependency on stdio.h, so if we would want to make it compilable
> - we would need to rename not only main .h files, but also dependent .h files.
> 
> something like:
>    move %cintsysdir%\include\stdio.h %cintsysdir%\include\_stdio.h
>
> however - apparently dependencies do change from release to release, may be some more tolerant / elegant
> solution could be made.
>
> Now I'm mastering windows.h & open gl api's...
>
> Do you have any sort of more detailed description about makecint autogenerated code - how it generates
> wrapped api and how simple it would make to walk through reflected data types, structs, functions ?
>
> --
> Have a nice day!
> Tarmo.
>

[Tarmik]

Hi !

 

I have tried also C# script engine - http://www.csscript.net/ .

 

Error handling is not perfect one, but at least it looks like working - at least with some simple C# scripts.

(Managed to parse xml, etc...)

 

Also tried Cint with newest Autocad object arx include headers - and makecint refuses to swallow all

new and fancy C++ templates.

 

In programming language wise also it's easier to start developing from clearer implementation

than from cryptic one - compare code of cint versus c sharp script.

 

So I'm still thinking about may be starting from C#, and then returning back to C++ if needed,

but I suspect that C# memory fingerprint is not so good... (#1)

 

Finally I have found similar kind of data types as in perl - perl operates in scalar, array, hash terms

(and any complex permutation out of it) - in C# there exists similar kind of classes like ArrayList and

Hashtable. Still missing scalar.

 

I guess most intrested feature for makecint - is to be able to remote API by providing necessary clue

- .h / .lib for C++ objects.

 

If I would start writing new source code parser, I would write it's scratch in perl.

For final code - C# or C++. (#2)

 

Based on ideas #1 & #2 above - may be we could start from basic data types (or objects ?) -

I would like to drag perl's data types into C++ / C#. Parse C++ / C# using basic data types, construct

abstract syntax tree of source code, and then transform one programming language to another.

 

It's quite obvious that eventually switching programming language could be good alternative,

we could start to identify base concept of how such language switch could be performed.

 

Would you prefer to chat over skype ?

 

--
Have a nice day!
Tarmo.

[gotom]

Hello Tarmo,

It's a great idea to start from C# and try to replace C++ interpreter with better implementation.

Several people have tried similar thing in past 15 years. The biggest challenge was C++ complexity. 

No one has completed the work, to my knowledge.  

There is something going on in CERN to replace CINT.  They may have power to accomplish it.

I'd like to state fundamental benefit of C++ interpreter like CINT.   Key thing is that we can write

performance hungry code and script in same language.  This is crucial for people who does serious

simulation , data analysis , etc.. requiring the best-of-the-date performance.  I know such population is 

very small, but important.    

Good luck

Masaharu Goto

On 2012/04/11, at 5:52, Tarmo Pikaro wrote:

Hi !

 

I have tried also C# script engine - http://www.csscript.net/ .

 

Error handling is not perfect one, but at least it looks like working - at least with some simple C# scripts.

(Managed to parse xml, etc...)

 

Also tried Cint with newest Autocad object arx include headers - and makecint refuses to swallow all

new and fancy C++ templates.

 

In programming language wise also it's easier to start developing from clearer implementation

than from cryptic one - compare code of cint versus c sharp script.

 

So I'm still thinking about may be starting from C#, and then returning back to C++ if needed,

but I suspect that C# memory fingerprint is not so good... (#1)

 

Finally I have found similar kind of data types as in perl - perl operates in scalar, array, hash terms

(and any complex permutation out of it) - in C# there exists similar kind of classes like ArrayList and

Hashtable. Still missing scalar.

 

I guess most intrested feature for makecint - is to be able to remote API by providing necessary clue

- .h / .lib for C++ objects.

 

If I would start writing new source code parser, I would write it's scratch in perl.

For final code - C# or C++. (#2)

 

Based on ideas #1 & #2 above - may be we could start from basic data types (or objects ?) -

I would like to drag perl's data types into C++ / C#. Parse C++ / C# using basic data types, construct

abstract syntax tree of source code, and then transform one programming language to another.

 

It's quite obvious that eventually switching programming language could be good alternative,

we could start to identify base concept of how such language switch could be performed.

 

Would you prefer to chat over skype ?

 

--
Have a nice day!
Tarmo.

[Tarmik]

Hi !

> Several people have tried similar thing in past 15 years. The biggest challenge was C++ complexity.

> No one has completed the work, to my knowledge.

Like my mail partially says, I'm not so intrested in analyzing whole permutation of individual language history. :-)

> There is something going on in CERN to replace CINT.

Can I get any contacts on who is working and on what ? May be I'll join your team.

 

--
Have a nice day!
Tarmo.

From: Masaharu Goto <gotom@...>
To: Tarmo Pikaro <tapika@...>
Cc: "cint@..." <cint@...>
Sent: Wednesday, April 11, 2012 12:07 AM
Subject: Re: [CINT] C sharp script...

Hello Tarmo,

It's a great idea to start from C# and try to replace C++ interpreter with better implementation.

Several people have tried similar thing in past 15 years. The biggest challenge was C++ complexity. 

No one has completed the work, to my knowledge.  

There is something going on in CERN to replace CINT.  They may have power to accomplish it.

I'd like to state fundamental benefit of C++ interpreter like CINT.   Key thing is that we can write

performance hungry code and script in same language.  This is crucial for people who does serious

simulation , data analysis , etc.. requiring the best-of-the-date performance.  I know such population is 

very small, but important.    

Good luck

Masaharu Goto

On 2012/04/11, at 5:52, Tarmo Pikaro wrote:

Hi !

 

I have tried also C# script engine - http://www.csscript.net/ .

 

Error handling is not perfect one, but at least it looks like working - at least with some simple C# scripts.

(Managed to parse xml, etc...)

 

Also tried Cint with newest Autocad object arx include headers - and makecint refuses to swallow all

new and fancy C++ templates.

 

In programming language wise also it's easier to start developing from clearer implementation

than from cryptic one - compare code of cint versus c sharp script.

 

So I'm still thinking about may be starting from C#, and then returning back to C++ if needed,

but I suspect that C# memory fingerprint is not so good... (#1)

 

Finally I have found similar kind of data types as in perl - perl operates in scalar, array, hash terms

(and any complex permutation out of it) - in C# there exists similar kind of classes like ArrayList and

Hashtable. Still missing scalar.

 

I guess most intrested feature for makecint - is to be able to remote API by providing necessary clue

- .h / .lib for C++ objects.

 

If I would start writing new source code parser, I would write it's scratch in perl.

For final code - C# or C++. (#2)

 

Based on ideas #1 & #2 above - may be we could start from basic data types (or objects ?) -

I would like to drag perl's data types into C++ / C#. Parse C++ / C# using basic data types, construct

abstract syntax tree of source code, and then transform one programming language to another.

 

It's quite obvious that eventually switching programming language could be good alternative,

we could start to identify base concept of how such language switch could be performed.

 

Would you prefer to chat over skype ?

 

--
Have a nice day!
Tarmo.