On Fri, Jul 27, 2012 at 11:32 AM, David Oswald <daosw...@gmail.com> wrote: > I've sort of moved away from recommending the automatic string > conversion typemap that is available to both Inline::C and > Inline::CPP, because it turns 100% of the responsibility for > understanding everything there is to know about Unicode over to the > C/CPP/XS programmer. I could be wrong in this notion, but to me the > lure of simplicity in passing a Perl string to a c-string is deceptive > and while presenting a slight savings in code up front, will create a > need for a lot more hand-rolled code to support Unicode. > > In my opinion (and I'd be happy to discover I'm wrong about this), > it's easier to pass the string-containing SV, *as an SV*, and then use > Perl's own string-handling "guts and API calls" to manipulate it. I > realize that this somewhat defeats the "performance improvement" > purpose of dropping into XS, but strings are truly one of those areas > where Perl's native performance is as it is because it's doing so much > (most of which has become necessary in a Unicode world).
Yeah. What one should do here depends on how much control you have over the code. You can have Perl downgrade the string to a true byte string if you use SvPVbyte_nolen, as I suggest, but then you loose any unicode characters that your user may have passed in. If you don't control your C++ library and it expects true C-style strings, then you haven't much of an option. David -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
