Re: CoreBase toll-free bridging

[Stefan Bidi]

On Mon, Mar 11, 2013 at 8:55 AM, Luboš Doležel <address@hidden> wrote:
> 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.

You can just treat NSConstantString as an ObjC-only class and call the
appropriate methods.  That's how this should work now, but I haven't
really spent a lot of time testing it.

CFGetTypeID() is a complete hack, right now.  The code checks for
cf->_typeID no matter what, and if doesn't match what the system
thinks it should be calls the method -_cfTypeID, which in turn returns
_kCFRuntimeNotATypeID for none CF types.


>
> --
> Luboš Doležel
>