Re: CoreBase toll-free bridging

[Luboš Doležel]

On Mon, 11 Mar 2013 08:17:43 -0500, Stefan Bidi wrote:
> Having the compiler output a compatible structure would be nice, but
> I'm not sure how realistic it is to depend on it.  Until recently,
> GNUstep still support GCC 2.95 and just recently move to minimum GCC
> 4.0.  If this charge were to be done, we'd be having to support two
> completely incompatible structures (they aren't backward compatible
> because of the CFTypeID variable in between the isa and string
> pointer) for at least another 6 years.

I would keep the NSConstantString class in place (there isn't really 
much to "maintain" anyway, it's a simple class), but drop the speed 
hacks so that these don't clutter the code anymore.
That way we would have compatibility and cleanliness at the same time. 
We wouldn't have the performance, but with GCC you don't even get all of 
the ObjC features anyway. It's a bad decision to use GCC for ObjC...

We could also hack around it "Apple style". This is C++, but it's for 
illustration only:

struct NewOldString
{
    void* isa;
    union
    {
        struct
        {
            const char* string;
            unsigned int length;
        } _old;

        struct
        {
            CFTypeID cfTypeID;
            int version; // for future extensions
            int flags;
            const char* data;
            int hash.... whatever we need here.
        } _new;
    };

    // This is how it could be accessed (consider the logic, not the 
implementation per se...)
    bool isOld() const { return _new.cfTypeID > 1024; } // anything 
less than 1024 is not a valid ptr and there'll never be more than 1024 
CF types anyway...

    const char* stringPtr() const { return isOld() ? _old.string : 
_new.data; }
};

> My preference, would be to do one of two things:
> (1) As David points out, GNUstep already replaces instances of
> NSConstantString with GSString.  The way I understand the code there,
> GSString can have any internal structure and isn't dependent on the
> compiler's output.

I don't know how this replacing works, but I'd say the replacement 
object has to fit into the original struct.
There isn't enough space to accomodate for CFTypeID.

> As for the Clang's built-in function for CFStrings, it outputs a
> NSConstantString-like structure.  I remember having a few problems
> with it (NSConstantString wasn't initialized by the time I had to use
> the strings) and decided to comment out that code for a while until I
> got a few other things sorted out.  Eventually, I removed it
> altogether.  Adding it back isn't a problem, but that piece of code
> just won't work with the way CoreBase is currently set up.

Yeah, how exactly would you support calls like CFGetTypeID() with a 
NSConstantString?
I can imagine checking for isa == NSConstantString everywhere, but 
that's ugly.

--
Luboš Doležel