[Clemens Ladisch]
Tim Goetze wrote:
Enter gcc version 3, which drops multi-line inline assembly support.
The following compiles fine with gcc 3.3.3:
void f()
{
__asm__ ("nop\n"
"nop\n");
}
May compile fine, but like this a 100-line __asm__ goes well beyond my
pain threshold when it comes to readability and maintainability.
If your external functions use the correct type (i.e., a pointer to
the base type), the compiler will automatically cast class pointers in
the correct way. Otherwise, you have to cast to the base type
yourself whenever you 'export' a pointer.
Believe me I have tried to come up with sensible solutions but there's
quite a lot more to it than just fixing a few thousand pointer casts.
Basically, you can't rectify the problem because the basic Python
Object type (from which my types are derived) is actually at a fixed
offset into a Python garbage-collected structure. You can't just slip
in a vtable, in fact you can't slip in anything at all; neither is it
possible to alternatively (and pointlessly to be sure) prefix the
Python GC structure with a vtable without rewriting Python itself.
Could you show some details? Probably the old code wasn't quite
correct according to The Standard(TM).
What I have is this (from caps code):
class DescriptorStub
: public LADSPA_Descriptor
{
/* just a constructor and destructor here */
};
template <class T>
class Descriptor
: public DescriptorStub
{
public:
Descriptor()
{ setup(); }
void setup();
...
};
The following is OK for an older g++:
void
Descriptor<AmpIV>::setup()
{
UniqueID = 1794;
...
}
but g++ since 4.0 wants this instead:
template <> void
Descriptor<AmpIV>::setup()
{
...
}
I cannot for the life of me imagine a good reason why "template <>"
should be necessary. "setup()" was never declared as a template, let
alone one with an empty template parameter.
If this is indeed prescribed by the language standard, I'll have a
very, very hard time getting over it.
It may not look like much but you have to understand that to me coding
is also an exercise in aesthetics.
Cheers, Tim
