Back to Basics: const and constexpr - Rainer Grimm - CppCon 2021

[@isayurdagul]

Is there a slip of tounge or did I misunderstand what is meant to be said at 19:30 . Should it be "The more variables are const, easier to reason about concurrent program"?

[@superscatboy]

Fantastic explanation of a subtle but fundamental set of tools.

[@LiveseyMD]

It would be really great to add time codes to the description.

[@MaxCoplan]

Great talk! I wish the chat could be shown on screen for the Q&A portion

[@fppt1555]

Thanks for the talk! Extremely helpful.

[@ChrisOffner]

Unfortunately I still don't understand the meaning of "logical constness: The object is const but could be changed." Yes, there was an example about avoiding a compilation error when using *mutable* for a mutex, but it didn't really clarify much for me conceptually.

[@darranrowe174]

One thing that these kinds of talks don't do that well is explain why you would want something like that. As an example, suppose you have a read only view into a database, you want to iterate though a database containing data on cats and their preferred treats as an example. Since it is data stored into an external service, you would have to read it first, and it may be unfeasible or even impossible to read all of the data at once if the database is large. In this case, it would be possible to cache a few entries, iterate through those and then cache more entries. The caching of the data would end up modifying any data that you are working with, but your view of that data would be technically read only.

[@MagnificentImbecil]

Physical constness: A non-static member function marked as const is not allowed (in the absence of const_cast and C-style cast and mutable) to modify the kernel-block of the object (e.g. a pointer-to-non-const), but it could modify an extension-block (e.g. the pointee). Logical constness: For a container or a Pimpl-wrapper, we might want to programatically consider both the kernel-block (the pointers) and the extension-blocks (the pointees) as logical parts of the object. And even if the compiler allows us to modify the pointees from a const member function, we should restrain from doing so. And from a const member function, we should not return pointer-to-non-const (even if the compiler allows us), but pointer-to-const instead. Please consider std::vector . It has two versions of the begin member function: one which is non-const and returns pointer/iterator-to-non-const and one which is const and returns pointer/iterator-to-const. The latter could have returned pointer/iterator-to-non-const without any cast -- it would have been allowed by the compiler, because the compiler only enforces physical constness. But the programmer wanted to enforce logical constness (i.e. constness not just of the kernel of the vector, but of the T elements too), which in this case goes beyond physical constness.

[@ejyjawa352]

Where are the slides ?! Thanks !

[@sky_is_the_limit_13]

Great talk! Thanks for sharing! I wish subtitles was enabled.

[@m1t0z]

Nice talk! Thanks for structuring different types of "const" both from historical and functional perspectives. Look forward to use constinit to solve issues with initialization order of the variables with ssd in our codebase (currently we are relaying on the linker order but are not really happy with that approach). P. S. In case you need some constructive feedback I would suggest to add an additional explicit section to your presentation where to highlight the guidelines where, when and why to use which type of "const".

[@bogdansikach7709]

To read the type correctly (const char* const ptr, etc) use the "spiral rule" - not just "right to left".

[@ns1198]

what is the spiral rule? Any reference pls?

[@x87-64]

@@ns1198 Google "Clockwise/Spiral Rule in C". It is a very classic way to read convoluted C declarations.

[@paxdei1988]

Or just write it as char const* const ptr. Now you can read it right to left without spirals.

[@discreet_boson]

This was a great refresher, thanks!

[@sadiqueali930]

Fantastic Presentaion

[@CppCon]

Many thanks

[@sanjaygatne1424]

small font size makes good information hard to understand. please give attention to font size its hard to read code on video.

[@saipan1970]

Such a wonderful content, could not enjoy just because of small fonts.Sir,please consider also the mobile viewers, I sincerely follows your 📖 and articles on C++.

[@ChrisOffner]

Even on my 16" notebook display I found the code examples hard to read. Any presenter should know to use large font sizes in their presentations.

[@bsdooby]

What about east const vs. const west?

[@badassopenpolling]

One thing is missing regarding consteval - Why should we use consteval ? Motivation advantages ?

[@rutabega306]

Prevent accidental runtime calculations

[@Heyothatsittahowski]

This is interesting @33:37

[@OlliS71]

Of course const objects can be victim of data races if there are mutable members.

[@Moriadin]

The shared screen is awfully blurry :(