4 ms·

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 des

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

masklinn 14y ago
> 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++.
- matthavener 14y ago
  Apple uses C++, even on mobile. The iBooks acknowledgements lists Boost and Google Protobufs.
  - anextio 14y ago
    And also like... the XNU kernel?
  - masklinn 14y ago
    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.
    - comex 14y ago
      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).
      - bronxbomber92 14y ago
        They can be cast the other way, too. No?
        plorkyeran 14y ago
        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.
    - hamidr 14y ago
      Also webkit. Can't they just treat lambdas as types(class/struct) with operator() methods?
  - huxley 14y ago
    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.
    - comex 14y ago
      A lot of Apple's userland C APIs are also wrappers for C++ implementations, but it varies by project.
varikin 14y ago
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
- mikeash 14y ago
  #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.
  - varikin 14y ago
    Hmmm...I thought there was a bit more to #import than that, but good to know.
bla2 14y ago
> 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/n3380.pdf 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.
- lgg 14y ago
  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.
  - chandlerc1024 14y ago
    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/n3347.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n334... [2]: http://youtu.be/8SOCYQ033K8 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.
pmr_ 14y ago
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.

masklinn 14y ago

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

matthavener 14y ago
Apple uses C++, even on mobile. The iBooks acknowledgements lists Boost and Google Protobufs.
- anextio 14y ago
  And also like... the XNU kernel?
- masklinn 14y ago
  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.
  - comex 14y ago
    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).
    - bronxbomber92 14y ago
      They can be cast the other way, too. No?
      - plorkyeran 14y ago
        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.
  - hamidr 14y ago
    Also webkit. Can't they just treat lambdas as types(class/struct) with operator() methods?
- huxley 14y ago
  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.
  - comex 14y ago
    A lot of Apple's userland C APIs are also wrappers for C++ implementations, but it varies by project.

varikin 14y ago

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

mikeash 14y ago
#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.
- varikin 14y ago
  Hmmm...I thought there was a bit more to #import than that, but good to know.

bla2 14y ago

> 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/n3380.pdf 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.

lgg 14y ago
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.
- chandlerc1024 14y ago
  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/n3347.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n334... [2]: http://youtu.be/8SOCYQ033K8 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.

pmr_ 14y ago

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.