Re:Herb Sutter confirms no more support for C beyond C90 in ...
by klodolph on Thursday May 03, 2012 @04:09PM
(#3925523)
For me, it'd be fine if MSC (Microsoft's C/C++ compiler) supported a good chunk the following features:
* 'restrict' keyword
* C99 inline semantics
* snprintf
* flexible array members
* designated initializers
* UTF-8 string literals without using escape sequences
* compound literals
Now I understand wanting to "focus" on C++, but some of the above are very easy. For example, you can write snprintf as a three line wrapper around _snprintf, and change the parser to accept restrict (it already accepts __restrict). One would hope that since MSC already accepts wide characters, adding UTF-8 support would be fairly trivial. (Right now, you can only put UTF-8 in string literals either by tricking the compiler into thinking that you're using an encoding OTHER than UTF-8, or by using escape sequences). I would also hope that C99 inline semantics are easy to implement.
If we had those easy things, the bigger items (designated initializers, flexible array members, and compound literals) would seem less.
* 'restrict' keyword * C99 inline semantics * snprintf * flexible array members * designated initializers * UTF-8 string literals without using escape sequences * compound literals
Now I understand wanting to "focus" on C++, but some of the above are very easy. For example, you can write snprintf as a three line wrapper around _snprintf, and change the parser to accept restrict (it already accepts __restrict). One would hope that since MSC already accepts wide characters, adding UTF-8 support would be fairly trivial. (Right now, you can only put UTF-8 in string literals either by tricking the compiler into thinking that you're using an encoding OTHER than UTF-8, or by using escape sequences). I would also hope that C99 inline semantics are easy to implement.
If we had those easy things, the bigger items (designated initializers, flexible array members, and compound literals) would seem less.