151–160 of 181 posts
Earlier quoted context omitted.
This issue is what stopped me contributing to the C++ standard. We knew brace initialisation was broken before C++11 came out, even std::vector was a mess.
Well, the issue is not brace initialization per se, but the ambiguity with initilalizer_list.
Earlier quoted context omitted.
Checked exceptions is definitely cruft. Java is also has the advantage of trying to be less things than c++. It's not a systems language and it's hardly even a desktop applications language anymore. Java has the same niches as ruby and python more than c++.
I'm seeing a few people in this thread mention checked exceptions being cruft. I haven't heard this before and was wondering about the reasoning. Why are checked exceptions cruft?
Most new libraries don't use checked exceptions. They were a good idea in theory but not in practice.
Earlier quoted context omitted.
Can you give me an example of a "JS enhancement" you are talking about? Its not that I don't believe you I just am curious. I haven't changed the way I, personally, written Javascript since jQuery came out so I'm not up with the new stuff.
Class syntax - https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...
Then there's "let". I guess it's not hurting anything, but how useful an addition is it, really? How many nested, non function, blocks you got in your code, buddy, that you need a new scope for your nested for-loops and else-ifs?!?
Between things like forEach, map, filter, etc, I don't actually write very many manual loops anymore, and often use an IIFE for something that outgrows a ternary. Most of my "blocks" are functions.
I've been programming professionally for over 20 years, most of it in C++. I really like developing fast code, and C++ used to be my favorite tool for the job. But the language complexity gets more insane with every revision. It's now at the point where Scott Freakin' Meyers can't figure out the interpretation of a short little chunk of code. I'm now actively looking for gigs in which I can develop high-performance c…
I would like to thank Mr Meyers for his Effective C++ book, back in the 90s. Said book for me was the tipping point with C++. Having used Borland Pascal-with-Objects, and read about Eiffel, that book confirmed for me, at least, that C++ was a tool of last resort for trying to build on top of existing C code. C++ devs are a hardy breed :-)
Most apps don't need this heartache.
Earlier quoted context omitted.
Those worshipped companies at Silicon Valley are a tiny spot in the ocean of companies that most of us, common developers, get to work on.
They do hire a lot of C++ programmers to work on cool projects tough. They also pay well. Also banks.
As for the banks, the ones around where I live only care for Cobol, RPG, JEE and .NET.
Earlier quoted context omitted.
> inline assembly code to render fast felt natural, unlike in Turbo Pascal. Turbo C: asm { .... } Turbo Pascal: asm ... end; What was unnatural about it?
You could do some tricks with GCC like not specifying arguments in your MOV instructions and let GCC use the optimal registers it calculates during compiling. Practical consequence was that instead of doing some default MOV AX, [something] then MOV BX, [something], then e.g. MUL BX, you could have avoided the first two operations as GCC would chain them together properly without the need to fill in values; so by inli…
So we just wrote the inline Assembly 100% ourselves, regardless of the compiler.
I've been programming professionally for over 20 years, most of it in C++. I really like developing fast code, and C++ used to be my favorite tool for the job. But the language complexity gets more insane with every revision. It's now at the point where Scott Freakin' Meyers can't figure out the interpretation of a short little chunk of code. I'm now actively looking for gigs in which I can develop high-performance c…
Any sense of where the C++ refugees are heading? Rust? Go?
I used to choose C for pet projects (when I cared about performance) but I've been learning Rust for ~3 months now. I think I'll replace my usage of C by Rust from here on as much as I can.
I also had a brief affair writing Go but it didn't resonate nearly as well with my background as Rust does.
Earlier quoted context omitted.
I'm not quite sure what you mean by 'goldilocks moment', but I think C++11 was it. Ever since then, the language has had a nice balance of high level abstractions at low level performance. (Theoretically it actually got faster due to move semantics)
The parent was asking the goldilocks question -- was there ever a point where C++ was not too complex like modern C++, e.g. this {} issue, but had enough features (contrast with C, which doesn't have enough features for many applications). I don't think there was such a moment. Apparently move constructors were a de-optimization in the case of std::vector. As far as I remember, it's related to iterator invalidation a…
RVO being transparent would be nice, though. There's a proposal somewhere to make it guaranteed in some circumstances, but it's still fairly opaque when reading code
Earlier quoted context omitted.
Well, the issue is not brace initialization per se, but the ambiguity with initilalizer_list.
Yes, either feature in isolation would have been an improvement to C++, but their combination was a mess. Probably one of the features shouldn't have been added, or their combination needed some serious tidying.
The worst part is that initializer_list can be 'emulated' via variadic constructors.
Earlier quoted context omitted.
No STL at all? That's the best part of C++! OK, don't use iostreams, or stringstreams perhaps, and use boost very sparingly. But not at all?
The STL is generally nice, I agree, and I really miss the separation of algorithms and containers in every other language. Generally, however, I'm not really a fan the ‘generic programming’ paradigm the STL (and boost) are based around. In C++ it quickly leads to an explosion of complexity. And as for the best part of C++, RAII and sparing use of templates. ;-)