[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANN: One Step to GNUstep - pre-release version 0.9

From: David Chisnall
Subject: Re: ANN: One Step to GNUstep - pre-release version 0.9
Date: Sun, 12 Jun 2011 14:44:31 +0100

On 10 Jun 2011, at 17:40, Richard Stonehouse wrote:

> I haven't been following the clang/Objc 2 discussion because it's
> a bit above my head :-)
> Are they now stable and mainstream, or still a bit experimental?

I have been using Clang as my default compiler for C, and Objective-C since 
about 2009, and for C++ since the middle of last year.  The only problems that 
I've encountered have been occasional breakage in trunk (as happens with any 
project), or in some experimental features.  

The latest release versions of clang and the GNUstep runtime provide feature 
parity with the iPhone Objective-C stack, but lack GC support.  The current 
trunk releases provide feature parity with OS X 10.6, including GC support.

> What sort of developer would you see as having need of clang and
> Objective C 2?

99% of Objective-C developers these days are coming from Mac or iPhone 
development.  All of the recent tutorials make heavy use of Objective-C 2 and 
2.1 features, such as synthesized properties or to add instance variables in a 
class extension, rather than requiring them to be declared in a header.

Currently, to the best of my knowledge, these features are supported by the 
combination of clang and the GNUstep runtime, some requiring the latest release 
of both (2.9 and 1.4, respectively):

- Associated references
- Blocks
- Non-fragile instance variables
- The forwarding mechanisms added with OS X 10.5
- Full protocol and property introspection
- Type dependent dispatch (protects against various type-related bugs)
- Unified Objective-C++ exception model, allowing Objective-C++ code to catch 
C++ and Objective-C exceptions
- Fully thread-safe +initialize (with Apple-compatible locking semantics)
- Correct support for C++ objects as ObjC++ object ivars
- Apple-compatible garbage collection (trunk only, needs testing and not ready 
for production use yet)

The following are only available with clang or GCC 4.6:

- Declared properties
- Fast enumeration

In addition, clang provides significantly more expressive error messages, which 
is a huge benefit for anyone writing code, and a static analyser which can 
catch a lot of bugs.  The front end is also reusable. For example, Étoilé's 
SourceCodeKit uses it for syntax highlighting and indexing source files.  This 
means that the code editor can highlight tokens with exactly the types that the 
compiler sees (for example, differentiating between macro instantiations and 
function calls, between typedefs and built-in types, and even between local and 
global scope variables.  I used this for the syntax highlighting in the ePub 
edition of the Objective-C book.

Since GCC decided to switch to GPLv3, there has been no active development on 
GCC by Apple employees.  As Apple owns the trademark on Objective-C, this makes 
clang / LLVM the de-facto standard Objective-C compiler.  

Anyone coming from OS X or iPhone development is going to expect either clang, 
or a compiler with equivalent functionality to clang.  Giving them an 
Objective-C environment that is just about at feature party with OS X 10.4 does 
not give the best impression of GNUstep.

> Would this be in place of, or in addition to, the gcc compiler and
> libobjc?

Some people may wish to have GCC support as well.  I've recently stopped 
testing everything with GCC, as the lack of features means that I can no longer 
build significant portions of my code with it (anything that requires the 
non-fragile ABI or blocks, and anything that needs to interoperate with code 
using GC), although I still try to test code that only uses ObjC 1 features 
with GCC 4.2.1 (the last GPLv2 version - the license change means that I will 
probably never see more recent GCC in the FreeBSD base system - FreeBSD 9 is 
expected to ship with Clang and GCC, FreeBSD 10 with just Clang).  

Étoilé requires the GNUstep Objective-C runtime for various features, most 
significantly for LanguageKit, which depends on certain features of the runtime 
which make it easier to target for languages like Smalltalk.  Various modules 
require clang, although I think the core ones (EtoileFoundation and friends) 
will still build with GCC.


-- Send from my Jacquard Loom

reply via email to

[Prev in Thread] Current Thread [Next in Thread]