C++20 is coming out soon with 43+ new features being discussed...

Assuming that we all know and love C++ (I rarely use it myself), the standards of C++11, C++14, and C++17 all add new features of...dubious...quality and usefulness. Now, C++20 is being drafted. However, Bjarne Stroustrup is firing warning shots about the **43** new features being proposed for the new standard. Forty Three new features? That's quite a bit, and that's not counting all of them.

https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf

Since I rarely use C++, I'm not competent enough to speak intelligently, or even qualified to offer a valid opinion on the subject. But that seems a little excessive for a programming language. The problem that I see here though is when you make major changes like this, different features may not be compatible with each other and cause conflict when compiling code. Some features are less than useless such as the entire lambda code structure that Microsoft adopted for their Windows RT platform.

What do you people think?

One thing. Last time I checked (which admittedly was some time ago), no compilers fully supported C++11 or C++14. I think the closest was Microsoft's Visual C++ compiler (which is brain dead). I only found out about C++17 6 months ago.
 
C++ is already way too complex. So much so that the previous updates already had simplifications of the language built in, such as the "auto" type. But C++ will be collapsing under its own weight. Or pull a Wasa and flip over. Unfortunately, for systems programming it is still fairly heavily used (applications much less so).

I don't know anyone who loves C++. I know lots of people who use it grudgingly, and some who are really good at it and understand it deeply. I know lots of people who love Python, Perl, Java, Ruby, Go, Swift, ... That already tells you something.

The problem that I see here though is when you make major changes like this, different features may not be compatible with each other and cause conflict when compiling code.
The C++ committee has been very very good at keeping backwards compatibility. Unfortunately, that means that there are several different dialects of C++ which are in use; for example, I just switched from developing on a large code base that's C++98 to C++14, and the language is at times barely recognizable.

Some features are less than useless such as the entire lambda code structure that Microsoft adopted for their Windows RT platform.
Modern C++ (14) has lambdas. The syntax is completely god-awful, and resembles modem line noise (or Perl).

Last time I checked (which admittedly was some time ago), no compilers fully supported C++11 or C++14.
I think all decent production compilers fully support C++14 (and all earlier versions), and either all of or most of C++17. CLANG definitely does.
 
I started my C++ with cfront. There was not much to it and it was useful. Then templates came in, and with the STL life was good. Then someone showed me that the template mechanism was touring complete, you could create classes by having it parse some ascii art image of your data structure. That's when I saw dark clouds on the horizon. This is going to become unmanageable. Now, I sometimes have no clue what the source there tries to do, or if the author knew what he was doing.

C++ is a nice language, not perfect but nice. What they should have done was getting rid of some old baggage, like include files. Stick that stuff into a debug section of the object and have the compiler read it from there. No more #ifdef in class definitions or templates.
 
Assuming that we all know and love C++ (I rarely use it myself), the standards of C++11, C++14, and C++17 all add new features of...dubious...quality and usefulness. Now, C++20 is being drafted. However, Bjarne Stroustrup is firing warning shots about the **43** new features being proposed for the new standard. Forty Three new features? That's quite a bit, and that's not counting all of them.

https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf

Since I rarely use C++, I'm not competent enough to speak intelligently, or even qualified to offer a valid opinion on the subject. But that seems a little excessive for a programming language. The problem that I see here though is when you make major changes like this, different features may not be compatible with each other and cause conflict when compiling code. Some features are less than useless such as the entire lambda code structure that Microsoft adopted for their Windows RT platform.

What do you people think?

One thing. Last time I checked (which admittedly was some time ago), no compilers fully supported C++11 or C++14. I think the closest was Microsoft's Visual C++ compiler (which is brain dead). I only found out about C++17 6 months ago.

You cannot stop the progress.

It is linked with innovation in computer sciences. It is just normal that a programming language evolves with more features and functions. This is how our industry works.

If there is stagnation and no evolution in the source code C++, this would mean less innovations, creative ideas, less reinventing the wheel, ... and less jobs in informatics. This is bad, because informatic industry employs lot of people. You need bugs and rewriting of softwares for making money. You see poor operating system performances to sell hardwares. Hardware heavily deal with MS, Apple and Google/Android to keep their market secured. You want that Microsoft and Apple get money, right?

Our society rely almost just on microsoft, apple and google. If you would offer FreeBSD, opensource, ultra performant operating systems, this would impact on jobs. You would have less necessary persons to do the same things. They would work faster and more efficiently. Closed code source allows a very low efficiency and this for any given tasks. Having opensource would speed up results and achieved work, and this would lead to cut jobs and large unemployment.

For instance, browsers, web services, and the web allow to work slower and to do less. It creates sales and allows larger development of big computer empires.

The more the features, the more possibilities. The more the Spaghettis and libraries, the slower the system, the richer & more powerful Microsoft, Apple and Google empires !
 
Yay, more fantastic awesome fast and efficient features that I will.... never actually use haha.

C++ hasn't come out with anything useful for me personally since TR1 and std::tr1::shared_ptr<T>.

There is so much focus on asynchronous code that modern C++ codebases are almost impossible to follow (like Javascript) and worse of all... unsafe. There is no real protection against race conditions and thread collisions. All of these "new standards" and they have not solved something as critical as that. Weird.

I was actually on the C++ standard discussion forums the other day asking why there wasn't an additional layer of protection on smart pointers so that "this" can never become use after free whilst inside a member function. They pretty much just responded with "don't do that and you'll be fine". Unfortunately the rest of us aren't that smart and have too much code to wrangle to be able to track down this kind of mistake haha.

Don't get me wrong, between C and C++, there is basically no other language choice for so many problem domains... but they are half crap aren't they ;)? I primarily teach my students C++ (mostly because of the few additional safety features over C) and it is basically 3 years of solid fun!
 
The only aspects of C++ that I have used include using objects and such. I use mostly C in my software because it's system level. Linus had some very interesting things to say about C++: http://harmful.cat-v.org/software/c++/linus which is quite an interesting read. I find myself agreeing with him. C++ is becoming the kitchen sink language. It needs to be slimmed down.
 
I find myself learning object pascal. All what you need, even templates, without the include hell. And when your code looks ugly, it is most likely buggy. C++ is still my tool of choice, but there is the possibility it will implode with more features.
 
I find myself learning object pascal. All what you need, even templates, without the include hell. And when your code looks ugly, it is most likely buggy. C++ is still my tool of choice, but there is the possibility it will implode with more features.

Plain C ok, pascal ok, and object pascal is awesome.
Just basics.

C++ good luck sometimes to make a portable project on microsoft and Unix. Compilers can be buggy, very buggy to make it work sometimes.
 
I have done that, projects with source code in the gigabytes. You need to take care about some things, and eventually you have to split the project since the automatic test cases run after check ins start to limit the check ins to about 100 a day, which is no good if you have more developers than that...
 
Compilers very rarely have bugs. "It was a compiler bug" is a common joke among software developers, but in my ~30 year career in software development, I can think of one or two cases where we had an actual compiler bug. Typically, users think compilers are buggy when they are writing non-standard-conforming code and it doesn't compile, when in reality their code is not "correct". The definition of "correct" is: follows the laws of the language exactly.

Writing code that compiles and runs on Microsoft and various Unix compilers is actually not very difficult, it just requires great care. You have to make 110% sure to only use standard language features, or OS features that are well-defined by standards bodies (such as POSIX), and then test correctly (good QA teams with skilled engineers, continuous integration, white-box testing, ...). It is a little extra effort, but in my experience you end up with better code.
 
The last feature missing from standard C++ is std::asio IMO. I have been waiting for it for a while. But indeed, I also notice a growing feature-hunger of the language standard. Which is sad because it makes C++ unnecessarily complex.
 
Compilers very rarely have bugs. "It was a compiler bug" is a common joke among software developers, but in my ~30 year career in software development, I can think of one or two cases where we had an actual compiler bug. Typically, users think compilers are buggy when they are writing non-standard-conforming code and it doesn't compile, when in reality their code is not "correct". The definition of "correct" is: follows the laws of the language exactly.

Writing code that compiles and runs on Microsoft and various Unix compilers is actually not very difficult, it just requires great care. You have to make 110% sure to only use standard language features, or OS features that are well-defined by standards bodies (such as POSIX), and then test correctly (good QA teams with skilled engineers, continuous integration, white-box testing, ...). It is a little extra effort, but in my experience you end up with better code.

I've recently taken a compiler class and I have to say, it was quite an undertaking. The hardest part for me was understanding the parser. In the homework, we used Flex and Bison to write the parser. Then the actions from there formed the AST (abstract syntax tree). The tree is basically a tree with lists in it for sequential statements. Then you walk the tree to generate an intermediate language. Our toy C compiler generated ILOC intermediate code.

The instructor is Dr. Ghassan Shobaki, Phd. He does optimization research using the LLVM toolchain. I have to say, he is a hard instructor but he will make you learn the material. One of his quotes goes something like this: "People use compilers to write software. Nobody is going to buy a compiler that is correct 50% of the time." So compiler bugs are extremely rare because that code must be correct and must produce correct assembly language code every single time.
 
Ahh, fond memories of compiler design...

The reason most code generation bugs will get caught is courtesy of chain builds, something that cygnus software then brought to gcc. It is unbelievable that they did not do it from a start. Here is how it works:
  • Your compiler has one bug in a rarely used part.
  • Compilers themself are non-trivial code bases.
  • Building the compiler with itself does apply one bug on itself, leading to more bugs in the binary (not source).
  • Using stage 1 to make stage 2 amplifies this even further.
  • Now stage 3 and stage 2 are build by compilers of the same code base, with the same capabilities. This is not true for the stage 1 binary.
  • If stage 2 and stage 3 are identical, proceed to test cases and the little shop of horrors (a.k.a. customer regression reports, bugs, ...)
And then you check the coverage builds of the chain build.
 
. . .
A lot of interesting stuff stripped.
. . .
One thing. Last time I checked (which admittedly was some time ago), no compilers fully supported C++11 or C++14. I think the closest was Microsoft's Visual C++ compiler (which is brain dead). I only found out about C++17 6 months ago.
Um, not sure you noticed. But the introduction, and landing of clang5 && 6 (llvm5/6) are now the default in $BASE.
That means *everything* must support (minimum) c++11. I can tell you first hand, as a Maintainer of some 150 ports. This was a real PITA. I'm still reeling from the fallout. o_O

Just thought I'd mention it. :)

--Chris
 
I'm on FBSD 11.1 and clang is still 4.0.0. Just checked it. Unless it's part of the new version coming out.
 
Odd.
Code:
FreeBSD demon0 11.1-STABLE FreeBSD 11.1-STABLE #0
root@demon0:/usr/obj/usr/src/sys/DEMON0NDB  amd64
and
Code:
# cc -v
FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLVM 5.0.1)
Target: x86_64-unknown-freebsd11.1
Thread model: posix
InstalledDir: /usr/bin
I think your copy of FreeBSD must me a fake. :)

--Chris
 
Hello, Maelstorm !
Ah. I can't speak to RELEASE. But here's what I see in UPDATING:
Code:
20170926:
    Clang, llvm, lldb, compiler-rt and libc++ have been upgraded to 5.0.0.
    Please see the 20141231 entry below for information about prerequisites
    and upgrading, if you are not already using clang 3.5.0 or higher.
Is this not in your copy?

HTH

--Chris
 
I'm thinking on writing my own OS, based on my own language.
I'm starting to studying C++. Till the day, I've found none complications.
If I stop because of the complexity of the language, I: move to another languages, and/or make my own.
I'm not bad at maths. In fact, I'm better in that area than informatics. Remember that informatics came from math.
Yes, it would be hard. Despite of it, would be better than use the s*** that others create. At least you know what you're using.
My own OS would come to be the simplest: a few lines of code, and the user could add more. Like Linux. But not the 9 million of lines of code of FBSD, for example.
Yes, you probably gonna think that I'm nobody to s*** or Linus and in Theo. But this, more like this kind of *big systems*, would be something basic.
I spent hours downloading OS. Now, tell me if someone of you could some time in your life read, analyze, edit, more than 1 mill of lines of code.
Yet I know that the hardware requires it...but for running the hardware would be this OS. Instead of using and learning the whole quantity of code (if you can access and edit it) that comes in the majority of OS. Besides, this is exactly the same problem that BSD haves: sometimes you need to write the code, or compile it, then install it.
 
Chris_H Nope. But it makes sense why though.

The stable branch gets new feature updates between releases because it is not for use in a production environment. The release branch only gets bug fixes and security updates because it is for use in a production environment.
 
Right. But somehow I figured they were landing version 5 in both, on 11*. Because 6 is already in 12.
Thanks for the info. It's easy for me to miss things like that. Because I maintain a boatload of ports, and always have to build against *whatever* landed in *any* of the versions.

Take care, Maelstorm !

--Chris
 
Back
Top