Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27

Thread: C++ Doesn't Change The Speed Of GCC

  1. #11
    Join Date
    Nov 2007
    Posts
    1,024

    Default

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

  2. #12
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    391

    Default

    Quote Originally Posted by Luke_Wolf View Post
    The article itself says not.
    No, in article Linux kernel compilation was timed.

  3. #13
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    391

    Default

    Quote 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?

  4. #14
    Join Date
    Nov 2012
    Posts
    192

    Default

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

  5. #15
    Join Date
    Sep 2011
    Posts
    141

    Default

    Quote 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, ...)

  6. #16
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    391

    Default

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

  7. #17
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    391

    Default

    Quote 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?

  8. #18
    Join Date
    Sep 2011
    Posts
    141

    Default

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

  9. #19
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    391

    Default

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


    Quote 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)"?

  10. #20
    Join Date
    Sep 2011
    Posts
    141

    Default

    Quote 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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •