3 ms·

The PoC did this: mod foo { #include "..." } Which is barely enough to say that Rust is hugely different than just #include-ing C files. I wa

The PoC did this: mod foo { #include "..." } Which is barely enough to say that Rust is hugely different than just #include-ing C files. I was talking more about linking objects incrementally and the consequences of that design, rather than singing the praises of headers (though I do rather like headers). I understand C from the compiler's perspective as well, having written my own linker and assembler from scratch myself, and I really appreciate the elegance of the design. >slow compilation That's objectively untrue. It's much faster to compile with something like headers. As far as inlining and DRY are concerned, back before Rust shipped I spoke with many Rust maintainers about solutions to all of these problems, but it was dismissed because "we're trying to ship". Maybe you shouldn't sail a boat when you need to replace the hull later?

arielby 11y ago
This is Rust's approach to splitting a crate between files - not for splitting to different isolated separately-compiled modules. I must say it works great for that purpose, being much better than dealing with build tools.
pcwalton 11y ago
> Which is barely enough to say that Rust is hugely different than just #include-ing C files. Well, sure, if you want to get fancy enough you can make a module system out of #include. (Your code snippet isn't enough because it doesn't replicate privacy or imports.) But replicating something approximating Rust's module system with "#include plus other stuff" doesn't show that Rust's module system is "just #include". > That's objectively untrue. It's much faster to compile with something like headers. I don't think that's true once you have the proper incremental build setup. With headers, you have to parse large source files over and over again. With a proper module system, the compiler can use a more efficient binary database format (with an index). For example, consider math.h. If your program is using one function (say, sin) from math.h, you have to parse all the prototypes in math.h. (And if you have inlined functions or templates in the header files, you have to parse those too!) But with a module system, the compiler can serialize an index of all the signatures of functions inside libmath.so, so the compiler can do a direct, O(1) hash table lookup for "sin". We aren't there today, of course, since we don't have incremental compilation, and C is certainly simpler, but I think doing it right from the start will pay dividends down the road. > As far as inlining and DRY are concerned, back before Rust shipped I spoke with many Rust maintainers about solutions to all of these problems, but it was dismissed because "we're trying to ship". Maybe you shouldn't sail a boat when you need to replace the hull later? I don't see anything backwards-incompatible about incremental compilation, and I believe where we're going will end up better than header files when all is said and done.
- shawn-butler 11y ago
  > For example, consider math.h. If your program is using one function (say, sin) from math.h, you have to parse all the prototypes in math.h. (And if you have inlined functions or templates in the header files, you have to parse those too!) Isn't this pretty much a solved problem with precompiled / pre tokenized headers? PTH are language / arch / compiler agnostic. http://clang.llvm.org/docs/PTHInternals.html http://clang.llvm.org/docs/PTHInternals.html
  - pcwalton 11y ago
    Precompiled headers inch C and C++ closer to a module system, by discarding the traditional notion of what a header is: it becomes a sort of binary metadata instead of a textually included file. But why not just start with the right thing in the first place?
  - ufo 11y ago
    Precompiled headers are a big hack. As pcwalton mentioned, the problem was actually solved when people invented real module systems.
    - the_why_of_y 11y ago
      Which, notably, happened decades before the first implementation of the precompiled headers hack.
      - TillE 11y ago
        Yes. Well. And just a few short decades later, modules will most likely make it into C++17.
        steveklabnik 11y ago
        In my understanding, they won't: https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ https://botondballo.wordpress.com/2015/06/05/trip-report-c-s... > Modules making it into C++17 is less likely. However, they do say > That said, from a user’s perspective, I don’t think this is any reason to > despair: the feature is still likely to become available to users in the > 2017 timeframe, even if it’s in the form of a TS.

arielby 11y ago

This is Rust's approach to splitting a crate between files - not for splitting to different isolated separately-compiled modules. I must say it works great for that purpose, being much better than dealing with build tools.

pcwalton 11y ago

> Which is barely enough to say that Rust is hugely different than just #include-ing C files. Well, sure, if you want to get fancy enough you can make a module system out of #include. (Your code snippet isn't enough because it doesn't replicate privacy or imports.) But replicating something approximating Rust's module system with "#include plus other stuff" doesn't show that Rust's module system is "just #include". > That's objectively untrue. It's much faster to compile with something like headers. I don't think that's true once you have the proper incremental build setup. With headers, you have to parse large source files over and over again. With a proper module system, the compiler can use a more efficient binary database format (with an index). For example, consider math.h. If your program is using one function (say, sin) from math.h, you have to parse all the prototypes in math.h. (And if you have inlined functions or templates in the header files, you have to parse those too!) But with a module system, the compiler can serialize an index of all the signatures of functions inside libmath.so, so the compiler can do a direct, O(1) hash table lookup for "sin". We aren't there today, of course, since we don't have incremental compilation, and C is certainly simpler, but I think doing it right from the start will pay dividends down the road. > As far as inlining and DRY are concerned, back before Rust shipped I spoke with many Rust maintainers about solutions to all of these problems, but it was dismissed because "we're trying to ship". Maybe you shouldn't sail a boat when you need to replace the hull later? I don't see anything backwards-incompatible about incremental compilation, and I believe where we're going will end up better than header files when all is said and done.

shawn-butler 11y ago
> For example, consider math.h. If your program is using one function (say, sin) from math.h, you have to parse all the prototypes in math.h. (And if you have inlined functions or templates in the header files, you have to parse those too!) Isn't this pretty much a solved problem with precompiled / pre tokenized headers? PTH are language / arch / compiler agnostic. http://clang.llvm.org/docs/PTHInternals.html http://clang.llvm.org/docs/PTHInternals.html
- pcwalton 11y ago
  Precompiled headers inch C and C++ closer to a module system, by discarding the traditional notion of what a header is: it becomes a sort of binary metadata instead of a textually included file. But why not just start with the right thing in the first place?
- ufo 11y ago
  Precompiled headers are a big hack. As pcwalton mentioned, the problem was actually solved when people invented real module systems.
  - the_why_of_y 11y ago
    Which, notably, happened decades before the first implementation of the precompiled headers hack.
    - TillE 11y ago
      Yes. Well. And just a few short decades later, modules will most likely make it into C++17.
      - steveklabnik 11y ago
        In my understanding, they won't: https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ https://botondballo.wordpress.com/2015/06/05/trip-report-c-s... > Modules making it into C++17 is less likely. However, they do say > That said, from a user’s perspective, I don’t think this is any reason to > despair: the feature is still likely to become available to users in the > 2017 timeframe, even if it’s in the form of a TS.