8 ms·

Microsoft to C99 Developers: Use ISO C++

50 points by T-zex 14y ago

excuse-me 14y ago
" If VS supported C99 natively, it would be easier for users to develop and port existing cross-platform applications." In the words of the noted philospher and business expert - "Well duh"
wickedchicken 14y ago
C99 Developers to Microsoft: nope.
- batista 14y ago
  Microsoft to C99 developers: don't let the door hit you on your way out. All 10 of you on the Windows platform.
diego_moita 14y ago
Pelles is a very nice IDE and (LCC based) compiler with C99 & C11 support: http://www.smorgasbordet.com/pellesc/ http://www.smorgasbordet.com/pellesc/
codgercoder 14y ago
Microsoft already filled the world with "C++" programmers by letting/making C programmers use Visual Studio. All of a sudden they could put "C++" on their resumes, even if they were really still doing C coding. That rather muddied the waters, then. Now, C99 is undercut. what about C11?
SoftwareMaven 14y ago
So why not use gcc or mingw? Is it just the IDE or are there other complications? I haven't developed natively on Windows since the Borland TurboC++ days, so I'm kind out out of the loop there.
- breckinloggins 14y ago
  - The VC compiler is actually really good, especially for Windows code (obviously) - Visual Studio is a great IDE but more importantly it's what MS devs are used to. It's harder to attract good MS developers if you don't support Visual Studio - Binary compatibility issues between stuff compiled with gcc/mingw and stuff compiled with VS (??? Someone chime in here if I'm wrong) - Gcc/mingw setup on Windows is perceived as more complex than installing VS
  - jhasse 14y ago
    >- Binary compatibility issues between stuff compiled with gcc/mingw and stuff compiled with VS (??? Someone chime in here if I'm wrong) If you aren't using C++, everything should work fine. I've been using C binaries from VS and mingw together without problems :)
    - excuse-me 14y ago
      'C' doesn't have name mangling Mixing C++ binaries from different compilers is much trickier
- radarsat1 14y ago
  I would like to, but from my experience thus far of writing a C library and using some C99'isms, then doing a bunch of work to port it to Windows: Windows developers are not satisfied with something working on Windows, they want to be able to compile it in Visual Studio or they won't use it. Don't know how generalisable this is, but all I know is that I'm forced to go back and remove any C99 from my code if I want my library to be used on Windows, despite the fact that the binaries I distribute work fine. Well, I can't blame them for wanting to use their tools of choice, but as a developer wanting his work to be compatible with the most popular platform, it's an unfortunate situation.
- mkup 14y ago
  MSVC has very powerful debugger. It is able to inspect STL collections, set conditional breakpoints, break on certain types of exceptions, watch complex expressions, view local variables by mouse hover etc. It can attach to running process, it may be closed-source process with my DLL, and I would be able to do source-level debugging for that DLL. I usually compile outside of IDE (from command line / Far Manager) with custom build script and use MSVC only as a debugger: it has nice feature of opening EXE file as a project workspace. We're stuck with MSVC until gcc and its Windows ports will have a decent GUI debugger.
deleted 14y ago
[deleted]
dsrguru 14y ago
There might be some merit to this. If you want a language that is very portable and has a definition that is compact enough to be fully understood both by you and by programs you might write that operate on source code (static analyzers, interpreters, compilers, etc.), you are probably going to use C89/90 instead of C99 (at least that seems to be what K&R felt--and what K still feels). Otherwise, what advantages do you have in going with pure C99 over the C99 almost subset of ISO C++? Even if you don't really use any language features unique to C++, you would still get some safer library functions and better portability than you would if you limited yourself to the C99 standard.
- TazeTSchnitzel 14y ago
  These are my feelings too. C++ is not supposed to be object-oriented C, rather, it is supposed to be an improved C with more features, one being language support for OOP. You might as well just use C++.
  - tmhedberg 14y ago
    Perhaps C++ is mostly a superset of C in a technical sense, but in practice, it comes with its own idioms, its own conventions, its own design patterns, and its own culture, all very distinct from those of C. There's far more to consider when selecting a programming language beyond "Does Language X have a superset of the features of Language Y?". Plus, sometimes having fewer features is itself a feature. I would say that this is especially true when comparing the slim, minimal design of C with the "everything and the kitchen sink" approach of C++. Not that C++ is never useful in its own right, but that doesn't mean its appropriateness for a given task is always greater than or equal to that of C.
    - TazeTSchnitzel 14y ago
      With C99 and C11 though, C is becoming larger and less minimal. I'm not sure that argument still applies.
  - derleth 14y ago
    > an improved C with more features This mostly means it's incompatible with C even in the parts of the language both of them share. Completely valid and idiomatic C code will therefore not always compile if you use a C++ compiler.
chj 14y ago
vs sucks any way. this decision just makes it even worse.
ComputerGuru 14y ago
We've been using a solution/workaround for ages because it was obvious MS was never going to play ball. Just install ICC (the Intel compiler). It hooks into Visual Studio, is a better compiler for both C and C++ than MSVC, works really well, produces really fast binaries, and does all its magic in the backend. Nothing changes for you, the developer. It's both free for non-commercial development and paid for commercial dev, which makes perfect sense to me.
- dman 14y ago
  Do you also instruct your customers to run on Intel chips for optimal performance?
  - theatrus2 14y ago
    A very good point, as ICC is known to produce very bad code (intentionally) when run on AMD systems.
    - xixi77 14y ago
      There is some truth to that, as it does not do all optimizations that it could; however, in my experience, even on AMD systems, ICC beats MSVC hands down.
    - masklinn 14y ago
      Technically, it does not produce very bad code when run on AMD systems, it produces very bad code for running on AMD systems.
      - excuse-me 14y ago
        It avoids using some performance instructions which it uses on the Intel build and which would work identically on AMD. Their excuse is that they can't guarantee they would work identically on AMD and so resort to much slower un-pipelined code. It's like Ferrari testing a Porsche and only using 1st gear because they can't be sure that other gears would perform in the same way
pkmays 14y ago
Good for Microsoft. If they think something is standardized garbage then they shouldn't have to use it. C99 and C11 look like mutants compared to C89. Too many bad design decisions made by a group of people who weren't involved with the initial standardization. They even did the very thing the guy who _invented_ the language explicitly told their predecessors in no uncertain terms not to do, and reintroduced noalias pointers into the language [1]. [1] http://www.lysator.liu.se/c/dmr-on-noalias.html http://www.lysator.liu.se/c/dmr-on-noalias.html
- stephencanon 14y ago
  Both C99 and C11 add many useful features to the language. I don't love all of the additions, but I use enough of them everyday to consider them a net benefit. It's still a vastly simpler and cleaner language than C++. `noalias` was fundamentally broken, which is why it was never adopted by the committee. Instead, `restrict` was standardized, but `restrict` does not suffer from the problem that Ritchie highlights in the post you linked to. It's also worth noting that C99 fixed some significant oversights in the C90 standard; C99 fully specified integer division for example (C90 left the behavior implementation-defined for negative arguments).
  - pkmays 14y ago
    There are some Good Parts to C99/C11, most of them adopted from Unix and Plan 9. Not surprisingly, most of the bad parts are all inventions. Read the link to dmr's comment again. His argument wasn't so much that noalias was specified incorrectly, it was that the whole idea of adding any kind of alias specifier to the language is against the spirit of C. I agree, and apparently so did the C++ committee. If you want to write FORTRAN, write a FORTRAN spec. Leave C alone.
aidenn0 14y ago
MSVC has been essentially a C++ development environment for almost 2 decades now. Asking for C99 support is a bit like asking for objective C support. MS has made it abundantly clear that it would be unprofitable for them to add C99 support on many occasions before this.
bryze 14y ago
Is anyone really surprised that Microsoft continues this behavior? For the fan-boys (not that I expect there are many): the purpose of standards, whether you like them or not, is to ease development and promote products with actual value - not merely technology lock-in. Having maintained a C compiler for Rabbit Semiconductor and read the C99 standard, I can say it is an improvement on C90. Contrary to certain comments by Microsoft employees in the article claiming irrelevance of C, it remains very relevant to the embedded systems community. If we, as developers, want standards to prevail, we must eschew nonconforming implementations. You've heard of "vote with your dollars", now "vote with your code".
RandallBrown 14y ago
What are some features of C99 and C11 that are not part of C++?
- excuse-me 14y ago
  Most useful is variable size arrays void func(int size) { int array[size];
- stephencanon 14y ago
  Designated initializers, restrict, hexadecimal floating-point literals and conversions. There are some others, but those alone are enough to prevent C++ from being interesting to me.

50 points by T-zex 14y ago

" If VS supported C99 natively, it would be easier for users to develop and port existing cross-platform applications." In the words of the noted philospher and business expert - "Well duh"

wickedchicken 14y ago

C99 Developers to Microsoft: nope.

batista 14y ago
Microsoft to C99 developers: don't let the door hit you on your way out. All 10 of you on the Windows platform.

diego_moita 14y ago

Pelles is a very nice IDE and (LCC based) compiler with C99 & C11 support: http://www.smorgasbordet.com/pellesc/ http://www.smorgasbordet.com/pellesc/

codgercoder 14y ago

Microsoft already filled the world with "C++" programmers by letting/making C programmers use Visual Studio. All of a sudden they could put "C++" on their resumes, even if they were really still doing C coding. That rather muddied the waters, then. Now, C99 is undercut. what about C11?

SoftwareMaven 14y ago

So why not use gcc or mingw? Is it just the IDE or are there other complications? I haven't developed natively on Windows since the Borland TurboC++ days, so I'm kind out out of the loop there.

breckinloggins 14y ago
- The VC compiler is actually really good, especially for Windows code (obviously) - Visual Studio is a great IDE but more importantly it's what MS devs are used to. It's harder to attract good MS developers if you don't support Visual Studio - Binary compatibility issues between stuff compiled with gcc/mingw and stuff compiled with VS (??? Someone chime in here if I'm wrong) - Gcc/mingw setup on Windows is perceived as more complex than installing VS
- jhasse 14y ago
  >- Binary compatibility issues between stuff compiled with gcc/mingw and stuff compiled with VS (??? Someone chime in here if I'm wrong) If you aren't using C++, everything should work fine. I've been using C binaries from VS and mingw together without problems :)
  - excuse-me 14y ago
    'C' doesn't have name mangling Mixing C++ binaries from different compilers is much trickier
radarsat1 14y ago
I would like to, but from my experience thus far of writing a C library and using some C99'isms, then doing a bunch of work to port it to Windows: Windows developers are not satisfied with something working on Windows, they want to be able to compile it in Visual Studio or they won't use it. Don't know how generalisable this is, but all I know is that I'm forced to go back and remove any C99 from my code if I want my library to be used on Windows, despite the fact that the binaries I distribute work fine. Well, I can't blame them for wanting to use their tools of choice, but as a developer wanting his work to be compatible with the most popular platform, it's an unfortunate situation.
mkup 14y ago
MSVC has very powerful debugger. It is able to inspect STL collections, set conditional breakpoints, break on certain types of exceptions, watch complex expressions, view local variables by mouse hover etc. It can attach to running process, it may be closed-source process with my DLL, and I would be able to do source-level debugging for that DLL. I usually compile outside of IDE (from command line / Far Manager) with custom build script and use MSVC only as a debugger: it has nice feature of opening EXE file as a project workspace. We're stuck with MSVC until gcc and its Windows ports will have a decent GUI debugger.

deleted 14y ago

[deleted]

dsrguru 14y ago

There might be some merit to this. If you want a language that is very portable and has a definition that is compact enough to be fully understood both by you and by programs you might write that operate on source code (static analyzers, interpreters, compilers, etc.), you are probably going to use C89/90 instead of C99 (at least that seems to be what K&R felt--and what K still feels). Otherwise, what advantages do you have in going with pure C99 over the C99 almost subset of ISO C++? Even if you don't really use any language features unique to C++, you would still get some safer library functions and better portability than you would if you limited yourself to the C99 standard.

TazeTSchnitzel 14y ago
These are my feelings too. C++ is not supposed to be object-oriented C, rather, it is supposed to be an improved C with more features, one being language support for OOP. You might as well just use C++.
- tmhedberg 14y ago
  Perhaps C++ is mostly a superset of C in a technical sense, but in practice, it comes with its own idioms, its own conventions, its own design patterns, and its own culture, all very distinct from those of C. There's far more to consider when selecting a programming language beyond "Does Language X have a superset of the features of Language Y?". Plus, sometimes having fewer features is itself a feature. I would say that this is especially true when comparing the slim, minimal design of C with the "everything and the kitchen sink" approach of C++. Not that C++ is never useful in its own right, but that doesn't mean its appropriateness for a given task is always greater than or equal to that of C.
  - TazeTSchnitzel 14y ago
    With C99 and C11 though, C is becoming larger and less minimal. I'm not sure that argument still applies.
- derleth 14y ago
  > an improved C with more features This mostly means it's incompatible with C even in the parts of the language both of them share. Completely valid and idiomatic C code will therefore not always compile if you use a C++ compiler.

chj 14y ago

vs sucks any way. this decision just makes it even worse.

ComputerGuru 14y ago

We've been using a solution/workaround for ages because it was obvious MS was never going to play ball. Just install ICC (the Intel compiler). It hooks into Visual Studio, is a better compiler for both C and C++ than MSVC, works really well, produces really fast binaries, and does all its magic in the backend. Nothing changes for you, the developer. It's both free for non-commercial development and paid for commercial dev, which makes perfect sense to me.

dman 14y ago
Do you also instruct your customers to run on Intel chips for optimal performance?
- theatrus2 14y ago
  A very good point, as ICC is known to produce very bad code (intentionally) when run on AMD systems.
  - xixi77 14y ago
    There is some truth to that, as it does not do all optimizations that it could; however, in my experience, even on AMD systems, ICC beats MSVC hands down.
  - masklinn 14y ago
    Technically, it does not produce very bad code when run on AMD systems, it produces very bad code for running on AMD systems.
    - excuse-me 14y ago
      It avoids using some performance instructions which it uses on the Intel build and which would work identically on AMD. Their excuse is that they can't guarantee they would work identically on AMD and so resort to much slower un-pipelined code. It's like Ferrari testing a Porsche and only using 1st gear because they can't be sure that other gears would perform in the same way

pkmays 14y ago

Good for Microsoft. If they think something is standardized garbage then they shouldn't have to use it. C99 and C11 look like mutants compared to C89. Too many bad design decisions made by a group of people who weren't involved with the initial standardization. They even did the very thing the guy who _invented_ the language explicitly told their predecessors in no uncertain terms not to do, and reintroduced noalias pointers into the language [1]. [1] http://www.lysator.liu.se/c/dmr-on-noalias.html http://www.lysator.liu.se/c/dmr-on-noalias.html

stephencanon 14y ago
Both C99 and C11 add many useful features to the language. I don't love all of the additions, but I use enough of them everyday to consider them a net benefit. It's still a vastly simpler and cleaner language than C++. `noalias` was fundamentally broken, which is why it was never adopted by the committee. Instead, `restrict` was standardized, but `restrict` does not suffer from the problem that Ritchie highlights in the post you linked to. It's also worth noting that C99 fixed some significant oversights in the C90 standard; C99 fully specified integer division for example (C90 left the behavior implementation-defined for negative arguments).
- pkmays 14y ago
  There are some Good Parts to C99/C11, most of them adopted from Unix and Plan 9. Not surprisingly, most of the bad parts are all inventions. Read the link to dmr's comment again. His argument wasn't so much that noalias was specified incorrectly, it was that the whole idea of adding any kind of alias specifier to the language is against the spirit of C. I agree, and apparently so did the C++ committee. If you want to write FORTRAN, write a FORTRAN spec. Leave C alone.

aidenn0 14y ago

MSVC has been essentially a C++ development environment for almost 2 decades now. Asking for C99 support is a bit like asking for objective C support. MS has made it abundantly clear that it would be unprofitable for them to add C99 support on many occasions before this.

bryze 14y ago

Is anyone really surprised that Microsoft continues this behavior? For the fan-boys (not that I expect there are many): the purpose of standards, whether you like them or not, is to ease development and promote products with actual value - not merely technology lock-in. Having maintained a C compiler for Rabbit Semiconductor and read the C99 standard, I can say it is an improvement on C90. Contrary to certain comments by Microsoft employees in the article claiming irrelevance of C, it remains very relevant to the embedded systems community. If we, as developers, want standards to prevail, we must eschew nonconforming implementations. You've heard of "vote with your dollars", now "vote with your code".

RandallBrown 14y ago

What are some features of C99 and C11 that are not part of C++?

excuse-me 14y ago
Most useful is variable size arrays void func(int size) { int array[size];
stephencanon 14y ago
Designated initializers, restrict, hexadecimal floating-point literals and conversions. There are some others, but those alone are enough to prevent C++ from being interesting to me.