Shinya Hayakawa <[EMAIL PROTECTED]> writes:
>> With a little work I am sure we could avoid the typedef 
>> and have typemap just say 
>> vector<int>          T_VECTOR_INT
>> vector<string>       T_VECTOR_STRING
>It seems that Inline::CPP doesn't support a typemap like that.

That is what I meant by a little work - it does not do so now 
but should be easy.

>I got the following enrror when didn't use typedef.
>    Can't locate auto/main/ in @INC...
>The xsubpp doesn't consider C++ namespaces, 

Which sounds risky - namespaces are becoming very common - and map 
to perl's namespace quite easily.

>and hence treat
>vector<int> differently from std::vector<int>.
>Therefore I think using typedef still have a little effectiveness.
>> The structure there is a feature of vector-ness. The only 
>> part that differs is the element to/from SV conversion.
>Yes I knew that, but couldn't work out a solution.
>> You cannot overload on return type unfortunately, so guts 
>> a generic T_VECTOR might look like 
>> template elemtype
>> ....
>>         elemtype elem;
>>         sv_to_type(sv,elem);
>>         var.push_back(elem);
>> The fun part of that is trying to devise a template scheme so that element types
>> of int, char, long etc do SvIV () while char *, string etc. do SvPV
>> and float, double to SvNV(). Might be easier just to have a set of 
>> overloaded functions:
>> inline void sv_to_type(SV *sv,int &elem)    { elem = SvIV(sv) }
>> inline void sv_to_type(SV *sv,double &elem) { elem = SvNV(sv) }
>That's an interesting idea, but still has a redundancy.

Not if you/we develop the same technique for the elements as well.
C++ can do "typemaps" neatly with overloaded functions and its own features
it does not _need_ all text transfrom and #define hackery that xsubpp does for 
C code.

>I think I want to apply existing typemaps to each template element,
>but it requires the xsubpp to scan code recursively, and process
>additional task.
>If I have a good idea for that, I'll try to write a patch for the xsubpp.

What I was trying to suggest is that we work out a clean C++ way to 
do the work. Then when we know what code we _want_ we teach xsubpp to 
build it. 

Be very careful trying to "scan code recursively" - before you know it 
you need a C++ parser - as I discovered.

xsubpp is going to have major headaches with general C++ anyway

void foo(int i_arg);
void foo(const char *c_arg)
void foo(const string &s_arg)

That needs to become one XS function foo() which examines its args
at run time to choose between them:

    if SvIOK(sv) 

and/or make a "policy" decision betwen char * and string for SvPV.

I have a (currently owned by day-job) script which exports the public:
methods and inheritance tree of a collection nested of C++ classes 
(with namespaces).
It turned out to be easier to start again and nearly-parse the C++
rather than try and re-use xsupp and typemaps.

I would like to shake loose this script (which I call findclass but could 
be called xsub++) - if there is enough interest.

Nick Ing-Simmons

Reply via email to