31–40 of 187 posts
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…
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…
There still is a processing cost for evaluating the instruction
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…
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…
No, that means that for foo.c a given header is only added once. It doesn't prevent bar.c from importing and recompiling that same header.
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…
No -- the point is still that you recompile each header for each source file that uses it. Running the compiler N times (once for each source file) costs M x N, not M + N.
> Why is this?
I agree with you here, I think this dismissal of precompiled headers needs a more thorough explanation (but perhaps it was given orally in the talk).
Earlier quoted context omitted.
First slide. It seems like he's employed by Apple and being paid to work on this. So yes, I think calling it Apple's solution an apt description.
Herb Stutter heads the C++ standards committee and credits his employer Microsoft [1]. Is C++11 or C++17 "Microsoft's"? [1] http://isocpp.org/std/the-committee
This particular proposal is from Apple.
When Herb Sutter/Microsoft make proposals for C++, it's phrased as "Microsoft's proposal for C++0x" or whatever.
It 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…
This is confusing. Surely Objective-C, which adds a hell of a lot that C does not address and many syntax and runtime changes to support it, would fall under the definition of "fork of the language", rather as C++ does, rather than simply a "non-standard C extension" (surely that description better applies to the many GNU C extensions in GCC?).
Re: "adding things without proper standardization", the role of standards committees is to reach consensus among vendors so that they can standardize non-standard extensions that they have variously implemented and tested in the real world first. To argue for the opposite, that the vendors must do nothing until the committee hands down the One True Way from On High, untested outside of their heads, is the height of Design By Committee.
i feel that the preprocessor ultimately ends up with the same amount of work, just an extra pass for each included header to build a version to be cached… not to mention the complexity required to handle the multiplicity of pre-processor states required for this. maybe i am being dim and missing the obvious.
tbh, i'd rather they made their compiler work properly, like respecting alignment on copies with optimisation turned on, or implementing the full C++ 11, before adding language features to fix problems that nobody really has.
This looks promising, aside from being long overdue. Header files have always been one of the more annoying parts of C/C++/Obj-C development. The important bit is that the proposal's ideas for making the transition easier are good and make it seem like this may get traction where similar efforts have failed before. That Doug Gregor and other LLVM/Clang/LLDB developers are already working on the Clang implementation i…
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.
I haven’t seen many people calling Dart, Pepper, Native Client or the Chrome Web Store “fragmentation”.
It 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…
As for standardization, Doug Gregor is on the standardization committee.