long overdue indeed, reminds me a lot of google go?
Golang should get a kickass debugger before C++ gets modules and steals their thunder.
Don't forget generics
Apple's Module proposal to replace headers for C-based languages [pdf]
161–170 of 187 posts
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#162I 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…
> Computers can compile things really fast nowadays.
Compiling Qt or LLVM from source will quickly put a rest to these unwarranted assertions.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#163Earlier quoted context omitted.
Object Pascal did the exact same thing 20 years ago, and it was a language much more influential than Go at its time. So, I don't think Apple programmers had even to look at Go to design this feature.
Yeah. Compile times there were ridiculously fast, bordering on interactive. Go follows the same path. Java has very fast compilation as well, due in no small part to tossing the preprocessor and having fast binary imports.
Also due to the java compiler doing very little work (it's a really dumb compiler)
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#164Almost like the way D programming language handle it http://dlang.org/module.html
For completeness, here's how Rust handles modules: http://dl.rust-lang.org/doc/tutorial.html#modules-and-crates Browsed golang.org for a bit and didn't find any info on how Go handles modules/packages. All I know is that it has something to do with the folder hierarchy of your project (links appreciated).
Here's a talk I gave about Go's package system: http://nf.id.au/my-linuxconfau-go-talk-mostly-about-packages
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#165Anyone saying 'inherently unscalable' about a feature of a language that's used in as many places as C needs to really think about things...
I understand some of the objections, and the import mechanism doesn't sound like a bad thing, though some of the objections are weird -
Import only imports the public API and everything else can be hidden - who wasn't doing this for libraries or large code modules anyway? Have static functions at the code module level, 'private' headers for sharing functions within a larger logical module and public headers at the logical module or libary level. Is this too cumbersome?
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#166If they're willing to fix one problem of C (...), why not fix them all instead ?
What's the point of even trying to keep C++ alive when it has been proven countless times that many of its features are useless and problematic to the point where no serious coder uses them ?
I'd rather see a language that's actually better than lisp and C - but I guess I'll have to write it to see it.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#167Anyone know where I can read more detail about this proposal? It looks really interesting, but there are a couple of things I'm not clear on from the pdf: How do you get away from creating a header file for a closed source module? Without a header, how would users of your module know what they can call? Can you perform reflection on a module to inspect it? Is there some kind of tool proposed, like javadoc or pydoc, t…
Your first stop should be the latest revision of the proposal by Vandevoorde [1]. He also presented the paper at C++Now! [2]. Do answer some of your questions: Instead of compiling directly to object files/libraries and distributing headers with them, you will be able to distribute modules files. Those will be preprocessed and already be transformed to some vendor specific format. Templates require some (actually a l…
Exactly what I was after - thanks a lot!
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#168Anyone saying 'inherently unscalable' about a feature of a language that's used in as many places as C needs to really think about things... I understand some of the objections, and the import mechanism doesn't sound like a bad thing, though some of the objections are weird - Import only imports the public API and everything else can be hidden - who wasn't doing this for libraries or large code modules anyway? Have s…
The problem with implementation hiding is that it is impossible to do well with templates. You will always make all implementation details available to your a user of your header and sometimes the implementation details are a public API themselves (libc++ vector brings in almost all of utility, a bunch of type_traits and so on).
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#169the one problem i agree with him on is performance - from what i can see his proposal does something to potentially improve that, but its not clear. i worry that caching pre-processed files is a red herring - its it really faster than re-including? what about preprocessor states? what about macros in include files? etc. i feel that the preprocessor ultimately ends up with the same amount of work, just an extra pass f…
> 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 some kind of linkage type solution going on with a lightweight interface - that feels functionally equivalent to what most of the standard library headers already are - so i don't understand what could possibly be that much faster or better about it.
not to mention that this is not a problem if you encapsulate your use of standard libraries properly... maybe 10-20 compilation units have to use it if you like to split your stuff into files a lot.
standard headers are poorly written/designed by including so much crap everywhere. why can't i have specific - per function headers which include minimal stuff?
fix the headers, not the preprocessor.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#170Earlier quoted context omitted.
Yeah. Compile times there were ridiculously fast, bordering on interactive. Go follows the same path. Java has very fast compilation as well, due in no small part to tossing the preprocessor and having fast binary imports.
Also due to the java compiler doing very little work (it's a really dumb compiler)
It does all the same work as a C++ compiler, except optimization phase. Yet any C++ compiler with optimization turned off is still order of magnitude slower. The key differences are:
- Java has a much simpler grammar to parse. - Everything is compiled at most once. - Encapsulation is stronger: private class members are not exposed in public class ABI and external code doesn't depend on them (this also extremely improves recompilation times - no need to compile half of the project because you changed a private method).