Comment by haberman | Hacker News Reader

Comment by haberman | Hacker News Reader

Parent Full thread

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 the way.

Sure it's non-standard and no one who cares about portability will use this (yet). But this is exactly the way that good ideas get refined and eventually standardized. You surely wouldn't want to standardize a module system that hadn't been already implemented and tested -- that would just leave you with surprises when theory meets reality.

C and C++ are here to stay -- we should be open to improvements in them.

They don't explicitly mention this, but I'm sure that they have no plans to remove existing #include functionality -- it is a near certainty that someone, somewhere depends on having the preprocessor state affect how an include file is processed. There are probably even cases where you can look at the design rationale for this choice and say "yep, that really is the best solution for what you are trying to do."

> 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 participation in WG21 is funded by and at the behest of Apple.

The germ of every idea starts with one person, but many (most?) ideas require the involvement of many people to make them happen. Where credit lies is complicated, but I think it is completely accurate to refer to this as either Doug's proposal or Apple's proposal.

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.

I'm wondering: All modules proposals so far have come from Daveed Vandevoorde including the last one [1].

As far as I can see clang is just the first compiler implementing this proposal which is a very important step for standardization, because prior implementation experience ends up influencing the process heavily.

[1] : www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf

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

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.

You can now implicitly cast lambdas to blocks, although they're otherwise completely separate (and must be - C++'s approach wouldn't easily translate to C).

They can be cast the other way, too. No?

Casting to a C++11 lambda doesn't really make any sense; each lambda function is a unique anonymous type. There's also no need to do any casting to use an Obj-C block anywhere that you can use a C++11 lambda, since they obviously already implement the Callable concept.

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

Probably in other areas, but a major one is in IO-Kit (their device driver framework) which is written in and uses a specialized subset of C++ called Embedded-C++, though the userspace API for it has a C wrapper.

A lot of Apple's userland C APIs are also wrappers for C++ implementations, but it varies by project.

And also like... the XNU kernel?

Having a limited C++ background, started with C++ in college, I have a half remembered idea about how #include works and linking and such not. When I started working with Obj-C, I found the mix of include and import. This proposal looks like Apple is migrating their* import (module) system to C and C++.

As for removing #include, at least in Obj-C, #include is still there to allow working with C libraries. I would assume the same for C & C++.

* Not really sure what is Apple's Obj-C versus a standardized Obj-C

#include and #import are nearly identical. Both simply take the contents of the file you point them at and blindly copy that text into your source file at that location. The only difference is that #import will ignore subsequent attempts to insert the same file, while #include will obediently insert the same contents over and over again.

Sadly, there's no such thing as "Standardized Obj-C", and Apple's version is about as close as it comes. They basically own the language.

Hmmm...I thought there was a bit more to #import than that, but good to know.

With regards to backward compatibility with include: modules will still be preprocessed before they are assembled. This is necessary to drive much of the preprocessor meta-programming that is around in various libraries and which will not go away with variadic templates due to performance reasons.

Reply on news.ycombinator.com