Earlier quoted context omitted.
I would also say that D did itself irreparable harm with the whole v1-v2 standard library debacle. Right when it was receiving the most attention, it came right out and said to anyone who might have considered it, "we have two incompatible versions of the standard library: one which we don't support anymore and one you can't use yet."
That was then and this is now, there is one standard library and the language has come on leaps and bounds. D is a great language.
We have C++14
331–340 of 353 posts
Re: We have C++14
#332Earlier quoted context omitted.
It's 240 pages of knowledge that you can completely do without, and it's a book called "47 engineering puzzles." The puzzles, of course, are entirely exception-related. I'm not saying it's impossible to write exception safe code. I'm saying that you can write code without exceptions without being worse off for it.
We're talking about the same book, _Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions_, by Herb Sutter. The takeaway I had from reading that book (a long time ago) was just to use RAII religiously, which also tends to make other things easier. So I'm curious about why you think RAII makes writing exception-safe code difficult?
The book is excellent. For anyone who wants to use C++ exceptions, it should be required reading. But as someone who has gone through that gauntlet, I feel that I probably would've been better served by spending my time on something other than mastering the finer points of exceptions.
The reason I started talking about C++ exceptions in the first place is because, in my experience, when someone is very pro-RAII (like the original commenter I responded to), they also tend to be pro-exceptions. This isn't always true, but on average, it seems like either people prefer both or prefer neither.
Writing exception-safe code is certainly one of the hardest challenges available in C++, so if you enjoy a good challenge, then it's hard to do better. But if you're just looking to design large-scale systems, it seems like exceptions are unnecessary, as Google has demonstrated by banning the use of exceptions in their codebases.
In my experience, by refraining from using exceptions, it's possible to design large codebases more quickly, with fewer bugs, and without losing any safety or extensibility. However, this is simply my personal experience, and it may be mistaken to generalize this into a claim that all codebases among all C++ teams should refrain from using exceptions.
So, that's all I meant. I was also in excruciating pain yesterday due to a certain tooth that decided to segfault in my mouth, which may have contributed to the adversarial nature of my writing style. I feel bad about how I came across, and I sincerely apologize for it. No excuses, though: I should've done better.
Re: We have C++14
#333Earlier quoted context omitted.
"Good luck doing it. It's not easy. I know; I've tried" Completely unsupported assertion (no pun) without evidence. Other people have tried it, and have succeeded. I could start listing all the software written in C++ that you use in your everyday life, perhaps 100's of times a day... but that'll quickly exhaust my word limit for this post. "That's why C++ is overly cumbersome unless you ignore most of its capabiliti…
> you can refuse to catch or throw exceptions for 99% of your (millions of lines) of code and still end up with a very large, stable code base running a large portion of the internet. The point is that these features are infectious. If you don't want to throw exceptions, how do you handle a failure in a constructor? And then if you abandon constructors, other C++ features are unusable without them. And so on.
Re: We have C++14
#334Earlier quoted context omitted.
>Comparing a later version of language to an earlier one to measure modernism seems rather pointless. C++ is a production ready systems language, not a theoretical CS research paper. How do you propose we define modern in this context then? As I'm sure you're aware, it takes years to vet design features, debate whether they can be implemented, whether they affect performance, whether they have unintended side-effects…
It implies that the features are somehow new and ground breaking. Lambdas have been understood for many many years, the same goes for GC. The were not only in the domain of academia. Common Lisp has many of these features and more, being a multi-paradigm programming language. And has been used in industry for many many years. Yet people say CL is antiquated while it has so called 'modern' features.
Re: We have C++14
#335Earlier quoted context omitted.
A factor of two difference is something that can be a result of using different C++ compilers or even different versions of the same compiler. See this: http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/ Particularly the comments section contains various results obtained from different compilers / versions. Variablility is higher than 2x for GCC. Comparing with Clojure is not fair, because it is not really sta…
I tossed out Clojure as a random language -- all my testing was done with the most efficient Java and C# I could write. The link is fine, but only shows micro-benchmarks. It's much easier to get a 3x difference in execution speed between compiler versions when you have a three-line example -- you're maybe exercising 5% of the optimizer? The current version of the C++ I was using comes in at around 50kloc. The Java an…
Those three lines can be as well a bottleneck in a big program, responsible for 80% of its runtime. This example was to show that compiler-induced performance differences in a single language can be just as large (here: up to 4x) as differences between Java and C++ in microbenchmarks. Therefore 2x difference in a microbenchmark where Java is losing to C++ is probably not a statistically significant difference, even though it may be important to the end user. If you rerun this benchmark in 3 years from now, using newer versions, you might as well get completely different results.
As for real applications - that you don't know of any real, fast Java program, doesn't mean there exist no evidence. Sure, it is quite hard to find a pair of two programs doing exactly the same written in two different languages, but there do exist quite a few high-performance Java apps out there which are #1 in their class: Netty, Apache Cassandra, Apache Spark, LMAX disruptor (Java used for ultra low-latency app, see: http://programmers.stackexchange.com/questions/222193/why-di...). Someone also ported Quake2 to Java (Jake2) just to show it was possible, and that didn't make it slower.
Re: We have C++14
#336Earlier quoted context omitted.
Why do people keep assuming that they need an X programmer, or a Y programmer? Go is a garbage collected imperative and OO language, right? It's not like Java and C++ programmers wouldn't be able to learn the basics in 3 days, and be proficient in a couple weeks. Why does the "pool of talent" even matters ?
Companies don't want to pay for training.
Re: We have C++14
#337Earlier quoted context omitted.
I will repeat, since you apparently managed to miss it last time around: using your type system does not require using UTF32 as your internal string encoding. Hell, you don't even need a type system to have separate bytes and string types, you can even do that in dynamically typed languages, regardless of the string type's internal encoding (it could even be variable, within a single string).
I didn't miss it. I simply know projects that use UTF-8 for in-memory strings, and none of the ones I'm familiar with uses a different type for it. It's all convention, and they all occasionally find that somebody flubbed the convention. Can you point me to any projects that manipulate UTF-8 encoded in-memory strings and actually use a different type for it them? I realize I won't convince you. That's what I meant in…
Which is relevant… how?
> Can you point me to any projects that manipulate UTF-8 encoded in-memory strings and actually use a different type for it them?
Rust does. Python 3.3 does something similar but slightly different (it switches internal representation between iso-8859-1, UCS2 and UCS4 depending on the string's codepoints).
> I realize I won't convince you. That's what I meant in the original comment that I know many people disagree with me on this.
Of course you won't convince me, your original comment is based on inane premises.
Re: We have C++14
#338Earlier quoted context omitted.
> you can refuse to catch or throw exceptions for 99% of your (millions of lines) of code and still end up with a very large, stable code base running a large portion of the internet. The point is that these features are infectious. If you don't want to throw exceptions, how do you handle a failure in a constructor? And then if you abandon constructors, other C++ features are unusable without them. And so on.
Googler here. We avoid doing "work" in constructors as per the style guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...
Re: We have C++14
#339Earlier quoted context omitted.
> Have you ever tried building GCC? I've wasted days on it and in the end still failed to make it work. I've hand-built GCC for half a dozen of different target architectures over the years and it's perhaps one of the most stable pieces of software when it comes to building it. I've only had one build failure over the years and that was unstable from git (even that usually works no problem). To build GCC, follow the…
I don't know how you manage it, but I can tell you it is not reasonable to expect people to compile every compiler they want to use on every system they want to use it.
If you're dealing with bare metal projects (kernel programming or micro controllers), building binutils and gcc for cross compiling from source is pretty much required. There are scripts that help and some distros have cross compilers in their package managers.
But building GCC is not difficult and it pretty much works first time, every time.
Re: We have C++14
#340Earlier quoted context omitted.
Too bad it's a mirage I hate to spoil your worldview, but modern C++ is very alive and well in the scientific computing communities. Disney Animation implemented a new renderer using it, and our next movie is currently being rendered using the new renderer, so I highly doubt it's on its way out in the these areas.
I don't see how that refutes the parent's comment. The areas you listed are very small niches. Frankly, very few people care about scientific computing or even animation rendering. Generally speaking, using C++ is like wearing jeans and white sneakers: popular in the 90s, but definitely out of fashion now.