I am currently reviewing what is required to convert a current MFC, COM
server application into a .NET application. The objective is to
compile ultimately to clr/safe.
So we are seeking a clear migration path for C++\MFC\COM to .NET.
We have now chosen to select C++\CLI.
We then need to remove the MFC classes such as CString CArray CMap etc
and replace with .NET equivalents. We are now considering replacing
these with STL type classes and have just learned about the pending
release of STL.NET.
Will STL.NET compile to clr\safe ????
When will it be available???
If a C++ application is already using STL, will this be compatible with
STL.NET?
Given native types are changed to managed types
e.g:
Vector<String*>
to
Vector<String^>
Thanks in advance.
Can you tell me why you would choose to take a project from where you are
now and recode into .net? It sounds like a step backwards. It sounds like
you have some good skills in your team and re-doing everything to satisfy
a .net craving sounds a little crazy.
Again, I have NOT ONE PROJECT in .net anything but it does sound
interesting. I would like to know what lead you to your conclusion to step
away from the language that made these other languages and tools.
--
new
Ultimately the component will be used on the internet and in intranets
which are to become 'low trust' environments and so the code must be
verifiable. So its about guaranteeing security and fitting in with
other components that are also .NET.
Long terms as well it should become platform independent( .NET VM )
which COM and MFC never were. I guess they are worried about it
becoming obsolete.
Performance is critical as the application is a type of calculator,
much work over the past 5 years has been related to this aspect. So im
not sure what performance we will lose or possibly gain ???
We also have to replace ODBC with .NET.ADO remove references to the
CRT etc.
If i have produced a .NET C++\CLI STL.NET application that compiles to
clr\safe and it just aint good enough, its not going to be too
difficult to convert it back to un-managed.
Im also concerned about the MFC classes becoming .NET compatible in a
future release, beyond 2005 and native classes being created on the
managed heap!
Its possible after converting it all, my original code will compile to
.NET safe at some later date.
At the end of the day they are paying me to do this and i am learning
alot... Im taking it seriously now.
Thanks for the insight.
> If a C++ application is already using STL, will this be compatible with
> STL.NET?
> Given native types are changed to managed types
> e.g:
>
> Vector<String*>
>
> to
>
> Vector<String^>
At this point this is all that we officially know:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/stl-netprimer.asp
Tom
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=6116&SiteID=1
You have to install team version of 2005 to get the alpha files of
STL.NET
Ronald Laeremans
Visual C++ team
I read the articles in the vc.* and vs.* newsgroups religiously, and I just
don't see how this .NET stuff is making things easier. New changes to the
syntax every version, incompatibilities, framework issues, installation
issues, framework security patches, getting farther abstracted from what's
happening and not being able to debug,...
Meanwhile, people get less and less traction on what they're trying to do,
because they're always upgrading and then needing to modify their code for
the new stuff. When does it end? The fact is, the tools from 5 years ago
gave everybody what they needed to be successful. The only thing needed was
bug fixes, better compliance, better STL, and better code optimization.
I'm not even saying that some of the .NET stuff isn't well thought out or
whatever and it has good points, I'm just saying that the world doesn't need
another proprietary language, and .NET isn't the panacea that the
multi-billion dollar marketing campaign makes it out to be. The world is
short of good, talented programmers, and this is an education problem, not a
"we didn't have the right language" problem.
-Michael Viking
"Herby" <prmar...@gmail.com> wrote in message
news:1132166280.7...@g49g2000cwa.googlegroups.com...
Can you confirm that when STL.NET is released it will be verifiable
safe code?
I could now spend my time replacing MFC classes like CString, CArray
etc with the STL equivalent classes string vector etc.
Can you confirm it will then not be too difficult for me to switch to
STL.NET when it is released?
Thanks.
I am also now seeing a Java component that i originally wrote being
re-written to .NET C# !
The software i am responsible for now works extremely well, i now have
to spend a year re-writing it rather than developing it further.
Im just glad now we have C++\CLI and soon STL.NET. So i do not have to
deviate to far from my original code base.
Replacing the MFC container classes with STL is a general improvement
in any case.
IMHO, Where .NET needs to improve is in very clear migration paths and
tool support for this activity. It seems this is only just beginning
to happen. Im just glad iv wisely held back for a couple of years and
did not jump on the .NET bandwagon else id be now re-writing my managed
extensions code and windows forms. I hope the same fate does not await
C++\CLI ?
For my project i want 100% safe code, not mixed mode, no doubt for some
other applications out there having a hybrid application is going to be
very beneficial, perhaps paralleing the success of C++ where it was a
hybrid with C, proving a clear migration path for C coders.
For me to acheive 100% verifiable code i have to change all my class
declarations to
ref class Point
{
int x;
int y;
}
and all my instantiations to
Point^ p = gcnew Point
This will now not compile unmanaged if i then face a serious
performance issue and am forced( at least for some clients ) to step
back.
Then i would have to go back and change it all to
class Point
{
int x;
int y;
}
.....
Point* p = new Point
It would be far easier for me if a compiler option existed to take the
latter source and map this onto the managed heap. it looks like im
going to have to have ugly macros everywhere...
On a positive note, compiling my original source code unmanaged with
the latest compiler in .NET 2005 has given approx 15% performance gain.
So the C++ compiler has 'developed' over the last 10 years since C++ 6.
One of the problems is that, IMHO, a language should never be called an
'upgrade' if it isn't 100% backwards compatible with the version it is an
upgrade to...
Clearly, if one uses this definition, 2005 is not really an upgrade to
2003...
It's ironic that some of the main purposes behind high-level languages have
been lost - they are no longer machine independent (transportability) and
often must be syntaxically changed to continue using (re-usabilty). While I
really do like the syntax used in 2005, this constant changing (an
oxymoron!) without being backwards compatible makes me wonder if any version
of VS can be relied upon for any length of time to entertain the concept
that a piece of code is actually 'done'. MS has even aggressively announced
that the '__gc' syntax will be removed in the future, thereby rendering the
2003 version useless. How do we know this won't be announced in 2 years with
2005 as well, keeping in mind that the '__gc' syntax was released with a lot
of enthusiasm as well?
[==P==]
PS - At least tell me the Frameworks are backwards compatible, or at least
co-existable, otherwise old software would no longer run...
"Michael Viking" <TheV...@sweden.se> wrote in message
news:ODLAt8v6...@TK2MSFTNGP12.phx.gbl...
Ronald