4 ms·

This looks promising, aside from being long overdue. Header files have always been one of the more annoying parts of C/C++/Obj-C development. The important bit

by _djo_ 14y ago

This looks promising, aside from being long overdue. Header files have always been one of the more annoying parts of C/C++/Obj-C development. The important bit is that the proposal's ideas for making the transition easier are good and make it seem like this may get traction where similar efforts have failed before. That Doug Gregor and other LLVM/Clang/LLDB developers are already working on the Clang implementation is even better. At the very least we may see this in Objective-C.

gte910h 14y ago
Objective-C is certainly important, but C++ and Objective C++ is where I think this is super important to see. I don't care which solution wins (yet, I might after more inspection/convincing), we just need A solution, and one that works for some older projects with little work.
- tptacek 14y ago
  It's been awhile since I did large scale C++, but I remember precision with header file inclusion was a big deal in C++ projects, to the point where you'd mangle your class structure if it'd keep a cascade of header dependencies out of a set of source files. It looks like this module proposal would work at cross purposes to that effort.
  - gte910h 14y ago
    I don't see why this is at cross purposes. The point of this is to do the following transformation to the Big O numbers M x N -> M + N With M being numbers of included headers and N being the number of files including that header. I think that would be solving that mangling of stuff not working at cross purposes. The point is to make it so you go over each file once, rather than multiplicatively many as you do now.
    - tptacek 14y ago
      That's what the previous best practices (impl pointers and such) did with C++ before; the goal of some of those practices was to minimize the constant factors. I may be misreading how "modules" work, but they seem to accept that sprawling dependencies will get pulled in (if only once).
      - Locke1689 14y ago
        I think the submodule system will help address this issue. People will often import the entire standard library just for one small feature. If submodules are implemented correctly we can reduce that. I'm a little wary at such a major change to C, though.
      - gte910h 14y ago
        This proposal supports "import std.stdio;" type syntax as well. That seems to greatly help fix the constant part of the equation as well. (In the selection called "Selective Import"). We can't save the world from horrible coders, but selective import would drastically drop the constant costs.
Someone 14y ago
I think it is promising and long overdue, too. It also is clear to me that this will win, because Apple pushes it into LLVM, and has a head start at it. On the other hand: if someone would do the equivalent to their browser, people would call it fragmentation. It will be interesting to see how gcc reacts to this. If this decreases compilation times significantly, I think they will have to follow suit.
- micampe 14y ago
  > On the other hand: if someone would do the equivalent to their browser, people would call it fragmentation. I haven’t seen many people calling Dart, Pepper, Native Client or the Chrome Web Store “fragmentation”.
  - Someone 14y ago
    With "the equivalent" I wasn't thinking about creating entirely new ecosystems; I was thinking of tweaking the existing ecosystem to favor one's own tool chain. The moment somebody writes the first module, the world sees the first 'best compiled with clang' code. Once that code uses #import to improve compilation speed, that could become 'must be compiled with clang'. That, IMO, is similar to adding an extra tag to your browser's HTML dialect and then promoting its use. I expect Apple is aware of the risk and wants to to prevent this (the fact that they plan a 100% compatible middle step is an indication of that), but the risk is there. Also, people have argued that the effort spent on Native Client should be spent on improving JavaScript performance because of the fragmentation issue. Responding to another comment: people also have complained about the gcc-isms present in lots of open source libraries.
    - micampe 14y ago
      The ecosystem is the www, not Javascript and HTML, so those are all tweaking and extending the ecosystem. The moment somebody writes the first Dart or NaCl based website or the first Pepper plugin, the world sees yet another (not the first) "must be viewed with Chrome".

by _djo_ 14y ago

gte910h 14y ago

Objective-C is certainly important, but C++ and Objective C++ is where I think this is super important to see. I don't care which solution wins (yet, I might after more inspection/convincing), we just need A solution, and one that works for some older projects with little work.

tptacek 14y ago
It's been awhile since I did large scale C++, but I remember precision with header file inclusion was a big deal in C++ projects, to the point where you'd mangle your class structure if it'd keep a cascade of header dependencies out of a set of source files. It looks like this module proposal would work at cross purposes to that effort.
- gte910h 14y ago
  I don't see why this is at cross purposes. The point of this is to do the following transformation to the Big O numbers M x N -> M + N With M being numbers of included headers and N being the number of files including that header. I think that would be solving that mangling of stuff not working at cross purposes. The point is to make it so you go over each file once, rather than multiplicatively many as you do now.
  - tptacek 14y ago
    That's what the previous best practices (impl pointers and such) did with C++ before; the goal of some of those practices was to minimize the constant factors. I may be misreading how "modules" work, but they seem to accept that sprawling dependencies will get pulled in (if only once).
    - Locke1689 14y ago
      I think the submodule system will help address this issue. People will often import the entire standard library just for one small feature. If submodules are implemented correctly we can reduce that. I'm a little wary at such a major change to C, though.
    - gte910h 14y ago
      This proposal supports "import std.stdio;" type syntax as well. That seems to greatly help fix the constant part of the equation as well. (In the selection called "Selective Import"). We can't save the world from horrible coders, but selective import would drastically drop the constant costs.

Someone 14y ago

I think it is promising and long overdue, too. It also is clear to me that this will win, because Apple pushes it into LLVM, and has a head start at it. On the other hand: if someone would do the equivalent to their browser, people would call it fragmentation. It will be interesting to see how gcc reacts to this. If this decreases compilation times significantly, I think they will have to follow suit.

micampe 14y ago
> On the other hand: if someone would do the equivalent to their browser, people would call it fragmentation. I haven’t seen many people calling Dart, Pepper, Native Client or the Chrome Web Store “fragmentation”.
- Someone 14y ago
  With "the equivalent" I wasn't thinking about creating entirely new ecosystems; I was thinking of tweaking the existing ecosystem to favor one's own tool chain. The moment somebody writes the first module, the world sees the first 'best compiled with clang' code. Once that code uses #import to improve compilation speed, that could become 'must be compiled with clang'. That, IMO, is similar to adding an extra tag to your browser's HTML dialect and then promoting its use. I expect Apple is aware of the risk and wants to to prevent this (the fact that they plan a 100% compatible middle step is an indication of that), but the risk is there. Also, people have argued that the effort spent on Native Client should be spent on improving JavaScript performance because of the fragmentation issue. Responding to another comment: people also have complained about the gcc-isms present in lots of open source libraries.
  - micampe 14y ago
    The ecosystem is the www, not Javascript and HTML, so those are all tweaking and extending the ecosystem. The moment somebody writes the first Dart or NaCl based website or the first Pepper plugin, the world sees yet another (not the first) "must be viewed with Chrome".