One of my e-mails got delivered out of sequence which is causing some
confusion....
On 18 Apr, Scott Haug wrote:
>> There isn't such a solution -- anytime that a program communicates to
>> a library via the C++ interface (vtable) both programs need to be
>> compiled with the same compiler. The C++ standard never standardized
>> how the names should be mangled and therefore two different C++
>> compilers cannot talk to each other.
>>
>> It sucks balls, but anytime you're creating a library that multiple
>> applications from different compiler architectures need to use, you
>> should use the standard C interface.
>
> Forgive my ignorance, but I'm not sure I understand. Maybe I don't grok enough
> how freeamp is built/distributed. Is this an issue with just the Windows
> platform, or is it a problem with every platform? If it's just Windows, Elrod
> suggested id3lib would ship with the Windows version, in which case wouldn't
> they be compiled with the same compiler? How does the compiled library under
> linux affect the Windows version? Wouldn't freeamp under linux be compiled
> with the same compiler as id3lib under linux? Or am I completely missing the
> point? Again, I apologize for this. I'm new to this cross-platform
> development thing.
Ok, some background on this problem -- this is not a freeamp problem is
a C++ problem. When a program wants to talk to a C++ library there are
two ways of doing it:
1) Use VTables. When the compiler compiles a class with from a .h file
it creates a vtable, which is essentially a table of function pointers.
Any program that has a pointer to a class, will also internally have
access to this vtable. So for a program to call a method on a this
class, the compiler looks up the right function in the vtable and it
will then call that function. There is no need to actually define this
function as part of the libary, since the calling application has the
complete header files necessary to call a method on the C++ object in
the library using the vtable.
The problem with Vtables is that different compilers will construct
vtables differently. And, other languages may not know how to deal with
vtable and won't be able to talk libraries that are based on vtable
use.
The vtable approach is good only when you have one application that is
compiled with one compiler. It is not good when you may have third
parties attempt to use other compilers with the vtable based library.
FreeAmp uses vtables and that's why there are no third party plugins
for FreeAmp. We plan to fix this in the 3.0 release of FreeAmp.
2) Export mangled names as part of the library. C++ functions get name
mangled (to see what I mean, do a 'nm libid3.so') in order to give
overloaded functions in one class unique names. The function signature
(the arguments) is encoded into a few characters and appended to the
method name to give all methods unique names.
The id3lib exports mangled function names and this works great as long
as the calling program was compiled with the same compiler as the
library. A program written in another language will not be able to call
the id3library, because that other library cannot handle name mangling.
And a C++ program written with a different compiler will also not be
able to use the library since name mangling is not standardized. Plus
it doesn't work too well under windows..
The lowest common denominator that libraries should be written in is C.
> How does the compiled library under linux affect the Windows version?
It doesn't -- however since I am writing cross platform code, I need to
use one interface windows and another under linux. So my code ends up
looking really nasty with a ton of #ifdefs around it. And don't get me
wrong, this is not because I am lazy or because I want to have my code
look clean, but other people will eventually request the same thing
from you, and when you change your lib interface in the future I will
need to change my code as well. Its much better to set up good
consistent interface right from the start.
> Wouldn't freeamp under linux be compiled
> with the same compiler as id3lib under linux?
Yes, it is and it works fine. But a python hacker will not be able to
call your library... If freeamp is your sole target customer (I hope
not!) then there is no problem. :-)
> Or am I completely missing the
> point? Again, I apologize for this. I'm new to this cross-platform
> development thing.
Don't sweat it -- this shit is not obvious at all.
> Any help you can give is greatly appreciated. I'll get crackin' on it ASAP,
> and I'll give you updates via private email of my progress to let you know if I
> have any issues.
The C wrapper that exists for the library is not bad. It mimicks the
C++ interface, but is not as clean and as nifty as using C++ straight
out. Personally, I do not know how I would make a better C wrapper for
that lib. Just stick with that and expose that as another interface to
your library and then people can choose which interface to use.
--ruaok Freezerburn! All else is only icing. -- Soul Coughing
Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
_______________________________________________
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/freeamp-dev
