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

151–160 of 187 posts

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

#151

Post by hamidr »

masklinn wrote: post #106
matthavener wrote: post #97

Earlier quoted context omitted.

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

That Apple uses C++ (you could also have mentioned LLVM) does not change their production and API being mostly C or Obj-C, and thus their proposals are usually for C. A previous examples was blocks, they created those for C and Obj-C, they can be used from C++ but are completely incompatible with C++11 lambdas as far as I know.

Also webkit. Can't they just treat lambdas as types(class/struct) with operator() methods?

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

#153

Post by fleitz »

dietrichepp wrote: post #139
greggman wrote: post #136

It's possible I don't understand the proposal and I'm probably going to get egg on my face and but I'm not sure I really want this. If I wanted Objective C or C# or Java or Python I'd use Objective C or C# or Java or Python. I actually like the preprocessor. I like that I can write code like this #ifdef DEBUG #define DEBUG_BLOCK(code) code #else #define DEBUG_BLOCK(code) #endif void SomeFunction(int a, float b) { DEB…

They're not ditching the processor, they're just making it so the preprocessor state is isolated for modules. You can still #define all you want, but it won't cross the boundary between your code and a module.

Which is pretty much how linking to a shared library works, your #defines and #includes have no effect.

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

#154

Post by chandlerc1024 »

lgg wrote: post #73
bla2 wrote: post #63

Earlier quoted context omitted.

> Sure it's non-standard Doug chairs the study group that's evaluating a module system for c++ ("""Sutter announces there is a Study Group for modules and Doug Gregor is the chair.""" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n338... ) Doug happens to be employed by Apple, but calling this "Apple's proposal" is somewhat misleading I think.

Have you ever worked at a company that develops compilers? Do you know anyone on the clang team at Apple? Do you know Douglas Gregor? dgregor is clearly heavily involved and the likely the principle architect of this proposal, but he did it on Apple's behalf to solve their problems, by one of their employees, with clear input for a number of Apple's internal stakeholders. Yes, he is the chair of study group, but is p…

I do work at a company (not Apple), developing compilers -- specifically Clang. I know most of the folks working on Clang at Apple, and I know Douglas Gregor quite well. I'm on Doug's study group working on modules.

So, I think I have some insight into what's going on. The design and implementation of the modules support in Clang is absolutely being driven by Doug at Apple. Anyone can see that. =] However, there are some other aspects to this effort that were not the focus of an LLVM dev meeting talk. Daveed Vandevoorde has written the proposals to the committee thus far[1], and is continuing to work on the proposal and language-design side[2]. Doug is currently the one driving the implementation forward, but Clang and this implementation is completely open source, and the intent (to my knowledge thus far) is absolutely to converge with the proposed standardized feature.

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n334... [2]: http://youtu.be/8SOCYQ033K8

I expect lots of others will end up contributing ideas and and implementation effort long-term, even though Doug has charted the course on the implementation side and Daveed on the proposal side thus far. I don't think this is at all likely to become a vendor-specific extension with no standards support. This is something the committee is really actively pursuing with broad interest across organizations and representatives.

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

#155

Post by pmr_ »

vilya wrote: post #74

Anyone know where I can read more detail about this proposal? It looks really interesting, but there are a couple of things I'm not clear on from the pdf: How do you get away from creating a header file for a closed source module? Without a header, how would users of your module know what they can call? Can you perform reflection on a module to inspect it? Is there some kind of tool proposed, like javadoc or pydoc, t…

Your first stop should be the latest revision of the proposal by Vandevoorde [1]. He also presented the paper at C++Now! [2].

Do answer some of your questions: Instead of compiling directly to object files/libraries and distributing headers with them, you will be able to distribute modules files. Those will be preprocessed and already be transformed to some vendor specific format.

Templates require some (actually a lot) processing before they can be instantiated. This can be done without knowing any of the types used for instantiation and this can be used to speed-up compilation.

[1]: www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf [2]: https://github.com/boostcon/cppnow_presentations_2012/blob/m...

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

#156

Post by pjmlp »

SeoxyS wrote: post #137

I think I'm the only person who likes headers. I'm not overly concerned with compilation times and big-o notation. Computers can compile things really fast nowadays. I'm more concerned with the developer usability benefits & drawbacks of the feature. As somebody who is a polyglot, but spends a large amount of time writing Objective-C, I have come to absolutely love header files. I see header files almost as documenta…

> Computers can compile things really fast nowadays.

You are free to take care of our > 1 hour compile time build.

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

#157

Post by zb »

sigil wrote: post #33
nkurz wrote: post #29

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

Instead of "#ifndef _SOME_HOPEFULLY_UNIQUE_NAME_H" I've started using "#pragma once" -- it's likely supported by every compiler you care about. http://en.wikipedia.org/wiki/Pragma_once

That can cause problems if a header is accessible by two different paths (which is not uncommon in a large project). Using both gives you maximum efficiency without sacrificing correctness, and it works everywhere.

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

#158

Post by pjmlp »

zach wrote: post #58
rjzzleep wrote: post #4

long overdue indeed, reminds me a lot of google go?

Definitely seems like Go has led the way here. Not that there wasn't a lot of pain before, but Go's lightning compilation seems to be an impetus for the "let's finally do this" change. I have to think that this is a minor repartee between Apple and Google language groups. Google did something clever that breaks with tradition, and now Apple is doing something similarly clever yet backwards-compatible. I like this dyn…

> Definitely seems like Go has led the way here. Not that there wasn't a lot of pain before, but Go's lightning compilation seems to be an impetus for the "let's finally do this" change.

Except that this is pure marketing. Languages with modules were already compiling as fast as Go does, back in the 80's.

Modula-2, Turbo Pascal, just to name two of many.

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

#159

Post by pjmlp »

coliveira wrote: post #146
rossjudson wrote: post #121

Earlier quoted context omitted.

Yeah. Compile times there were ridiculously fast, bordering on interactive. Go follows the same path. Java has very fast compilation as well, due in no small part to tossing the preprocessor and having fast binary imports.

Part of the advantage of Pascal at the time is that it was created explicitly to allow for fast parsing. C and especially C++ are much harder to parse.

The main advantage was still the possibility of having binary modules, without parsing the same imports multiple times during "make world" compilation.

Just as input, the ISO Pascal eventually got the changes that were available in Turbo Pascal and Mac Pascal (known as ISO Extended Pascal), but by then most people considered Turbo Pascal the _de facto_ standard.

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

#160

Post by pjmlp »

lttlrck wrote: post #122
VMG wrote: post #32

Earlier quoted context omitted.

It's only MxN if there is no use of the "#ifndef _HEADER_H" workaround that he mentioned earlier. There still is a processing cost for evaluating the instruction

For GCC this is highly optimized: "The preprocessor notices such header files, so that if the header file appears in a subsequent #include directive and FOO is defined, then it is ignored and it doesn't preprocess or even re-open the file a second time. This is referred to as the multiple include optimization." http://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html

Except that the contents of foo.h might be different depending on where it is being included.
Post reply on HN