@jhamby I know ARM has their own wacky thing instead of using normal dwarf tables, but GCC supported it since way back.
-
-
Replying to @RichFelker
@jhamby If Google used SJLJ for Android it's because they were overriding the GCC defaults and doing something dumb.1 reply 1 retweet 1 like -
Replying to @RichFelker
.
@RichFelker Google didn't use SJLJ for Android. I misread the headers. Google didn't support C++ exceptions in the NDK API until later.2 replies 0 retweets 1 like -
Replying to @jhamby
.
@RichFelker The worst C++ ABI for ARM was Symbian. They used an ancient version of GCC, rolled their own SJLJ-style exceptions with macros.1 reply 0 retweets 0 likes -
Replying to @jhamby
.
@RichFelker My basic complaint with Android is it's "the revenge of BeOS". They forced Java on developers, just like BeOS forced C++ APIs.1 reply 1 retweet 0 likes -
Replying to @jhamby
.
@RichFelker Two basic complaints with BeOS in 1997: 1) the fragile base class problem, which they solved by padding public C++ classes.1 reply 0 retweets 0 likes -
Replying to @jhamby
.
@RichFelker 2) BeOS forced developers to use threads, which led to tons of race conditions. Each BWindow needed its own event loop thread.1 reply 0 retweets 1 like -
Replying to @jhamby
.
@RichFelker So my impression of Android is: ex-Be devs (Travis Geiselbrecht, Dianne Hackborn, et al) rewrote BeOS in Java instead of C++.1 reply 0 retweets 0 likes -
Replying to @jhamby
.
@RichFelker The major architectural difference was to use a single UI event thread, just like every other GUI API that became successful.2 replies 0 retweets 0 likes -
Replying to @jhamby
.
@RichFelker My major complaint with Android is that all apps are forced to run the Java VM in user space to interface with the system.2 replies 0 retweets 0 likes
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.