Day-before reminder: If you are interested in tablet apps using VC++, check out the livestream starting at 9am U.S. Pacific time tomorrow, or come back later to watch the talks on demand.

Stood me in good stead for a career in computing – even if I didn’t learn C++ until I was in my 20s (and handicapped by having learned C first!)

@Herb, is the committee open to syntax changes to C++ Next to make the callback process nicer?

As much as I like the lamda capture mechanism and don’t wish to be critical there, the whole f( [] ( X& a ) { called_back_with( a ); } ); syntax hurts and makes for inside out code. I don’t think I’ll ever get used to the } ); syntax even, let alone the inside out coding pattern it seems to induce.

I’d love to see more ideas to improve this.

Thanks

Herb, I have this etched into my future template trinkets, but sadly VC as of yet does not support variadiac templates. I would like to express gratitude for all the hard work you and the standards committee have done preparing this wonderful new language to use. Thank You! I’m sure Mr Caves is working diligently on the variadiac template issue, but if you get the chance give him and STL a pat on the back for the ranged for loop added to the beta.

If anyone happens to find the worlds youngest designer as well, can they suggest MS hire her to replace Monty because his latest VS UI update isn’t winning the war. I think this may be our only hope!

@serhan, alternatively, I’m with you, lets just go back to using HiSoft’s C compiler for the Zx Spectrum! I still have the tape and the cool red manual!! It uses a lot less ram than VS, and the UI is just as grey!! What visionaries they were! Oh and hello world compiles to well under 48k too!

Then again, with LLVM gaining Z80 support, we might be able to get clang going on it too! The future is brighter than grey after all!

So lets see if I can contribute my thoughts in a more expressive way.

C++ surely contains most of C, while being more type safe. As such the decision to make C++ the default systems language for Windows makes sense. The C compiler support is then more seen as a kind of migration support.

On the other hand, when you are developing in other higher level languages, regardless if they generate native code or not, C is the ABI used to talk to other languages at the code level.

This and the bias that, unfortunately, many on the open source community have against C++, make that the majority of native libraries are usually developed in C.

Currently there are two camps:
- The ones that don’t care about Microsoft’s lack of support for C99 and choose to support other compilers;
- The ones that are keen in still supporting Microsoft compilers and restraint themselves to C89

This of course complicates matters if, for whatever reason, external C99 source code has to be taken into a project.

The main issue with Herb’s suggestion to go take another compiler (gcc, icc, clang, ..) implies the following:

- increase on the build process’s complexity, as several tool-chains need to be maintained
- possible lack of debugging support with mixed compiler libraries (debug symbols mismatch)
- C runtime compatibility issues

As such, developers like myself, that develop multi-platform software, might consider to rely on a set of C and C++ compilers from a single source, on the use cases where Visual C++ is not a requirement for the project success.

Apple and all UNIX vendors are able to provide both set of compilers, compliant to latest standards.

Given Microsoft’s success on the desktop, one would expect that it would be possible to have the same set of available resources to keep support for both standards.

Of course this is only an issue on projects that need to integrate foreign C99 code, which I do concede, might be a minority on the Windows platform, and Microsoft has to foremost care for its direct costumers.

I hope this has come out better, than on previous comments.

1: is heavily gamed, and completely and utterly meaningless, and
2: shows Java to outrank C++ too. So should Microsoft also deliver a Java compiler?

There are a lot of popular languages around. What I’d like to see from Microsoft isn’t that their compiler tries to implement and support them all, but perhaps just that they make life easier for third-party compilers. Third parties have pretty much given up on implementing SEH, because of obscure patents and lack of documentation, for example.

Ideally, we wouldn’t *need* Microsoft to deliver a C compiler. Ideally, a third-party compiler would be a first-class citizen on Windows.
x
Personally, my priority is C++ (and C++11), and the way things are looking right now, I’m far from impressed with Microsoft on that front either.

C isn’t a huge deal to me. I know it matters to others, but we can’t realistically expect Microsoft to build and maintain a compiler for a language solely because it is popular.

Instead, as I said, I’d like to see more openness on the platform side. Less reliance on undocumented ABIs, so that third party compilers are able to pick up the slack.

I think that there is going to be some overreaction about the lack of official C99 support but not realizing that most of C99 (the really usable parts) are already part of C++98 and C++11. In fact, I think that there is probably only a small set of people who are investing in features that are not a subset of C++98/11. From an academic sense, nobody ever teaches these specialized features anyways. In fact C11 kind of shoots C99 in the foot by making some of these features optional anyways…meaning there are a lot of compilers out there that don’t want to invest in these fringe features. If there was a need, I think that compiling strictly to the C subset of C++98/11 would be better at supporting folks wanting to write truly portable code.

To jump into the C vs C++ camp, I think that they both have their place. Linus has a point about C++ in the sense that if you are not good at implementing object oriented techniques, then it is easy to build these huge abstractions which might actually just end up being bad. But if you have other software that then depends on these abstractions, then you have a real problem. You get into a position where you are stuck with bad abstractions that can’t just get switched out. Then to avoid getting into these problems, then you start to restrict what you can do with the language and ultimately you’re almost back at C style features so why not just use C?

Personally, I think C++ can be an extremely powerful tool for building software but yes you can blow your leg off if you’re not careful. C on the other hand is not as severe because the language is less complicated and supports inherently less complicated abstractions. The point is well written C++ code looks beautiful next to comparable C code. The second point is that many people cannot write beautiful C++ code. To combat that, the new C++ features are going to be able to make it easier to write better C++ code and better code to begin with.

Hopefully the ISO C and C++ committees will work together next time to make C a better subset of C++ while incorporating features that C programmers want. Personally, I’m glad to know that C90 support is being specifically included since I consider that to be the most “official” C dialect around.

Since C has started to evolve more significantly on its own though, i.e. vla’s and generic, C has got worse IMHO, so I’m keen to stop that rot and that is the base of my viewpoint I suppose. I appreciate people have other opinions on that, of course.

@turbo

FWIW, I think you have zero chance of convincing Herb to do much on C here. He has said clearly, if you don’t like it, use another compiler. That’s about as blunt as you get. I support that view in this case, but I also support your right to differ and champion your own view.

I think you might have more joy though if you follow Olaf’s suggestion of listing out what it is from C you find so important, and seeing if other people can offer you C++ work arounds? I imagine you already know them though, but resist that route for other reasons?

As far as I remember, the linkage problem is solved using the extern “C” construct.

Regarding Linus, he’s clearly a talented guy with some great achievements to his name so if he wants to use straight C in his main project, I don’t really object since he clearly gets results with without the distraction of template errors etc. Maybe I’d choose to limit myself too if I did what he does, but I don’t know since I don’t do what he does. His opinionated nature makes me laugh on balance more than it offends me though, in any case. He gets results and things like Git are brilliant.

What I am confident about though, is if I continued to use straight C now myself, I’d die in a swirling mess of pointers and memory allocation errors; so I wouldn’t make the choice to avoid a C++ compiler myself.

I do pity people coming to C++ though who are dieing in a mess of template compiler errors instead. I can see why they think staying with C is better. It’s just not my choice though. I bitch at STL, but I use it, and I think C++ will continue to evolve in a good direction. I’m less sure of that in the case of C.

My hope is Bjarne and Co. can get Concepts into C++Next, which I hear might not be the case? When templates are constrained and the errors from them are understandable, I think their promise will have been delivered.

I think people (without C experience) genuinely just don’t know why some people / projects prefer C over C++.
Neither do I. Sometimes I see C apps that re-implement stuff like strings, vectors, lists and hash_maps in an OO way or use other constructs that’d be much simpler in C++.

Maybe one should describe what C features not in C++11 one is looking for. Low hanging fruit might be easy to get, but lots of people are requesting C++ (and XP) support too.
That said, I don’t get why it has to be en exclusive or. MS is a big company, it should be possible to do more. How come GCC has better C++11 support?

BTW I think Linus has provided good reasons for his arguments. The drapes his arguments in colorful language but there are well thought out arguments in there is you care to look, and not just brush him off because of the inflamatory style of his writing.

I go back and forth between C and C++ enough to know the differences. I much prefer working in C++. There are a few things that C++ could stand to learn from C, but mostly I feel much more comfortable with C++.

The biggest reason I want better C support is to support the billions of lines of C code that is NOT valid C++. That C code is not likely to be rewritten in C++ (or the C++ compatible subset of C) anytime soon (it ain’t broke, we won’t fix it), but it is still being maintained.

Some of the maintainers might start thinking that a 22-year-old standard like C90 might not quite meet their needs (strange, but it might happen), and might start itching for features from a standard that is only 13 years old. I know, they’re being unreasonable to expect that kind of support, but people can be crazy like that.

The result is that there is a lot of really good C code doesn’t work very well (or at all) on Windows. MinGW is ok but not great. You can often hack things to work with MinGW, but that’s just one more roadblock, often tipping the scales and making people decide to not support a Windows version. If Microsoft were to make a bit of an effort at making the Windows platform more compatible with this code, a lot more people would be comfortable using Windows as their platform. At least that’s my take on it.

I am much more concerned with C++11 support. Even with the renewed focus on native development, it still feels like C++ is a second-class citizen inside the Visual Studio team. I understand the C++11 standard is new and that VC2011 was released at a bad time — at just about the same time the standard came out (C++98/VS6 all over again). However, there are features of C++11 that were set in stone long ago. Some even made it into VC2010. Other important ones though are still lacking in VC2011: variadic templates, template alias, initializer lists, delegating constructors, deleted functions, C99 preprocessor — all supported by both GCC and Clang along with some support by other major compilers. Microsoft is no longer the champion of native development and it saddens (and as a Windows developer frustrates) me.

C# has had the spotlight for a long time and C# is a quality language and the love its received shows; but it’s time for Microsoft to focus again on catching up on native development. I would love to see Microsoft take the lead again, but I’ll be content if MS just catches up.

STL is evil. C++ is garbage. To quote Linus:

“Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.”

I can just imagine the C++ committee’s joy at requests like “My C compiler vendor says they’ll only implement features in the C++ standard, so please add _Generic to C++”

No thanks!

But there is some existing C code with an reasonable license out there, which I have to port to C++ or VC like C code. I’m simply bored to port “portable” C Code to windows.

That is great. But not useful for C programmers since you only provide it in C++ compiler.
Maybe you should provide a flag for C++ compiler so that C++ compiler only allows C subset of the language.

http://en.wikipedia.org/wiki/C99

So if the other vendors are able to, why not Microsoft?