C++\CLI and STL.NET and clr\safe

[Herby]

Hi,

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.

[beginthreadex]

I would just like to be nosey. I have just read a post from a very nice
person on c++.net and some of the perspective. I have many projects in
classic c++ that enjoy the performance and reliability of c++.

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.

Hi,

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.

--
new

[Herby]

LOL! Talk to my managers!
Iv been crying the same for about 2 months now... but am slowly coming
round to the idea.

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.

[beginthreadex]

Ah, getting paid. That's the best reason listed below. The other is to play
with other .NET requirements. If you need to speak Russian ... it's best to
learn Russian and not sign language.

Thanks for the insight.

LOL! Talk to my managers!
Iv been crying the same for about 2 months now... but am slowly coming
round to the idea.

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.

[Tamas Demjen]

Herby wrote:

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/de...-netprimer.asp

Tom

[Herby]

Yep. Read that today.
That was written in 2004 with the promise of many more follow on
articles, that did not seem to materialise...
Explain yourself Stan Lipman????

[Herby]

Well seems STL.NET will and partially is verifiable

http://forums.microsoft.com/MSDN/Sho...=6116&SiteID=1

You have to install team version of 2005 to get the alpha files of
STL.NET

[Ronald Laeremans [MSFT]]

Herby wrote:

Well seems STL.NET will and partially is verifiable

http://forums.microsoft.com/MSDN/Sho...=6116&SiteID=1

You have to install team version of 2005 to get the alpha files of
STL.NET

No, this was in all versions of Beta 2. It is no longer in any released
version. And in fact what was there for all intents and purposes did not
work all that well. Which is indeed the reason we weren't able to
release it for RTM.

Ronald Laeremans
Visual C++ team

[Michael Viking]

It's all about managers. That's the whole problem; started with the Java
people: market your language to management, not engineers. Genius, but I
think in the end it's bad. Heck, we've got customers demanding software be
written with certain languages. They don't even know anything about the
languages, just various FUD and hype they've read. The fact is, no language
fits every task perfectly.

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" <pr********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

LOL! Talk to my managers!
Iv been crying the same for about 2 months now... but am slowly coming
round to the idea.

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.

[Herby]

Cheers Ronald.

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.

[Herby]

I totally agree.
But for me, i cannot pretend it is going to go away so i have to accept
it now.

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.

[Peter Oliphant]

> 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,...
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" <Th*******@sweden.se> wrote in message
news:OD**************@TK2MSFTNGP12.phx.gbl... It's all about managers. That's the whole problem; started with the Java
people: market your language to management, not engineers. Genius, but I
think in the end it's bad. Heck, we've got customers demanding software
be
written with certain languages. They don't even know anything about the
languages, just various FUD and hype they've read. The fact is, no
language
fits every task perfectly.

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" <pr********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

LOL! Talk to my managers!
Iv been crying the same for about 2 months now... but am slowly coming
round to the idea.

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.

[Ronald Laeremans [MSFT]]

Herby wrote:

Cheers Ronald.

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.

STL.Net will generate verifiable code if you use it on verifiable types
and with verifiable constructs.

Ronald