Announcement

Collapse
No announcement yet.

C Language Modules For LLVM Still Being Tackled

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • C Language Modules For LLVM Still Being Tackled

    Phoronix: C Language Modules For LLVM Still Being Tackled

    Last year at the LLVM developers' meeting it was proposed by an Apple engineer the concept of "modules" for C code in LLVM/Clang to replace the common development approach for C/C++ languages of including header files and passing the library to the linker. LLVM modules seek to take a different approach...

    http://www.phoronix.com/vr.php?view=MTMzMjQ

  • #2
    Might be cool idea. This should be proposed as standard and discussed by Stroustrup and rest of the standard team. Because it doesn't makes any sense to implement such things outside the standards.

    Comment


    • #3
      C and C++ really need this. The whole .h files and cross-file-forward-referencing thing are probably the biggest thing which makes C/C++ feel "dated" compared to languages with proper "module" systems (Java, D, C#, etc). Hopefully it can be done as a standard, or at least added to GCC as well.

      Comment


      • #4
        Awesome, about time. Now let us hope this gets worked into the standard.

        Comment


        • #5
          Worked into standards? Sure.

          In the meantime, the 21st century's second decade will end before that happens. Glad to see LLVM/Clang is designing and testing now.

          Comment


          • #6
            Originally posted by j2723 View Post
            Awesome, about time. Now let us hope this gets worked into the standard.
            No, let's hope this get implemented and then standardized later.

            Back in the old days Turbo Pasal compiled with similar lines/min as Borland C. However as there is *much* less to compile when there are no include files building a project in Pascal was much faster then with C. The situation only worsened with C++ as there much more code in the header files. Borland in the time tried to speed C compiling up while maintaining compatibility by introducing compiled header, which was just a memory dump of the data structures after compiling the headers. This precompiled header file could only could only be reused between C modules if the included file where exactly identical. This of course didn't work well.

            It really is time to introduce something similar like the old Trubo Pascal:
            Unit xxx; #import the interface of another module
            Interface; #define function prtotypes of functions that are exported
            Implementation; # function bodies follow here

            Comment


            • #7
              Stroustrup and friends have surely looked at modules, and possibly considered it for the next standard. Probably helps if Clang developers do this first though.
              Also, for template heavy libraries, like boost can be, the gains aren't really that great.

              Seems like Clang would make use it this in a very smart way, which is nice to hear.
              The "futuristic" version doesn't really seem feasible though, especially for C++.

              Comment


              • #8
                How dare they attempt to fork the tried and true standard and do their own thing!!!!!!!!!!

                Oh, LLVM has nothing to do with Canonical?

                I mean, what a great initiative, good for them!!!!


                On a slightly more serious note, C is a low level language, and there's no reason to ever screw with it, C89 and C99 should continue being the standard dialects for all of eternity. C has a niche in low level, high performance STANDARDIZED UNIX-like code, this is another fine example of the stupidity of LLVM. Who would re-write their C code for LLVM so that they can lose 50% of their performance but gain some useless "compiler modularity"?

                C++ has always sucked, confusing syntax, confusing memory management, and is pretty much a memory leak waiting to happen. I guess it's better than the proven failures that managed languages like C# and Java are, but falls short of the interpreted languages like Python and Perl for ease of use. It's funny to hear supposed Linux fanboys speak of C# as if it was some holy grail, what great ground breaking applications were written in C#? Answer: there are none. Even big name Java applications like Netbeans and Eclipse are so slow and buggy, they'd be better off written in PyQt than Java.

                Comment


                • #9
                  This should be proposed as standard and discussed by Stroustrup and rest of the standard team.

                  Comment


                  • #10
                    Sounds interesting. D and Go are doing without headers and it’s one of their big “plusses”. It would be great to get such an improvement in C too.

                    I hope they don’t waste their time with C++ though, it’s complicated beyond repair.

                    Edit: after reading the documentation, I see it’s not what I thought: you still have to write headers. Not so interesting then.
                    Last edited by stqn; 03-21-2013, 08:49 AM.

                    Comment


                    • #11
                      Originally posted by porkbutt View Post
                      Who would re-write their C code for LLVM so that they can lose 50% of their performance but gain some useless "compiler modularity"?
                      They aren't even suggesting you would rewrite any code. And you wouldn't lose any performance nor would you gain any either. And the noone has mentioned anything related to "compiler modularity".

                      The most direct effect of this would be that faster compilation and smaller and more logically constructed ASTs for clang. Presumable faster linking as well.
                      Long term it could make C/C++ much move convenient to use, and less patching shit together with preprocessor macros which is what we do now. No performance loss anywhere.
                      Those are very very good reasons why you should "screw with it".

                      Comment


                      • #12
                        As I see the replace the prerpocessor with an module system, but why don't improve the preprocessor and use the filesystem for the submodule stuff?

                        Comment


                        • #13
                          Originally posted by Thaodan View Post
                          As I see the replace the prerpocessor with an module system, but why don't improve the preprocessor and use the filesystem for the submodule stuff?
                          I'm not sure in what way you want to improve the preprocessor. It does exactly what it should be doing. It just that copy pasting code like #include is fragile and inefficient, and there is no way to the compiler to know that something #included. Some code relies on this behavior (things like OpenFOAM even abuses #include all the time). The compiler needs to know that you are trying to import a module, so you cant do it solely with a preprocessor.

                          They are going to give special treatment to
                          #include <*>
                          macros and map them to the corresponding import statement (which will be the correct thing to do in all well behaved C/C++ code). If you have some obscure code, then you just turn off that feature and compile the old way.
                          So, in the backwards compatible mode, you won't change anything in your code, and compilation will just be faster. If it becomes standard, you can make use of all the other advantages they mention.

                          Comment


                          • #14
                            Originally posted by Micket View Post
                            They aren't even suggesting you would rewrite any code. And you wouldn't lose any performance nor would you gain any either. And the noone has mentioned anything related to "compiler modularity".

                            The most direct effect of this would be that faster compilation and smaller and more logically constructed ASTs for clang. Presumable faster linking as well.
                            Long term it could make C/C++ much move convenient to use, and less patching shit together with preprocessor macros which is what we do now. No performance loss anywhere.
                            Those are very very good reasons why you should "screw with it".
                            Oh, I see... So like how GCC and the Linux kernel are both bad for having/using GNU extensions that everyone whines about making it difficult for LLVM to compile the Linux kernel, LLVM too wants to add their own set of extensions to create the exact opposite situation...

                            LLVM is the Wayland of compilers.... It'll be really good in 5 more years, you just wait :P

                            Somebody please PM me when LLVM has anything to offer over GCC for a C developer like myself, because I'm writing it off as useless and a waste of my time for now.

                            Things I would care about:
                            * performance of the compiled binary

                            Things GCC currently beats LLVM up in and takes it's lunch money:
                            * performance of the compiled binary

                            Comment


                            • #15
                              Originally posted by michal View Post
                              Might be cool idea. This should be proposed as standard and discussed by Stroustrup and rest of the standard team. Because it doesn't makes any sense to implement such things outside the standards.
                              What has Stroustrup to do with C?

                              Comment

                              Working...
                              X