Chris Wood wrote:
> 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 /clr:pure 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?

> Chris Wood wrote:
>> 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 /clr:pure 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?

"Brandon Bray [MSFT]" <branbray@online.microsoft.com> wrote in message
news:eFYQA0%23pEHA.2696@TK2MSFTNGP15.phx.gbl...
>> Chris Wood wrote:
>>> 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 /clr:pure 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?
>
> 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 /clr:pure 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 /clr:pure are
> not portable (like calling native code). This isn't to say that it cannot
> be
> done with /clr:pure, but it's probably more difficult than one would
> realize. Converting code between /clr:pure 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!
>
> --
> Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
> Bugs? Suggestions? Feedback? http://msdn.microsoft.com/productfeedback/
>
>

> 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