To C++ or not to C++, that is the question!

C++ programmers who want to write code targeting the CLR are now facing a rather complicated situation – the problem being that there is currently no C++ option that they can safely choose to write .NET code. Of course, there might be a few who would argue that we could use VC++.NET 2003 and use the managed extensions (MC++) – but, and it’s a very big “but” here, the problem is that the MC++ syntax is now obsolete. It will be supported in VC++.NET Whidbey through the /clr:oldSyntax compiler switch, but there is not much probability that it will be supported in future versions like Orcas (hope I spelled it right).

Not only that, when you start coding for Whidbey using C++/CLI, you’d then have to convert all your MC++ syntax code into the new syntax – even though you could get away with leaving some standalone code in the old syntax itself – but again that won’t be a very good idea nor a clean one. Another issue is that because of the differences in grammar between the old syntax and the new syntax, there is no one-to-one conversion option possible. So even if you come up with a few smart regexps and start converting your MC++ code into the new syntax, you’d still have to spend ages going through every single line of code to make sure things are okay.

Of course, now that the March 2004 Public Preview is out, you might be thinking that you could start writing .NET code using C++/CLI, but again you will be faced with a major problem. The C++/CLI compiler is still in a very early stage of infancy and most of the features have either not been implemented yet or been implemented in a slightly buggy manner – which is natural considering that it’s still in an Alpha stage as of now.

Now obviously Microsoft is not really at fault here – they brought out the MC++ syntax for us and got a lot of negative feedback from the developer community on the syntax/grammar. So they are now bringing out a much improved version which has even been standardized by the ECMA, but obviously they’d need time to get it up to shape. So essentially, while they are doing a very nice and civil thing for their trusted developer community, the major shift in syntax/grammar means that C++ programmers are left without a practical option for about an year and a little more.

The options for C++ developers are :-

  1. You could continue writing MC++ code until the C++/CLI compiler matures enough for it to be put to serious use
  2. You could start using the C++/CLI compiler once the first Beta is out
  3. You could stay away from .NET based coding with C++ until Whidbey is out

Of the three options (1) is not very smart and is actually pretty stupid if you consider everything. (2) is a bit risky, but C++ guys usually like to live on the edge and I’d strongly recommend that you go for it – you’d only have to wait another 3 months or so for the beta hopefully. (3) is obviously the safest option if you are okay with using C# for any unavoidable .NET programming requirements you might encounter.

Okay, that’s all I have to say for the moment. Now I’ll have to get Jambo and we’ll have to try and fix all those RSS feed errors that people have been reporting to us. There goes the weekend! *sigh*

Advertisements

11 thoughts on “To C++ or not to C++, that is the question!

  1. Hey Nish,
    I had been exploring the different option available to migrate a c++ code base to the managed code. Till i read your blog i was under the firm belief that Managed C++ was the best option. I guess looking ahead it would be safer to port this code to C#.

  2. Hey Anjoe

    You’d probably have to weigh the pros and cons and choose your best option. If you want to convert the entire code base to managed code, C# would be the better long term option for you. Because if you use MC++ now, you’d then have to re-port to C++/CLI next year or so.

    But if it’s mostly a matter of interop, you’d find it easier to write some MC++ wrappers for the required managed-unmanaged interaction cases. And later on you can port these wrappers to C++/CLI as there won’t be too much code there.

    Nish

  3. Hi Albert

    While convertors will be of some help, we’d still have to go through the entire code because of some basic differences between the old syntax and new syntax.

    Nish

  4. Would you recommend me to cancel my c++ .Net book?
    I mean, it’s not many other major changes in the new version?

    It would be possible to learn from a .net book (FW 1.1) without a large disadvantage for the future?

    PS. Good article

  5. Hi Ole

    Mayeb you should go ahead with your MC++ book, as some of the basic concepts like accessing and using GC objects, data marshalling etc. won’t change in a big way [hopefully]

  6. Thanks for relplying

    I figured, that too, so I ordered Managed C++ and .NET Development by S.R.G. Fraser. It looks pretty good.

  7. Hello Nish,
    Can you pls help me to solve the error:
    : error C2440: ‘type cast’ : cannot convert from ‘DexterLib::IGraphBuilder ^’ to ‘void **’
    1> Cannot convert a managed type to an unmanaged type

  8. i have a c lib with callback function like
    /*****FUNCTION***************************************************
    * NAME : PDLsr_enbhdlr
    * DESCRIPTION : enables the handle function callback_hdlr
    * INPUT : pointer to function
    * OUTPUT : None
    * RETURNS : void
    * CAUTIONS : None
    ****************************************************************/
    void PDLsr_enbhdlr(int (*callback_hdlr)());

    and i have project c++/cli to use it like

    main.cpp
    //
    int CallbackHdlr(void)
    {
    return 0;
    }

    main{
    PDLsr_enbhdlr(&HMPmain::CallbackHdlr);
    }

    but this error i returned

    Error 1 error C2664: ‘PDLsr_enbhdlr’ : cannot convert parameter 1 from ‘int (__thiscall HMPmain::* )(void)’ to ‘int (__cdecl *)(void)’ e:\Visual Studio 2005\Projects\psiHMPLib\psiHMPLib\HMPmain.cpp 30

  9. hi nish,
    i have some win32 dll with me i want to use them with c#
    there is some classes inside DLL.
    i used DLLimportProerty for that

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s