It breaks "there should be one-- and preferably only one --obvious way to do it". And quite a few others. But as a stand-alone feature, stateless preprocessor includes could be a nice feature to have.
Is C bound by Zen?
Apple's Module proposal to replace headers for C-based languages [pdf]
171–180 of 187 posts
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#172I hear D is backwards compatible with C (and C++?). They already have modules: http://dlang.org/module.html . I should use D more often.
D is not backwards compatible with C or C++, it doesn't even have a preprocesser. I think what you mean is D code can link C code if you use the C standard libraries.
Yes, I was referring to ABI compatibility. You are probably referring to source-level compatibility. If it's compatible at the binary level, it's compatible.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#173It's possible I don't understand the proposal and I'm probably going to get egg on my face and but I'm not sure I really want this. If I wanted Objective C or C# or Java or Python I'd use Objective C or C# or Java or Python. I actually like the preprocessor. I like that I can write code like this #ifdef DEBUG #define DEBUG_BLOCK(code) code #else #define DEBUG_BLOCK(code) #endif void SomeFunction(int a, float b) { DEB…
D has static-ifs as a part of the language. It enables the exact same kind of conditional compilation, but without using a pre-processor: http://dlang.org/cpptod.html#metatemplates
The latest version of D is compelling. It's mostly a reasonable cleanup of C++. It retains all of the power, but the design learns from the decades of experience. The problem is that it's mostly a reasonable cleanup of C++ - it's not different enough to stand out, I think.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#174Almost like the way D programming language handle it http://dlang.org/module.html
When I saw import std.stdio; I could've sword I was looking at D for a second. So clearly I'm all for this proposal. Anything to make C++ more like D is a win in my books.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#175I once thought about an automatic bullet-proof precompiled-header system. I think this is actually not impossible to implement.
When first parsing a header, the parser can take track about all macros it depends on in the preprocessor state. E.g. a very common macro is the one it reads very first, like `#ifndef __MYFILE_H`.
Then, including a header becomes a function () -> (parser state update, i.e. list of added stuff). This can be cached.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#176My concern is portability because that is the largest benefits of C at-least. C++ portability is less true however it is more portable than most languages.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#177I think I'm the only person who likes headers. I'm not overly concerned with compilation times and big-o notation. Computers can compile things really fast nowadays. I'm more concerned with the developer usability benefits & drawbacks of the feature. As somebody who is a polyglot, but spends a large amount of time writing Objective-C, I have come to absolutely love header files. I see header files almost as documenta…
No, you're not alone. I view headers as a wonderful way of documentation as well. Usually I've got a header file open on the left side of the screen while working on the implementation on the right side. It's extremely convient to work this way.
I'm aware of the performance issues headers create at compile time but I still like them quite a lot. On the other hand I haven't really been too fond of any module system I've seen so far. Maybe I'm just extremely old fashioned.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#178Earlier quoted context omitted.
> i worry that caching pre-processed files is a red herring - its it really faster than re-including? For future reference: In large C++ projects, it's not at all unusual for greater than 90% of the compile time to be spent parsing (and re-parsing, and re-parsing, and re-parsing, ad nauseam ) header files. > what about macros in include files? The AST of the header is persisted. If the parser can parse macro definiti…
you have completely missed my point. i know full well how much time is spent parsing these things and how the mechanism works - i don't believe this proposal will actually improve that. i also don't believe your answers address the point i was trying to make either... namely that whatever preprocessed import module thing is created, it still has to be included into the compilation unit somehow... even if there is som…
> i know full well how much time is spent parsing these things and how the mechanism works - i don't believe this proposal will actually improve that.
Well, then you're pretty much 100% wrong in most C++ projects.
I honestly don't know what to tell you here. That persisting header ASTs between translation units is faster than re-parsing should be trivially obvious, and if it isn't trivially obvious, then the mere fact that precompiled headers and ccache dramatically speeds up builds ought to make it empirically obvious.
The facts just aren't on your side.
> namely that whatever preprocessed import module thing is created, it still has to be included into the compilation unit somehow
Well, yes, obviously. In the current model the compiler slurps the header into the source file, and parse the entire combination, resulting in the parse tree of the header + the parse tree of the rest of the file. In the proposed model the compiler pulls the parse tree of the header out of cache and just builds the parse tree of the file. Since in C++ header parse trees are often quite expensive to build (since template declarations have to live in the headers and their parse trees are incredibly expensive to build), this ought to be a blindingly obvious win.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#179I think I'm the only person who likes headers. I'm not overly concerned with compilation times and big-o notation. Computers can compile things really fast nowadays. I'm more concerned with the developer usability benefits & drawbacks of the feature. As somebody who is a polyglot, but spends a large amount of time writing Objective-C, I have come to absolutely love header files. I see header files almost as documenta…
Most of the time header compilation time isn't a big deal to me either, but then I started working on a project that uses Boost extensively and noticed that even small files were taking several seconds to compile because the headers were so enormous.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#180Earlier quoted context omitted.
C# together with visual studio solves this in an amazing way. You can browse .NET DLL-files as if they were source files, with only public members being visible and without the function bodies. Good for finding function names and constants. I can't believe nobody else is using the same system, using "go to definition" on a library function is just as natural as using it on one of your own functions. Only difference i…
Most (all?) Java IDEs do this as does XCode ( Obj-C) and probably many other things. This isn't the point here though...
But Eclipse does stupid stuff like disabling Ctrl-Ffull text search when viewing a .class file, even though text method names are plainly visible.