C++23

[Cubbi]

protoseepp wrote:

Should I hold off

no, I don't think it's ever a good idea to hold off: doing something is better than doing nothing. Besides, good up-to-date books will mention up-and-coming stuff, like Bjarne's Tour of C++ always does - he's working on a 3rd edition right now that is about C++20 with what's in store for C++23.

George P wrote:

even the guys who write the books have to learn the new features as they are introduced before they can show others.

(most of) the guys who write the books aren't programmers or language/library designers; they don't use the language except to come up with examples for the books. In a way, Stroustrup's books show where the language is coming from, and Josuttis (and Meyers before) show where it can take you if you aren't careful.

[deleted account xyzzy]

And seeing examples of where one should fear to tread is bad, how?

Even here I see different ways to do the same task, by multiple posters. Diversity of code isn't wrong. Lots of learning to be had.

Having some code blow up in one's face because very human errors were made is a great teaching moment. If someone is willing to learn from the mistakes.

I know I make more than my fair share all the time, because.....

YMMV.

[seeplus]

A downside with ebooks (and self-published books on say Amazon) is that you really are trusting the author. You don't know what QA/editorial process the book has been through before publication (if any). Also just because the biography of the author says they have done this that and the other etc etc this is no guarantee that they are good writers as opposed to good coders. The required skill-set is different. This also applies to books published by Packt IMO as IMO some are much better quality than others. They aren't consistent in quality IMO. They just seem to churn them out...

On leanpub I would trust books by Grimm, Filipek (Bartek) and Josuttis. Also books by Horton, Deitel, Meyers (although out of date), Sutter (also very out of date) and Stroustrup. Books published by Addison Wesley are also usually good. The same with Apress publisher.

The advantage, of course, with leanpub is that books are often published at a discounted price before they have been fully completed. More complete versions are then published over time (hopefully!). Also it's much easier for the authors to produce corrected versions if there are errors found - rather than for a printed book to have a web site with 'corrections' posted.

[deleted account xyzzy]

To a large degree, obviously, the point of writing a book is to make money. Duh!

As seeplus points out there are authors who are generally trust-worthy since they've produced quality before. Just as there are trusty publishers.

There are also more than enough authors and books and publishers not worth the time and effort to get a hacked PDF for free. Clearly the people involved were only looking at a big pay-day.

One newish C++ book (2019) that came up recently in discussion with someone asking questions about the book's code revealed out of 21 chapters the first 15 chapters of code were using C I/O exclusively! *OUCH!*

It didn't help the book was geared towards experienced C programmers wanting to learn C++, not beginners who have yet to learn any programming language.

[Cubbi]

George P wrote:

seeing examples of where one should fear to tread is bad, how?

It can be good when it's about making intentional good engineering choices (EffC++ "Declare data members private"), but as the author needs to keep writing some get trapped in inventing increasingly contrived issues to have something to write about (EffMC++ "Use decltype on auto&& parameters to std::forward them."). At least Meyers had the integrity to recognize the trap and retire.

[CodeChaser]

@seeplus
I am using latest VS, thanks for info.

@George P
Thanks. I have been eyeing "Beginning C++20" as well and it is tied in with the Sam's book. I really need physical too as it is great to get away from the PC and spread out on the couch with a good book. I have the Sam's C14/17 version and it is great. It explains things for a beginner and that is exactly what I need. Great reviews on Amazon too! Gripes are that sometimes Siddhartha Rao just uses things without fully explaining or explaining with more detail, but thankfully you guys helped me out with them. Such as the :: scope resolution operator.

I think I will be getting both ("Beginning C++20"), because it is good to see a different perspective.
Is there any site that you can get a good deal for all 3 digital and the physical? This site here has the Sam's ALL for $54, but no "Beginning C++20"?

https://www.informit.com/store/sams-teach-yourself-c-plus-plus-in-one-hour-a-day-9780137334681

Also, how many C++ books have you guys read? Do you try to read at least 1-3 a year? I also notice that many of you are always on cplusplus, seems like you eat/sleep/drink C++? Seems advantageous to always read up and refresh concepts as it solidifies your understanding. You guys are inspiring and I think I would like to do the same.

[seeplus]

I see different ways to do the same task, by multiple posters

'Ask 6 C++ programmers and you'll get at least 9 solutions...'

[seeplus]

how many C++ books have you guys read

I currently have over 60 printed and e C++ books - some dating back to pre ++98! I've held off buying some C++20 updated books from C++17 as I'm waiting for the C++23 versions. I've also got a stack of Windows programming books and several old c programming books.

Once you have a good grounding in C++ then I'd suggest
Professional C++ (5th Edition which covers C++20) by Marc Gregoire
https://www.amazon.co.uk/Professional-C-Marc-Gregoire/dp/1119695406/ref=sr_1_3

Not that this is NOT an intro guide.

Personally, I prefer a printed book to an e-book. Probably because of age...

[seeplus]

For a summary re the current status of C++23, see:
https://github.com/steve-downey/papers/blob/master/wg21-status.org

[deleted account xyzzy]

"Beginning C++20" is published by Apress.

https://www.apress.com/us
https://link.springer.com/book/10.1007/978-1-4842-5884-2

There is no print/eBook bundle, sadly, even on Amazon.

I purchased the print from Amazon after searching in vain for a nice bundle price. https://www.amazon.com/gp/product/1484258835/

There are "free" PDF versions of the book available online, a bit of scraping the bowels of the interwebz is required.

Re: Amazon's kindle version....available to rent?!? YOW!!

The Apress eBook version is PDF, the Amazon is in Kindle format which restricts it to Amazon devices.

I'd suggest getting the print version through Amazon since it is currently discounted, the Apress site is full price.

FYI, there is an additional PDF available online, Appendix A, not included in the book that delves into the nitty-gritty of "Preprocessing, ODR, Linkage, and Header Files."

The source code in the book is available online as well, a lot of the examples in the book are not "in one piece".

Should you purchase the book get the additional PDF and the source code. :)

I can tell you there are a couple of "book-keeping" details you need to remember when working with modules and VS. There are interface files and there are internal partition files. Internal partition files have to manually set in the IDE properties for the file to not throw up a bunch of errors. The "Beginning C++20" book doesn't mention that.

[seeplus]

No book is perfect...

[deleted account xyzzy]

Yeah, I know. To err is human, to really make a mess of things write a book. It'll last "forever."

All the problems of getting the examples from "Beginning C++20" to work was a very painful yet very helpful learning experience.

Should I ever forget to manually change an internal partition file's "compile as" property I know I'm being lazy. VS will thump me upside the noggin. :Þ

VS 2019 requires more book-keeping mucking around to work with modules compared to VS 2022. I shan't go into the details of the differences. All I will say is, "Yuckers."

[seeplus]

VS2019 is so yesterday...

[deleted account xyzzy]

I have VS 2019 side installed with VS 2022 currently. I am thinking I should probably uninstall it since I never actually use 2019 any more.

Think MS will be releasing a newer VS version for C++23? Shoe-horning support into VS 2022 as they did with C++20 support in VS 2019?

[seeplus]

Attempting to write a book is not something I'd even think of doing in my wildest nightmare. For those that do, even if they don't get it right, I have admiration for the attempt.

Back in the 90's, when I was involved with the Pick OS development/deployment, I wrote some articles regarding Pick Assembler - but writing an article is quite different from writing a book.

[seeplus]

Think MS will be releasing a newer VS version for C++23? Shoe-horning support into VS 2022 as they did with C++20 support in VS 2019?

I don't think so. I think VS2022 will have full C++23 support (although my crystal ball has been known to have spells of being unreliable). I guess the next version of VS will be VS2024/2025. C++23 is now feature-complete and is in it's final stages of being formally approved and probably will be by the end of the year/early next.

However DR 'features' to C++23 may only be implemented in the next VS version...

[seeplus]

I have VS 2019 side installed with VS 2022 currently

Yes so do I - along with VS2022 preview which I mainly use as there's currently issues with VS2022 and Windows 7 which have been fixed in the current preview.

[deleted account xyzzy]

According to an authors' note in the book's introduction at the time "Beginning C++20" was written and went to press no compiler fully supported C++20. Not even VS.

So I'm not surprised how to properly use modules wasn't covered in the book.

From what I've read about using modules from MS sources when module support was still a "work in progress" makes me think theory and actual practice went off in different directions. The differences of usage between VS 2019 and 2022 point that out.

[Peter87]

What do you guys think about the new assume attribute ...

See the proposal "Portable assumptions" for more information.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1774r8.pdf

... and the std::unreachable function?

https://en.cppreference.com/w/cpp/utility/unreachable

Examples:

int divide_by_two(int x)
{
	[[assume(x >= 0)]];
	return x / 2;
}

void print_die(int n)
{
	switch (n)
	{
	case 1:
		std::cout << "   \n";
		std::cout << " o \n";
		std::cout << "   \n";
		break;
	case 2:
		std::cout << "  o\n";
		std::cout << "   \n";
		std::cout << "o  \n";
		break;
	case 3:
		std::cout << "  o\n";
		std::cout << " o \n";
		std::cout << "o  \n";
		break;
	case 4:
		std::cout << "o o\n";
		std::cout << "   \n";
		std::cout << "o o\n";
		break;
	case 5:
		std::cout << "o o\n";
		std::cout << " o \n";
		std::cout << "o o\n";
		break;
	case 6:
		std::cout << "o o\n";
		std::cout << "o o\n";
		std::cout << "o o\n";
		break;
	default:
		std::unreachable();
	}
}

The compiler might be able to take advantage of this to generate more efficient code, but it also means it would be UB if the assumption is false or if std::unreachable() is called.

When the "contracts" feature was being proposed a few years ago I think this was one of the things many people hoped to get out of it. It now seems like if we ever get contracts it will be without the UB, but at least for the asserts it will now be relatively easy to hack something together that works similar to the old proposal.

#ifdef ASSUMED_ASSERTS
#define ASSERT(expr) [[assume(expr)]]
#elifdef CHECKED_ASSERTS
#define ASSERT(expr) assert(expr)
#else
#define ASSERT(expr)
#endif 

So is this a useful addition that will allow "experts" to write more efficient code or will this be misused a lot (and taught to self-taught "students" by self-taught "teachers" on YouTube because it's "cool and makes your program run faster") and become a frequent source of bugs?

[Cubbi]

we use (builtin) unreachable all the time at work, it's great for catching bugs and sometimes I just stick it in here and there to crash intentionally while developing/testing. I suppose better codegen doesn't hurt either.

contracts are a huge topic, and the problem with C++ contracts is mainly that two influential groups of people/companies both want them to be part of C++, but they want opposite things out of them and they failed to compromise in time for C++14. And failed big time for C++17. And barely even tried for C++20.
I do like Timur's assume paper because it's just reconciling existing behavior.