I’ve been writing C++ code since it’s inception in the 1980’s. In the last two weeks I’ve written close to 1000 lines and no raw ptrs… in fact no smart ptrs either… not even one c-style array. No worries about leaks or memory safety. It doesn’t look anything like C++ code I wrote even 10 years ago.
I'm curious and would love to take a look. Any chance any of that code is available somewhere? My c++, little that I write, mostly looks like C and I'd love to learn something new.
If you consider thread safety an aspect of memory safety, I still see those issues pop up in modern c++. And memory leaks in terms of ever growing maps still happen. But the only times I have seen use after free or similar in modern code is where there was a bit that wasn't so modern. Is there some list for clang tidy modernize that will treat using anything other than value semantics as a warning?
I was called inexperienced because I was saying pointers are not 100% necessary in C++ anymore.
I'm not even certain if using stl containers always use the heap.
I'm a bit confused at times, since I avoid using oop and inheritance, I prefer data oriented, I just write functions and avoid side effects as often as possible.
I feel like the standards are starting to get ahead of implementation. It's almost 2023 and C++20 still doesn't have even full support in any of the main compilers.
Clang well, apparently all those compiler vendors that profit from it, see only a value in LLVM itself, after Apple and Google switched focus to their own languages.
To focus on the book itself, the very first "hello world" example doesn't seem to work with any compiler. Literally
import std;
int main()
{
std::cout << "Hello, World!\n";
}
I even tried futzing with the latest compilers - VS 2022 Preview and clang++ 16.0.0 and it wouldn't work. Perhaps it works in some specific earlier released versions? As somebody noted, perhaps this book is for reading and not for actually trying out the code. Very strange for a programming language book in 2022.
He says in the book (right after introducing that example), "if you have trouble with import std;, try the old-fashioned and conventional #include <iostream> ..." And he shows a snippet with that.
The title says it covers C++20 with some C++23 features. This requires a module version of the standard library's iostreams mechanism - and that's a C++23 feature.
In 2023, compilers are likely to support this - and you will have a less-obsolete book. If Bjarne had written a C++20-only book, it would have been supported by existing compilers, but would have gotten older, quicker.
Modular standard library is part of C++23, unlike the modules themselves which appeared in C++20. In Visual C++ you'd need to install modules for the standard library and use /experimental:module and /std:c++latest[0]. Also half a year ago I had to use import std.core; instead of import std;
The author later states that std as a module isn't implemented in standard C++20 (though hopefully will be in C++23) and provides ways to work around that somewhere in the back of the book. It's somewhere in the appendix.
Clang doesn't seem to support modules well and g++ is rapidly falling behind the other compilers. It'll be a few years before this code will compile on any system of your choosing. I'm confident Microsoft can release a compiler that will compile all the code mentioned once C++23 gets standardised, though.
Kind of weird to write a book using a language standard that's not even out yet, especially in a language where the freely available compilers lack a significant portion of the standard, but as one of the language's designers I can see why he's getting ahead of himself.
It's probably better to have this book available already once C++23 does finally land than to have to wait for standardisation before writing a book using it, but I think the book shouldn't have relied on unreleased standards or custom setups like it does until the new standard is out. Yes, you can get a std module of your own and yes the performance improvements are significant, but with open toolsets lagging behind I don't think it's smart to merely mention the downsides in a side note and the appendix.
It should work for g++, as long as you build you own "std" module (which sadly is
somewhat complicated) and enables -fmodule-ts. I guess he's hoping that will be easier in 2023.
I don't have the professional experience that most of the commenters here have, but I hear a lot of negativity. Like, a lot.
Sure, the compilers might be a little bit behind, but who cares, I believe it's just a matter of time before they implement the missing features. They are pretty solid, the libs are battle tested, the ecosystem is huge (which can be an issue too).
For me the bigges issues are:
- lots of pre-11 docs and blogs showing up in the first 1-2 search pages
- not clear answers or FAQs about how to develop cross platform code (and backward compatible), the devil is always in the details here.
- not always clear which tool to use: what do I use for unit tests? And coverage? I would like to have like 2-3 top used libs, the rest I don't care
- some things which should be basic in 2022 can be daunting for people coming from simpler languages like Python or Javs, stupid example: dates. I see that with c++20 they did a lot of good work (with chrono, not sure if there is anything else), but that's not enough. The API is really good, but it's quite minimalistic for a 2020 standard. You can clearly live with that, but if you want to keep the language competitive you need to provide also higher level constructs. (Just to say some BS: Take Python's date module and copy it as is.)
Finally, if you exclude all the features you won't probably ever use, focus on simplicity and use the tools at your disposal (clang-tidy, clang-format, etc.) I think things are quite OK. But hey, I am not paid to work on old c++ codebases so of course I might be biased :)
Quite good reading to stay up to date how to write proper C++ code instead of classical C with C++ compiler, given how the language is anyway unavoidable in many domains until they migrate to something else, mostly beyond our lifetimes.
Like LLVM and GCC contributions, GPGPU frameworks and Khronos standards, language runtimes,...
The 'advice' section in the Tour excerpt is perhaps the most useful part. The learncpp excerpt is more about writing your own container class - note that many would consider the examples outdated with lots of raw new and deletes, but others would say, how else would you learn why uniq_ptr was introduced? (learncpp covers that later).
As far as how containers are allocated, C has malloc, calloc and free; new and delete in 'C with classes C++' are wrappers around those functions, and modern C++ has unique and shared pointers as wrappers around new and delete in turn. Actually learning modern C++ in depth thus seems to require going through that whole chain, including gaining a solid understanding of stack vs. heap, and the benefit is improved performance relative to languages like Python and JavaScript.
There's a notion that one can prototype in Python and then just translate that easily to modern C++, using idioms like ranges, without necessarily knowing the history of C++. It's an interesting idea, seems to be fairly popular, but I'd guess you'd still need to have that foundation in C to make it really work well.
There's a notion that one can prototype in Python and then just translate that easily to modern C++
That was my first thought on looking at the github link posted by waynecochran above: if I'm going to write C++ code that looks like that, why don't I just use Python or a similar language? What exactly is C++ doing for Wayne here?
It's not going to be much slower if it all, given that all he's doing is invoking higher-level abstractions.
Another thought: again, given the abstractions and high-level resources that C++ programmers will be coming to rely on in the years ahead, someone could "just" write a back end that translates a cleaner high-level language like Python to modern C++ for compilation and optimization.
Having left the C/C++ professional programming world several years back to wallow in other pastures, I've lost close touch with the languages except at a low-key hobbyist level. That said, I am curious over what is the motivation to pursue updates in 20 and 23? Are there really new features promised that today's programmer simply can't live without or are they all various levels of syntactic sugar or something in between? Is there a concern over whether these changes are making the language ever more complex and obese thus making mastery even harder to achieve?
One of the things I've mostly been looking at is the additions to the standard library. Especially the new <stacktrace> header looks like something that should have been in the language already.
I like the new <bit> header. In C++/20 they added support for BSR and BSF instructions from 1985, introduced in Intel i386. In C++/23 they even added BSWAP instruction, much newer one, introduced in 1989, in Intel i486. Most other instruction sets (ARM, Power, etc) have equivalents of these instructions.
Currently I use C++/17, have to rely on compiler-specific intrinsics. They work fine in practice, but standard library functions are IMO better.
> Having left the C/C++ professional programming world several years back to wallow in other pastures.
As someone who wants to follow the same trajectory, how did you do it? And how did you dissociate professionally from being seen as the C++/systems guy?
This is an obvious ad to sell a book, but I wish more publishers would let you read one of the chapters without buying it first. Stroustrup has a lot of books and I have read some of them so he is a known entity, but I see ads like this all the time from authors I know nothing about. The preface and table of contents are good information, but they don't give you a good sense of the author's writing style.
[+] [-] waynecochran|3 years ago|reply
[+] [-] Icathian|3 years ago|reply
[+] [-] galangalalgol|3 years ago|reply
[+] [-] deltasevennine|3 years ago|reply
[+] [-] jokoon|3 years ago|reply
I'm not even certain if using stl containers always use the heap.
I'm a bit confused at times, since I avoid using oop and inheritance, I prefer data oriented, I just write functions and avoid side effects as often as possible.
[+] [-] nicolapede|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] snovv_crash|3 years ago|reply
[+] [-] pjmlp|3 years ago|reply
GCC is getting there thanks Red-Hat support.
Clang well, apparently all those compiler vendors that profit from it, see only a value in LLVM itself, after Apple and Google switched focus to their own languages.
[+] [-] jahnu|3 years ago|reply
[+] [-] kramerger|3 years ago|reply
It was even worse in the old Microsoft C++ days.
[+] [-] Triangle9349|3 years ago|reply
[+] [-] npalli|3 years ago|reply
[+] [-] troydj|3 years ago|reply
[+] [-] einpoklum|3 years ago|reply
In 2023, compilers are likely to support this - and you will have a less-obsolete book. If Bjarne had written a C++20-only book, it would have been supported by existing compilers, but would have gotten older, quicker.
[+] [-] _dhruva|3 years ago|reply
[+] [-] protomolecule|3 years ago|reply
[0] https://learn.microsoft.com/en-us/cpp/cpp/modules-cpp?view=m...
[+] [-] jeroenhd|3 years ago|reply
There are also experimental flags to enable (some parts of) this behaviour on the most recent compilers, apparently. (i.e. https://learn.microsoft.com/en-us/cpp/cpp/modules-cpp?view=m...)
Clang doesn't seem to support modules well and g++ is rapidly falling behind the other compilers. It'll be a few years before this code will compile on any system of your choosing. I'm confident Microsoft can release a compiler that will compile all the code mentioned once C++23 gets standardised, though.
Kind of weird to write a book using a language standard that's not even out yet, especially in a language where the freely available compilers lack a significant portion of the standard, but as one of the language's designers I can see why he's getting ahead of himself.
It's probably better to have this book available already once C++23 does finally land than to have to wait for standardisation before writing a book using it, but I think the book shouldn't have relied on unreleased standards or custom setups like it does until the new standard is out. Yes, you can get a std module of your own and yes the performance improvements are significant, but with open toolsets lagging behind I don't think it's smart to merely mention the downsides in a side note and the appendix.
[+] [-] TinkersW|3 years ago|reply
[+] [-] Sin2x|3 years ago|reply
https://en.wikipedia.org/wiki/Input/output_(C%2B%2B)#Input/o...
[+] [-] nn3|3 years ago|reply
What bothers me more is the lack of "return 0"
[+] [-] w4rh4wk5|3 years ago|reply
[+] [-] jesse__|3 years ago|reply
[deleted]
[+] [-] mk89|3 years ago|reply
Sure, the compilers might be a little bit behind, but who cares, I believe it's just a matter of time before they implement the missing features. They are pretty solid, the libs are battle tested, the ecosystem is huge (which can be an issue too).
For me the bigges issues are:
- lots of pre-11 docs and blogs showing up in the first 1-2 search pages
- not clear answers or FAQs about how to develop cross platform code (and backward compatible), the devil is always in the details here.
- not always clear which tool to use: what do I use for unit tests? And coverage? I would like to have like 2-3 top used libs, the rest I don't care
- some things which should be basic in 2022 can be daunting for people coming from simpler languages like Python or Javs, stupid example: dates. I see that with c++20 they did a lot of good work (with chrono, not sure if there is anything else), but that's not enough. The API is really good, but it's quite minimalistic for a 2020 standard. You can clearly live with that, but if you want to keep the language competitive you need to provide also higher level constructs. (Just to say some BS: Take Python's date module and copy it as is.)
Finally, if you exclude all the features you won't probably ever use, focus on simplicity and use the tools at your disposal (clang-tidy, clang-format, etc.) I think things are quite OK. But hey, I am not paid to work on old c++ codebases so of course I might be biased :)
[+] [-] pjmlp|3 years ago|reply
Like LLVM and GCC contributions, GPGPU frameworks and Khronos standards, language runtimes,...
[+] [-] photochemsyn|3 years ago|reply
https://ptgmedia.pearsoncmg.com/images/9780136816485/samplep...
It's worth comparing that to one of the more popular free C++ resources, learncpp:
https://www.learncpp.com/cpp-tutorial/container-classes/
The 'advice' section in the Tour excerpt is perhaps the most useful part. The learncpp excerpt is more about writing your own container class - note that many would consider the examples outdated with lots of raw new and deletes, but others would say, how else would you learn why uniq_ptr was introduced? (learncpp covers that later).
As far as how containers are allocated, C has malloc, calloc and free; new and delete in 'C with classes C++' are wrappers around those functions, and modern C++ has unique and shared pointers as wrappers around new and delete in turn. Actually learning modern C++ in depth thus seems to require going through that whole chain, including gaining a solid understanding of stack vs. heap, and the benefit is improved performance relative to languages like Python and JavaScript.
There's a notion that one can prototype in Python and then just translate that easily to modern C++, using idioms like ranges, without necessarily knowing the history of C++. It's an interesting idea, seems to be fairly popular, but I'd guess you'd still need to have that foundation in C to make it really work well.
[+] [-] CamperBob2|3 years ago|reply
That was my first thought on looking at the github link posted by waynecochran above: if I'm going to write C++ code that looks like that, why don't I just use Python or a similar language? What exactly is C++ doing for Wayne here?
It's not going to be much slower if it all, given that all he's doing is invoking higher-level abstractions.
Another thought: again, given the abstractions and high-level resources that C++ programmers will be coming to rely on in the years ahead, someone could "just" write a back end that translates a cleaner high-level language like Python to modern C++ for compilation and optimization.
[+] [-] sizzzzlerz|3 years ago|reply
[+] [-] einpoklum|3 years ago|reply
For C++20:
* Ranges! With may range operations and views
* Expansion of ability of compile-time computation, including a lot of standard library code.
* Concepts - constrained templates
* 3-way comparisons with spaceship operator + automatic comparisons generation.
* You can write your own modules (Java-esque import rather than textual inclusion)
* Support (albeit ugly) for co-routines
* Spans: https://stackoverflow.com/q/45723819/1593077
* Parallelism primitives
* Asynchronous network operations in the standard library (Boost-ASIO-based IIANM)
* Can safely implement scope guards
For C++23:
* Standard library via modules
* Stack traces (e.g. in exceptions)
* Many range views/algroithms/adapters
* Expected: https://stackoverflow.com/q/68368581/1593077
* Monadic semantics for std::optional
* etc.
> Are there really new features promised that today's programmer simply can't live without
Well, people can live with a lot. Many people write C, after all... so you could ask that about any language undergoing long term development.
[+] [-] helen___keller|3 years ago|reply
[+] [-] Deukhoofd|3 years ago|reply
[+] [-] Const-me|3 years ago|reply
Currently I use C++/17, have to rely on compiler-specific intrinsics. They work fine in practice, but standard library functions are IMO better.
[+] [-] DoingIsLearning|3 years ago|reply
As someone who wants to follow the same trajectory, how did you do it? And how did you dissociate professionally from being seen as the C++/systems guy?
[+] [-] didgetmaster|3 years ago|reply
[+] [-] frou_dh|3 years ago|reply
[+] [-] qualudeheart|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]