Good riddance to /clr:oldSyntax

As I already mentioned in my blog post about tech-ed day 3, the C++ compiler switch /clr:oldSyntax will be deprecated with the release of Orcas.

This is a good thing.

What is ‘managed extensions for C++’?

If you know what Managed Extensions for C++ is, you can skip this section. If you don’t, then this is for you.

‘Managed extensions for C++’ is the syntax that made it possible to program managed .NET code in versions 2002 and 2003 of Visual C++.

The syntax was designed with the idea in mind to be as compatible with the existing ISO C++ standard as possible. For those of you who don’t know, this means among other things that you are constrained in the naming convention of your keywords.

Names of non-standard keywords have to start with a double underscore, e.g. __gc.

Any kind of  pointer is dereferenced with *, and you use & to pass the address of a variable.

There is a lot of other stuff, but this is the most visible part to the programmer.

Why does managed extensions suck

There are 2 major reasons why MC++ has a significant amount of – what we in the trade call – suckage.

It is butt-ugly

When programming, I don’t mind having to use the occasional keyword with leading __, because it draws attention to a special feature, and it is not too obtrusive anyway.

Now consider a source file that has __gc, __nogc, __pin __whatever on every other line. It is very obtrusive, it is a lot of syntactical noise, and it makes it very hard to read.

Now consider reading your way through thousands of lines of code like that.

It is ambiguous

An essential part of being able to maintain a code base is the ability to read it and to know what you are looking at.

MC++ fails this test miserably.

Consider the following example:

T * t = new T();

Is T managed or not? You cannot tell by looking at the code. You actively have to track down the declaration of T and find out.

Suppose you want to adapt come piece of code that uses T, but you have no idea what the type of T is.

This is a bit akin to a situation where you have screws and nails to join 2 pieces of wood together, but you can’t tell the difference by looking at them. You can either walk to the box they came from and read the label, or you just take the hammer, try to bash it into the wood and if that fails, it must have been a screw, right?

That is exactly what you would have to do if you want to adapt that piece of code, only the wood is the application, the screw or nail is your change, and the hammer is the compiler.


Along came C++/CLI. It is the new C++ binding for writing .NET code. It has an elegant syntax, and is easy to use and learn.

It uses ^ and % for managed code instead of * and &, and gcnew instead of new. There are other differences, but they are all for the good.

Of course there are a couple of complainers that do not like the fact that it is an extension to the C++ syntax, instead of following the old rules.

What does /clr:oldSyntax do?

It is a compiler switch that allows Visual C++ 2005 to compile C++ managed code that uses the old syntax.

It is not perfect, and there are some subtle behavior changes compared to VC2003, but most of the time it works.

Why does /clr:oldSyntax have to die

That switch was created to give early adopters the time to migrate away from the MC++ syntax.

The reasons that this switch really has got to go away are:

  • A lot of toolkits and libraries are distributed as source code. If MC++ would remain a valid syntax, new code would be written every day, and the C++ source code world would eventually split in 2 pieces. This would be bad for code reuse, bad for people trying to learn C++ for .NET that would have to learn 2 completely unrelated languages.

  • It is not perfect anyway. In the public newsgroups I helped a few people migrate their codebase to VC++2005 using the /clr:oldSyntax, but this is only a syntax patch. There are a couple of nuances that make the behavior of the compiled code slightly different from what it used to be.
    Apart from that, there are a couple of bugs in it, so it is far from perfect.

  • It is a significant burden on the compiler from end. The compiler has to be able to parse 2 different syntaxes for doing the same thing. This makes it more complex, and could lead to bugs.

  • It is a significant cost to Microsoft, because the whole part of the front end that supports the switch has to be maintained, updated and tested with each new release of VC++. This is pretty stupid since it keeps a language feature alive that they want dead anyway.


Microsoft warned in 2003 that C++/CLI would replace MC++, so you can’t claim that you didn’t see this coming.

/clr:oldSyntax is dead. Get over it or fade away.

If you are one of the early adopters, this sucks. I know it does, and it should not have happened like this, but it did anyway.

Microsoft made a serious mistake by developing MC++ in the first place, but they have to make this hard decision.

It sucks for the early adopters, but if Microsoft does not remove the switch, they have to spend a lot of money to keep the few happy.

At the same time they would hurt the C++ .NET adoption by fragmenting the available technology. This would also split the community and cost the industry a load of money because programmers would have to learn 2 languages.

This would be a lose – lose situation, so they have no choice to bite the bullet. They cannot do anything else.

4 thoughts on “Good riddance to /clr:oldSyntax”

  1. I am absolutely agreee with you. I work in company wich uses this syntax and we`re tring to migrate C# but our CEO does not want to do this.

  2. I am a little late to this party but how in the God’s name do I remove this compiler option from the set of compiler switches? I have migrated my project to VS 2008 and I get that dreaded D9035 warning which says that the /clr:oldSyntax option will be deprecated in a future release. Ok I get that but how do I remove it?

  3. There are 2 ways that spring to mind. The first is that /clr:oldSyntax is configured under configuration properties ->general->Common Language Runtime Support which could still be set to ‘Use common language, old syntax.

    The other place where it could be specified would be under configuration properties ->c++->command line

    But my money would be on the first option.
    NOTE: this can also be specified on a file by file basis.
    So first check the project settings. if you don’t find it there, have a look for which file generats this problem, and then look at the file settings.

Leave a Reply

Your email address will not be published. Required fields are marked *