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



## Maelstorm (Jun 19, 2018)

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.


----------



## ralphbsz (Jun 20, 2018)

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.



Maelstorm said:


> 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.


----------



## Crivens (Jun 20, 2018)

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.


----------



## Spartrekus (Jun 21, 2018)

Maelstorm said:


> 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
> ...



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 !


----------



## kpedersen (Jun 21, 2018)

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!


----------



## Maelstorm (Jun 23, 2018)

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.


----------



## Crivens (Jun 23, 2018)

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.


----------



## Spartrekus (Jun 30, 2018)

Crivens said:


> 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.


----------



## Crivens (Jun 30, 2018)

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...


----------



## ralphbsz (Jun 30, 2018)

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.


----------



## Cthulhux (Jul 2, 2018)

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.


----------



## Maelstorm (Jul 19, 2018)

ralphbsz said:


> 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.


----------



## Crivens (Jul 19, 2018)

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.


----------



## Chris_H (Jul 19, 2018)

Maelstorm said:


> . . .
> 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. 

Just thought I'd mention it. 

--Chris


----------



## Crivens (Jul 19, 2018)

Thumbs up to Chris_H for efford.


----------



## Maelstorm (Jul 19, 2018)

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.


----------



## Chris_H (Jul 19, 2018)

Odd.

```
FreeBSD demon0 11.1-STABLE FreeBSD 11.1-STABLE #0
root@demon0:/usr/obj/usr/src/sys/DEMON0NDB  amd64
```
and

```
# 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


----------



## Maelstorm (Jul 21, 2018)

What is your stable date?  I'm running release.


----------



## Chris_H (Jul 21, 2018)

Hello, Maelstorm !
Ah. I can't speak to RELEASE. But here's what I see in UPDATING:

```
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


----------



## P15C15 (Jul 22, 2018)

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.


----------



## P15C15 (Jul 22, 2018)

In fact, you all that know of programming and so, I think you could create a new OS, and even a language.


----------



## Maelstorm (Jul 22, 2018)

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.


----------



## Chris_H (Jul 22, 2018)

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


----------

