Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: R14->R15

Hi Adam,

On 5/20/02 10:16 PM, Adam Wildavsky wrote:
> I'm finishing up a long round of 3.1.5 to R14 conversions and
> preparing to move on to R15. The main stumbling block I've found so
> far is the pervasive use of CString_AC in interfaces. The conversion
> approach I prefer is to allow my application source code to compile
> against the old and new MacApp versions simultaneously. To that end
> I'm trying a suggestion Tom Becker provided a year or two ago and
> have added the following lines to AutoSwitches_AC.h:
>
> #define qBackwardCompatible 1
> #define CString_AC CStr255_AC

I don't recommend defining CString_AC as CStr255_AC. It would have the
effect of changing the MacApp implementation. If at some time I did
recommend it, I have changed my mind.

> I've also commented out the body of CString_AC.h by surrounding the file with
>
> #if 0
> #endif
>
> starting with the line:
>
> #include <string>
>
> CPascalString_AC lacks a few features of CString_AC so the changes
> above do not suffice. I've started by adding two inlines to the
> CStr255_AC interface, after operator const char*() const:
>
> const char* data() const
> { return CChar255_AC(*this); }

That's returning a pointer to temporary stack data. It's inherently unsafe.
I don't think there's any way it can be made safe without changing the data
representation of CStr255_AC. Sorry.

> unsigned char size() const
> { return this->Length(); }
>
> There's more work to be done, though. Has anyone else tried this
> approach to conversion, or does anyone have an alternative approach
> to suggest?

How about:

#if MA_Version >= 0x0F00
#define MyString CString_AC
#else
#define MyString CStr255_AC
#endif

I think it has to be a #define rather than a typedef, so you can override
methods that take a string as an argument.

> For the record, I recognize that CString_AC is a superior solution,
> and for the long term the code ought to be converted to use it. At
> the moment, though, I'm not close to having the budget that would
> allow that to happen.

Regards,

Tom

--
Tom Becker "Within C++, there is a much smaller and
Object-Oriented Propeller Head cleaner language struggling to get out."
<email@hidden> -- Bjarne Stroustrup
_______________________________________________
macapp-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/macapp-dev
Do not post admin requests to the list. They will be ignored.
References: 
 >R14->R15 (From: Adam Wildavsky <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.