Announcement

Collapse
No announcement yet.

C++ Doesn't Change The Speed Of GCC

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

  • #11
    Originally posted by LightBit View Post
    However, it will make compilation of GCC itself slower.
    Not necessarily, especially when used responsibly. Remember that GCC has a lot of special pre-compilation code to run on itself for various "extensions" like gengtype. Removing those steps and replacing them can make things faster.

    Also, C++ is generally not slower to compile unless using templates (including the STL of course) or exceptions. Exceptions are turned off here and templates are limited to sensible uses where they have a real benefit. With some templates compilation may be a little slower but if that greatly reduces code complexity then your development time is still under a net improvement. I'd be fine with a little longer build if it meant hours or even days shaved off of feature work. Build time is important because it impacts iteration time; language and tools are more important because they impact iteration time even more.

    Comment


    • #12
      Originally posted by Luke_Wolf View Post
      The article itself says not.
      No, in article Linux kernel compilation was timed.

      Comment


      • #13
        Originally posted by elanthis View Post
        Not necessarily, especially when used responsibly. Remember that GCC has a lot of special pre-compilation code to run on itself for various "extensions" like gengtype. Removing those steps and replacing them can make things faster.

        Also, C++ is generally not slower to compile unless using templates (including the STL of course) or exceptions. Exceptions are turned off here and templates are limited to sensible uses where they have a real benefit. With some templates compilation may be a little slower but if that greatly reduces code complexity then your development time is still under a net improvement. I'd be fine with a little longer build if it meant hours or even days shaved off of feature work. Build time is important because it impacts iteration time; language and tools are more important because they impact iteration time even more.
        Yes it depends how much C++ functions they use. But does it make sense to use C++ without C++ functions?

        Comment


        • #14
          Originally posted by LightBit View Post
          Yes it depends how much C++ functions they use. But does it make sense to use C++ without C++ functions?
          Without STL? Yes, definately. The big win with C++ is classes, templates, a better type-system and constructors/destructors for safer and cleaner state handling.

          Comment


          • #15
            Originally posted by LightBit View Post
            But does it make sense to use C++ without C++ functions?
            What do you mean by "functions"? C++ is much (not all...) about classes, so why not use "classes"?
            And that's one great plus:
            classes with constructors and destructors. RAII. Not having to think about "which objects need to get destroyed in this error case"?
            GCC currently uses macros/static inline functions and so on for "emulating" functionality they get for free in a much more pleasant way when using C++. (think of inheritance, generic structures like lists, ...)

            Comment


            • #16
              Originally posted by carewolf View Post
              Without STL? Yes, definately. The big win with C++ is classes, templates, a better type-system and constructors/destructors for safer and cleaner state handling.
              This features can still make compilation little slower and you get accused of bad C++ coding, if you don't use STL.
              Better type-system? Until C++11 there wasn't even stdint.h.

              Comment


              • #17
                Originally posted by schmalzler View Post
                What do you mean by "functions"? C++ is much (not all...) about classes, so why not use "classes"?
                And that's one great plus:
                classes with constructors and destructors. RAII. Not having to think about "which objects need to get destroyed in this error case"?
                GCC currently uses macros/static inline functions and so on for "emulating" functionality they get for free in a much more pleasant way when using C++. (think of inheritance, generic structures like lists, ...)
                Why "emulating" classes with structs is so unpleasant?

                Comment


                • #18
                  Originally posted by LightBit View Post
                  Why "emulating" classes with structs is so unpleasant?
                  from a quick google search:
                  http://www.codeproject.com/Articles/...ymorphism-in-C
                  And now try to maintain more complex relations then "Employee inherits Person".

                  And what does stdint.h have to do with type system? That header contains typedefs, nothing more...
                  This is about Weak (C) vs. Strong (C++) type system. If you don't have an idea read the wikipedia articles.

                  Comment


                  • #19
                    Originally posted by schmalzler View Post
                    from a quick google search:
                    http://www.codeproject.com/Articles/...ymorphism-in-C
                    And now try to maintain more complex relations then "Employee inherits Person".
                    GTK+ seems fine and I use this approach in my unfinished cryptographic library.


                    Originally posted by schmalzler View Post
                    And what does stdint.h have to do with type system? That header contains typedefs, nothing more...
                    This is about Weak (C) vs. Strong (C++) type system. If you don't have an idea read the wikipedia articles.
                    Sorry for misunderstanding.
                    Anyway, I prefer weak type system, because strong requires more typing. Don't know why "char *str = (char *)malloc(100)" is better than "char *str = malloc(100)"?

                    Comment


                    • #20
                      Originally posted by LightBit View Post
                      GTK+ seems fine and I use this approach in my unfinished cryptographic library.
                      Yes, it's fine, but C++ takes away a lot of work that may introduce errors if not done properly.


                      Don't know why "char *str = (char *)malloc(100)" is better than "char *str = malloc(100)"?
                      Then take a better example: (everyday problem when using a C lib within C++):
                      Code:
                      void fun(char* c);
                      
                      void use_fun() {
                        char const* str = "Hello const";
                        fun(str);
                      }
                      Is it good that this compiles fine with C (at best you get a warning)? What if fun() modifies the string?

                      Comment

                      Working...
                      X