On Thu, Jul 7, 2011 at 20:23, Ivan Vučica <[email protected]> wrote: > If calling -retain, -release and -autorelease is not allowed, how is it > possible to mix ARC with non-ARC code? Does the compiler throw a warning, an > error, or the thing just silently doesn't work?
The compiler throws an error. The boundary of mixing ARC and non-ARC code is the translation unit: object files compiled with ARC can be linked with those compiled without, but mixing ARC and non-ARC code within the same source file is not possible. > What happens when -retain, -release and -autorelease are overridden? The compiler throws an error. If you explicitly require different retain/release semantics for your class, you can't use ARC within it. However, ARC code should still be able to use your class (I haven't tested this, though). > What happens when non-__unsafe_unretained pointers are stored in structure? The compiler throws an error here too. Apple says you should be using Objective-C objects (instead of structs) as containers for other Objective-C objects anyway. (If you disagree with their sentiment, you can simply continue using traditional retain-release, which isn't going away as long as we have oddball classes like NSProxy.) > Does it silently crash? Quite unlike a silent crash, the compiler whined loudly when I tried anything "evil". (Part of the ARC magic happens within the compiler, part within the runtime, neither of which are known for silent crashes.) > Are all pointers __strong by default? All ObjC pointers, yes. > What happens with non-Objective-C pointers, such as results of SDL functions? They remain untouched by ARC. ObjC pointers are detected using semantic analysis -- a heuristic along the lines of "oh, an asterisk, I'm taking over" would break everything (including the "strict superset of C" philosophy). > Will I have any problems using SDL if ARC is used in same codebase? My guess is no, but I haven't tried it yet. Hope that helps (at least partly), ~~ Ondra _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
