porting from C++Builder

  • Thread starter Thread starter emavisu
  • Start date Start date
E

emavisu

Dear guys,
I'm in trouble having to port my project from C++Builder6 to VisualC++.
Has anyone of you idea if there are any tools to help my doing this job?
My current project is widely using VCL and these 2 IDE (C++Builder and
VisualC++) seems to be so far each other that I can hardly think to find out
a tool to "automatically" perform something for me.
Thank you.
 
emavisu said:
Dear guys,
I'm in trouble having to port my project from C++Builder6 to VisualC++.
Has anyone of you idea if there are any tools to help my doing this job?
My current project is widely using VCL and these 2 IDE (C++Builder and
VisualC++) seems to be so far each other that I can hardly think to find out
a tool to "automatically" perform something for me.
Thank you.
Click to expand...

emavisu:

Visual C++ is a compiler, not a GUI framework. It is actually a compiler for
three languages: C, C++ and C++/CLI.

If you want to create a GUI program using Visual C++ you have to decide whether
you want a plain Win32 application (using C or C++), MFC application (using
native C++) or a .NET application (using C++/CLI).

The porting issues will be completely different in these three cases. But in
each case, before you start, you should try to separate the core functionality
of your C++Builder6 applications from the GUI part. This core functionality can
then be used in Visual C++.

[If you want to go the .NET route, you might consider whether you want to write
the GUI part of your application in C#, or even rewrite everything in C#.]
 
Dear guys,
I'm in trouble having to port my project from C++Builder6 to VisualC++.
Has anyone of you idea if there are any tools to help my doing this job?
My current project is widely using VCL and these 2 IDE (C++Builder and
VisualC++) seems to be so far each other that I can hardly think to find
out
a tool to "automatically" perform something for me.
Thank you.
Click to expand...
C++Builder (and Delphi) VCL is not compatible with MFC/.NET in any way.
The only thing to do is continue with Builder or do David Wilkinson has
answered you.

VCL model is near to .NET Windows Forms model (Same person did it), but
completelly incompatible because VCL is built in Pascal and .NET is built
in... er... C# and names and some concepts are different. Then passing
from VCL to .NET is significant easier than pass to MFC (or other C++
framework), but you will find a lot of things that does not work as
expected in .NET that worked in VCL. Plus Windows Forms designer is er..
"easy to crash" and you need to do very bad and uncommon things to crash
VCL form designer.

Both VCL and .NET have the concepts of Event Driven User interface,
passing sender object and event cause to events but all common things
stops here. Concepts are the same, but names are very different.

However you have VCL.NET, an Pascal VCL extensions to use Pascal and VCL
in .NET, but there are none similar in C++ Borland side like Microsoft
C++/CLI.


--
Microsoft Visual C++ MVP
========================
Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Cosas mías: http://rfog.blogsome.com/
Libros, ciencia ficción y programación
========================================
La causa de la mujer es la del hombre; los dos se levantan o sucumben
juntos.
-- Alfred Tennyson. (1809-1892) Poeta británico.
 
THank you for considering my question. I know these possibilities and for
sure I want to use .NET framework. Do you think it is better to use VisualC#?
In this way I cannot reuse my C++ classes. Which can be the benefits instead?

Thanks.
emavisu

David Wilkinson said:
emavisu said:
Dear guys,
I'm in trouble having to port my project from C++Builder6 to VisualC++.
Has anyone of you idea if there are any tools to help my doing this job?
My current project is widely using VCL and these 2 IDE (C++Builder and
VisualC++) seems to be so far each other that I can hardly think to find out
a tool to "automatically" perform something for me.
Thank you.
Click to expand...

emavisu:

Visual C++ is a compiler, not a GUI framework. It is actually a compiler for
three languages: C, C++ and C++/CLI.

If you want to create a GUI program using Visual C++ you have to decide whether
you want a plain Win32 application (using C or C++), MFC application (using
native C++) or a .NET application (using C++/CLI).

The porting issues will be completely different in these three cases. But in
each case, before you start, you should try to separate the core functionality
of your C++Builder6 applications from the GUI part. This core functionality can
then be used in Visual C++.

[If you want to go the .NET route, you might consider whether you want to write
the GUI part of your application in C#, or even rewrite everything in C#.]
Click to expand...
 
emavisu said:
THank you for considering my question. I know these possibilities and for
sure I want to use .NET framework. Do you think it is better to use VisualC#?
In this way I cannot reuse my C++ classes. Which can be the benefits instead?
Click to expand...

emasivu:

You should be aware that Microsoft is no longer promoting C++/CLI as a language
for .NET GUI applications, just for interfacing to native C++ code. C# is really
recommended for GUI code. You can use it for GUI code, but you may regret it.

You do have legacy C++ code, but it contains VCL code that cannot be used in
Visual C_++. Two possibilities:

1. A complete rewrite in C#

2. Use C++/CLI to wrap your (cleaned) C+ code into C++/CLI classes which can be
consumed by a C# GUI.
 
Dear Mr. Wilkinson,
you are confirming my feeling that MS is, as usual, pushing developers in
the direction of working in a complete proprietary solution!

Frankly speaking I think C++Builder and VCL are great tool to work with but
the problem is that you can hardly find people using it (mainly in italy,
whare I live). In this situation, when you need something is nearly
impossible to find out a forum like this one where to chat with someone about
the possible solution for the problem you are facing.
I think this is the main reason why I'm thinking about this migration.

Which is your personal point of view? It seems you are a very experienced
person so your suggestion would be really worthwhile.

Thanks so much.

emavisu
 
emavisu said:
Dear Mr. Wilkinson,
you are confirming my feeling that MS is, as usual, pushing developers in
the direction of working in a complete proprietary solution!

Frankly speaking I think C++Builder and VCL are great tool to work with but
the problem is that you can hardly find people using it (mainly in italy,
whare I live). In this situation, when you need something is nearly
impossible to find out a forum like this one where to chat with someone about
the possible solution for the problem you are facing.
I think this is the main reason why I'm thinking about this migration.

Which is your personal point of view? It seems you are a very experienced
person so your suggestion would be really worthwhile.
Click to expand...

emavisu:

My personal decision is to stick with MFC, but I have 10 years invested in
learning it. Also, after 10 years of neglect. Microsoft is once again investing
resources in it, because they have accepted that this is what the majority of
their existing C++ customer base wants.

Of course MFC is also a proprietary Microsoft solution. If you are interested,
there are other native C++ libraries (QT, wxwidgets, WTL ...) that are not
controlled by Microsoft.
 
I also would like to stick with VCL but the problem is to know if Embarcadero
and CodeGear want to keep a good support to this product or not! from the
other side (MS) I would need a good library with a full support for Unicode
(for Chinese GUI) but as far as I know I see that MFC is not enough (they
told me I have to use .NET).
Also I would like to keep using C++ (I also invested a lot of time on this
language) but I do not know if using one of the others libraries/frameworks
you are talking about (QT, wxwidgets, WTL ...) would be a good choice for the
future of my applications.
 
emavisu said:
I also would like to stick with VCL but the problem is to know if Embarcadero
and CodeGear want to keep a good support to this product or not! from the
other side (MS) I would need a good library with a full support for Unicode
(for Chinese GUI) but as far as I know I see that MFC is not enough (they
told me I have to use .NET).
Also I would like to keep using C++ (I also invested a lot of time on this
language) but I do not know if using one of the others libraries/frameworks
you are talking about (QT, wxwidgets, WTL ...) would be a good choice for the
future of my applications.
Click to expand...

emavisu:

MFC has full support for Unicode. In fact, a default MFC application created in
VS2005 or VS2008 uses Unicode characters by default.

Who told you otherwise?

While nothing is certain, I also think that the future of MFC is much better
assured than QT, wxwidgets, WTL or VCL.

The downside of MFC is that it is old, bloated, and not very elegant. It also
has quite a learning curve. But it works, and there is a ton of code samples
available for it.
 
Well I think I will test MFC solution for a while...but my learning curve
MUST be very short so, for sure, I will need to hire good people if I will
decide to go on in this direction: do you know a place to find some of them?

Thanks very much for your time.

emavisu
 
needs them, which is probably not true of MFC, VCL, or Qt which will
only be around for as long as Microsoft, Embarcadero (aka CodeGear,
formerly part of Borland), and Nokia choose to keep them going -- I
imagine that will be quite a long time, though.
Click to expand...
Actually, QT is available under the GPL as well as under a proprietary
license. If Nokia/trolltech folded or stopped developing it, the community
would just keep using the GPL version. (at least those releasing open
source software that is)
 
Daniel James said:
Nothing is certain in this world. I would say that as WTL and wxWidgets
are Open Source projects they will be around for as long as anyone
needs them, which is probably not true of MFC, VCL, or Qt which will
only be around for as long as Microsoft, Embarcadero (aka CodeGear,
formerly part of Borland), and Nokia choose to keep them going -- I
imagine that will be quite a long time, though.
Click to expand...

This is just the point! How far will Embarcadero-CodeGear will support VCL,
and even more C++Builder? I think the aswer is "as long as some big customer
will keep on using it". Unfortunately I do not know any big brand that is
using these tools.
It's old and its design reflects some decisions that had to be made in
order to support it under Microsoft's old and non-compliant 16-bit C++
compiler -- it is therefore inelegant in places and not a great example
of good C++ design ... but it's hardly bloated (it is quite a thin
layer over the Win32 API) and the learning curve is not steep if you
know Win32 programming.

On the contrary, I'd say that VCL is a more heavyweight framework, and
that the learning curve is steeper because it provides a richer
abstraction of the underlying APIs (though this is mitigated
considerably by fact that the RAD IDE does a lot of the early work for
you). For the C++ programmer the fact that VCL is written in a
different language (Object Pascal) that whose functionality doesn't map
exactly onto that of C++ makes the learning curve just a little
steeper.
Click to expand...

For what is my experience I would say that VCL is very userfriendly and
powerful to be used. As long as you have a pointer to an object in your
application and a big set of methods/properties to use you really do not mind
which is the layer they used under to implement this object...and I have to
say that my application has really no problems concerning speed and GUI
responsiveness.
As you say, MFC works. It's the pragmatic choice for developers wanting
to write native-code C++ applications on Windows with Microsoft tools.

Of all the above my current favourite is wxWidgets -- largely because
it's cross-platform and free -- but if I had a large project in VCL and
I had no requirement to port it to non-Windows platforms I'd stick with
VCL. There's nothing to be gained by porting it.
Click to expand...

I've heard that also Qt is cross-platform and there is a version for Eclipse
but I have no idea if these solutions are really reach enough from a
graphical point of view to build a good commercial solution as a customer is
expecting nowadays.

emavisu
 
You should be aware that Microsoft is no longer promoting C++/CLI as a
language
for .NET GUI applications, just for interfacing to native C++ code. C# is really
recommended for GUI code. You can use it for GUI code, but you may regret it.
Click to expand...

we noticed this :-) LOL
 
well, why don't you download the free trial of C++Builder 2009 and see for
yourself (also ask for their companion/partner cd)
 
qt is super expnsive! that's a fact the getlemen from nokia (current owner of
qt) don't seam to quite follow (it doesn't fit in their power point
presentations...)

both wxWidgets and VCL currently are maintained FULL SPEE AHEAD and they
have full support for UNICODE. the problem with wxWidgets (i was to say
wxWindows) is that in terms of database development (especially dbaware
controls) they are like 15 years in the past... and they don't seam to
undestand that where people cannot build vertical database client
applications, well, there is a problem right there! (don't need to be a
genius to agree) - it's not that we're all buiding compilers, debuggers,
frameworks, kernel stuff... :-)
 
nokie has NOT changed the dual license of QT, if you wanna do "commercial"
software (in a box or not/in house) you HAVE TO BUY A LICENSE FOR EVERY
SINGLE DEVELOPER! (which, if you phone their marketing geniuses and request a
price tag, you will find out that it's about $3,000/developer/plaform, ONLY
FOR THEIR FRAMEWORK, which, because of MOC, it's a tramp in terms of
debugging), 100% inferior to VCL (BCB has native support of properties
methods events model, for NATIVE code! 2 way designers, etc) - so let's not
compare an exorbitant cheap stuff from EUROPE with BCB...

and the geniuses from GPL go like "you can use this, but hey, your
work/source code is common good" - you have to share it, whith whom? nobody
knows... but then again, do GPL stuff from Nokia/QT and let us know how it
went... :-)
 
This is just the point! How far will Embarcadero-CodeGear will support VCL,
and even more C++Builder? I think the aswer is "as long as some big customer
will keep on using it". Unfortunately I do not know any big brand that is
using these tools.
Click to expand...

For starters, Embarcadero products are writen in VCL (and BCB). For them, to
spare 23 million bucks was paddy cash, just to have the tools on board.

Second, they've just released BCB 2009, with enhanced VCL (100% backward
compatible) and FULL UNICODE SUPPORT (among other things...)

Third, there were 2 products in Borland's history which registered amazing
sales. The two products are: Borland Pascal 7 and... BCB 6!?! (bcb6 because
borland was "cooking" on aberations like cbuilderX instead of doint what they
always did bet (well, more or less, since 75% of their top engineers, smile
at us from Redmond WA - and hey, nothing wrong with this!)

Embarcadero will support BCB, that's for SURE! They have to, and are
extremely motivated by the vibrant help they've got from Microsoft (which
currently does just a little bit of C++, right?)

Regards,
d
 
absolutely, great point! and the person is called ANDERS!!!
some things are not too clear tough... for example, the fact that you can:

1. buy bcb 2009 and you will feel like a fish in water, with full unicode
support, more compliant ANSI stuff, better RTL, better STL, better everything!
2. then start isolating the layers (and I did not call them tears!)
3. understand that actually, you can instantiate EVERY SINGLE .NET CLASS
(sorry, COMPONENT) from inside your BCB application! you can even host .NET
contols in your NATIVE VCL FORMS! so, you are not really in a cage... you
just preserve your investment, until Microsoft decides to purchase
Embarcadero (just kidding)

but consuming .NET classes from inside your VCL NATIVE application is NOT A
JOKE!
also, it's not a joke that the COM support just got better (in BCB 2009!) -
I'm gonna make a little bit of fun of their ridl (restricted idl) but hey,
it's better than persisting in tlb (that hurted... :-) anyway, if you start
isolating your tiers and encapsulate the basic/core functionality in COM
objects, well, your migration path to .NET would be so easy... after-words...
but if the BCB application is spagetti, it's not even worth to keep in this
state... (forgime my directness).

so, what i would do, i would just start "layering" my bcb application, with
bcb 2009 or even with old bcb 6 (i do not work for borland, nor i am trying
to make a sale here!) and then start build definitely layers (let's say based
on COM) then, if you don't like ADO.NET, you can use OLEDB bridges, and go
from there... to implement the presentation tier is not the end of the world,
if your application is already properly architected...

now, a joke, a friend of mine asked me "why don't we build a bridge like
OLEDB for .NET" exactly the opposite of ".NET bridge for OLEDB / ODBC" -
since so many applications currently use OLEDB, this may be an interesting
idea... :-)

stick with VCL, do not promisse anything to your folks, porting legacy VCL
application from BCB to ANYTHING ELSE is not a walk in the park, and the
first steps, the first porting strategy may not require any purchase of any
kind (we all have subscriptions anyway, btw, they offer subscriptions for
bcb/delphi as well) so, it's the architectural discipline in your application
giving you freedom of choice and not a tool/framework or another)

best regards, may have no reply to the right persons, have fun,
d++
 
Both VCL and .NET have the concepts of Event Driven User interface,
passing sender object and event cause to events but all common things
stops here. Concepts are the same, but names are very different.
Click to expand...

absolutely! except that anders did not have a sens of humor when he decided
to use the system namespace, not for us, the ones who temporary joined the
borland croud after elvis left the building :-)

the cool thing about microsoft purchasing embarcadero is about adding a
smooth migration path to all all the VCL developers (about 3.5 millions, by
my precise statistics) - this is about being able to port a VCL application
from VCL to VCL.NET (even a BCB one) with minimal changes. but then again, if
they cared, they would have offered the very same smooth migration path to
VB6 and MFC developers, in a way, the VB6 folks do not matter much, because
they would digest what is offered to them... no disrespect for QuickBasic
folks, with a mouse, now even having implementation inheritance :-) but there
would be a MFC.NET (idi*t idea, right? well, not really!) I wish Bill (or
other senior architects) were here, to remember the episode from 1989 when
the c++ folks offered him something which had all it needed, componentness,
elegance, everything! but it needed 45% more memory, and of course, Bill said
no! What happened with those classes - well, they turned into intrinsic
controls of Visual Basic ONE. Sad story - Microsoft had no idea that the
component market will book and take VB with it, in the sky... Even the COM
model made to us (to you, actually) by a "pragma"... :-) Anyway, at least,
the MFC developers got a late update (the ribon interface, of course, without
designing capabilities, BCB has one with FULL DESIGNER! and about 3-4 3rd
party alternatives) - because in order to have a RAD experience you need a
form designer (and not just a dialog editor) and you need full component
model, at language level... But I was to say that the MFC developers got a
smooth migration path via hybrid applications... the ones who really did
software in box know exactly what I am talking about... The VCL developers
were almost to get a VCL.NET support for BCB, but nah, Danny, Eli & many
others decided that enough was enough... and left the building, just like
their older brother Anders!

d++
 
Back
Top