From looking at the supported platforms, the standard library seems to work for most OpenBSD targets, but they don't provide official builds (presumably due to not having anyone volunteering to maintain dedicated hardware for them to use for CI); the Tier 3 platforms[1] list OpenBSD on x86_64, i686, aarch64, sparc64, powerpc64, and riscv64gc as all having the standard library functioning. Due to there not being official builds, I'm guessing that there would either have to be an officially maintained package to install or you'd have to build it from scratch, though, but it seems likely that having a functioning compiler already means that you wouldn't have to fully bootstrap everything (and if you did, maybe it would be possible to bootstrap from rustc?)
Seems a nice way to bury a lede :) No links back to GCC including the languages, and a look at https://gcc.gnu.org/ doesn't reveal it either, even if you click on changes for GCC 13.
Ugh; one of our profs had spent some years in Switzerland working on control systems for tunnels or something like that, and made modula-2 mandatory for our data comm course even though students were proficient in C/C++ at this point and preferred it.
The OS X platform code for Firefox is written in Objective-C++. It's not without issues, but overall it's a nice way to use Objective-C from within a larger C++ code base. I didn't find it difficult to work with, particularly as opposed to what we'd have to do if Objective-C++ didn't exist.
If you want to see what this looks like, look at the .mm files here:
Basically what you're looking for is being able to make Obj-C calls (e.g. [[ChildView alloc] initWithFrame:r geckoChild:this]) from within what is otherwise normal C++, and vice-versa.
You're talking to someone that has hold NeXT manuals for an university porting project, and in fact the very first editions of Apple documentation have exactly the very same manual, rebranded for Apple.
And just not to be a random dude in the Internet, here are the NeXT documents straight out of 1993, page 173.
Objective-C is a superset of C, and Objective-C++ extends that to C++. It's really only meant as a shim layer to bridge C++ libraries with Objective-C. Or at least, that was the case in the pre-Swift days.
It’s really great when you need to call ObjC APIs from C++ or vice versa.
For the most part you can keep things as regular C++ and then just mix in some ObjC APIs when needed without splitting out your files and targets.
It’s extra useful because macOS provides a lot of really great utility libraries like dealing with media or networking, which means you can greatly reduce your dependency count on Apple platforms.
I try and take the approach of reducing dependencies in favour of platform native APIs where possible when making multi platform code, and this is great for that.
Of course it means you have different details on each platform, but I find it much more pleasant than having to keep building dependencies, and dealing with all the corresponding issues like security, size or dealing with platform specific acceleration.
> I try and take the approach of reducing dependencies in favour of platform native APIs where possible when making multi platform code, and this is great for that.
I’m not familiar enough with the GCC stack. I’m curious how much effort was necessary for the M2 front end developer to concentrate on efficiency and optimization in contrast to writing something straightforward and having GCC optimize the intermediate form.
I’m sure both components have some responsibility, just curious how much the intermediate form gives the compiler author “for free”.
By adding it to upstream GCC, I assume that it incurs some maintenance burden.
So I think the more interesting question would be "Why would upstream GCC merge support for Modula-2, and with that accept some work and risk for little reward?".
Stupid question, but doesn't rust have it's own, highly praised compiler? I'm just genuinely curious - would using gcc be better under any practical circumstance? Do they both generate low level code with/for LLVM?
Actually, if they can provide a stable release with the most important nightly features I might pick this over rustc.
The rust team don't seem to understand anything about production software, quality assurance and maintenance. Hopefully competing with a more organised compiler with TLS support that is not crippled will put some pressure on them.
37 comments
[ 2.8 ms ] story [ 88.1 ms ] thread[1]: https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
I don't think it's about what tier is supported in rustc, as that's compiled by LLVM in that case.
http://users.fred.net/tds/lab/p2c/
and more here:
http://www.garret.ru/ptoc/Readme.htm
http://freesourcecode.net/cprojects/94701/Pascal-to-c-conver...
https://web.archive.org/web/20060426224216/http://directory....
[1] https://en.wikipedia.org/wiki/Objective-C#Objective-C++
Doesn't it just use objc/runtime.h and if anything is missing you can just add your custom api calls?
If you want to see what this looks like, look at the .mm files here:
https://github.com/mozilla/gecko-dev/tree/master/widget/coco...
If you want a specific file to look at with good examples of how this works, here's one:
https://github.com/mozilla/gecko-dev/blob/master/widget/coco...
Basically what you're looking for is being able to make Obj-C calls (e.g. [[ChildView alloc] initWithFrame:r geckoChild:this]) from within what is otherwise normal C++, and vice-versa.
And just not to be a random dude in the Internet, here are the NeXT documents straight out of 1993, page 173.
http://www.bitsavers.org/pdf/next/Release_3_Nov93/Object-Ori...
Page 31 on "Developing business applications with OpenStep"
https://archive.org/details/developingbusine00gerv/page/n7/m...
Finally, from the language authors themselves, chapter 15, Objective-C++ (1989-1990)
"The Origins of Objective-C at PPI/Stepstone and Its Evolution at NeXT"
https://dl.acm.org/doi/pdf/10.1145/3386332
For the most part you can keep things as regular C++ and then just mix in some ObjC APIs when needed without splitting out your files and targets.
It’s extra useful because macOS provides a lot of really great utility libraries like dealing with media or networking, which means you can greatly reduce your dependency count on Apple platforms.
I try and take the approach of reducing dependencies in favour of platform native APIs where possible when making multi platform code, and this is great for that.
Of course it means you have different details on each platform, but I find it much more pleasant than having to keep building dependencies, and dealing with all the corresponding issues like security, size or dealing with platform specific acceleration.
We need more developers like you!
I’m sure both components have some responsibility, just curious how much the intermediate form gives the compiler author “for free”.
[1] https://news.ycombinator.com/item?id=34040397
The rust team don't seem to understand anything about production software, quality assurance and maintenance. Hopefully competing with a more organised compiler with TLS support that is not crippled will put some pressure on them.
https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...
I'm in no way a compiler expert, but from what I understood, they specifically want to avoid mixing GCC and LLVM: https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...
https://github.com/rust-lang/rustc_codegen_gcc