| Reinout Heeck 2006-04-19, 4:05 am |
| Ian Upright wrote:
> Reinout Heeck <reinz@desk.org> wrote:
>
>
> Not quite sure what you mean by "give up the independence of C-compilers for
> all the platforms VW is deployed on".. But I assume you mean, that you
> don't want to compile a C wrapper DLL/library for each platform you want to
> use your library on. Is that your concern?
Correct, this is one of the features of DLLCC I really love, write once
run everywhere :-)
> I guess with SQLite, they
> happen to provide precompiled binaries for each platform, and you're saying
> that you don't like having to compile an additional wrapper for each
> platform too. With some other libraries, there may not be any precompiled
> binaries, so if you're compiling a library anyway, it usually doesn't matter
> if you're adding in another C wrapper. However, even if the SQLite binary
> library changed, you likely wouldn't need to compile a new SWIG C wrapper --
> it likely would be done only once, and that same wrapper would work on all
> Smalltalk dialects. (such as VA and VW on linux for example)
This is the interesting bit of SWIG/St: that all St dialects access the
wrapper in a uniform way.
In fact I proposed such a project way back when:
http://wiki.cs.uiuc.edu/CampSmallta...+representation
[...]
> Even for pure wrappering, SWIG does generate
> some handy code that DLLCC doesn't, like providing additional support for
> booleans, null terminated strings, etc.
What is missing in the VW support for null terminated strings?
In my experience conversion between objects and C strings is transparent.
> It is more flexible in controling
> the names of the methods, instead of just (myfunc:with:with:with) etc..
DLLCC allows full naming freedom too, only if you use the header parser
will you get such ugly names by default.
> Also, using typemaps for more exotic and complex cases is obviously
> impossible with DLLCC.
Yes, another big DLLCC weakness is the limited support for macros.
[...]
>
> Is this your main concern?
Yes, but my remark wasn't meant to cover the general case, Boris quite
clearly pointed out the trade-off in the case of DB accessor libraries:
connecting to the C library is the smaller part of the chore, connecting
to the St DB abstraction is where the grunt work lies.
Clearly SWIG alleviates several DLLCC deficiencies, like hooking up to
C++ libraries and transparent macro expansion, but where feasible I
personally would fall back to DLLCC just to cut a wrapper out of the
complexity loop.
Cheers!
Reinout
-------
|