Eric, On Jan 23, 2014, at 7:00 PM, Eric Botcazou <ebotca...@libertysurf.fr> wrote:
>> One other point I must make is in regards to clang's Objective-C support vs. >> that of GCC. GCC regards Objective-C as a second class language and has >> done so for some time. Objective-C, according to recent statistics has >> surpassed C++ in the number of developers using it (see this link >> http://www.i-programmer.info/news/98-languages/4462-objective-c-overtakes-c >> -in-tiobe-index.html). > > I think that neither GCC nor any other compilers can reasonably compete with > clang when it comes to Objective-C given that clang is effectively the > reference implementation of the language through the connection with Apple. Granted, however, at the very least GCC should consciously ramp up it’s support for Objective-C. Currently the Objective-C implementation in GCC is woefully out of date as it doesn’t include basic support for ARC. >> Clang has, in my experience, at least the above two advantages over GCC. My >> project is a free software project, but, yet, we are already starting to >> shift towards using Clang as our primary compiler for the above two reasons >> among others. It will not surprise me if I see more projects go the same >> way. > > Your case (implementation of Cocoa + Objective-C parser) is very specific > though so generalizing from it alone seems a bit fast. I’m not so sure about that. My point was that GCC in general is not built in a modular fashion. This is a shortcoming, no matter how specific, that clang doesn’t have. The ability to use the compiler’s parser in applications outside of the compiler is an extremely powerful advantage that clang offers and is used in multiple places in clang’s own suite of software. The static analyzer uses the parser. On Mac OS X Xcode uses the parser to provide contextual feedback to the user while editing the source code and also uses it to colorize the source for easy reading. So, yes, while I’m giving a very specific example what I’m referring to is an advantage. What I can say is that something so trivial which I learned in my first course in Computer Science course at the University of Maryland where I went to school nearly 20 years ago should be reflected in GCC, yet it is not. I found this surprising at the time I attempted to create the parser and I still do today. >> Is it enough to "win" based on philosophical grounds, but lose on technical >> ones? And if GCC loses on technical grounds aren't you, in effect, losing >> the war since fewer people will end up using your stuff since it doesn't do >> what they need or want? I don't believe that making technical decisions on >> the basis of political ends really wins anything. A message earlier in >> this same thread bears out that many technical decisions on GCC were, in >> fact, made for political reasons and that GCC should carefully consider >> which ones should be rescinded. > > Why do you think that there is a war? It's at most a competition between > projects with a different focus and different strengths. I wasn’t referring to a war between clang and gcc. I was referring to the war that the FSF openly has with proprietary software. GCC’s policies were specifically designed to prevent proprietary software from leveraging it, as stated by RMS and other people on this list. I believe this was done because of the position of GCC at the time as the only free software compiler of any reasonable usability. That situation has now changed and GCC can no longer rely on it’s position and be assured that it will be the most commonly used compiler on systems which promote Free Software. I don’t believe these policies made sense then and I don’t believe they make sense now, especially given clang’s growing prominence. I believe it is better to compete on functionality and make certain people want to use GCC because it offers more features and better features than clang, not because of any political agenda. > -- > Eric Botcazou Gregory Casamento
