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/test_int_vector.al 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
consider
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)
foo(SvIV(arg))
else
foo(SvPV_nolen(arg))
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
http://www.ni-s.u-net.com/
