151–158 of 158 posts
Earlier quoted context omitted.
Also known as MFC, PowerPlant, Turbo Vision, CSet++, Taligent, OWL, ATL, Symbian, Motif++,... all on average 5 years old when Java came into the world.
Well, they knew how to write Java in C++ even before Java came out...
Just like JEE was originally written in Objective-C during the OpenSTEP days as the Distributed Objects Everywhere framework, and then ported to Java afterwards.
Earlier quoted context omitted.
Educate yourself on Android source code. You can even start by the new entries related to Rust. https://source.android.com/setup/build/rust/building-rust-mo...
Why would I care about anything on that page? I have no need to read hype about Rust, regardless of where it might run. And, I have no desire to build Android apps, in any language.
The reference to Rust was just an example on how such members are also looking for alternatives, other big names are looking into Swift, C#, whatever.
Meanwhile clang crawls along on its support for newer ISO C++ features, as the biggest contributors now have their focus elsewhere.
> You may like STL, but that doesn’t change the fact that a huge number of companies have policies against using it. Sources? I haven't heard of any company disallowing it, on the contrary, have heard of companies promoting its use. edit: fixed formatting
A lot of game companies don't use STL. I assume theremust be plenty of system software companies doing the same.
Earlier quoted context omitted.
Why would I care about anything on that page? I have no need to read hype about Rust, regardless of where it might run. And, I have no desire to build Android apps, in any language.
To educate yourself about what ISO C++ companies are actually doing with the language. The reference to Rust was just an example on how such members are also looking for alternatives, other big names are looking into Swift, C#, whatever. Meanwhile clang crawls along on its support for newer ISO C++ features, as the biggest contributors now have their focus elsewhere.
What did you mean by this? I am not an LLVM expert or anything, but I find more-often-than-not most of the new features I read about that make its way into LLVM are requirements needed due to clang adding things from new C++ standards. These improvements then benefit other frontends like the one for Rust.
I tend to disagree. (Modern) C++ is an incredibly powerful programming language. Contrary to some other languages it gives the developer maximal freedom and does not impose a particular way of doing things on the developer.
> Contrary to some other languages it gives the developer maximal freedom and does not impose a particular way of doing things on the developer You seem to be implying that's a good thing. It's literally not. Imagine if I created a programming language where every random string of characters was a valid program (cue the Perl jokes). Clearly this language permits even more freedom than C++, but this would be a nightma…
, that it must be true that utility decreases with the unconstrained-ness of a language (and thus increases with more constraint).
However, this is not true. You only have to look to the other extreme to see there must be a middle ground. A language where there is only one valid program has no more utility than one where any string is a valid program.
Because this relationship of constraint and utility is clearly not simple, we can't use those extrema to judge if C++ is less useful because it gives so much control. There might be some "local extrema" where a language fits a niche. C++ might fill that niche, or it might not, but I think it needs a bit more of a nuanced consideration than "less constraint, bad".
Earlier quoted context omitted.
To educate yourself about what ISO C++ companies are actually doing with the language. The reference to Rust was just an example on how such members are also looking for alternatives, other big names are looking into Swift, C#, whatever. Meanwhile clang crawls along on its support for newer ISO C++ features, as the biggest contributors now have their focus elsewhere.
> Meanwhile clang crawls along on its support for newer ISO C++ features, as the biggest contributors now have their focus elsewhere. What did you mean by this? I am not an LLVM expert or anything, but I find more-often-than-not most of the new features I read about that make its way into LLVM are requirements needed due to clang adding things from new C++ standards. These improvements then benefit other frontends li…
Well, for Apple, C++ is relevant only in the context of Metal shaders (a C++14 subset) and IO/DriverKit (an embedded C++ like subset), everything else is about Objective-C and Swift, with C++17 being good enough for whatever else they need.
Likewise on Google style, it is all about C++ guidelines at Googleplex, where even not all C++17 features are welcomed.
Everyone else seems more interested in C++ features for their own platforms rather than contributing to upstream (thanks license), so there you go.
Earlier quoted context omitted.
> Contrary to some other languages it gives the developer maximal freedom and does not impose a particular way of doing things on the developer You seem to be implying that's a good thing. It's literally not. Imagine if I created a programming language where every random string of characters was a valid program (cue the Perl jokes). Clearly this language permits even more freedom than C++, but this would be a nightma…
Your assumption seems to be that if: 1) an existing language has finite utility 2) a language where any string is a valid program has no utility , that it must be true that utility decreases with the unconstrained-ness of a language (and thus increases with more constraint). However, this is not true. You only have to look to the other extreme to see there must be a middle ground. A language where there is only one v…
The converse is actually the OP's argument, ie. that a language's utility increases with unconstrainedness. I merely showed that to be false, and argued that constraints are essential, but nowhere did I suggest that utility scales with the number of constraints.
Earlier quoted context omitted.
In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". At the point you rule out using available facilities of the language you might as well use something else.
> (...) such as Google's famous "no exceptions". If I recall correctly, Google's rationale regarding exceptions is that their legacy code is not exception-safe, and so they were faced with the choice of either rewriting critical parts of their legacy code to handle exceptions, or don't use them. Also, their "no exceptions" rule only applied to work involving their legacy code. I'm too lazy to find the source, but tha…
That's not the case, the no exceptions rule applies to legacy and non-legacy code: https://google.github.io/styleguide/cppguide.html#Exceptions.