Bill - Sorry I haven't replied to this earlier. I mentally book-marked it, but never returned. I see two potential paths for discussion.
First, suppose that you want to convert the array-of-strings each time this function gets called because char * names[] can change with each function call. In that case the nicest handling of this would be typemaps. I presume that you expect your caller to supply an anonymous list of scalars, in which case you should be able to do the following: 1) Get the length of the AV. 2) Use Newx to have Perl allocate a char ** for you with the length of the AV [http://search.cpan.org/~rjbs/perl-5.16.0/pod/perlguts.pod#Memory_Allocation] 3) Mark that just-allocated char ** to be freed at the end of the current scope with SAVEFREEPV so that your own XS code doesn't have to SAVEFREE it [http://search.cpan.org/~rjbs/perl-5.16.0/pod/perlguts.pod#Localizing_changes], and you prevent memory leaks 4) Iterate through the SVs in the AV; assign each char * in your array to the return value of SvPVbyte_nolen on the given SV [http://perldoc.perl.org/perlapi.html#SV-Manipulation-Functions] On the other hand, if you know that char * names[] does not change because it's an immutable part of a Singleton or it's a Perl-side "constant", you could cache the array-of-strings in a C-level global. If you do the former, you can populate that cache 1) with C code in your BOOT section 2) with a special internal C function that is called once from Perl (tracking the state of the cache with Perl code) 3) with your function's C code that creates the cache when the function is invoked if it doesn't already exist You can free the cache 1) at object destruction, if your object is a true Singleton 2) with a special internal C function that is called from an END block in your module 3) never, as it's not a huge memory leak If you do a C-level global, you can use savepv for the string copy so that you're not pointing to potentially changed PV elements of a mutable SV. Just my 2 cents for now. David On Tue, Jul 17, 2012 at 9:36 AM, Bill Moseley <mose...@hank.org> wrote: > Quick follow up: > > On Tue, Jul 17, 2012 at 7:05 AM, Bill Moseley <mose...@hank.org> wrote: >> >> >> family( int count, char* names[], int ages[], char* family_name ); >> >> >> [1] I guess I'd better see if family() holds on to the addresses of >> names[] and ages[] after returning. Hum, if I don't know that maybe I need >> to malloc my own "object" so I can free those on DESTROY. Is that right? > > > > Thinking about this a bit more I realized that this specific constructor is > only called ONCE per process. So, if I malloc names[] and ages[] I'm not > sure it's a problem if they don't get freed. Does that simplify things? > i.e. don't need to malloc a struct to hold these until DESTROY. > > Second, this is my first use of XS and C++, and in the simple tests I've > been doing XS is setting up a "THIS" for me. If I need to malloc a struct > that holds names[], ages[], and the address returned by the C++ constructo > ("my_cpp_object"), if my new method returns this struct then is that what > THIS ends up as? That is, instead of THIS->method() I would then do > THIS->my_cpp_object->method(). > > Am I making this harder that it is? > > -- > Bill Moseley > mose...@hank.org -- "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
