7 ms·

I disagree. Competition is good. Don't want to end up with every C/C++ compiler being a clang skin in the same way as (almost) every browser is a chrome skin.

I disagree. Competition is good. Don't want to end up with every C/C++ compiler being a clang skin in the same way as (almost) every browser is a chrome skin. And for what it's worth cl compiles faster for me than even clang-cl. I like having both available though.

ch_123 5y ago
Many of the proprietary C++ compilers (Intel included) are just repackaging of the EDG front end. The monoculture has existed for a long time in the C++ world due to the complexity of implementing the language to spec. Honestly, I think it will be great to have one less set of compiler-specific oddities to worry about.
- MauranKilom 5y ago
  MSVC does not use EDG for the frontend as far as I'm aware. IntelliSense does, though.
  - bumblebritches5 5y ago
    Not anymore, they changed that in the last few years
- account42 5y ago
  Funnily, the only reason I ever used ICC was as a linter since it was the most easily available EDG-based commpiler for me and different frontends help find different bugs.
volta83 5y ago
> Don't want to end up with every C/C++ compiler being a clang skin in the same way as (almost) every browser is a chrome skin. Why not ? There is one open C++ spec, that's really hard to implement, so we have a dozen C++ compilers that are impossible to support properly because they each have their own set of different ten thousand bugs. The value of supporting all of this is really small in practice, and the cost for everybody involved is huge. Having a single, e.g., C++ parser with a single set of bugs is a much better value proposition for C++ programmers.
- lenkite 5y ago
  Clang is lagging behind in C++ 20 support while MSVC is miles ahead. LLVM is also getting slower and slower every release.
  - volta83 5y ago
    So? I don't see how focusing the available manpower on one implementation instead of splitting it over 10 different implementations would make this worse. I do see how it would make this much better. What one implementation lacks, another implementation provides. This is a weakness of the current ecosystem. Most software projects restrict themselves to the minimum common denominator, and splitting manpower across compilers lowers it.
    - logicchains 5y ago
      You sound like you haven't worked with many BigCo projects. Clang is turning into an "enterprise" junkyard due to too many cooks spoiling the broth, crumbling so much under the weight of its own complexity that 2022 is almost here and support for C++20 still isn't anywhere near complete (unlike GCC). The more parties that get involved, the worse the code will get. Clang already has more people working on it than MSVC, yet MSVC is iterating faster; this suggests a fundamental problem with the architecture or development processes of Clang, which is not something that will be fixed by more hands on deck (remember the mythical man-month).
- account42 5y ago
  We did have one major C++ compiler on Windows (MSVC) and one major C++ compiler elsewhere (GCC) and they both stagnated in many areas before Clang came along and forced them to advance to stay competitive.
  - pjmlp 5y ago
    GCC wasn't elsewhere. Up to 2005 I was using UNIX own C++ compilers, meaning aCC, xlC, SunPRO. Then there were Microchip, ARM, TI,...
danuker 5y ago
> Competition is good. On the other hand, collaboration is also good. Why waste time reinventing the wheel?
- marcos100 5y ago
  Wasn't LLVM reinventing the wheel at the time? They could just collaborate to GCC.
  - _flux 5y ago
    Maybe if GCC project wasn't opposing the ability to easily integrate third-party tools we wouldn't have LLVM to begin with.
  - ch_123 5y ago
    They wanted to, but RMS wasn't interested at that time: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00594.html https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... I have also been told by more than one person that does professional compiler development that GCC's codebase is very difficult to work with. At least some commentary I've read suggests that this was a deliberate choice on the part of the GNU project.
    - kps 5y ago
      > I have also been told by more than one person that does professional compiler development that GCC's codebase is very difficult to work with. Add another. (Now-former professional compiler developer.) > At least some commentary I've read suggests that this was a deliberate choice on the part of the GNU project. This is the ‘RMS loophole’ in the GPL. In theory you can do what you want with the source; in practice you need help from the insiders.
    - marcos100 5y ago
      Sure, I'm not denying any problems with the GCC codebase and/or how RMS handles GNU software. Just pointing that reinventing the wheel is not necessarily a bad thing or a waste of time.
justicezyx 5y ago
Well competition is good for consumers but is not for the actual market players. And what's the point of competing in the compiler space?
- jabl 5y ago
  > And what's the point of competing in the compiler space? To an extent, processor vendors sell CPU's based on how they perform on SPEC{int,fpu}. So what matters is not how fast your HW is, but rather on how fast the combination of HW + compiler is.
bigbillheck 5y ago
> Don't want to end up with every C/C++ compiler being a clang skin I've wasted too much of my life dealing with compiler differences, and I certainly do want that.

ch_123 5y ago

Many of the proprietary C++ compilers (Intel included) are just repackaging of the EDG front end. The monoculture has existed for a long time in the C++ world due to the complexity of implementing the language to spec. Honestly, I think it will be great to have one less set of compiler-specific oddities to worry about.

MauranKilom 5y ago
MSVC does not use EDG for the frontend as far as I'm aware. IntelliSense does, though.
- bumblebritches5 5y ago
  Not anymore, they changed that in the last few years
account42 5y ago
Funnily, the only reason I ever used ICC was as a linter since it was the most easily available EDG-based commpiler for me and different frontends help find different bugs.

volta83 5y ago

> Don't want to end up with every C/C++ compiler being a clang skin in the same way as (almost) every browser is a chrome skin. Why not ? There is one open C++ spec, that's really hard to implement, so we have a dozen C++ compilers that are impossible to support properly because they each have their own set of different ten thousand bugs. The value of supporting all of this is really small in practice, and the cost for everybody involved is huge. Having a single, e.g., C++ parser with a single set of bugs is a much better value proposition for C++ programmers.

lenkite 5y ago
Clang is lagging behind in C++ 20 support while MSVC is miles ahead. LLVM is also getting slower and slower every release.
- volta83 5y ago
  So? I don't see how focusing the available manpower on one implementation instead of splitting it over 10 different implementations would make this worse. I do see how it would make this much better. What one implementation lacks, another implementation provides. This is a weakness of the current ecosystem. Most software projects restrict themselves to the minimum common denominator, and splitting manpower across compilers lowers it.
  - logicchains 5y ago
    You sound like you haven't worked with many BigCo projects. Clang is turning into an "enterprise" junkyard due to too many cooks spoiling the broth, crumbling so much under the weight of its own complexity that 2022 is almost here and support for C++20 still isn't anywhere near complete (unlike GCC). The more parties that get involved, the worse the code will get. Clang already has more people working on it than MSVC, yet MSVC is iterating faster; this suggests a fundamental problem with the architecture or development processes of Clang, which is not something that will be fixed by more hands on deck (remember the mythical man-month).
account42 5y ago
We did have one major C++ compiler on Windows (MSVC) and one major C++ compiler elsewhere (GCC) and they both stagnated in many areas before Clang came along and forced them to advance to stay competitive.
- pjmlp 5y ago
  GCC wasn't elsewhere. Up to 2005 I was using UNIX own C++ compilers, meaning aCC, xlC, SunPRO. Then there were Microchip, ARM, TI,...

danuker 5y ago

> Competition is good. On the other hand, collaboration is also good. Why waste time reinventing the wheel?

marcos100 5y ago
Wasn't LLVM reinventing the wheel at the time? They could just collaborate to GCC.
- _flux 5y ago
  Maybe if GCC project wasn't opposing the ability to easily integrate third-party tools we wouldn't have LLVM to begin with.
- ch_123 5y ago
  They wanted to, but RMS wasn't interested at that time: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00594.html https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... I have also been told by more than one person that does professional compiler development that GCC's codebase is very difficult to work with. At least some commentary I've read suggests that this was a deliberate choice on the part of the GNU project.
  - kps 5y ago
    > I have also been told by more than one person that does professional compiler development that GCC's codebase is very difficult to work with. Add another. (Now-former professional compiler developer.) > At least some commentary I've read suggests that this was a deliberate choice on the part of the GNU project. This is the ‘RMS loophole’ in the GPL. In theory you can do what you want with the source; in practice you need help from the insiders.
  - marcos100 5y ago
    Sure, I'm not denying any problems with the GCC codebase and/or how RMS handles GNU software. Just pointing that reinventing the wheel is not necessarily a bad thing or a waste of time.

justicezyx 5y ago

Well competition is good for consumers but is not for the actual market players. And what's the point of competing in the compiler space?

jabl 5y ago
> And what's the point of competing in the compiler space? To an extent, processor vendors sell CPU's based on how they perform on SPEC{int,fpu}. So what matters is not how fast your HW is, but rather on how fast the combination of HW + compiler is.

bigbillheck 5y ago

> Don't want to end up with every C/C++ compiler being a clang skin I've wasted too much of my life dealing with compiler differences, and I certainly do want that.