5 ms·

> GCC and GDB have ... switch[ed] from C to (a strict subset of) C++ to simplify at least some of the more painful C hackeries. Interesting! Where can I read m

by i336_ 10y ago

> GCC and GDB have ... switch[ed] from C to (a strict subset of) C++ to simplify at least some of the more painful C hackeries. Interesting! Where can I read more about this? Is it true that gcc compiles using g++? That's rather amusing. :) > "We can drop support legacy compilers and platforms (looking at you, MS-DOS)." > how is that an opportunity when it effectively removes support for platforms. Supporting MS-DOS is something of a challenge now. I've not done any research but I have vague notions that GCC ports aren't really being maintained anymore. Besides that, many platforms (for example BeOS) are stuck on GCC 2.95.3, a rather famous last version using a particular ABI. A lot of stuff is stuck on that GCC version. (I don't know many details, although I'm very interested to learn more if anyone else has any insight.) With the above said, I do disagree with wholesale willingness to summarily sweep legacy platforms off the table. Rust has saved itself some maintenance nightmares because it doesn't support DOS, but it means quite a large number of people are still stuck on C for industrial control system tooling. (Granted, I can't deny that I'm talking about a really tiny niche here...)

pjmlp 10y ago
Yes it is true, all major C compilers are now written in C++. You can find everything related to GCC's C++ transition here: https://gcc.gnu.org/wiki/gcc-in-cxx https://gcc.gnu.org/wiki/gcc-in-cxx On Windows even the C runtime, MSVCRT.dll got re-written in C++ and the C functions are actually extern "C" ones. https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great-c-runtime-crt-refactoring/ https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great... So a kind of small victory for us on the C++ side of the fence on the endless C vs C++ discussions. Now the joke "my compiler compiles yours" has been reversed.
- i336_ 10y ago
  Wow, that's a surprise. I'm really considering learning C++ now... I'm just hugely put off by the long compile times :( (I have 10+ year old hardware)
  - adrianN 10y ago
    The compile times are not that long unless your program is very big. I also have 10 year old hardware.
    - AlphaSite 10y ago
      Its all relative.
    - pg314 10y ago
      I guess it depends on what you're used to. Each time I switch from C to C++, compile times take some adjusting. If you're not careful about how you organise your C++ code (be careful what you put in headers, don't go crazy with templates), compiling can get really slow, even for relatively small projects. Just #include <iostream> and the compiler needs to process 37,799(!) lines and more than a MB of data: echo '#include <iostream>' | g++ -E -x c++ - | wc 37799 104779 1280834 To contrast in C: echo '#include <stdio.h>' | gcc -E -x c - | wc 456 1638 20880 Comparing the compile times of PostgreSQL (C, minutes on an old laptop) and MySQL (C++, 30+ minutes) is also instructive. Maybe when modules are finally introduced, things will improve.
      - majewsky 10y ago
        The numbers seem to depend heavily on your environment, by the way: $ uname -m x86_64 $ source /etc/os-release && echo $NAME Arch Linux $ echo '#include <iostream>' | g++ -E -x c++ - | wc 27336 59448 643240
        pg314 10y ago
        Sure. Mine was macOS Sierra. If your <stdio> is comparable to mine, that's still about 30 times more bytes that the compiler sees for C++ compared to C.
    - i336_ 10y ago
      I'd edit this into the original comment if I could; here seems to be a good spot to put it. I think I should add a bit of context about what I mean by slow compile times: I feel comfortable if I can hit CTRL+S* and have my code rerun or restart within about half a second. At one second, it should either be executing or have output something and finished, and if it takes more than about 10 seconds to get to whatever point I'm prototyping or making a decision on, I get jittery. It's partly because I have a ridiculously short feedback loop, but also because I am (for some reason) sensitive to interactivity latency and I prioritize responsiveness extremely highly. So long compile times tend to lean on those buttons and make me uncomfortable. With this in mind, the only C++ experience I've had yet was doing some modifications to the Dillo web browser, which was the main web browser I was running on the 800MHz AMD Duron box I used between 2012-2014 (the same one I described in https://news.ycombinator.com/item?id=13344332 https://news.ycombinator.com/item?id=13344332). It was a lot of fun - I modified the tab bar so tabs could be dragged around, moved between windows, etc :D - but the compile times were around 3 seconds! This was just for the test harness I built which had an absolute minimum of code in it; I was also using GCC precompiled headers for literally everything (my prototype code was a ~300 line .cpp file, no headers or anything). This was a really big adjustment for someone used to tcc (~10ms compile time) or gcc (~300ms compile time) who felt that gcc took juuuust a bit too long to do its thing. I've seen C and C++ code compile on friends' i3 boxes (haven't seen what an i7 can do yet) and been amazed. I think when I have a machine like that I'll probably be able to seriously get into the language. (I actually have an i3 here but it had a memory failure several months ago, hopefully I can get some new DIMMs for it soon and see if the motherboard actually still works.) -- * About ^S - I'm yet to play with Emacs which I understand has two keystrokes to save files; I mostly use Vim because it's installed everywhere. I far prefer ^S over ESC (Press)Shift ; (Release)Shift w Return i/a.

by i336_ 10y ago

pjmlp 10y ago

Yes it is true, all major C compilers are now written in C++. You can find everything related to GCC's C++ transition here: https://gcc.gnu.org/wiki/gcc-in-cxx https://gcc.gnu.org/wiki/gcc-in-cxx On Windows even the C runtime, MSVCRT.dll got re-written in C++ and the C functions are actually extern "C" ones. https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great-c-runtime-crt-refactoring/ https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great... So a kind of small victory for us on the C++ side of the fence on the endless C vs C++ discussions. Now the joke "my compiler compiles yours" has been reversed.

i336_ 10y ago
Wow, that's a surprise. I'm really considering learning C++ now... I'm just hugely put off by the long compile times :( (I have 10+ year old hardware)
- adrianN 10y ago
  The compile times are not that long unless your program is very big. I also have 10 year old hardware.
  - AlphaSite 10y ago
    Its all relative.
  - pg314 10y ago
    I guess it depends on what you're used to. Each time I switch from C to C++, compile times take some adjusting. If you're not careful about how you organise your C++ code (be careful what you put in headers, don't go crazy with templates), compiling can get really slow, even for relatively small projects. Just #include <iostream> and the compiler needs to process 37,799(!) lines and more than a MB of data: echo '#include <iostream>' | g++ -E -x c++ - | wc 37799 104779 1280834 To contrast in C: echo '#include <stdio.h>' | gcc -E -x c - | wc 456 1638 20880 Comparing the compile times of PostgreSQL (C, minutes on an old laptop) and MySQL (C++, 30+ minutes) is also instructive. Maybe when modules are finally introduced, things will improve.
    - majewsky 10y ago
      The numbers seem to depend heavily on your environment, by the way: $ uname -m x86_64 $ source /etc/os-release && echo $NAME Arch Linux $ echo '#include <iostream>' | g++ -E -x c++ - | wc 27336 59448 643240
      - pg314 10y ago
        Sure. Mine was macOS Sierra. If your <stdio> is comparable to mine, that's still about 30 times more bytes that the compiler sees for C++ compared to C.
  - i336_ 10y ago
    I'd edit this into the original comment if I could; here seems to be a good spot to put it. I think I should add a bit of context about what I mean by slow compile times: I feel comfortable if I can hit CTRL+S* and have my code rerun or restart within about half a second. At one second, it should either be executing or have output something and finished, and if it takes more than about 10 seconds to get to whatever point I'm prototyping or making a decision on, I get jittery. It's partly because I have a ridiculously short feedback loop, but also because I am (for some reason) sensitive to interactivity latency and I prioritize responsiveness extremely highly. So long compile times tend to lean on those buttons and make me uncomfortable. With this in mind, the only C++ experience I've had yet was doing some modifications to the Dillo web browser, which was the main web browser I was running on the 800MHz AMD Duron box I used between 2012-2014 (the same one I described in https://news.ycombinator.com/item?id=13344332 https://news.ycombinator.com/item?id=13344332). It was a lot of fun - I modified the tab bar so tabs could be dragged around, moved between windows, etc :D - but the compile times were around 3 seconds! This was just for the test harness I built which had an absolute minimum of code in it; I was also using GCC precompiled headers for literally everything (my prototype code was a ~300 line .cpp file, no headers or anything). This was a really big adjustment for someone used to tcc (~10ms compile time) or gcc (~300ms compile time) who felt that gcc took juuuust a bit too long to do its thing. I've seen C and C++ code compile on friends' i3 boxes (haven't seen what an i7 can do yet) and been amazed. I think when I have a machine like that I'll probably be able to seriously get into the language. (I actually have an i3 here but it had a memory failure several months ago, hopefully I can get some new DIMMs for it soon and see if the motherboard actually still works.) -- * About ^S - I'm yet to play with Emacs which I understand has two keystrokes to save files; I mostly use Vim because it's installed everywhere. I far prefer ^S over ESC (Press)Shift ; (Release)Shift w Return i/a.