Board index » delphi » Re: Moving from Delphi to C++

Re: Moving from Delphi to C++


2003-12-13 01:56:32 AM
delphi80
"Kevin Collins" <XXXX@XXXXX.COM>writes
Quote

We are planning for significant hand editing as well. But it should help
the grunt work considerably.

The link to that tool is

ivan.vecerina.com/code/delphi2cpp/

It is a flex based tool which was one of the reasons we chose not to make
use of it directly. Recursive descent compilers are far easier to work with
and we will have to do extensive customization to save as much work as
possible.
<shrug>I still think it would make more sense just to redesign the apps and
DLL's using experienced C++ programmers. And when you take the result of
this direct translation and show it to veteran C++ programmers they are
going to blanche and ask why you did things the way you did. There is way
more to the difference between Delphi and ANSI C++ than just syntax. Your
current plan seems to be to use up to least 6 months to come up with a
result that is, except for syntax, identical to what you already have. And
that is assuming that the translation tool takes almost no time to create.
Economically, this seems awfully expensive. If you pay your 5 developers the
market rate then this mere syntax translation [Delphi ->C++] is going to
cost (0.5)x$80000x5 = $200,000+cost of benefits for employees. And if any of
us here that doubt your timescale are correct, the financial cost goes even
higher.
And then there are the maintenance costs. It is no small secret that C++
entails a higher maintenance cost than Delphi.
I just don't see the economic rationale here. Is there some big>$200,000
contract that you can only land if you use C++ instead? If so, then why
can't that windfall finance a full-blown redesign in C++?
 
 

Re: Moving from Delphi to C++

Quote
Fine Eric, whatever.
If you don't want to see replies to yours posts,
please don't post.
Eric
 

Re: Moving from Delphi to C++

KC>Only if you write poor Delphi code. I'd like to hear about
KC>these language constructs which can not be done in C++.
Partial polymorphism in C++ (in constructors and destructors), virtual
constructors, interfaces, properties, string as native datatype.
KC>It is your turn to enlighten me. The only significant thing that
KC>can't be done is RTTI which we have designed a much better method to
KC>convert to. And a few things like Low() and High(), and finally.
KC>Finally is used for freeing resources associated with local variables,
KC>it should never be used as a flow control hack.
How about resource state switching?
Screen.Cursor:=crHourGlass;
try
// do something
finally
Screen.Cursor:=crDefault;
end;
lvRecs.Items.BeginUpdate;
try
lvRecs.Clear;
// other modifications of list view
finally
lvRecs.Items.EndUpdate;
end;
KC>Because of this, C++
KC>automatically handles local object variables that are created
KC>without the call to new according to scope (similar to a Delphi
KC>record).
But it not automatically handle heap objects unless you use special classes
from STL or BOOST.
---
Andrew V. Fionik, Papillon Systems, Unix Programmers Group
For reply use "ender" instead of "fionika" in e-mail.
 

Re: Moving from Delphi to C++

On 12-Dec-03, Rudy Velthuis (TeamB) said:
Quote
Nonsense. C++ follows a different philosophy, and uses different
idioms than Delphi. A simple one to one port to C++ is not a good C++
program at all.
Although porting from Delphi to C++ will certainly be easier than the
other way, especially with some of the ugly C++ code I have seen <g>.
--
Bill
--------
"Just because an establishment deals with the public doesn't make it
public property." -- Walter Williams
 

Re: Moving from Delphi to C++

"Kevin Collins" <XXXX@XXXXX.COM>writes
Quote
In addition, we are not insane. Several of our current 3rd party tools
will simply be wrapped in a DLL interface that can be called from our c++
code until such time as they can be replaced. So we will have some legacy
Delphi code in the system for probably the next year. At the end of which
we should be able to begin the migration of those pieces to allow us to do
cross platform builds of everything. Until then, we will only focus on
cross-platform builds of the apps that do not make use of them.
This means that your original statement that you expected to do a complete
port of several applications and dozens of DLL's to C++ within 6 months was
not what you intended to say. Here it sounds like you actually expect to
complete the first stage of a long transition process within 6 months, but
the full transition will take years. That is far more realistic than your
original (mis?)statement.
Quote
Just because it sounds difficult doesn't make it impossible. And everyone
has agreed to put in many extra hours to make this happen.
Just remember that you can not get more than 10-12 hours of real productivity
from a programmer, no matter how hopped up on {*word*110} they are.
 

Re: Moving from Delphi to C++

Quote
And you have NOT found this to be true of free tools for other languages?

Give me a break...
I was not saying that it is just a Delphi thing. I think almost ALL open
source is a crock.
 

Re: Moving from Delphi to C++

"Dennis Landi" <none[at]none.com>writes
Quote
Don't sweat it. You are obviously quite a competent engineer. Good luck.
Many a project staffed with superb engineers fails.
 

Re: Moving from Delphi to C++

Yes, we are well aware of those differences. They are all relatively minor and in most cases there IS an equivalent in C++.
I did not say differences. I said things missing. Differences can and will be translated.
And much of what you mention (definitions and redefinitions) only exist in poor Delphi code. The few places that it happens in the VCL won't affect us because we won't be using the VCL anymore.
The things that will effect us, we have already planned conversion methods to go from one way to the other way of doing things.
As far as the one thing you mentioned which did actually answer the question that I asked you. Was sets. Most enumerated types should be kept to only a handful of values to be useful (which we have rules on that in our code). Guess what, we get the same functionality with enums and some nicely wrapped routines making use of bitmath. This will give us up to 32 bits with an int32, or we can increase the datatype size if we need more. A set is just a slightly prettier version of this. In fact, with our routines to handle this, it will look different but the code will be 100% functionally equivalent.
Of course the code won't port perfectly. But you continually ignore things I have stated. For instance, I have stated sevaral times that a large amount of hand editing time has been planned for each section of code.
And I am telling you what I know from 5 years experience at proper software management and 15 years as a developer.
Go ahead and substitute Software Developer in my last statement if you like. It still stands.
I am more than willing to continue discussing differences. Possible problems, etc. Hell, it could be helpful to me. But you need to understand, that argueing about whether it is possible or the right thing is a moot point and I do not find it helpful. So I will address any technical questions you have, but no more of the "it's not possible because" stuff.
And if you would care to ask how we addressing some of the differences you mentioned, I'd be happy to reply to that. Just ask.
Kevin
"Captain Jake" <johnjac76[nospam]@comcast.net>writes:
Quote
"Kevin Collins" <XXXX@XXXXX.COM>writes
news:3fd9faed$XXXX@XXXXX.COM...
>
>>This is actually worse than I expected. You aren't even planning to
rewrite
>>the logic in C++ but just translate Delphi syntax. If you want to see
what a
>>mess results from trying to do Delphi code as translated into C++ just
look
>>at BCB. C++ doesn't do several of the language constructs endemic to
Delphi,
>>so you can not just translate (unless the code is very rudimentary).
>
>Only if you write poor Delphi code. I'd like to hear about these
language constructs which can not be done in C++. It is your turn to
enlighten me. The only significant thing that can not be done is RTTI which
we have designed a much better method to convert to. And a few things like
Low() and High(), and finally. Finally is used for freeing resources
associated with local variables, it should never be used as a flow control
hack. Because of this, C++ automatically handles local object variables
that are created without the call to new according to scope (similar to a
Delphi record). The reason C++ is more difficult to convert to Pascal is
because of more language constructs in C++. Not the other way around.

Nope
.
Delphi allows virtual constructors. If you just port Delphi code to C++ it
will look fine and compile OK but constructors will act differently. (By the
way, C++ calls constructors in a different order than Delphi does, which is
another subtle gotcha that awaits anyone that does a mere port instead of
redesign.)

C++ has no equivalent of the event handler types in Delphi. As a result, the
C++ Builder designers had to hack C++ to accomodate the VCL, by adding
compiler-specific features (whose name escapes me right now but you can find
out on the C++ Builder newsgroups, I think they are called "closures" but I
am not sure)

There is no set type in C++.

Case statements bleed through in C++, they do not in Delphi.

C++ has a different exception mechanism than Delphi. There is no "finally",
AND you can directly specify what types of exceptions to catch. Well-written
C++ looks entirely different in regard to exception handling than
well-written Delphi code. In C++, cleaning up resources when going out of
scope is best done by creating objects on the stack. You aren't even allowed
to create objects on the stack in Delphi.

Include files in C++ are deep, in that anything included in any include file
is also therefore included in any file that includes the first include file.
This is not true for the uses clause in Delphi. This changes the way
definitions and redefinitions occur.

C++ has the STL, which is quite different than the various collection and
algorithm packages available for Delphi. Good C++ will use the STL when it
is appropriate.

And so on. These are all things that imply that well-written C++ code is
going to be quite different than well-written Delphi code. Significantly
different. You can port well-written Delphi code to C++ and usually end up
with bad C++ code, or at least code that makes seasoned C++ programmers
laugh derisively. (or vice versa)


>And since you continue to make rash assumptions and unproveable
statements, I will end with this. If you NEED Delphi to be a good
programmer, than you aren't a programmer, you are a Delphi user.

I am not a programmer. I am a software developer. And I am not making any
rash assumptions. I am telling you what I think about the economics of this
transition as you have described it on this newsgroup, based on my years of
experience and the little bit of economics that might have seeped into my
head during all my years in economics prior to software development. You can
do what you want with what I offer.


 

Re: Moving from Delphi to C++

"BOB-O-MATIC" <XXXX@XXXXX.COM>writes:
Quote
>And you have NOT found this to be true of free tools for other languages?
>
>Give me a break...

I was not saying that it is just a Delphi thing. I think almost ALL open
source is a crock.
Okay. Your message made it sound like you were limiting your complaint to open source Delphi tools.
kjh
 

Re: Moving from Delphi to C++

Quote
Partial polymorphism in C++ (in constructors and destructors),
Partial polymorphism? You can have virtual, pure virtual(abstract), and normal functions.
virtual
Quote
constructors, interfaces, properties, string as native datatype.
Interfaces? What do you think interfaces are for? It was a way to do multi-inheritance (and support COM of course). I already explained sevaral times how RTTI can be handled even better in C++ with the right coding. There is a string object which behaves exactly as String for Delphi. We will be using a different one because the original is problematic, but it is there.
If your scariest thing in a conversion is how to change your cursor, I am sorry, you need to dig into it a little more. You can achieve similar results by good coding in C++.
Kevin
 

Re: Moving from Delphi to C++

"Kevin Collins" <XXXX@XXXXX.COM>writes
Quote

>This is actually worse than I expected. You aren't even planning to
rewrite
>the logic in C++ but just translate Delphi syntax. If you want to see
what a
>mess results from trying to do Delphi code as translated into C++ just
look
>at BCB. C++ doesn't do several of the language constructs endemic to
Delphi,
>so you can not just translate (unless the code is very rudimentary).

Only if you write poor Delphi code. I'd like to hear about these
language constructs which can not be done in C++. It is your turn to
enlighten me. The only significant thing that can not be done is RTTI which
we have designed a much better method to convert to. And a few things like
Low() and High(), and finally. Finally is used for freeing resources
associated with local variables, it should never be used as a flow control
hack. Because of this, C++ automatically handles local object variables
that are created without the call to new according to scope (similar to a
Delphi record). The reason C++ is more difficult to convert to Pascal is
because of more language constructs in C++. Not the other way around.
Nope
.
Delphi allows virtual constructors. If you just port Delphi code to C++ it
will look fine and compile OK but constructors will act differently. (By the
way, C++ calls constructors in a different order than Delphi does, which is
another subtle gotcha that awaits anyone that does a mere port instead of
redesign.)
C++ has no equivalent of the event handler types in Delphi. As a result, the
C++ Builder designers had to hack C++ to accomodate the VCL, by adding
compiler-specific features (whose name escapes me right now but you can find
out on the C++ Builder newsgroups, I think they are called "closures" but I
am not sure)
There is no set type in C++.
Case statements bleed through in C++, they do not in Delphi.
C++ has a different exception mechanism than Delphi. There is no "finally",
AND you can directly specify what types of exceptions to catch. Well-written
C++ looks entirely different in regard to exception handling than
well-written Delphi code. In C++, cleaning up resources when going out of
scope is best done by creating objects on the stack. You aren't even allowed
to create objects on the stack in Delphi.
Include files in C++ are deep, in that anything included in any include file
is also therefore included in any file that includes the first include file.
This is not true for the uses clause in Delphi. This changes the way
definitions and redefinitions occur.
C++ has the STL, which is quite different than the various collection and
algorithm packages available for Delphi. Good C++ will use the STL when it
is appropriate.
And so on. These are all things that imply that well-written C++ code is
going to be quite different than well-written Delphi code. Significantly
different. You can port well-written Delphi code to C++ and usually end up
with bad C++ code, or at least code that makes seasoned C++ programmers
laugh derisively. (or vice versa)
Quote
And since you continue to make rash assumptions and unproveable
statements, I will end with this. If you NEED Delphi to be a good
programmer, than you aren't a programmer, you are a Delphi user.
I am not a programmer. I am a software developer. And I am not making any
rash assumptions. I am telling you what I think about the economics of this
transition as you have described it on this newsgroup, based on my years of
experience and the little bit of economics that might have seeped into my
head during all my years in economics prior to software development. You can
do what you want with what I offer.
 

Re: Moving from Delphi to C++

William Meyer writes:
Quote
On 12-Dec-03, Rudy Velthuis (TeamB) said:

>Nonsense. C++ follows a different philosophy, and uses different
>idioms than Delphi. A simple one to one port to C++ is not a good C++
>program at all.

Although porting from Delphi to C++ will certainly be easier than the
other way, especially with some of the ugly C++ code I have seen <g>.
I think it would be nearly impossible in some cases. I have converted
quite a few lines, and if they start using template metaprogramming, you
can forget it. Simple template classes can be replaced by directly coding
the classes, and using casts, and template functions by overloads or the
like, but template metaprogramming is too hard to follow, in most cases.
--
Rudy Velthuis (TeamB)
"Ever stop to think, and forget to start again?" -- bumper sticker
 

Re: Moving from Delphi to C++

"rk" <XXXX@XXXXX.COM>writes
Quote
Welcome to the REAL world Cap'n.

You do realize that your post has shown, you now have the ability to see
TRUTH in the world. As opposed to just mumbling about useless theories,
like
you typically get caught up in (I'm not being mean, just calling it how I
see it)?
Mumbling? I guess I will have to start posting in capital letterrs...<g>
 

Re: Moving from Delphi to C++

Kevin Collins writes:
Quote

>Partial polymorphism in C++ (in constructors and destructors),

Partial polymorphism? You can have virtual, pure virtual(abstract),
and normal functions.
Virtual functions, when called from constructors and destructors behave
differently in C++ than in Delphi. IN Delphi, they remain virtual, in
C++, they are called as the class of the constructor currently running.
Also, base constructors are always called at the beginning, i.e. they
must completely construct the base class. The reverse is true for
destructors. In Delphi, you can call inherited anywhere, or not at all.
Quote
how RTTI can be handled even better in C++ with the right coding.
The C++ prgorammers I know don't agree. <g>And most definitely not by a
simple converter.
Quote
There is a string object which behaves exactly as String for
Delphi.
If you mean std::string, not entirely. It doesn't for instance like it
when you use it as a buffer for an API call.
Quote
We will be using a different one because the original is problematic,
but it is there.
std::string is problematic? It is part of one of the best tested and
optimized libraries you can get, in C++: the SCL.
Quote
If your scariest thing in a conversion is how to change your cursor
No, he is addressing the fact that try-finally is not present in C++, and
that resource protection is done via RAII (Resource Acquisition Is
Initilization, see Stroustrup). The cursor was just an example of
resource protection. In C++, you often use template classes like those
from the BOOST lib for that.
--
Rudy Velthuis (TeamB)
"Three o'clock is always too late or too early for anything you want to
do."
-- Jean-Paul Sartre (1905-1980)
 

Re: Moving from Delphi to C++

"Captain Jake" <johnjac76[nospam]@comcast.net>writes
Quote
"Dennis Landi" <none[at]none.com>writes
news:3fd93465$XXXX@XXXXX.COM...
>Don't sweat it. You are obviously quite a competent engineer. Good
luck.

Many a project staffed with superb engineers fails.


True. Its all about releastic expectations and accurate project estimates.
All too frequently talented engineers look like idiots to the
Martketing/Sales VPs (who made promises to customers) when the deadline
rolls around and lo and behold, the project is no where near completion...
-d