This is cool, should make Rusty Russell's CCAN [0] a whole lot more interesting. Instead of just snippets of useful code, it could contain full modules like CPAN/PyPI/PEAR/CRAN/CTAN and various other repositories for other languages.
Apple's Module proposal to replace headers for C-based languages [pdf]
111–120 of 187 posts
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#112I may come off as a bit nutty here, but do we really want to add another mechanism to C/C++ for something that has been worked with for decades? Most of these issues are things you learn really fast how to avoid in production systems, using things like #pragma once, include guards, and proper symbol and header exposure when writing C libraries. This doesn't really seem like much other than feature bloat for something…
Well if you looked they are trying to improve fragility and performance.
But I think your real issue is that you banged your head against to wall to learn it so why change it, right? You don't want that since you'd have to learn something new as well as the fact that you already know how to use the old stuff.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#113Earlier 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.
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).
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#114I don't buy the performance argument: NxM -> N + M only works if every one of the N .c files is including every one of the M .h files. If you're spamming #includes like that, you need to fix your #includes, not redefine the language.
If a .c file includes U x M .h files on average, where U is a number from 0 to 1, then the work we expect to do at compilation time is proportional to U x (N x M). This is still O(N x M).
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#115Earlier quoted context omitted.
Apple uses C++, even on mobile. The iBooks acknowledgements lists Boost and Google Protobufs.
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.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#116Earlier quoted context omitted.
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.
Bjarne believes that for C++17, we only have resource for 1 major feature, 2 medium features, and a dozen minor features.
https://www.ibm.com/developerworks/mydeveloperworks/blogs/58...
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#117While 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…
Perhaps "terrible" is a bit strong, but precompiled headers are basically a hack. They can hardly compete with a proper redesign.
I'm not sure what you'd do about the conditional behaviour, though - seems like something of an omission. I've found it handy, and it is used a lot by the Windows headers. (I don't recall seeing it much outside Windows, though - perhaps a case of "Unix doesn't use it, OS X doesn't use it, RISC-OS doesn't use it, AmigaOS doesn't use it, Windows DOES use it - OK, four to one, it's not important"? ;)
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#118It 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…
Doug Gregor, the author of this proposal, is the chair of the modules study group of the C++ standards committee (source: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n338...). And this proposal looks very similar to the C++ modules proposal by Daveed Vandevoorde http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n334...
So it looks like Apple is working towards making this a standard, not a non-standard extension.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#119While 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…
>> Precompiled headers are a terrible solution
> Why is this?
Think about it: the header potentially depends on any "define" value defined before the header is processed. If we'd have modules that define interfaces that don't depend on macros, we can process all the definitions that make the module only once for all the obj files that depend on it.
You typically don't need conditionals on if another module is used or not. You need conditionals to compile the whole application or the dynamic library some specific way, but that is also only once per the compilation of the whole application.
At the moment there is really code that can include more times he same header to define different types, but these are extreme use cases, however most of the libraries would gain if they would be defined as "modules" definitions of which can be compiled only once per application build.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#120Earlier quoted context omitted.
WRT compiler overhead, this is an asymptotic improvement, not just a constant factor. If this can get my 30-second to 20-minute compiles (depending on what's changed since the last make) down to the compile-duration range of Go (which uses this kind of dependency management for compiler performance reasons) that completely changes the workflows that are possible. But yeah - the standardisation issue is worrying, alth…
Compile time is usually fine if you build your code so that dependencies are simple as intermediate .o files are only built in dependency chains. Link time is much higher on larger projects, which this still fails to solve. Knowing your shit gets you further than language changes here. For ref, I've been writing c since 1986 and I've seen proposals like this come and go lots and every one doesn't end up with an impro…
I've used Oberon, which has a module system quite similar to this, quite heavily, and the way to diminish link time is to not link, instead use dynamic loading: leaf modules are loadable and unloadable, nonleaf modules can be made leaf by unloading all their descendants. Gives you the possibility for immediacy/flow, that a good REPL does. For many cases, you get edit/compile/run cycles measured in (often single-digit) seconds.