Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple's Module proposal to replace headers for C-based languages [pdf]

llvm.org

Post reply on HN
Print view View original

101–110 of 187 posts

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#101

Post by mtdev »

mbrubeck wrote: post #79
mtdev wrote: post #20

Looks like the core issue is a poor preprocessor implication. It's a good idea in principle, however, we would be adding new features to address shortcomings in existing features instead of fixing the problems in the existing code.

No, the issue is not just poor implementation. Problems like O(M*N) bloat and scope pollution are fundamental design flaws with the preprocessor header system. Almost every widespread modern language (all except JavaScript? [1]) has a built-in module system. Adding modules to C is not just some sort of hack to work around preprocessor limitations. Instead I'd say that the C preprocessor is a hack to work around lack…

You can add some functionality to limit scope and implement a caching system (which is also proposed here) to deal with M*N issues with a focus on keeping backwards compatibility. E.g. the caching is done automatically, the scope spamming control is a best effort solution based on static analysis (for example).

Moving from headers to modules is a fundamental change in how the language operates and is guaranteed to further break compatibility between compilers further. I worry that jumping to add these features to the language standard is premature and we should instead look further to optimizations within the preprocessor and linker to see if we can improve performance first.

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#102

Post by kevinnk »

optymizer wrote: post #90

I 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.

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#103

Post by anextio »

matthavener wrote: post #97
masklinn wrote: post #52

Earlier quoted context omitted.

> instead of, for example, inextricably tying its design to classes and namespaces Considering it's Apple-designed and Apple works mostly with C (and Obj-C), it's not really surprising that they designed it for C and working with C++ rather than design it for C++.

Apple uses C++, even on mobile. The iBooks acknowledgements lists Boost and Google Protobufs.

And also like... the XNU kernel?

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#104

Post by aidenn0 »

vilya wrote: post #74

Anyone 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…

I know nothing about this proposal, but I can make educated guesses on all of these:

Creating header: the module needs only the public information for a closed source module. You could generate it from a .h file if you are a consumer of a closed source module, or if you are the producer of the module, you could potentially ship either pre-generated modules or all the information needed to generate a module.

javadoc, etc. It sounds like you could generate the information directly from the C/C++ source since there is now information about what is public and private in the source

Compiling this: template Type max(Type a, Type b) { return a > b ? a : b; } Generates no code, but it does some work in the compiler that can be cached. This is what would be stored in the module.

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#105

Post by nkurz »

haberman wrote: post #92
cozmic wrote: post #54

Earlier quoted context omitted.

> Why is this? To get any benefit from the use of precompiled headers at all, you need to include practically every single header in your project in your precompiled header. Doing this is the opposite of modular.... it tightly couples each of your N compilation units with each of the M modules (changing any one of the modules bundled in the pch will force you to recompile all compilation units using the pch.)

> changing any one of the modules bundled in the pch will force you to recompile all compilation units using the pch Is there a fundamental reason the compilation can't be optimized away? For example, given a header file A.h, couldn't you precompile it and generate a bloom filter of all preprocessor tokens contained therein (except ones defined in files that A.h includes)? Then if B.h (which includes A.h) changes, se…

I wonder how necessary this actually is. I think using non-command-line defines to change the behavior of header files is rare. From what I can tell, ccache just ignores the issue: https://ccache.samba.org/manual.html#_how_ccache_works

I'm not sure how it gets away with this and works as well as it does. Maybe there is a behind the scenes check that I don't know about? In any case, it might be a good framework to add the caching you describe.

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#106

Post by masklinn »

matthavener wrote: post #97
masklinn wrote: post #52

Earlier quoted context omitted.

> instead of, for example, inextricably tying its design to classes and namespaces Considering it's Apple-designed and Apple works mostly with C (and Obj-C), it's not really surprising that they designed it for C and working with C++ rather than design it for C++.

Apple uses C++, even on mobile. The iBooks acknowledgements lists Boost and Google Protobufs.

That Apple uses C++ (you could also have mentioned LLVM) does not change their production and API being mostly C or Obj-C, and thus their proposals are usually for C. A previous examples was blocks, they created those for C and Obj-C, they can be used from C++ but are completely incompatible with C++11 lambdas as far as I know.

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#107

Post by cpeterso »

sev wrote: post #50

They mention: > "‘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!

You can still use #include if you want preprocessor state to leak into a specific header file.

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#108

Post by huxley »

matthavener wrote: post #97
masklinn wrote: post #52

Earlier quoted context omitted.

> instead of, for example, inextricably tying its design to classes and namespaces Considering it's Apple-designed and Apple works mostly with C (and Obj-C), it's not really surprising that they designed it for C and working with C++ rather than design it for C++.

Apple uses C++, even on mobile. The iBooks acknowledgements lists Boost and Google Protobufs.

Probably in other areas, but a major one is in IO-Kit (their device driver framework) which is written in and uses a specialized subset of C++ called Embedded-C++, though the userspace API for it has a C wrapper.

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#109

Post by angersock »

I may come off as a bit nutty here, but do we really want to add another mechanism to C/C++ for something that has been worked with for decades?

Most of these issues are things you learn really fast how to avoid in production systems, using things like #pragma once, include guards, and proper symbol and header exposure when writing C libraries.

This doesn't really seem like much other than feature bloat for something that works, works well enough, and which probably won't be implemented in a timely fashion by at least 1 major compiler vendor (Hey folks! There's life outside clang and gcc and icc!).

Re: Apple's Module proposal to replace headers for C-based languages [pdf]

#110

Post by richy_rich »

Too wrote: post #88
acomjean wrote: post #44

I thought one of the points of headers system was you could use the code without having to slog through all the source. 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.

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...
Post reply on HN