discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Which ObjC2.0 features are missing in the latest GCC?


From: H. Nikolaus Schaller
Subject: Re: Which ObjC2.0 features are missing in the latest GCC?
Date: Mon, 25 Nov 2019 11:51:35 +0100


Am 25.11.2019 um 11:41 schrieb Maxthon Chan <address@hidden>:

Where should we put the creativity to though?

The highest level of creativity is to do both

I would argue that some better places for our creativity to go towards would be things like our own updating Base, CoreBase and GUI to cover all modern Cocoa API, Swift standard library, GNUstep Back compatible CocoaTouch and SwiftUI implementation, Vulcan-based Metal, SpriteKit and SceneKit reimplementation etc.

Oh since I mentioned it, if we want to try implementing Metal, we have to fix Objective-C++ first, which requires clang. GCC’s version of Objective-C is too broken to support modern features.

If I recalled it right, some modern Objective-C and Swift features even requires the use of LLVM libc++ and libc++abi instead of GCC libstdc++.



On Nov 25, 2019, at 6:27 PM, H. Nikolaus Schaller <address@hidden> wrote:


Am 25.11.2019 um 11:21 schrieb Andreas Fink <address@hidden>:


On 25 Nov 2019, at 11:18, H. Nikolaus Schaller <address@hidden> wrote:

I know that I likely start a flame war, but watching the discussion from an elevated point of view...

Am 25.11.2019 um 10:30 schrieb Gregory Casamento <address@hidden>:
* Compatibility, much of the API is moving towards using blocks. Blocks *ARE NOT SUPPORTED* on GCC and aren't likely to be anytime in the near future.

Hm, where has our own creativity gone?

Fred mentioned that it could be possible to define some block wrapper macros if some time is invested.
It that works out, we do not make our decisions depend on gcc *not* implementing something.

So this argument for moving to clang looks more like an excuse that we do not work on our own gcc compatible solution, isn't it?

-- hns

using the same argument you can say we could use assember by creating some tools to output assembler first.

No. We are not talking about different language hierarchies but the same and one language feature.

As David pointed out, its a  hell of a lot of work for no benefit and dragging along old workarounds which lead to problems and performance impacts.

Have you even tried? And evaluated what the workarounds and performance impacts are?

Nobody has, but you already argue against it. That seems to confirm my argument that we have lost creativity...



reply via email to

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