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 6 2086
Chris Wood wrote: 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/archi...21/218487.aspx, Stan talks
about a translation guide that he's been developing.
HTH
-cd
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?
Thanks again,
-- Chris
"Carl Daniel [VC++ MVP]" wrote: Chris Wood wrote: 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/archi...21/218487.aspx, Stan talks about a translation guide that he's been developing.
HTH
-cd
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?
That part I don't know. I don't believe that it's necessary to use
/clr:pure, but if I'm understanding correctly, what you want to know is if
/clr:oldSyntax will support 64-bit development.
I'd suggest asking on microsoft.priva te.whidbey.cplu splus.codegen.
Information about access to the Whidbey (semi-)private newsgroups can be
found at: http://communities.microsoft.com/new...elcomePage.htm
-cd
> 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/
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 /clr:oldsyntax. 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
"Brandon Bray [MSFT]" <br******@onlin e.microsoft.com > wrote in message
news:eF******** ********@TK2MSF TNGP15.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/
According to the latest MSDN article, such a tool will be release at Whidbey
beta 2
"Chris Wood" <Ch*******@disc ussions.microso ft.com> дÈëÏûÏ¢
news:7B******** *************** ***********@mic rosoft.com... 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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: Hugo |
last post by:
I have a dual boot machine, runs Win XP pro and Win XP Pro 64, XP boots from
C and XP 64 boots from D.
They both have VS 2005 Beta 2 installed.
I have a webapp developed in Win XP (32) which has gone well and runs fine
in XP.
I Now want to get this same app running under IIS on XP 64.
|
by: Dave Vandervies |
last post by:
I just fixed a bug that some of the correctness pedants around here may
find useful as ammunition.
The problem was that some code would, very occasionally, die with a
segmentation violation error. (Not as infrequent as some bugs that
have been discussed here in the past, but maybe once in an overnight
run of the program when it was configured to aggressively exercise the
section that the bug was in.) It was easy enough to trap the...
|
by: Hugo |
last post by:
I have a dual boot machine, runs Win XP pro and Win XP Pro 64, Win XP boots
from C and Win XP 64 boot from D.
They both have VS 2005 Beta 2 installed.
I have a webapp developed in Win XP (32) which has gone well and runs fine
in XP.
I Now want to get this same app running under IIS on XP 64.
|
by: krunalb |
last post by:
Hi,
I am trying to shift unsigned long long value by 64 bits and this is
what i get
#include <stdio.h>
int main()
{
unsigned short shiftby= 64;
|
by: =?Utf-8?B?UGF1bCBQaGlsbGlwcw==?= |
last post by:
I have read many things about this but I haven't got a clear vision on what
to do if anything about this.
I have a system that tries to find holes in my web site. One of the things
it has found and has been sent to me is
an Invalid_Viewstate exception. I will provide the stack trace below. If
you read down the stack trace it talks about "Invalid chararcter in a base-64
| |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |