Live data from Hacker News

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

llvm.org

131–140 of 187 posts

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

#131
post #66

I didn't see any mention of the recursive-usage problem. How do they plan on handling co-dependant files? For example, class A's code makes use of class B. Class B's code makes use of class A. a.h looks like: class B; class A { public: void foo (B *); } a.cc looks like: #include "a.h" #include "b.h" void A::foo (B *) { b->narf (); } and b.h and b.cc use A in the same way.

I don't see what the issue is. In some sense, the proposal is to essentially do away with inserted code and instead do what Java is doing with its import statements: a public API. There's no recursion issue in Java. I think you may be mixing this up with C's #include, which does have recursion issues, hence the need for its absurd #ifdef guards. But Apple did away with that years ago with #import, which is basically…

I'm wondering how it accomplishes this as a practical matter. Does it compile a file twice? Once to create the interface info, and a second time to compile the implementation? Can they even parse enough of a C++ file to generate the interface in all cases?

That they chose not to mention the issue makes me nervous that they think they can just ignore the problem. Many previous languages have ignored the problem and said "don't do that." I hope this proposal does not go in that direction.

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

#133
Sounds interesting, but I've got to admit my initial response is cautious.

How will this avoid the LD_LIBRARY_PATH hell of trying to depend on a local module (ie. conflicts)?

How will it work at all with local submodules inside a single project? (ie. I have 200 local c files, each with a header. Now what? A module each? How do we handle simple dependencies between classes and functions?)

How will we import actual macros?

My guess is that the answers are:

1) include path style --module-path=blah

Seems fair, but this is going to be as messy as include paths already are.

2, 3) dont use modules except at a system level.

Thats a shame as far as im concerned, but perhaps I'm wrong. Can anyone else see how these might work?

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

#134
post #113

Earlier quoted context omitted.

You can now implicitly cast lambdas to blocks, although they're otherwise completely separate (and must be - C++'s approach wouldn't easily translate to C).

They can be cast the other way, too. No?

Casting to a C++11 lambda doesn't really make any sense; each lambda function is a unique anonymous type. There's also no need to do any casting to use an Obj-C block anywhere that you can use a C++11 lambda, since they obviously already implement the Callable concept.

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

#135
post #105

Earlier quoted context omitted.

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

ccache doesn't cache the results of compiling each individual header. Other than the shared cache, ccache is conceptually just a workaround for deficiencies in make.

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

#136
It'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) {
      DEBUG_BLOCK({
        LOG_IF_ENABLED("Called SomeFunction(%d, %f)\n", a, b);
      });
      ... do whatever it was SomeFunction does ..
    }
In other languages that I'm used to there's no way to selectively compile stuff in/out.

I like that I can change the behavior of a file for a single include unit

   -- foo.cc --
   #include "mylib.h"

   -- bar.cc --
   #include "mylib.h"

   -- baz.cc --
   #define MYLIB_ENABLED_EXPENSIVE_DEBUGGING_STUFF 1
   #include "mylib.h"
because enabling it globally would run too slow

I like that I can code generate

    // --command.h--
    #define COMMAND_LIST \
       COMMAND_OP(Stand) \
       COMMAND_OP(Walk)  \
       COMMAND_OP(Run)   \
       COMMAND_OP(Hide)  \
       COMMAND_OP(Jump)  \

    // make enum for commands
    #define COMMAND_OP(id) k##id,
    enum CommandId {
        COMMAND_LIST
        kLastCommandId,
    };
    #undef COMMAND_OP

    // --command.cc--
    // Make command strings
    #define COMMAND_OP(id) #id
    const char* GetCommandString(CommandId id) {
      static const char* command_names[] = {
        #define COMMAND_OP(id) #id,
        COMMAND_LIST
        #undef COMMAND_OP
      };
      return command_names[id];
    }

    // make a jump table for the commands
    typedef bool (*CommandFunc)(Context*);
    bool FunctionDispatch(CommandID id, Context* ctx) {
      static CommandFunc s_command_table[] = {
        #define COMMAND_OP(id) id##Proc,
        COMMAND_LIST,
        #undef COMMAND_OP
      }
      return s_command_table[id](ctx);
    };
Or this

    class Thing {
    public:
      void DoSomething();

    private:
      #ifdef USE_SLOW_LEGACY_FEATURE
      // needs access to Thing's internals.
      void EmulateOldSlowLegacyFeature();
      #endif
    };
Yes, I can try to hide the implementation but again, the reason I'm using C++ is because I want the optimal code. Not a double indirected pimpl. If I wanted the indirection I'd be using another language.

I love C/C++ and it's quirks. I use it's quirks to make my life easier in ways other some other languages don't. Modules seems like is ignoring some of what makes C/C++ unique and trying to turn it into Java/C#

People saying the preprocessor has issues are ignoring the benefits. I miss the preprocessor in languages that don't have one because I miss those benefits.

You could say, "well, just don't use this feature then" but I can easily see once a project goes down this path, all those benefits of the preprocessor will be lost. You can't easily switch your code between module and include, especially if it's a large project like WebKit, Chrome, Linux, etc.

Leave my C++ alone! Get off my lawn!

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

#137
I 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 documentation. To me, a header file is a description of everything that's public about an API. My header files tend to be very well commented, and very sparse, only containing public methods and typedefs.

When the need arises to make internally-includable headers (say I'm writing a static library, and have methods that are private to the library, but public to other classes within the library), I will usually write a `MyApi+Internal.h` header for internal use, which doesn't ship with the library.

A developer should never have to dig into implementation files, or into documentation, in order to use a library. Its headers ought to be sufficient. Things like private instance variables or anything private does not belong in a header file.

FWIW, here's the public header for the library I spend most of my time working on:

https://gist.github.com/e83169d2c3984c6f077c

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

#138

It'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…

On a closer read of this proposal, I believe the key is in these lines:

    A module is a package describing a library
    • Interface of the library (API)
    • Implementation of the library
That is, this will never replace the way you write applications.

All it means is that there is an alternative way to depend on 3rd party libraries that improves compile time if that library supports it.

If you're writing a library, you may choose to support it.

I agree, if this was a proposal to remove #include, #define and #if, it would be doomed as a non-starter; that's simply not practical. I don't believe that it is though.

Edit: Yes, I am saying that I believe this proposal is only practical for getting rid of public header files, the sort you'd find in /include/, and will have no impact on header files inside a single code base.

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

#139

It'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…

They're not ditching the processor, they're just making it so the preprocessor state is isolated for modules. You can still #define all you want, but it won't cross the boundary between your code and a module.

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

#140

It'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…

> You could say, "well, just don't use this feature then" but I can easily see once a project goes down this path, all those benefits of the preprocessor will be lost. You can't easily switch your code between module and include, especially if it's a large project like WebKit, Chrome, Linux, etc.

It seems to me that that's the genius of this proposal: You can continue to use #include and the preprocessor where you feel it best serves you, because you can freely mix the two in the same compilation unit. It's fairly obvious when you're building things like your hypothetical command.h that you're going to base them on the preprocessor from the start, so the cost of moving from modules to pre-processor based solutions is irrelevant. And note that this proposal is not about removing macros, or removing the preprocessor, so your other two examples will continue to work in either scenario.

Liking macros and the preprocessor is fine and dandy, but there's no need to force template-heavy code to continue to pay insanely high re-re-re-re-re-parsing costs ad infinitum simply to retain those features.

Post reply on HN