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/

Reply via email to