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.
> If Bjarne had written a C++20-only book, it would have been supported by existing compilers
Not yet. Most of the C++ 20 features are implemented in at least one compiler, but if you just write a whole pile of C++ 20 without checking all the features you used are in all the compilers you use, that won't work.
Ooooooh not at all. MSVC does "support" most features but they are full of issues.
MSVC's development seems focused mostly on ticking off boxes, whereas GCC is focused on actually implementing things properly and not releasing things until they actually work. Clang is all but abandoned.
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.
The point is the code they cited is relying on a C++ 23 feature (standard modules) which isn't yet ratified (hence the name C++ 23) and nobody yet completely implements.
If you had standard modules, then the import line at the top of that code does get you all of std, including std::cout and thus the I/O streams.
This example is still silly if you do have C++ 23 though because I/O streams are (say it quietly) basically obsolete in C++ 23 since it has a proper imperative print format feature like any modern language - with decent performance and all the format behaviour you're used to from other modern languages.
I expect that, when C++ 23 becomes a thing lots of people actually use, the canonical "Hello, world" example for it will use std::println()
Yep, that's my pull request. :-) At the moment, it's usable if you build the microsoft/STL repo with VS 2022 17.4 Preview 3 or later. When VS 2022 17.5 Preview 1 ships (in the very near future; can't say when exactly), it will be "in box" without the need to build our GitHub repo.
It will still be necessary to build the std.ixx source file (to produce std.ifc and std.obj for consumption; we will never ship prebuilt IFCs/OBJs for the standard modules). It takes maybe 3-5 seconds and doesn't need to be rebuilt until you change your compiler options or upgrade your toolset. Build system support for doing this automatically is a work in progress.
Although we have test coverage running that exercises every header of the Standard Library through `import std;`, we're still working on fixing various compiler bugs, especially in complicated scenarios (e.g. using Ranges through modules). My hope is that the experience will be solid by the time that VS 2022 17.5 is released for production.
Other compilers support modules in varying ways as well, but there's no universal module "std" yet.
Clang also requires some more command line flags to build modules it seems and g++ needs a command line flag to enable module support as well.
Microsoft's compiler seems to have the best language support in many areas, but seems to fail in others (notably the "core language features"). Then again, the standard isn't finished yet.
If I were to write a program in modern C++ I'd go for the Microsoft compiler. The open source and free implementations are clearly not capable of keeping up with a commercial software powerhouse when it comes to a complicated language like C++.
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.
A return statement in main has the effect of leaving the main function (destroying any objects with automatic storage duration) and calling std::exit with the return value as the argument. If control reaches the end of main without encountering a return statement, the effect is that of executing
On Linux/Unix you will get in a (somewhat) random exit value, so if you run the program from a "set -e" script it will randomly fail. I guess that didn't bother whoever "allowed" that, but I consider it a bug.
It shouldn't in C++. Omitting an explicit return (or falling through to the end without hitting another return) should have the same result as if you ended it with `return 0`. If it's returning a random value then that is erroneous behavior. I've also never witnessed this and print non-zero exit codes in my command line prompt (so after execution my prompt looks like `blahblah(EXIT_CODE) $`).
And I just looked it up for C. Since C99, if the return type of `main` is `int` and there is no explicit return (or again you fall through to the end without hitting one) there's an implicit `return 0`. Before C99, undefined.
