[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sun, 3 Dec 2017 11:16:57 +0000
On 3 Dec 2017, at 10:01, Andreas Fink <address@hidden> wrote:
> Which raises the question on how many people use Objective C and still use
I haven’t for a long time, but last time we discussed it some people were very
vocal about keeping GCC support.
> If you use ObjectiveC 2.0 features such as automatic properties or ARC, you
> for sure will use clang. GCC is a real deal breaker there.
GCC does support declared properties, but it doesn’t support ARC. I’ve spoken
to someone who is interested in adding ARC support to GCC a couple of times,
but he’s always been too busy with other projects to get around to it (they had
a customer who wanted blocks in GCC, so he was working on that and became
interested in ARC). ARC is a very complex feature to get right (there are
complex rules about how scopes relate to lifetimes, which are part of the
reason why ARC saves a lot of code)
> In my project, ARC made a lot of stuff a lot simpler to code and avoided a
> lot of human errors. ARC saves your there.
> I'm not sure who else uses GNUStep-base in what scenario and if supporting
> GCC is still kind of a important thing to keep around or not.
I think being able to use ARC in -gui and -base would save us a lot of effort,
but the biggest gain would be being able to delete a load of compatibility code.
That said, I’d be far more inclined to suggest that we depend on Objective-C++
and libobjc2 than clang. GSIMap, for example, is quite painful to use and
would be a lot cleaner in C++. In other code bases, I can simply do things
like std::unordered_map<int, id __weak> and all of the memory management works
correctly. Before we had reliable ARC support, I had some C++ strong_object
and weak_object wrappers that called the relevant runtime functions in their
constructors and destructors (and, for weak, implemented an implicit cast
operator to a strong object type that called the function to materialise a