2 ms·

> cpp -I. src/foo.cc | grep '^# ' | sed 's/^[^"]"//;s/"[^"]$//' | sort | uniq | grep -v \< So how would you change that incantation to accommodate C++ with mod

> cpp -I. src/foo.cc | grep '^# ' | sed 's/^[^"]"//;s/"[^"]$//' | sort | uniq | grep -v \< So how would you change that incantation to accommodate C++ with modules? Edited to add: Okay, you did say "I'm not going to try to design the best way to do the equivalent for C++ modules here in a HN comment", but then all you've shown is that it's easy to implement for C++ without modules.

knorker 5y ago
What I meant with that oneliner was to show that you don't even need compiler integration. A much simpler tool (in this case the preprocessor) could extract just the needed parts without parsing the rest. Sure, it's harder to tokenize C++, but once you have the yacc for it it's pretty simple to get a list of provided and needed modules, right? We have pretty advanced tools nowadays even for rewriting source code. The Go standard library has a package for parsing a Go file. You can use that and easily extract the import list and package name definition. I don't see (perhaps due to my ignorance of C++ module details) why this doesn't translate. Yes, Go's compiler is integrated with its build system. But I'm saying that's not a prerequisite. I'm saying extracting the necessary information from a C++ file is quick and easy. What I'm not trying to do is design build system and compiler passes. Am I missing something? Is it inherently not possible to create a tool that will take C++ source code and output its imports and exports, or that it's even hard? (again, aside from writing the YACC correctly, once. But the complexity of C++ is mostly not its tokenization)