Closed GoogleCodeExporter closed 9 years ago
I just ran into this as well. Now that LLVM 3.0 is the default compiler, this
has become an important issue!
Original comment by bfulg...@gmail.com
on 17 Oct 2011 at 5:50
I've fixed this within the latest repository push by creating a build-time
defined term cpt_weak_property which translates to "weak" on projects that
target iOS 5.0 and Lion, and "assign" on those deployed to iOS 4.0 and Snow
Leopard. To pair with this, __weak has been replaced with __cpt_weak, which
falls back to __unsafe_unretained on the older deployment targets.
This should make the framework fully ARC-compatible now.
Original comment by waupacalarson@gmail.com
on 28 Oct 2011 at 8:38
Actually putting this stuff to header files is lame.
Move your private instance variables, properties and methods to anonymous
interface in .m files and compile them with whatever is able to digest it.
Header files should contain only public interface which is independent of those
arc issues.
Original comment by Vadim.Ye...@gmail.com
on 26 Jan 2012 at 11:47
I agree it's ugly. If you've got a suggestion on how to clean this up, let's
take the conversation to the discussion board (
http://groups.google.com/group/coreplot-discuss ). Private methods and
properties are not the problem--these are already defined in class extensions
in the .m files. Core Plot does not use synthesized instance variables because
of the need to support 32-bit Mac apps.
Keep in mind that as a library intended to be used in a wide variety of
applications, it has to support all of the following environments:
* Execute on iOS 3.1.3+ and MacOS X (i86 and x86_64) 10.5+
* Compile on latest versions of Xcode under both MacOS X 10.6 and 10.7.
* Headers must be compatible with all compilers provided with Xcode.
* Headers must be useable in applications with and without ARC.
Original comment by eskr...@mac.com
on 28 Jan 2012 at 4:28
Original issue reported on code.google.com by
drewmcco...@mac.com
on 7 Jun 2011 at 10:53