On Mon, Mar 11, 2013 at 8:55 AM, Luboš Doležel <lu...@dolezel.info> 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
>
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
