[linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

[Tim Goetze]

[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