On 2013-07-18 07:54, Joseph Rushton Wakeling wrote:

> Though I imagine that for optimal performance, some manual work will always be necessary.

Yes, it's always the preprocessor that's causing the problems, including #includes.

-- 
/Jacob Carlborg

On Thursday, 18 July 2013 at 06:35:21 UTC, Jacob Carlborg wrote:
> On 2013-07-18 01:53, Brad Roberts wrote:
>
>> 6. the time cost of parsing/semanticing c/c++ is significantly higher
>> than D, making .h importing dwarf the rest of the cost of the
>> compilation process
>>
>> 7. .h files are roughly static so translating them on each compilation
>> unit is wasteful, generate once as part of the build process and update
>> only as needed.  This is stuff that build processes are good at.
>
> Yeah, that's true. This year Clang has got support for modules. Basically a better and safe(er) version of percompiled headers.

They are not there yet.

I was really looking forward for it, mostly due to the C++17 modules effort being done at Apple.

However, what was presented at WWDC 2013 was a half baked solution that only works in Objective-C for system headers.

--
Paulo

On 2013-07-18 09:36, Paulo Pinto wrote:

> They are not there yet.
>
> I was really looking forward for it, mostly due to the C++17 modules
> effort being done at Apple.
>
> However, what was presented at WWDC 2013 was a half baked solution that
> only works in Objective-C for system headers.

If it works for Objective-C, I'm pretty sure it will work for C. In fact, the documentation contains a lot of examples with standard C headers.

http://clang.llvm.org/docs/Modules.html

Why would they work only for system headers?

-- 
/Jacob Carlborg

On Wednesday, 17 July 2013 at 22:52:40 UTC, Walter Bright wrote:
> 1. there may be various #define's necessary to compile it that would normally be supplied on the command line to the C compiler
>
> 2. there are various behavior switches (see the PR for DMD that wants to set the signed'ness of char types)

Those two plus the fact that h->d conversion is fairly static and should not be done at compilation stage is pretty much enough for me to oppose such misfeature.

Everything else is not that relevant. Even if the idea was considered good, pulling in more dmc legacy is the last thing I'd be glad to see done.

On Thursday, 18 July 2013 at 08:23:42 UTC, Jacob Carlborg wrote:
> On 2013-07-18 09:36, Paulo Pinto wrote:
>
>> They are not there yet.
>>
>> I was really looking forward for it, mostly due to the C++17 modules
>> effort being done at Apple.
>>
>> However, what was presented at WWDC 2013 was a half baked solution that
>> only works in Objective-C for system headers.
>
> If it works for Objective-C, I'm pretty sure it will work for C. In fact, the documentation contains a lot of examples with standard C headers.
>
> http://clang.llvm.org/docs/Modules.html
>
> Why would they work only for system headers?

Because that is what Apple is supporting in XCode 5. If you have an Apple ID, have a look at,

Session "Advances in Objective-C"
https://developer.apple.com/wwdc/videos

Slides from page 9 up to 69. Slide 61 lists all current caveats.


--
Paulo

On Wednesday, 17 July 2013 at 22:52:40 UTC, Walter Bright wrote:
> Over the years, I've given a fair amount of thought to, and talked about it with various people:
>
>    import "foo.h";
>

Personally I'd rather see something like this as part of a more generic feature rather than built in to the compiler. If CTFE could call external libraries or programs, such as utilizing libclang for parsing (and ideally if it could perform caching of [pure?] mixins that took more than X to evaluate), it would be nicer than including a C parser inside a D compiler. Then it's the responsibility of the project / package manager to make sure that the dependency is present and also avoids certain licensing / maintainability issues. Not sure how feasible having CTFE be able to call external libraries is though, or if it would be desired.