8 ms·
This is excellent news. MSVC is a big pain in the ass for me, as I tend to write C code (not ++ usually) and Microsoft's C compiler is the one with the worst su
by exDM69 11y ago
This is excellent news. MSVC is a big pain in the ass for me, as I tend to write C code (not ++ usually) and Microsoft's C compiler is the one with the worst support for language level features (out of widely used compilers). E.g. having to move variables to beginning of block (c89 style) is just miserable. A popular option is to compile C code as C++ inside an "extern C" block to stop name mangling, but this isn't too clean either.
I'd also like to have compatibility of some language extension features, such as built-in functions and attributes. In particular, CPU-agnostic intrinsics for common instructions like atomics, popcount or count leading zeros as well SIMD arithmetic would be great.
My favorite C language extension is SIMD vector arithmetic with infix operators. You can get really pretty and portable (!) vector math code written in Clang and GCC using vector extensions, but again, it's not available in MSVC.
For most of my current projects, I have no intent of supporting the (current) Microsoft C compiler. It's not worth the effort.
- Ono-Sendai 11y agoMSVC has those things. __popcnt64 __mm_add_ps etc.. or do you mean something else?
- valarauca1 11y ago>My favorite C language extension is SIMD vector arithmetic with infix operators. You can get really pretty and portable (!) vector math code written in Clang and GCC using vector extensions, but again, it's not available in MSVC. Forgive me as I might be wrong but aren't system intrinsics the same in each compiler? I was under this impression as I wrote a lot of SSE2/3 C99 code for the GCC using MSVC++ documentation it compiles/runs without an issue. (This also before finding the MMX/SSE/AVX docs that intel has which are beautiful). I mean the function/variable type names (for x86_64 at least) are the same for Clang/ICC/GCC/MSVC.
- phkahler 11y ago>> Forgive me as I might be wrong but aren't system intrinsics the same in each compiler? >> I mean the function/variable type names (for x86_64 at least) are the same for Clang/ICC/GCC/MSVC. Yes, all those compilers support the same names for x86_64. Then a different set for ARM NEON, and a different set for PPC AltiVec. What GCC has done is implement another set of names that can be used across all those hardware architectures. To clarify the difference, you can choose - do you want to move your code between different compilers, or different hardware but always with GCC.
- to3m 11y agoVC++ has historically been the odd man out, but it's improved greatly in the last couple of versions. Certainly, VS2013 has reasonable support for a lot of C99 code. My C99 code builds on clang (OS X), gcc (Linux), and VC++ (Windows). Maybe I need to get more adventurous, but what I see as the key improvements (designated initializers, compound literals, declarations (nearly) anywhere) are now in place. Main omissions I've noticed: printf isn't quite the same (no 'z' modifier, the 'n' forms are noticeably inferior), no VLAs.Also, standard library isn't POSIX (which is not an omission but a lot of C code assumes POSIX so you'll probably end up having to deal with this). I'm surprised you mention intrinsics, since VC++ has a wide selection - https://msdn.microsoft.com/en-us/library/hh977022.aspx https://msdn.microsoft.com/en-us/library/hh977022.aspx - and I'd expect, though without proof, the differences between many of those available on both VC++ and gcc/clang to be something you could work around with #define or, failing that, a small inline function (and cross your fingers). Aside from VLAs, which is annoying, you can work around most of these with wrapper functions and #defines. So I've been pleased enough with the latest VC++. As a long time programmer for multiple platforms, I can put up with a certain amount of deprivation, and having to put in a bit of effort doesn't bother me (all that much). But I've noticed a tendency for people to sometimes assume that "multiple platforms" means "ten different types of gcc+POSIX+fork+pthreads". I'm sure that even shiny new C99-friendly VC++ won't make them happy.
- pjmlp 11y ago> But I've noticed a tendency for people to sometimes assume that "multiple platforms" means "ten different types of gcc+POSIX+fork+pthreads". Having done multiple platform C development across Aix, HP-UX, Solaris, GNU/Linux and Windows in the first .com wave, as well as, having some embedded knowledge, it is always interesting that for some people only gcc and now clang exist. As for C99, Microsoft is pretty clear that are only supporting what is required by the C++ standard.
- ch_123 11y agoI believe they have started explicitly targeting C99 support in more recent versions in order to make it easier to port C code developed against gcc or clang. Here's an older article - http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-librar... (I've seen more recent ones, but I can't find an example to hand)
- userbinator 11y agoE.g. having to move variables to beginning of block (c89 style) is just miserable. I actually find this style clearer since all the variables are accounted for at the beginning and it helps when looking for them (and associated comments, if any). You can always open a new block when you need a new set of variables. Do you happen to have started with a more dynamic language which didn't require variables to be declared? That was the case I've seen with most other programmers who preferred creating (often very many) variables only at the point of use.
- autoreleasepool 11y agoI believe creating variables at the point of use was retroactively inherited from C++ in C99. It can be useful feature when not abused.
- Peaker 11y agoWhat would be considered abuse here? Beginning of block variables are generally always worse than as late as possible variables.
- GFK_of_xmaspast 11y agoI learned c in the c89 days as my 3rd or 4th language (after modula-2 and pascal and maybe fortran) and now, in 2015, I can confirm that beginning-of-block variables are in fact just miserable.
- bluecalm 11y agoI share the view that it's more clear to have all the variables declared at the top. The only exception I am making in my code are loop variables but the point doesn't apply to those as you want the smallest scope possible so declaring them at the top of the block where the loop is located is just inferior. I find the style easier to read as you can instantly see what variables will be operated on, what arrays filled etc. It's also quite important for me to know how much stuff is allocated in given block so I don't blow out the stack and having all the things at the top makes it easier to think about. It's probably about being used to it but I found the code with mixed declarations and logic to be inelegant and more difficult to understand.
- yoklov 11y agoHonestly the non-intrinsic SIMD code is a mixed bag. I like the portability compared to intrinsics, but it encourages SIMD antipatterns like using a vector register to store one object (as opposed to using it to step over loops 4/8/16 at a time). It's also less reliable about generating good code IME.
- stinos 11y agoE.g. having to move variables to beginning of block (c89 style) is just miserable Since VS2013 there has been partial C99 support and as such this is not needed anymore, finally.
- jlarocco 11y agoUnfortunately, Microsoft has stated publicly on a few occasions that they have no plans of supporting C99 or C11 outside of what they have to implement anyway for new versions of C++. The article isn't very clear, but I would guess backward compatibility is going to trump adding new features as far as the C compiler goes. I wouldn't mind getting proved wrong, but the article mentions a lot of C++ features they're working on, and doesn't mention an C features they're working on.