Coupla points: 1. After (painful) experimentation with Inline::Struct, I've determined it's got some significant short comings at this time <heavy sigh>
2. Howver, for my purposes, with Inline::C and some clever editting (thank you TextPad!) I can emulate most of Inline::Struct and probably do so in a more code optimal fashion. 3. As for Perl vs. C code, I abstain, as I haven't visited this particular soil in some time. My only perspective is from hacking DBD::ODBC some 3 years ago for array binding, and it was kinda painful for a newbie then. 4. That being said, if your API is based on simple C primitives, Inline::C might be an attractive solution...but beware of array or non-primitive inputs! Many thanks for the input, Dean Arnold Presicient Corp. www.presicient.com On Fri 17 Oct 2003 14:10, Tim Bunce <[EMAIL PROTECTED]> wrote: > On Thu, Oct 16, 2003 at 02:12:36PM -0700, Dean Arnold wrote: > > Has anyone attempted to write a DBD > > using Inline::C (or C++) ? I'm looking into updating a driver > > to selectively switch between a pure Perl implementation, > > and a native C i/f to a low level vendor API library if its available, in order > > to get more performance/functionality. Inline::C looked > > like an attractive alternative (esp w/ Inline::Struct) to all the XS > > madness. This would allow the driver to exploit Perl's > > strenghts for parsing SQL, mapping things w/ hashes, etc, but > > use the vendor lib for the low level data movement, as opposed > > to writing a complete DBD in C/XS. > > I don't think any DBD is pure C/XS. All have a significant amount of perl. l1:/pro/3gl/CPAN/DBD-Unify-0.27 107 > wc -l dbdimp.ic 1634 dbdimp.ic l1:/pro/3gl/CPAN/DBD-Unify-0.27 108 > wc -l dbdimp.h 105 dbdimp.h l1:/pro/3gl/CPAN/DBD-Unify-0.27 109 > wc -l Unify.h 47 Unify.h l1:/pro/3gl/CPAN/DBD-Unify-0.27 110 > wc -l Unify.pm 483 Unify.pm l1:/pro/3gl/CPAN/DBD-Unify-0.27 111 > wc -l Unify.xs 40 Unify.xs l1:/pro/3gl/CPAN/DBD-Unify-0.27 112 > So you're right. But only in the absolute meaning of the word: counting code lines. For me 99.5% of the time goes to dbdimp.ic (the C E/SQL part), and only 0.5% to Unify.pm. The latter primarily for updating the docs :) I never visit Unify.xs nowadays. Ah, and Makefile.PL needs some care too in the occasional version check > Driver authors wanting to use C don't have to write _any_ XS if they > use the Driver.xst template mechanism (which is strongly recommended). > > Then just add some logic around the "bootstrap()" method call in > the .pm file. The .pm file can implement the same methods as the > C/XS code and, if the c/XS code hasn't been bootstraped, then the > perl methods will be called instead. Simple. > > Tim. -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/