"Does C++ Have a Future?"

DSP, Plug-in and Host development discussion.
Miles1981
KVRian
1366 posts since 26 Apr, 2004 from UK

Post Sun Apr 15, 2018 1:19 pm

camsr wrote:
Miles1981 wrote: 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
KVRian
1366 posts since 26 Apr, 2004 from UK

Re: "Does C++ Have a Future?"

Post Sun Apr 15, 2018 1:22 pm

Z1202 wrote:
Miles1981 wrote: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
KVRAF
6890 posts since 17 Feb, 2005

Re: "Does C++ Have a Future?"

Post Sun Apr 15, 2018 1:24 pm

Siekmanski wrote: 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.
Image

Miles1981
KVRian
1366 posts since 26 Apr, 2004 from UK

Re: "Does C++ Have a Future?"

Post Sun Apr 15, 2018 1:25 pm

quikquak wrote: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
KVRian
1366 posts since 26 Apr, 2004 from UK

Re: "Does C++ Have a Future?"

Post Sun Apr 15, 2018 1:26 pm

Max M. wrote:EoD (as anything he writes is times more profound than what you do).
Well, I can write things that are very stupid so...

quikquak
KVRist
425 posts since 6 Aug, 2005 from England

Re: "Does C++ Have a Future?"

Post Sun Apr 15, 2018 1:32 pm

Miles1981 wrote:
quikquak wrote: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
KVRian
1366 posts since 26 Apr, 2004 from UK

Re: "Does C++ Have a Future?"

Post Sun Apr 15, 2018 1:45 pm

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

v1o
KVRian
1251 posts since 2 Oct, 2004

Re: "Does C++ Have a Future?"

Post Sun Apr 15, 2018 3:33 pm

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.
Orion Platinum, Muzys 2

ckoe
KVRist
116 posts since 26 Sep, 2017 from Berlin

Re: "Does C++ Have a Future?"

Post Sun Apr 15, 2018 11:41 pm

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.

User avatar
Max M.
KVRist
275 posts since 20 Apr, 2005 from Moscow, Russian Federation

Re: "Does C++ Have a Future?"

Post Mon Apr 16, 2018 12:52 am

Miles1981 wrote:
Max M. wrote: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.

User avatar
Guillaume Piolat
KVRist
182 posts since 21 Sep, 2015 from Grenoble

Re: "Does C++ Have a Future?"

Post Mon Apr 16, 2018 2:33 am

ckoe wrote: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.
VST/AU/AAX: Couture | Panagement | Graillon

Z1202
KVRian
978 posts since 12 Apr, 2002

Re: "Does C++ Have a Future?"

Post Mon Apr 16, 2018 2:33 am

Miles1981 wrote:
Z1202 wrote:
Miles1981 wrote: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).
Miles1981 wrote:- 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
KVRian
978 posts since 12 Apr, 2002

Re: "Does C++ Have a Future?"

Post Mon Apr 16, 2018 3:21 am

Guillaume Piolat wrote: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.

User avatar
Max M.
KVRist
275 posts since 20 Apr, 2005 from Moscow, Russian Federation

Re: "Does C++ Have a Future?"

Post Mon Apr 16, 2018 3:46 am

v1o wrote:C++ does not have a future.
Yeah. They've been telling this since 70s.
v1o wrote: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?

User avatar
Guillaume Piolat
KVRist
182 posts since 21 Sep, 2015 from Grenoble

Re: "Does C++ Have a Future?"

Post Mon Apr 16, 2018 3:58 am

Z1202 wrote:
Guillaume Piolat wrote: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.
VST/AU/AAX: Couture | Panagement | Graillon

Return to “DSP and Plug-in Development”