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

Apple's Module proposal to replace headers for C-based languages [pdf]

llvm.org

Post reply on HN
Print view View original

91–100 of 187 posts

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#91

Post by nkurz »

cozmic wrote: post #54
haberman wrote: post #35

Earlier quoted context omitted.

> Wouldn't adding a preprocessor directive like "#include_once " solve this? No -- the point is still that you recompile each header for each source file that uses it. Running the compiler N times (once for each source file) costs M x N, not M + N. > Why is this? I agree with you here, I think this dismissal of precompiled headers needs a more thorough explanation (but perhaps it was given orally in the talk).

> Why is this? To get any benefit from the use of precompiled headers at all, you need to include practically every single header in your project in your precompiled header. Doing this is the opposite of modular.... it tightly couples each of your N compilation units with each of the M modules (changing any one of the modules bundled in the pch will force you to recompile all compilation units using the pch.)

I don't follow. I'd think that for any given header, you would only have to recompile it if the #include dependencies listed in that file (or their subdependencies) changed. I'd hope that for most projects this is far from every header. When would this happen?

It also seems like this would be a win even if only used for rarely-changing system headers. As shown in the slides, for small projects the lines of unchanging standard includes dwarf the project specific code. Wouldn't it be a big win to avoid parsing and compiling all of these?

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#92

Post by haberman »

cozmic wrote: post #54
haberman wrote: post #35

Earlier quoted context omitted.

> Wouldn't adding a preprocessor directive like "#include_once " solve this? No -- the point is still that you recompile each header for each source file that uses it. Running the compiler N times (once for each source file) costs M x N, not M + N. > Why is this? I agree with you here, I think this dismissal of precompiled headers needs a more thorough explanation (but perhaps it was given orally in the talk).

> Why is this? To get any benefit from the use of precompiled headers at all, you need to include practically every single header in your project in your precompiled header. Doing this is the opposite of modular.... it tightly couples each of your N compilation units with each of the M modules (changing any one of the modules bundled in the pch will force you to recompile all compilation units using the pch.)

> changing any one of the modules bundled in the pch will force you to recompile all compilation units using the pch

Is there a fundamental reason the compilation can't be optimized away?

For example, given a header file A.h, couldn't you precompile it and generate a bloom filter of all preprocessor tokens contained therein (except ones defined in files that A.h includes)? Then if B.h (which includes A.h) changes, see if any of the preprocessor macros that are defined at the point of inclusion are in A's bloom filter. If not, you can safely skip the recompilation of A.h. If so, you should probably change A.h anyway to directly include the definition of any macros that are affecting its compilation.

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#93

Post by astrodust »

meaty wrote: post #24

It the risk of starting a fight, I really don't want this. I'm quite happy with headers and know how to effectively manage them without shooting myself. Granted there is some compiler overhead for importing large header files but I don't really notice it at all. Also, we already have an Apple/Next non-standard C extension (objective-C). I don't think we want anything else added without proper standardisation regardle…

I guess you haven't tried to compile a big project like WebKit to experience the pain of importing large header files.

Well-defined modules, if standardized, would be a huge boost to C and C++ compilation speed. Remember the proposal does not take anything away, you can always use #include, but adds a new method for those wanting to take advantage of it. Why the resistance there?

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#94

Post by munificent »

micampe wrote: post #87
Someone wrote: post #70

Earlier quoted context omitted.

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 y…

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".

Websites written in Dart work just fine in any standards-compliant modern browser. You just compile it to JS the same way you do CoffeeScript.

This makes sense because no widely deployed browser, not even Chrome, has the native Dart VM in it. You can download a build of Chromium with the Dart VM in it, but Chrome itself doesn't have it (though we hope it will when the time is right).

Check out api.dartlang.org. If the site works for you then your browser supports Dart just fine. :)

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#95

Post by gte910h »

tptacek wrote: post #71
gte910h wrote: post #62

Earlier quoted context omitted.

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.

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).

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.

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#96

Post by stcredzero »

msbarnett wrote: post #77
stcredzero wrote: post #12

Earlier quoted context omitted.

Golang should get a kickass debugger before C++ gets modules and steals their thunder.

Genuinely curious: what are you looking for in a "kickass debugger" for Golang that isn't already provided by GDB's golang support?

The ability to recompile code in the debugger and continue execution?

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#97

Post by matthavener »

masklinn wrote: post #52
haberman wrote: post #46

Overall I like it. I like how they are treating both C and C++ as first-class citizens of this new feature (instead of, for example, inextricably tying its design to classes and namespaces). I like that they have a plausible migration story for how to interoperate with existing header files. And the overall design really looks like something that would fit into all of the C and C++ work that I do without getting in t…

> instead of, for example, inextricably tying its design to classes and namespaces Considering it's Apple-designed and Apple works mostly with C (and Obj-C), it's not really surprising that they designed it for C and working with C++ rather than design it for C++.

Apple uses C++, even on mobile. The iBooks acknowledgements lists Boost and Google Protobufs.

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#99

Post by micampe »

munificent wrote: post #94
micampe wrote: post #87

Earlier quoted context omitted.

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".

Websites written in Dart work just fine in any standards-compliant modern browser. You just compile it to JS the same way you do CoffeeScript. This makes sense because no widely deployed browser, not even Chrome, has the native Dart VM in it. You can download a build of Chromium with the Dart VM in it, but Chrome itself doesn't have it (though we hope it will when the time is right). Check out api.dartlang.org. If th…

Right, I forgot about that, thanks.

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#100

Post by msbarnett »

meaty wrote: post #48
msbarnett wrote: post #37

Earlier quoted context omitted.

> Also, we already have an Apple/Next non-standard C extension (objective-C). I don't think we want anything else added without proper standardisation regardless of the motivation. I'd rather they forked the language. This is confusing. Surely Objective-C, which adds a hell of a lot that C does not address and many syntax and runtime changes to support it, would fall under the definition of "fork of the language", ra…

Well Objective C was a preprocessor extension as this proposal is so it's one and the same. Both are extensions. Yes we all know where vendors that do that got us: -moz-gradient: -ms-gradient: gradient: -webkit-gradient: Oh and Microsoft with their C++ CLR extensions and middle finger to C99.

> Well Objective C was a preprocessor extension as this proposal is so it's one and the same. Both are extensions.

This is daft. Objective-C has been implemented using a full-fledged compiler for decades. Is C++ "just an extension to C" because it was once a pre-processor on top of C? Is Common Lisp "an extension to C" because ECL transforms it into C?

Utter lunacy.

> Yes we all know where vendors that do that got us

Yes; they got us tried and tested ways of implementing things like gradients, so that the standards body had something in the real world to base a successful standard off of. The alternative gets us things like C++98's export templates: unimplementable garbage that no vendors could support because they were invented on paper and any attempt to actually build them in the real world caused more problems than they solved.

And just so we're clear what's going on here:

The linked slides are about LLVM's implementation of Daveed Vandevoorde's proposal to the C++ committee (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n334...). The C++ Standards Committee held off on adopting that proposal for C++11 because there were no implementations of it, and asked that vendors try implementing it, adapting it as necessary to make it feasible, and provide feedback so that informed decisions based on experience could be made in the final draft of C++17.

Let me repeat that: LLVM is doing exactly what the standards committee asked them to do.

Post reply on HN