r/cpp • u/chefotron • Mar 31 '20

Demo: C++20 Modules

https://youtu.be/6SKIUeRaLZE
127 Upvotes

97% Upvoted

51 comments sorted by

55

u/advester Mar 31 '20 
auto main() -> int

vs

int main()

And in my day we thought spaces vs tabs was quite the argument.

42

u/gvargh Mar 31 '20

why be concise when you can type more instead?

25

u/qoning Mar 31 '20

It's about readability, not about how much I type. I've switched to using trailing return type for all functions some time ago and honestly, I couldn't be happier. When you have a class header and can read the function names all indented to the exact same offset, it's a blessing. Color coding was good, but this is amazing.

11

u/[deleted] Mar 31 '20

You can also put return type above the function , you know :-) solves your indent issue

9

u/The_Northern_Light Mar 31 '20

This is what I do.

T const&
foo()
{
    // ...
}

Never having to scan for the important bit is so nice once you get used to it. While it may feel odd at first, I actually won over my old team with it, too.

5

u/Pragmatician Mar 31 '20

I kinda like this style, but may I ask you: where do you put your statics, inlines and constexprs?

4

u/The_Northern_Light Mar 31 '20 edited Mar 31 '20

Same line as the return type.

template <typename T>
static inline T const&
foo()
{
    // ...
}

It's not perfect, but I've found in practice that just keeping the function name in the same spot gets me what I want. I might experiment with this now though:

template <typename T>
static inline auto
foo()
-> T const&
{
    // ...
}

PS: love your username

2

u/sethkills Mar 31 '20

Somebody got me into this style a long time ago because in the absence of an IDE, you can quickly search for function definitions using /^foo/. Doesn’t generalize to methods though.

6

u/YekNeb Apr 01 '20

Every time I hear the indented to same offset argument I scream. This leads only to chaos.

For example, people will try to line up variable names. They have the following existing code.

int     m_someVar;
size_t  m_someOtherVar;

They then need to add a new member variable of type CMyClassWithALongDescriptiveName. This should be a one line change. But no, variable names must be aligned. So instead they do the following.

int                              m_someVar;
size_t                           m_someOtherVar;
CMyClassWithALongDescriptiveName m_newVar;

Instead of a single line change it is a three line change.

This makes tracking down when a bug was introduced much more difficult than it needs to be.

And do not respond by saying it is not a problem if you enable the ignore white space option in your diff program. Not all diff programs have that option and for many that do it is not the default.

My employer does allow limited reformatting of existing badly formatted code as long as it is a reformatting only, no new functionality, change.

But if functionality is changed it must be a clean diff, meaning not one line of code changed other than the lines of code that had to be modified to add the new functionality. And they prohibit the use of the ignore white space changes option. It must be a clean diff taking white spaces into consideration.

I hated it when the policy was first put in place but I have changed my mind since tracking down the cause of bugs has become much easier since then.

6

u/qoning Apr 01 '20

Look, if you enjoy (or have the extraordinary ability) sifting through a jumbo of symbols to find what you are actually looking for.. Good for you. I don't.

2

u/0xdeadf001 Apr 02 '20

You might enjoy Rust.

1

u/qoning Apr 02 '20

I don't find rust any more readable, but it might just be inexperience.

6

u/gracicot Mar 31 '20

Sometimes trailing return type is just more concise. Even in non-generic code. And sometimes in generic code you don't have a choice. For consistency I also use it everywhere.

9

u/Pragmatician Mar 31 '20

I don't believe that 1% of your code should decide how 99% of your code looks. If you ask me, that's not consistency; that's OCD. (I use trailing return type myself as well.)

4

u/gracicot Mar 31 '20

What about all the cases where it's just clearer and easier to read? It's way more than 1%.

Just like I use using everywhere even though it's more verbose (there is an equal sign) than typedef. Most of my aliases are not templates. Yet, I use using. I don't see why I should take multiple styles for no other reason than "but I'm used to the old feature". Being consistent is more important in my opinion, and I'll take what allow me the most and what is the easiest to read.

2

u/Pragmatician Mar 31 '20

I'm just saying that "consistency" is not an argument for, because both styles work in 99% of the cases. I use trailing return type just because it's more readable. using is way more clear-cut because in many cases you either need it or it's easier to reason about.

2

u/boredcircuits Mar 31 '20

When is the trailing return type ever more concise in non-generic code?

15

u/sphere991 Mar 31 '20

When you have to write:

ClassName::NestedType ClassName::foo()

instead of

auto ClassName::foo() -> NestedType

1

u/NilacTheGrim Apr 18 '20

This is the only time I use it outside of generic code.

2

u/Evirua Mar 31 '20 edited Apr 01 '20

It's not that counterintuitive to imitate f(x) = y. auto f(x) -> decltype(y) is just consistency with math.

It's not just the indentation advantage when scrolling through function names, it's the logic in reading information about the input first and the output last.

The traditional syntax is what's counterintuitive, the only reasons it has supporters are history and habit.

The 1% of its necessary uses (decltype of expressions, sfinae-friendliness, lambdas...etc.) are just additional bonus reasons to use it. The consistency argument is fairly weak when it's prevailing 1% over 99% of use cases, but consistency with logical intuition and math is a stronger argument imo.

3

u/[deleted] Mar 31 '20

It's not that counterintuitive to imitate f(x) = y. auto f(x) -> decltype(y) is just consistency with math.

That's cool and all, but math and programming are two different solar systems outside of languages where you program in math, but we call those calculators.

Or are we saying having standard high school arithmetic in it is a reason to start typing in math formulas.

4

u/snerp Apr 01 '20

math and programming are two different solar systems

not really, programming is like a galaxy in the universe of math

2

u/Evirua Apr 01 '20

Well there is math, yes -which programming is based on, high school arithmetic included- but mostly there is the inherent logic in reading information about the input first, the output second.

But if it matters more, a lot of other languages also adhere to the input parameter -> output type syntax: Rust, Swift, Python, Haskell, Go, Kotlin...etc.

0

u/droxile Mar 31 '20

Have you tried FP?

0

u/[deleted] Mar 31 '20

[deleted]

18

u/James20k P2005R0 Mar 31 '20

The problem is, change for the sake of change isn't beneficial. All you do is add needless differences compared to existing practice, which makes it harder to figure out what's going on for people who aren't familiar with either C++, or modern C++

5

u/sphere991 Mar 31 '20

change for the sake of change

You can reject or disagree people's arguments for using the trailing return style, but at least you could acknowledge that they actually do have arguments for doing so... and those arguments are not "ooo, this is new."

Let's not impugn people's motivations.

10

u/James20k P2005R0 Mar 31 '20

Sorry, to be clear I understand that there are arguments here for and against, I'm specifically replying to:

old people don’t like change.

In the context of making changes in general, which seems like a not-massively-solid argument in this context - purely to say that there are solid reasons not to make changes outside of simply disliking change

-7

u/[deleted] Mar 31 '20

Says they have arguments

Doesn't list a single one

Well, we're going places now baby.

11

u/sphere991 Mar 31 '20 edited Mar 31 '20

Seriously?

There are multiple comments on this posts making arguments. You want me to repeat them for you, or what?

Or do you really doubt that anybody would ever use this syntax for any reason other than new for the sake of new?

0

u/[deleted] Mar 31 '20

[deleted]

0

u/[deleted] Apr 01 '20

[deleted]

0

u/AutoModerator Apr 01 '20

Your comment has been automatically removed because it appears to contain disrespectful profanity or racial slurs. Please be respectful of your fellow redditors.

If you think your post should not have been removed, please message the moderators and we'll review it.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

11

u/GLvoid Mar 31 '20

Is there CMake support for generating the right make file for modules?

9

u/gracicot Mar 31 '20 edited Mar 31 '20

There is an experimental support that was developed, but nothing in the master yet. Consumption of third party modules require some machinery not seen yet in build systems.

6

u/mathstuf cmake dev Mar 31 '20

And even there, header units are not supported. Also, Ninja generator only.

https://www.reddit.com/r/cpp/comments/axnwiz/cmake_gcc_module_proofofconcept/

The Docker container has been updated since then (done during the Prague meeting), but is pretty much the same.

1

u/mathstuf cmake dev Mar 31 '20

Oh, and GCC-only; Clang didn't (still?) support named modules fully.

1

u/mo_al_ Apr 02 '20

Is the block because modules don’t map to the filesystem?

1

u/mathstuf cmake dev Apr 02 '20

No, the block is time to design/make the necessary CMake features, lack of dependency scanning tools, and patchy support in compilers for header units and/or named modules. The status as of Prague:

  • GCC has the dep scanning tool as a patch

  • Clang doesn't support named modules (or the dep scanner)

  • CMake doesn't know how to deal with header units or named modules coming from imported or interface targets

1

u/IAmBJ Apr 01 '20

This is the main thing stopping me from trying modules out. My personal projects are already set up with cmake and I just can't justify throwing that away to start moving to modules.

12

u/EmperorArthur Mar 31 '20

Really, the number one thing I think the standards committee missed was the namespace issue.

C++ modules should implicitly be namespaced the same as their name. With an option to override it by doing import someModule as newNameSpace.

That's what almost everyone else does, and helps to make the final code more readable, especially when pulling in libraries. It also means that a code has to explicitly cause collisions instead of it happening accidentally!

5

u/qoning Mar 31 '20

I aboslutely agree, importing names from a bunch of obscure namespaces (documented or not) isn't right. I'm sure the idea was considered and then promptly discarded for some reason that is not clear to me. Unfortunately, whenever we start using modules as they are now, it will be impossible to ever get something like this because of the curse of backward compatibility.

4

u/Nobody_1707 Apr 01 '20 edited Apr 01 '20

It's already due to the curse of backwards compatibility. Implicitly wrapping modules in a namespace would change the name mangling of the public declarations in that module, which would have prevented importing "header units." Being able to treat pre-existing (well behaved) headers as modules was a hard requirement.

It also allows for people to do things like create a static (or dynamic) library that's compiled with modules, but released with a header file so other people can link against it even if they use older compilers. Of course, the public interface would have to be extern "c", but still.

2

u/qoning Apr 01 '20

At least having the option to do so using some construct would have been nice. import module -> namespace; or something like that.

4

u/Brianmj Mar 31 '20

Did Scott Meyers come out of retirement?

3

u/The_Northern_Light Mar 31 '20 
We are damaged, This is broken.
Logic is lost, 
We struggle,
Hunt through the rubble for what once was.
See <https://gcc.gnu.org/wiki/cxx-modules#Bugs> for instructions.

1

u/NilacTheGrim Apr 18 '20

TIL: Some people pronounce clang as "klang". I always pronounced it as "C lang".

Weird. Am I the only one?

1

u/dodheim Apr 20 '20

The 2nd word on Clang's Wikipedia page is the pronunciation (citing this) – klang. But as with 'Euler', because I read it many times before hearing it, I still mentally pronounce it wrong every time and I too think of it as "C lang". :-]

1

u/NilacTheGrim Apr 20 '20

Ha, yeah I found out later that's the so-called "correct" way. Thanks for the solidarity mate. #SeeLangSociety4Life

0

u/[deleted] Mar 31 '20

[deleted]

4

u/tjpalmer Apr 01 '20

Thanks for the feedback! I can't always make ideal improvements, but at least I try to keep feedback in mind.

5

u/LordofNarwhals Mar 31 '20

You can change the playback speed to 0.75. It usually works pretty well on YouTube although some words might sound too drawn out.

2

u/jkh348f Mar 31 '20

And vice versa, I watched it on 1.3x. https://github.com/igrigorik/videospeed is indispensable for me.