c++ as choice for long term application choice.

[miles.jg]

Have a application (custom written for a vetical market) which has been
developed in VB over the last several years. Now that MS has done what MS
does best and is to relegated VB to the twilight zone in feb of 08 I have
decided to rewrite in another language. The application is constatnly being
upgraded with new features and I would like to find someting that would have
long term support, if such is possible. Never would have thought MS would
"disregard" VB. How about VC++. ? It would need to be somewhat on par with
VB as far as the features and capabilities of VB.
Any thoughts from the programming community. ?

Thanks and Regards
JM

 

[Kira Yamato]

Have a application (custom written for a vetical market) which has been
developed in VB over the last several years. Now that MS has done what MS
does best and is to relegated VB to the twilight zone in feb of 08 I have
decided to rewrite in another language. The application is constatnly being
upgraded with new features and I would like to find someting that would have
long term support, if such is possible. Never would have thought MS would
"disregard" VB. How about VC++. ? It would need to be somewhat on par with
VB as far as the features and capabilities of VB.
Any thoughts from the programming community. ?

Thanks and Regards
JM

(1) You must stick with Microsoft
(2) Something with long term support from Microsoft
(3) Something with a rich and growing list of features.

(1)+(2)+(3) => C#

 

[Kira Yamato]

(1) You must stick with Microsoft
(2) Something with long term support from Microsoft
(3) Something with a rich and growing list of features.

(1)+(2)+(3) => C#

Actually, I used incorrect notation here. C# is a sufficient but not
necessary condition for (1), (2) and (3). So, the correct notation
should have been
C# => (1) + (2) + (3).
At least I think that is what Microsoft is trying to do with C#.

The incorrect original statement I used is saying C# is a necessary
condition for (1), (2) and (3), and that is just not true. At least I
hope that is *not* what Microsoft is trying to do with C#.

 

[tragomaskhalos]

(1) You must stick with Microsoft
(2) Something with long term support from Microsoft
(3) Something with a rich and growing list of features.

(1)+(2)+(3) => C#

Since the original code is in VB, the obvious migration
choice is VB.NET (which, all hype and FUD to the
contrary, is effectively identical to C# once you
get beneath the syntax).
VC++ would not be a logical choice in this instance
IMO.

 

[Christopher Pisz]

Since the original code is in VB, the obvious migration
choice is VB.NET (which, all hype and FUD to the
contrary, is effectively identical to C# once you
get beneath the syntax).
VC++ would not be a logical choice in this instance
IMO.

Since when is VC++ a language?
Last I checked it was an old outdated IDE.

C++ will be around for many years to come. I doubt it we can say that much
for the C# language , the MFC library, or .NET libraries

 

[James Kanze]

Have a application (custom written for a vetical market) which has been
developed in VB over the last several years. Now that MS has done what MS
does best and is to relegated VB to the twilight zone in feb of 08 I have
decided to rewrite in another language. The application is constatnly being
upgraded with new features and I would like to find someting that would have
long term support, if such is possible. Never would have thought MS would
"disregard" VB. How about VC++. ? It would need to be somewhat on par with
VB as far as the features and capabilities of VB.
Any thoughts from the programming community. ?

I'm not too familiar with VB, but somehow, I don't think that
C++ addresses the same domains. Off hand, I'd probably look at
Python, or maybe Java (which isn't that bad for small projects).

 

[tragomaskhalos]

Since when is VC++ a language?
Last I checked it was an old outdated IDE.

C++ will be around for many years to come. I doubt it we can say that much
for the C# language , the MFC library, or .NET libraries- Hide quoted text -

It's fairly safe to assume that by "VC++" the OP meant Standard C++ +
MS extensions + the usual libraries (MFC, ATL). In the context of his
question it would make sense to also include C++/CLI.

Perhaps in the long term C++ will indeed outlive these MS-specific
technologies (I'm sure most of us would hope so), but .NET will be
around for a while yet (MFC I'm not so sure about). But the OP is
where he is - he has a VB application that needs to be migrated in a
sensible and cost-effective way. The approach taken by virtually all
organisations in this position is to move the app to C# or VB.NET.

Rewriting any reasonably sized VB application in C++ (and especially
in a form that eschews any MFC or .NET scaffolding) is a significantly
more complex undertaking than the path I suggest - for which automated
conversion tools exist that do at least some of the work for you.

 

[AnonMail2005]

Have a application (custom written for a vetical market) which has been
developed in VB over the last several years. Now that MS has done what MS
does best and is to relegated VB to the twilight zone in feb of 08 I have
decided to rewrite in another language. The application is constatnly being
upgraded with new features and I would like to find someting that would have
long term support, if such is possible. Never would have thought MS would
"disregard" VB. How about VC++. ? It would need to be somewhat on par with
VB as far as the features and capabilities of VB.
Any thoughts from the programming community. ?

Thanks and Regards
JM

I recently began learning C# for a project after previously
programming C++
on both Windows and Linux platforms for a number of years.

The .NET metadata that is kept in a library allows some quite amazing
things
to be done. After creating a C# library, we used a tool that backed
out the
source code directly from the library. The same tool was able to do
the same
except back out VB code from the C# library.

I suspect it would be straight forward to upgrade your VB app to VB.
Net and then
"convert" it to C# via one of these tools.

hth

 

[Victor Bazarov]

I recently began learning C# for a project after previously
programming C++
on both Windows and Linux platforms for a number of years.

The .NET metadata that is kept in a library allows some quite amazing
things
to be done. After creating a C# library, we used a tool that backed
out the
source code directly from the library. The same tool was able to do
the same
except back out VB code from the C# library.

I suspect it would be straight forward to upgrade your VB app to VB.
Net and then
"convert" it to C# via one of these tools.

hth

Nothing I just read says that MS will not "disregard" C# just like
it did VB. And then the OP (or somebody after him) will be stuck
rewriting it again in C## or D# or some such.

V

 

[owebeeone]

Have a application (custom written for a vetical market) which has been
developed in VB over the last several years.

While C++ may need a lot more work (learning curve etc), it is likely
that you will never have to re-write your code for any other reason
other than your code needs a revolution. The question is how much
effort/resources you can afford to re-implement in C++.

As for the .Net languages, I personally am steering away from them -
if I had to move significant chunks of code from C++ I would move to
Java which is also likely going to be around a very long time.

Personally, because I don't have a huge learning curve, I would stick
with C++ and some select libraries like boost or my own Austria C++
plus whatever else I could find that I like.

The problem with a single vendor solution (like VB and .Net - yes
- .Net) is that it will fail if the company fails or changes it's
direction (see VB!). C++ will not fail due to one company failing or
changing direction because there are so many efforts and so much code
available out there that interest is unlikely to flail for a long long
time.

So the question you need to ask yourself is how much resource can I
spend on the re-write and is that enough for a C++ version. If the
answer is no, you may need to look at alternative or hybrid solutions.

 

[AnonMail2005]

Nothing I just read says that MS will not "disregard" C# just like
it did VB. And then the OP (or somebody after him) will be stuck
rewriting it again in C## or D# or some such.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask- Hide quoted text -

- Show quoted text -

You are correct. But IMHO the migration path to VB .Net or
another .Net
language is much easier than converting to C++ directly. I would make
the case of doing this migration first before considering C++.

 

[Victor Bazarov]

[..] But IMHO the migration path to VB .Net or
another .Net
language is much easier than converting to C++ directly. I would make
the case of doing this migration first before considering C++.

If you're walking and want to start moving faster, "migrating" first to
a bicycle, then to a moped, then a motorcycle, and only then a car is
easier from a financial point of view. It doesn't get you away from
the elements and you won't be moving as fast and be as protected (from
collisions with other vehicles) as you could be in a car, though...

If you're listening to a baseball game broadcast by an AM station,
"migrating" to an FM station is much easier than to a satellite TV in
high def... Not as much enjoyment either.

If time to market is the most important, and resources are not too
limited, then migration to both would likely be the most beneficial.
While converting VB to C# is quick and less painful, converting to C++
represents a longer term stable investment.

V

 

[James Kanze]

You are correct. But IMHO the migration path to VB .Net or
another .Net language is much easier than converting to C++
directly. I would make the case of doing this migration first
before considering C++.

Having been burned once, you're going to play with fire again,
just because it's cheaper in the short run. In the long run,
again, you have the choice of converting once to C++, or
converting now to C#, and in ten years to whatever Microsoft
replaces it with, and then again ten years later...

Proprietary languages have their place, and can be justified in
certain circumstances. But they're not appropriate for "long
term" applications, especially when they're only supported by
one major player.

(The issue is obviously not quite that simple, and there are
non-proprietary languages with ISO standards for which no
commercial compiler exists. But you're comparing a language
with an ISO standard and ten or twenty different suppliers with
one with no standard and only one major supplier---a major
supplier known for occasional lapses in support for existing
code.)

 

[Alf P. Steinbach]

* James Kanze:

Having been burned once, you're going to play with fire again,
just because it's cheaper in the short run. In the long run,
again, you have the choice of converting once to C++, or
converting now to C#, and in ten years to whatever Microsoft
replaces it with, and then again ten years later...

Proprietary languages have their place, and can be justified in
certain circumstances. But they're not appropriate for "long
term" applications, especially when they're only supported by
one major player.

(The issue is obviously not quite that simple, and there are
non-proprietary languages with ISO standards for which no
commercial compiler exists. But you're comparing a language
with an ISO standard and ten or twenty different suppliers with
one with no standard and only one major supplier---a major
supplier known for occasional lapses in support for existing
code.)

I'm sorry, that's incorrect: C# is standardized by ECMA and ISO, and the
standard is publicly available for free, from both.

Cheers,

- Alf

 

[Michael DOUBEZ]

James Kanze a écrit :

Having been burned once, you're going to play with fire again,
just because it's cheaper in the short run. In the long run,
again, you have the choice of converting once to C++, or
converting now to C#, and in ten years to whatever Microsoft
replaces it with, and then again ten years later...

Proprietary languages have their place, and can be justified in
certain circumstances. But they're not appropriate for "long
term" applications, especially when they're only supported by
one major player.

Mono provides a good enough support of C#.
http://www.mono-project.com/

Michael

 

[Cholo Lennon]

* James Kanze:







I'm sorry, that's incorrect: C# is standardized by ECMA and ISO, and the
standard is publicly available for free, from both.

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Yeah, C# is standardized, but without dot net framework it is nothing.
It lacks of some kind of standard library(ies).

 

[Alf P. Steinbach]

* Cholo Lennon:

* Alf P. Steinbach:

Yeah, C# is standardized, but without dot net framework it is nothing.
It lacks of some kind of standard library(ies).

Please don't quote signatures (corrected), see the FAQ.

The situation for C# re library is on a par with C++.

The basics of CLI is standardized, again, by ECMA and ISO.


Cheers, & hth.,

- Alf