"Does C++ Have a Future?"

[Miles1981]

Which why in modern C++, you write it like this:

Code: Select all

for (auto item: list) {
   doSomethingWith(item);
}

I'm not familiar with this construct, can you elaborate how it works?

C++11 range for loops with the auto keyword (type deduction).
As long as std::begin(list) and std::end(list) works, you can create this. You can also use auto& if you want to modify the object in place or const auto& if the object is costly to copy.

[Miles1981]

Deprecated in C++11 or C//14, removed in C++17. So if you don't understand a list:
- everything deprecated due to lambdas (std::unary_functions...)
- auto_ptr
- register
- export
- the old auto keyword
- random_shuffle

Never used any of these I don't think one _has_ to use all features of the language either

- people used pre-lambdas before for std::transform + std::bind/boost::bind. That was a way of avoiding writing explicit for loops/
- the predecessor for good C++ memory management (the C+ code guidelines pushes you to not use new or delete anymore) with move semantics
- me neither
- same
- random_shuffle is used a lot for permutations, I just saw a discussion on cfe-dev about that one.

[camsr]

Some advantages of Assembly:
No stupid multiple type casting for the same word size etc. or code constructors you don't know what code it produces.

Yes that is probably the worst part of C, the casting. In all fairness, it's probably possible to disable these kinds of checks at compilation, but it's not wise. If you do memory management, you do casting, and this is basically the bulk of what "high level languages" hide from the programmer.

[Miles1981]

Occasionally something appears that I like:- http://en.cppreference.com/w/cpp/memory/unique_ptr
Which is going to be replacing ScopedPointer in the JUCE code...

the successor to auto_ptr... (and boost::scoped_ptr/array, JUCE didn't invent anything)
ScopedPtr is not relevant now that we have move semantics and make_unique.

[Miles1981]

EoD (as anything he writes is times more profound than what you do).

Well, I can write things that are very stupid so...

[quikquak]

Occasionally something appears that I like:- http://en.cppreference.com/w/cpp/memory/unique_ptr
Which is going to be replacing ScopedPointer in the JUCE code...

the successor to auto_ptr... (and boost::scoped_ptr/array, JUCE didn't invent anything)
ScopedPtr is not relevant now that we have move semantics and make_unique.

I didn't say they invented anything. I was just making a reference to usage.

[Miles1981]

Sorry, didn't meant to upset you, just complement.

[v1o]

C++ does not have a future. There is something called progress. As humans we are a creative species and always find better more efficient tools to do things. Isn’t it telling that there are very few really good C++ coders out there? If you look at a lot of source code out there, much of it is quite messy and full of hacks. So I was thinking whatever replaces C++ needs to be designed and structured around our limitations and the way we humans as a species think.

I was reading an interview where the developer of the novel/book writing application Scrivener, said over the course of two years, he hired different sub contractors to write the iPad port of his software. Scrivener is a complex bit of code, he was unhappy with the results he was getting after trying different programmers. In the end he just couldn’t find anyone who could do it right, so he scrapped all the work that was down and ended up coding the port himself. So over two years of work was lost. Which led to delays in the new version of Scrivener for the desktop.

With the millions of people who learned programming through the various learning institutions out there. We really shouldn’t be having these issues.

[ckoe]

I think C++ will have a great Future. C++11, C++14, C++17 and I hope with modules in C++20 are great improvements to make things easier. The next 20 year C++ Code will still rule the IT-World if performance and less resources are the goal.

No worry about the Future of C++ here.

[Max M.]

EoD (as anything he writes is times more profound than what you do).

Well, I can write things that are very stupid so...

I know. It's just the wordings like "I learned XYZ and you did not" make me to feel seek so I become rude.

[Guillaume Piolat]

The next 20 year C++ Code will still rule the IT-World if performance and less resources are the goal.

You hear that a lot, but what would be the technical reasons why something written in C++ should be faster and use less resources? It's not my experience. All native languages are pretty fast. The backend of the compiler makes much more difference than the front-end language used.

[Z1202]

Deprecated in C++11 or C//14, removed in C++17. So if you don't understand a list:
- everything deprecated due to lambdas (std::unary_functions...)
- auto_ptr
- register
- export
- the old auto keyword
- random_shuffle

Never used any of these I don't think one _has_ to use all features of the language either

- people used pre-lambdas before for std::transform + std::bind/boost::bind. That was a way of avoiding writing explicit for loops/

Personally I don't share the belief "raw fors are evil". Once you learn how to write them they should become a standard pattern. I do agree though that the language was not really ready for the introduction of the STL iterators, so this is where auto and range-based fors save quite a lot of typing. But that's it, just saving the typing time Also improving readability, but simply due to smaller code size, so you can see more code at once, not because the old fors looked unreadable (matter of practice).

- the predecessor for good C++ memory management (the C+ code guidelines pushes you to not use new or delete anymore) with move semantics

Didn't look really convincing to me (neither do the new smart pointers, except unique_ptr). Proper structuring and encapsulation of the code was still available as a means of avoiding the mess with news/deletes. I do agree that the move semantics is cool though. But I was using it long before it became an explicit part of the language

All in all my opinion that C++ is a very good language is not because I believe that all of its features are good, rather it has a good subset of features

[Z1202]

what would be the technical reasons why something written in C++ should be faster and use less resources?

Access to low-level (assembler-level) features. Being able to convince the compiler to do the same things one would generally need assembler for without the "safety" overhead of higher-level languages. Off the top of my head: unions, pointer arithmetics (nicely interleaved with array arithmetics), reinterpret casts, raw function pointer calls, virtual function calls which are so efficient that one can use them instead of raw function pointer calls, explicit control of memory layout, explicit memory management (new/delete vs GC). Last but not least, gotos (even though generally they largely decrease readability, in certain rare situations, used with good judgement, they can improve performance, while the code could be even more readable than without them). On top of that any of these features can be encapsulated into custom wrappers which can be shaped according to the specific task, adding zero- (or low-) overhead safety, if necessary. Essentially one can construct a custom set of language features, tailored to the task, with the tradeoffs according to the engineer's needs.

[Max M.]

C++ does not have a future.

Yeah. They've been telling this since 70s.

There is something called progress.

There is. Except that it's never made by those who only whine how cool things could be if only they had a right tool.

... Scrivener ...

Cool story bro. Except that it has nothing to do with C++.

With the millions of people who learned programming through the various learning institutions out there. We really shouldn’t be having these issues.

And the problem is of course in the wrong tools and languages and not in the education system itself, is it?

[Guillaume Piolat]

what would be the technical reasons why something written in C++ should be faster and use less resources?

Access to low-level (assembler-level) features. Being able to convince the compiler to do the same things one would generally need assembler for without the "safety" overhead of higher-level languages. Off the top of my head: unions, pointer arithmetics (nicely interleaved with array arithmetics), reinterpret casts, raw function pointer calls, virtual function calls which are so efficient that one can use them instead of raw function pointer calls, explicit control of memory layout, explicit memory management (new/delete vs GC). Last but not least, gotos (even though generally they largely decrease readability, in certain rare situations, used with good judgement, they can improve performance, while the code could be even more readable than without them). On top of that any of these features can be encapsulated into custom wrappers which can be shaped according to the specific task, adding zero- (or low-) overhead safety, if necessary. Essentially one can construct a custom set of language features, tailored to the task, with the tradeoffs according to the engineer's needs.

Perhaps at one point C++ was the only langage to provide all this (especially your last point), now there are several competitors that can do every single thing you have listed.