Re:Rejuvenating the Microsoft C/C++ Compiler
by uxcn on Saturday September 26, 2015 @01:35PM
(#10283725)
I read Chris Lattner's posts. There are definitely things the standards don't specify that people take for granted (twos-complement for example). C is still an order of magnitude easier to parse than C++ though (especially modern). In theory, implementing and maintaining a compiler for it for a platform should be simpler.
Implementing an effective compiler is another concern entirely, but I would still argue that there tend to be more incompatibilities between C++ implementations than C.
Re:Rejuvenating the Microsoft C/C++ Compiler
by pjmlp on Saturday September 26, 2015 @02:57PM
(#10284058)
Yes, parsing is way harder because C++ requires the context aware grammar.
However many C++ incompatibilities are actually caused by C compatibility and the goal of having higher constructs that are copy paste compatible with C but with additional semantics, e.g. structs.
So in both cases, to achieve your portability goal the languages would have to be fully specified.
Re:Rejuvenating the Microsoft C/C++ Compiler
by uxcn on Saturday September 26, 2015 @05:26PM
(#10284474)
C and C++ are admittedly different languages, but I would think more than less of the code for compiling both languages should be the same. I personally can't see how one language would impede the other.
As a C/C++ user, I'm honestly still not sure why a number of C features have yet to be formalized in C++ (e.g. restrict).
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
Many equate "C == what my compiler does", but just like any standardized technology with holes open to implementers to decide upon, portability isn't as people think.