64-bit & Managed C++ vs. C++/CLI

[Guest]

I have a complex codebase developed in Managed C++ that I am not particularly
looking forward to porting to C++/CLI I'd like to know what the most
compelling arguments for doing so are so I can justify the cost. For
example, will Whidbey generate 64-bit assemblies for Managed C++, or only for
C++/CLI? If we have to move to C++/CLI to get 64-bit support, then that's a
pretty good reason to move.

Also, I've heard rumors about a tool that may ship with Whidbey that will
translate Managed C++ into C++/CLI. Is this true? How "smart" will this
tool be? If it exists, is there a beta anywhere I can check out?

Thanks!
-- Chris

 

[Carl Daniel [VC++ MVP]]

I have a complex codebase developed in Managed C++ that I am not
particularly looking forward to porting to C++/CLI I'd like to
know what the most compelling arguments for doing so are so I can
justify the cost. For example, will Whidbey generate 64-bit
assemblies for Managed C++, or only for C++/CLI? If we have to move
to C++/CLI to get 64-bit support, then that's a pretty good reason to
move.

Also, I've heard rumors about a tool that may ship with Whidbey that
will translate Managed C++ into C++/CLI. Is this true? How "smart"
will this tool be? If it exists, is there a beta anywhere I can
check out?

A tool is being developed. Last I heard, exactly how it will be made
available hadn't been worked out, but the plan is to make it available
(possibly through gotdotnet or something like that). The tool's being
developed by Stan Lippman - you can read about it in various entries on his
blog: http://blogs.msdn.com/slippman. In this entry
http://blogs.msdn.com/slippman/archive/2004/08/21/218487.aspx, Stan talks
about a translation guide that he's been developing.

HTH

-cd

 

[Guest]

Thanks Carl; I appreciate your responce.

My concern about 64-bit is that I haven't heard if it will be supported for
Managed C++. I expect that C++/CLI will support it, if only through the
/clrure switch. But is there any support for Managed C++? I was expecting
not, since the syntax is being replaced with C++/CLI. If that's the case I'd
like to know sooner rather than later, so I can budget time for the
migration. Do you have any information on this?

Thanks again,
-- Chris

 

[Carl Daniel [VC++ MVP]]

Thanks Carl; I appreciate your responce.

My concern about 64-bit is that I haven't heard if it will be
supported for Managed C++. I expect that C++/CLI will support it, if
only through the /clrure switch. But is there any support for
Managed C++? I was expecting not, since the syntax is being replaced
with C++/CLI. If that's the case I'd like to know sooner rather than
later, so I can budget time for the migration. Do you have any
information on this?

That part I don't know. I don't believe that it's necessary to use
/clrure, but if I'm understanding correctly, what you want to know is if
/clrldSyntax will support 64-bit development.

I'd suggest asking on microsoft.private.whidbey.cplusplus.codegen.
Information about access to the Whidbey (semi-)private newsgroups can be
found at:

http://communities.microsoft.com/newsgroups/ICP/whidbey/US/welcomePage.htm

-cd

 

[Brandon Bray [MSFT]]

Since I'm here now, I can answer the question. Portability between 32-bit
and 64-bit platforms for binary images is more work than just switching
syntaxes. That said, the new syntax (sometimes called C++/CLI) is the only
syntax that is going to support 64-bit portability. New compilation modes
like /clr:safe and /clrure are only supported for the new syntax.

To get reasonably supported 64-bit portability, you'll need to compile with
the /clr:safe mode. The language subset there is similar to C# with a few
C++ features like templates. Many things that can be done in /clrure are
not portable (like calling native code). This isn't to say that it cannot be
done with /clrure, but it's probably more difficult than one would
realize. Converting code between /clrure and /clr:safe is likely going to
be the same cost as rewriting the code.

Hopefully, that doesn't sound too discouraging. I will say that converting
between the old syntax and the new syntax is not as difficult as it may
sound. I've done it by hand a few times, and I have a rate of about 2000
lines per hour. With the assistance of tools, it's sure to be faster.

Cheerio!

 

[Ronald Laeremans [MSFT]]

Assuming you are willing to have separate images for 32 and 64 bits (like
you have to do for anything native anyway), we do support that fully in
Whidbey.

Including /clrldsyntax. But as Brandon said, I really would encourage you
to port that over as soon as possible. We will try to get a translation tool
out around Bea 2 timeframe.

Ronald Laeremans
Visual C++ team

 

[Justin Shen]

According to the latest MSDN article, such a tool will be release at Whidbey
beta 2