41–50 of 187 posts
Almost like the way D programming language handle it http://dlang.org/module.html
with Ada.Strings.Unbounded;
but "withing" ada, you'd get the parent package(s). eg you'd get Ada.Strings and Ada.Strings.Unbounded but not Ada.Strings.Fixed
long overdue indeed, reminds me a lot of google go?
It's also my understanding that there are no "submodules" in Go. If you want what's in the import path "foo/bar", importing "foo" is unrelated. In fact, there might not be anything in "foo", making it an invalid import path, despite "foo/bar" being a valid one.
And then there's the stuff with being able to directly import code from github, code.google.com, etc, but that dovetails in to the same mechanism after downloading.
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…
Obj-C already has this: #import http://en.wikipedia.org/wiki/Objective-C#.23import
It’s just #include with built-in guards, but headers still have to be compiled once per compilation unit.
Thinking about my trips to /usr/include, those headers weren't that useful for coding with but you could get constants and function names at least.
"Apple's Module proposal..." Is Apple really who deserves credit here? Is there something I missed about Apple's management driving this, and not Gregor or the C++ standards committee?
Sure it's non-standard and no one who cares about portability will use this (yet). But this is exactly the way that good ideas get refined and eventually standardized. You surely wouldn't want to standardize a module system that hadn't been already implemented and tested -- that would just leave you with surprises when theory meets reality.
C and C++ are here to stay -- we should be open to improvements in them.
They don't explicitly mention this, but I'm sure that they have no plans to remove existing #include functionality -- it is a near certainty that someone, somewhere depends on having the preprocessor state affect how an include file is processed. There are probably even cases where you can look at the design rationale for this choice and say "yep, that really is the best solution for what you are trying to do."
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.
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…
> 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 regardless of the motivation. I'd rather they forked the language. 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", ra…
Yes we all know where vendors that do that got us:
-moz-gradient:
-ms-gradient:
gradient:
-webkit-gradient:
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…
> 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 regardless of the motivation. I'd rather they forked the language. 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", ra…
It's not even a fork, it's a different language source-compatible with C. It has its own semantics, its own syntax and its own runtime.
> "‘import’ ignores preprocessor state within the source file"
I wonder if that would remove specific use-cases where you wouldn't want the import to ignore the state of the pre-processor within the source file?
Overall, I like it!