5 ms·
Last time I checked their custom C++ parser was not able to get even some simple templates. Finally they ditched it in favor of clang. Way to go!
by koja86 10y ago
Last time I checked their custom C++ parser was not able to get even some simple templates. Finally they ditched it in favor of clang. Way to go!
- abstractbeliefs 10y agoGreat news for developers to get better syntax highlighting, but another nail in the coffin for gcc, sadly. This exact topic notoriously came up last year where emacs wanted to use exported gcc datastructures to highlight code. This proposal was disallowed by rms sticking so dogmatically to his core values that one GNU project ended up not being able to interact with another, for fear of proprietary vendors doing so. While I fully understand the technical background to what exporting such data would enable those acting in bad faith to the letter of the license, whats happened here is that 1) emacs users didn't get better highlighting 2) kdevelop never had a chance to even consider gcc as a result and 3) gcc is now failing to compete with another compiler that it really needs to. What's better, a dead but libre compiler that doesn't interop, or one that has a degree of compromise while still having an effective license that risks proprietary vendors "freeloading" on some good work?
- fithisux 10y agoC++ is broken anyway. Rust and/or D would be a better fit. C11 is enough. No nail in the coffin of gcc.
- abstractbeliefs 10y agoWhile I don't write and don't like C++, I don't understand why major foss projects choosing clang over gcc due to a philosophical spat is anything other than damning. gcc should be fighting hard to continue to provide features competitive to clang while remaining true to it's values, but instead it has opted out of this for hypothetical purity (exporting the data in question is within the license terms and does not require changes in gcc itself, it can be implemented as a plugin, rms just doesn't like it and discourages loudly its implementation as it simply makes it easier for proprietary tools to use it. The situation is quite similar to dynamic linking).
- pnathan 10y ago> While I fully understand the technical background to what exporting such data would enable those acting in bad faith to the letter of the license, whats happened here is that 1) emacs users didn't get better highlighting 2) kdevelop never had a chance to even consider gcc as a result and 3) gcc is now failing to compete with another compiler that it really needs to. Yes, that is not the most beautiful moment in the libre software movement. I'm pretty sad about it.
- marktangotango 10y ago> 3) gcc is now failing to compete with another compiler that it really needs to. I'm not sure this is true, is gcc really competing with clang? I personally don't perceive there to be competition. I'm not clear on the emacs situation though, is emacs unable to call out to clang for metadata because of the license? Regardless, correctly parsing c++ is just about the toughest problem there is when it comes to parsing programming languages. Besides clang, gcc, and the parsers in open source projects like qt creator, kdevelop (these two used to be related iirc, but now both are clang i believe), and eclipse cdt, there aren't any free ones. All the rest are closed source. Last I heard microsoft licensed the c/c++ parser they use from a third party. There's value in being able to parse c++ correctly, clang is really exceptional in addressing tool support in this way.