Is D not doing this sort of thing already or am I wrong?
Apple's Module proposal to replace headers for C-based languages [pdf]
61–70 of 187 posts
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#62Earlier quoted context omitted.
Objective-C is certainly important, but C++ and Objective C++ is where I think this is super important to see. I don't care which solution wins (yet, I might after more inspection/convincing), we just need A solution, and one that works for some older projects with little work.
It's been awhile since I did large scale C++, but I remember precision with header file inclusion was a big deal in C++ projects, to the point where you'd mangle your class structure if it'd keep a cascade of header dependencies out of a set of source files. It looks like this module proposal would work at cross purposes to that effort.
I don't see why this is at cross purposes. The point of this is to do the following transformation to the Big O numbers
M x N -> M + N
With M being numbers of included headers and N being the number of files including that header.
I think that would be solving that mangling of stuff not working at cross purposes.
The point is to make it so you go over each file once, rather than multiplicatively many as you do now.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#63Overall 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 t…
> 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.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#64Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#65It 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…
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 improvement.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#66I didn't see any mention of the recursive-usage problem. How do they plan on handling co-dependant files?
For example, class A's code makes use of class B. Class B's code makes use of class A.
a.h looks like:
class B;
class A {
public: void foo (B *);
}
#include "a.h"
#include "b.h"
void A::foo (B *) { b->narf (); }
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#67I 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.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#68Overall 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 t…
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 ass…
#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.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#69long 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…
I don't intend to downplay the importance of Go (it's definitely helped people realize how nice fast compiles can be when you don't have to fight the language to get it), but Clang (whose leaders are making the proposal here) has had an explicit focus on fast compile times since the very beginning:
http://clang.llvm.org/features.html#performance
Note that "Fast compiles and Low Memory Use" is listed more prominently than any other feature (in primary position, with more text and pretty graphics).
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#70Earlier quoted context omitted.
I think it is promising and long overdue, too. It also is clear to me that this will win, because Apple pushes it into LLVM, and has a head start at it. On the other hand: if someone would do the equivalent to their browser, people would call it fragmentation. It will be interesting to see how gcc reacts to this. If this decreases compilation times significantly, I think they will have to follow suit.
> On the other hand: if someone would do the equivalent to their browser, people would call it fragmentation. I haven’t seen many people calling Dart, Pepper, Native Client or the Chrome Web Store “fragmentation”.
With "the equivalent" I wasn't thinking about creating entirely new ecosystems; I was thinking of tweaking the existing ecosystem to favor one's own tool chain.
The moment somebody writes the first module, the world sees the first 'best compiled with clang' code. Once that code uses #import to improve compilation speed, that could become 'must be compiled with clang'. That, IMO, is similar to adding an extra tag to your browser's HTML dialect and then promoting its use.
I expect Apple is aware of the risk and wants to to prevent this (the fact that they plan a 100% compatible middle step is an indication of that), but the risk is there.
Also, people have argued that the effort spent on Native Client should be spent on improving JavaScript performance because of the fragmentation issue. Responding to another comment: people also have complained about the gcc-isms present in lots of open source libraries.