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

21–30 of 187 posts

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

#21

Post by pjmlp »

octopus wrote: post #18
jeremyx wrote: post #8

Since these are not in C++11, we'll have to wait 10 years...

Actually you'll have to way from 2 to 5 years. Have a look at Herb Sutter's talk about "The Future of C++": http://channel9.msdn.com/Events/Build/2012/2-005

Only one major feature is planned to make its way through C++17, modules is considered a major feature.

And there are lots of people interested in other sets of major features.

So who knows if C++17 will include it, and even it does, how long one can use it in production.

Until 2017 many native developers might just had moved into Rust, D, Go or whatever comes along.

Just look how computing used to be 5 years ago.

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

#22

Post by strmpnk »

kibwen wrote: post #17
ori_b wrote: post #13

Earlier quoted context omitted.

in Go, you declare a package for your file. Exported symbols start with an upper case letter.

Okay, so the `package` keyword in Go is like the `export` keyword in this proposal? Does Go allow submodules?

Packages are given paths or URLs so they might be a subpath but it's not really a subpackage of any sort other than by name.

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

#24

Post by meaty »

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 regardless of the motivation. I'd rather they forked the language.

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

#25

Post by thwest »

strmpnk wrote: post #16
thwest wrote: post #15

"Apple's Module proposal..." Is Apple really who deserves credit here? Is there something I missed about Apple's management driving this, and not Gregor or the C++ standards committee?

First slide. It seems like he's employed by Apple and being paid to work on this. So yes, I think calling it Apple's solution an apt description.

Herb Stutter heads the C++ standards committee and credits his employer Microsoft [1]. Is C++11 or C++17 "Microsoft's"?

[1] http://isocpp.org/std/the-committee

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

#26

Post by aaronblohowiak »

mtdev wrote: post #20

Looks like the core issue is a poor preprocessor implication. It's a good idea in principle, however, we would be adding new features to address shortcomings in existing features instead of fixing the problems in the existing code.

Backwards compatibility is a Big Deal for these communities.

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

#28

Post by kibwen »

pjmlp wrote: post #21
octopus wrote: post #18

Earlier quoted context omitted.

Actually you'll have to way from 2 to 5 years. Have a look at Herb Sutter's talk about "The Future of C++": http://channel9.msdn.com/Events/Build/2012/2-005

Only one major feature is planned to make its way through C++17, modules is considered a major feature. And there are lots of people interested in other sets of major features. So who knows if C++17 will include it, and even it does, how long one can use it in production. Until 2017 many native developers might just had moved into Rust, D, Go or whatever comes along. Just look how computing used to be 5 years ago.

Do you have a source for "Only one major feature is planned to make its way through C++17"? Wikipedia tells me (without citations) that C++14 and C++17 are minor and major revisions respectively, but doesn't indicate that "major revision" stipulates only a single major change at most.

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

#29

Post by nkurz »

While LLVM authors probably know best, I don't understand some of his criticisms on the "Inherently Non-Scalable" slide.

  • M headers with N source files ->  M x N build cost
It's only MxN if there is no use of the "#ifndef _HEADER_H" workaround that he mentioned earlier. Wouldn't adding a preprocessor directive like "#include_once " solve this? Alternatively, these guards could be added to the headers themselves without changing the preprocessor. This probably should be a parallel set of headers (#include ) to avoid breaking the rare cases that depend on multiple inclusions, but creating that set would be a simple mechanical translation.

  • C++ templates exacerbate the problem
I'm mostly a C programmer, so I have no argument here.

  • Precompiled headers are a terrible solution
Why is this? It likely would break the ability of headers to be conditional on previous #define statement, but since the proposal does this anyway it doesn't seem insurmountable. Along that lines, how does this proposal handle cases where one needs/wants conditional behavior in the header such as "#ifdef WINDOWS" or the like? And is caching headers during the same compilation also "terrible"?

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

#30

Post by msbarnett »

[deleted] wrote: post #27

[deleted]

> The article is disingenuous. Alongside its oh-so-sassy table of file sizes for helloworld, it needs a table of runtimes for helloworld. Turning stdio into an API instead of preprocessor soup is going to blow that up, unless the guy means something very unusual by "API".

You seem to be deeply confused here. This is simply a proposal for persisting the AST for eg) stdio across compiler invocations instead of reparsing it on every textual substitution of a #include, and isolating source AST changes from erroneously corrupting header ASTs. It has no runtime implications because the outputs of the linking stage will be identical.

stdio's preprocessor soup is its API. You seem to be the one with an unusual and much narrower meaning of "API".

Post reply on HN