Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ Modules Are Here to Stay

faresbakhit.github.io

Post reply on HN
Print view View original

131–140 of 143 posts

Re: C++ Modules Are Here to Stay

#131

Post by quuxplusone »

kccqzy wrote: post #115
nextaccountic wrote: post #114

Earlier quoted context omitted.

The .h could have been a compiler output, like the .so

The C language is too complicated and too flexible to allow that. If you are starting from scratch and creating a new language, this could be a design goal from the beginning.

> The C language is too complicated and too flexible to allow that.

I disagree. In fact, I would expect the following could be a pretty reasonable exercise in a book like "Software Tools"[1]: "Write a program to extract all the function declarations from a C header file that does not contain any macro-preprocessor directives." This requires writing a full C lexer; a parser for function declarations (but for function and struct bodies you can do simple brace-matching); and nothing else. To make this tool useful in production, you must either write a full C preprocessor, or else use a pipeline to compose your tool with `cpp` or `gcc -E`. Which is the better choice?

However, I do see that the actual "Software Tools" book doesn't get as advanced as lexing/parsing; it goes only as far as the tools we today call `grep` and `sed`.

I certainly agree that doing the same for C++ would require a full-blown compiler, because of context-dependent constructs like `decltype(arbitrary-expression)::x (z)`; but there's nothing like that in K&R-era C, or even in C89.

No, I think the only reason such a declaration-extracting tool wasn't disseminated widely at the time (say, the mid-to-late 1970s) is that the cost-benefit ratio wouldn't have been seen as very rewarding. It would automate only half the task of writing a header file: the other and more difficult half is writing the accompanying code comments, which cannot be automated. Also, programmers of that era might be more likely to start with the header file (the interface and documentation), and proceed to the implementation only afterward.

[1] - K&P's "Software Tools" was originally published in 1976, with exercises in Ratfor. "Software Tools in Pascal" (1981) is here: https://archive.org/details/softwaretoolsinp00kern/

Re: C++ Modules Are Here to Stay

#132

Post by fl0ki »

groby_b wrote: post #28
reactjs_ wrote: post #7

Here’s the thing I don’t get about module partitions: They only seem to allow one level of encapsulation. Program - Module - Module Partition whereas in module systems that support module visibility, like Rust’s, you can decompose your program at multiple abstraction levels: Program - Private Module - Private Module - Private Module - Public Module - Public Module Maybe I am missing something. It seems like you will…

I don't think you're missing something. The standards committee made a bad call with "no submodules", ran into insurmountable problems, and doubled down on the bad call via partitions. "Just one more level bro, I swear. One more". I fully expect to sooner or later see a retcon on why really, two is the right number. Yeah, I'm salty about this. "Submodules encourage dependency messes" is just trying to fix substandard…

Fascinatingly, I am not aware of any real issues with how Rust did nested modules. It even treated crates as top-level modules for most language-level purposes. I am sure there are nuanced reasons that C++ can't do quite the same, but the developer experience consequences can't be worth it.

Re: C++ Modules Are Here to Stay

#133

Post by kccqzy »

quuxplusone wrote: post #131
kccqzy wrote: post #115

Earlier quoted context omitted.

The C language is too complicated and too flexible to allow that. If you are starting from scratch and creating a new language, this could be a design goal from the beginning.

> The C language is too complicated and too flexible to allow that. I disagree. In fact, I would expect the following could be a pretty reasonable exercise in a book like "Software Tools"[1]: "Write a program to extract all the function declarations from a C header file that does not contain any macro-preprocessor directives." This requires writing a full C lexer; a parser for function declarations (but for function…

> Write a program to extract all the function declarations from a C header file that does not contain any macro-preprocessor directives

There you go. You just threw away the most difficult part of the problem: the macros. Even a medium-sized C library can have maybe 500 lines of dense macros with ifdef/endif/define which depends on the platform, the CPU architecture, as well as user-configurable options at ./configure time. Should you evaluate the macro ifdefs or preserve them when you extract the header? It depends on each macro!

And your tool would still be highly incomplete because it only handles function declarations not struct definitions, typedefs you expect the users to use.

> the other and more difficult half is writing the accompanying code comments, which cannot be automated

Again disagree. Newer languages have taught us that it is valuable to have two syntaxes for comments, one intended for implementation and one intended for the interface. It’s more popularly known as docstrings but you can just reuse the comment syntax and differentiate between // and /// comments for example. The hypothetical extractor tool will work no differently from a documentation extractor tool.

Re: C++ Modules Are Here to Stay

#134

Post by Maxatar »

kccqzy wrote: post #133
quuxplusone wrote: post #131

Earlier quoted context omitted.

> The C language is too complicated and too flexible to allow that. I disagree. In fact, I would expect the following could be a pretty reasonable exercise in a book like "Software Tools"[1]: "Write a program to extract all the function declarations from a C header file that does not contain any macro-preprocessor directives." This requires writing a full C lexer; a parser for function declarations (but for function…

> Write a program to extract all the function declarations from a C header file that does not contain any macro-preprocessor directives There you go. You just threw away the most difficult part of the problem: the macros. Even a medium-sized C library can have maybe 500 lines of dense macros with ifdef/endif/define which depends on the platform, the CPU architecture, as well as user-configurable options at ./configur…

I interpreted OP's post to say that you take a C file after the preprocessor has translated it. How you perform that preprocessing can simply be by passing the file to an existing C preprocessor, or you can implement it as well.

Implementing a C preprocessor is tedious work, but it's nothing remotely complex in terms of challenging data structures, algorithms, or requiring sophisticated architecture. It's basically just ensuring your preprocessor implements all of the rules, each of which is pretty simple.

Re: C++ Modules Are Here to Stay

#135

Post by maccard »

yunnpp wrote: post #77
maccard wrote: post #44

Earlier quoted context omitted.

What about auto g() -> auto { return 0.0; }

0.0 is a double, so I would assume the return type of g is deduced to be double, if that is what you're asking.

I was more pointing out that the syntax was dumb for that particular example!

Re: C++ Modules Are Here to Stay

#136

Post by kccqzy »

Maxatar wrote: post #134
kccqzy wrote: post #133

Earlier quoted context omitted.

> Write a program to extract all the function declarations from a C header file that does not contain any macro-preprocessor directives There you go. You just threw away the most difficult part of the problem: the macros. Even a medium-sized C library can have maybe 500 lines of dense macros with ifdef/endif/define which depends on the platform, the CPU architecture, as well as user-configurable options at ./configur…

I interpreted OP's post to say that you take a C file after the preprocessor has translated it. How you perform that preprocessing can simply be by passing the file to an existing C preprocessor, or you can implement it as well. Implementing a C preprocessor is tedious work, but it's nothing remotely complex in terms of challenging data structures, algorithms, or requiring sophisticated architecture. It's basically j…

And you had the same misunderstanding as OP. Because you have eliminated all macros during the preprocessor step, you can no longer have macro-based APIs, including function-like macros you expect library users to use, #ifdef blocks where you expect user code to either #define or #undef, and a primitive form of maintaining API compatibility but not ABI compatibility for many things.

It’s a cute learning project for a student of computer science for sure. It’s not remotely a useful software engineering tool.

Re: C++ Modules Are Here to Stay

#137

Post by amluto »

bluGill wrote: post #125
amluto wrote: post #62

Earlier quoted context omitted.

Even some much simpler things are extremely half baked. For example, here’s one I encountered recently: alignas(16) char buf[128]; What type is buf? What alignment does that type have? What alignment does buf have? Does the standard even say that alignof(buf) is a valid expression? The answers barely make sense. Given that this is the recommended replacement for aligned_storage, it’s kind of embarrassing that it work…

The only people who write code like that have plenty of time to understand those questions - and why the correct answer is what it is is critically important to that line of code working correctly. The vast majority of us would never write a line like that - we let the compiler care about those details. the vast majority of the time 'just use vector' is the right answer that has zero real world exceptions. but in the…

> and why the correct answer is what it is is critically important to that line of code working correctly.

> but in the rare case you need code like that be glad C++ has you covered

I strongly disagree. alignof(buf) works correctly but is a GCC extension. alignof(decltype(buf)) is 1, because alignas is a giant kludge instead of a reasonable feature. C++ only barely has me covered here.

Re: C++ Modules Are Here to Stay

#138

Post by nextaccountic »

AnimalMuppet wrote: post #130
nextaccountic wrote: post #114

Earlier quoted context omitted.

The .h could have been a compiler output, like the .so

Not for things like public/private, static, virtual. Not for inheritance, either.

You add all those things in a single .c or .cpp source, without manual authoring of .h files (this may require language changes, maybe in C30 and C++30 or something)

Then whatever is relevant to the public interface gets generated by the compiler and put in a .h file. This file is not put in the same directory of the .c file to not encourage people to put the .h file in version control.

Re: C++ Modules Are Here to Stay

#139

Post by maccard »

zabzonk wrote: post #64
maccard wrote: post #43

Earlier quoted context omitted.

I really wish they had used func instead, it would have saved this confusion and allowed for “auto type deduction” to be a smaller more self contained feature

the standard c++ committee is extremely resistant to introducing new keywords such as "func", so as not to break reams of existing code.

Indeed. I am a frequent critic of the c++ committee’s direction and decisions. There’s no direction other than “new stuff” and that new stuff pretty much has to be in the library otherwise it will require changes that may break existing code. That’s fine.

But on the flip side, there’s a theme of ignoring the actual state of the world to achieve the theoretical goals of the proposal when it suits. Modules are a perfect example of this - when I started programming professionally modules were the solution to compile times and to symbol visibility. Now that they’re here they are neither. But we got modules on part. The version that was standardised refused to accept the existence of the toolchain and build tools that exist, and as such refused to place any constraints that may make implementation viable or easier.

St the same time we can’t standardise Pragma once because some compiler may treat network shares or symlinks differently.

There’s a clear indication that the committee don’t want to address this, epochs are a solution that has been rejected. It’s clear the only real plan is shove awkward functional features into libraries using operator overloads - just like we all gave out to QT for doing 30 years ago. But at least it’s standardised this time?

Re: C++ Modules Are Here to Stay

#140

Post by quuxplusone »

kccqzy wrote: post #136
Maxatar wrote: post #134

Earlier quoted context omitted.

I interpreted OP's post to say that you take a C file after the preprocessor has translated it. How you perform that preprocessing can simply be by passing the file to an existing C preprocessor, or you can implement it as well. Implementing a C preprocessor is tedious work, but it's nothing remotely complex in terms of challenging data structures, algorithms, or requiring sophisticated architecture. It's basically j…

And you had the same misunderstanding as OP. Because you have eliminated all macros during the preprocessor step, you can no longer have macro-based APIs, including function-like macros you expect library users to use, #ifdef blocks where you expect user code to either #define or #undef, and a primitive form of maintaining API compatibility but not ABI compatibility for many things. It’s a cute learning project for a…

Our points of view are probably not too far off, really. Remember this whole thought-experiment is counterfactual: we're imagining what "automatic extraction of function declarations from a .c file" would have looked like in the K&R era, in response to claims (from 50 years later) that "No sane programming language should require a duplication in order to export something" and "The .h could have been a compiler output." So we're both having to imagine the motivations and design requirements of a hypothetical programmer from the 1970s or 1980s.

I agree that the tool I sketched wouldn't let your .h file contain macros, nor C99 inline functions, nor is it clear how it would distinguish between structs whose definition must be "exported" (like sockaddr_t) and structs where a declaration suffices (like FILE). But:

- Does our hypothetical programmer care about those limitations? Maybe he doesn't write libraries that depend on exporting macros. He (counterfactually) wants this tool; maybe that indicates that his preferences and priorities are different from his contemporaries'.

- C++20 Modules also do not let you export macros. The "toy" tool we can build with 1970s technology happens to be the same in this respect as the C++20 tool we're emulating! A modern programmer might indeed say "That's not a useful software engineering tool, because macros" — but I presume they'd say the exact same thing about C++20 Modules. (And I wouldn't even disagree! I'm just saying that that particular objection does not distinguish this hypothetical 1970s .h-file-generator from the modern C++20 Modules facility.)

[EDIT: Or to put it better, maybe: Someone-not-you might say, "I love Modules! Why couldn't we have had it in the 1970s, by auto-generating .h files?" And my answer is, we could have. (Yes it couldn't have handled macros, but then neither can C++20 Modules.) So why didn't we get it in the 1970s? Not because it would have been physically difficult at all, but rather — I speculate — because for cultural reasons it wasn't wanted.]

Post reply on HN