Windows RAD - C++ or Delphi
C.A.Scot
Which language in your opinion is best for Microsoft Windows based
Rapid Application Development, C++ or Delphi? My applications will
always involve a GUI and will more often than not require database
functionality.
I want to be able to create and distribute standalone .exe files. No
need for things like 6Mb runtime libraries or Virtual Machine, etc.
Hence no mention if VB or Java.
Can anyone offer any advice on the best way to jump?
--
C.A.Scot
Richard Heathfield
C++ Builder and Delphi are pretty much of a muchness. After all, Builder
is the "C++ port" of Delphi. So which language do you like best, C++ or
Pascal? If you prefer Pascal, go for Delphi. If you prefer C++, go for
C++ Builder. They are just about as good as each other - i.e. excellent.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
C.A.Scot
>C++ Builder and Delphi are pretty much of a muchness. After all, Builder
>is the "C++ port" of Delphi. So which language do you like best, C++ or
>Pascal? If you prefer Pascal, go for Delphi. If you prefer C++, go for
>C++ Builder. They are just about as good as each other - i.e. excellent.
Thanks for your reply Richard.
I was asking about the languages themselves not any development tools,
so C++, be it Inprise C++ Builder or MS Visual C++, compared to
Delphi, which admittedly has only one tool as it was developed by
Inprise (then Borland).
I know a little bit of Pascal from college courses in the distant
past, but basically I would be starting either from scratch.
--
C.A.Scot
Josh Sebastian
wrote:
>
>Which language in your opinion is best for Microsoft Windows based
>Rapid Application Development, C++ or Delphi? My applications will
>always involve a GUI and will more often than not require database
>functionality.
>
>I want to be able to create and distribute standalone .exe files. No
>need for things like 6Mb runtime libraries or Virtual Machine, etc.
>Hence no mention if VB or Java.
And you think that VCL apps link to what, thin air? VB programs can,
IIRC, be statically linked, as can most C++ programs, if you're more
keen on bloating your exe size than entangling yourself in DLL hell.
Unless you're using raw API calls, you're going to be linking to some
sort of runtime library (be it at link-time or run-time).
Josh
Gerry Quinn
Not sure about database calls, but for many types of programs (such
as my games, for example) the overhead of static linking is only of the
order of 100K. A small price for avoiding runtimes.
Gerry Quinn
--
http://bindweed.com
Entertainment software for Windows
Puzzles, Strategy Games, Kaleidoscope Screensaver
Download evaluation versions free - no time limits
C.A.Scot
wrote:
>And you think that VCL apps link to what, thin air? VB programs can,
>IIRC, be statically linked, as can most C++ programs, if you're more
>keen on bloating your exe size than entangling yourself in DLL hell.
>Unless you're using raw API calls, you're going to be linking to some
>sort of runtime library (be it at link-time or run-time).
I'm aware of all that, but if I write a tiny little utility program
that's say 50k in size, if I only need functionality (be it built into
an exe or resident within a dll) that takes up another 50k or 100k, it
is ridiculous that I should be faced with the prospect of distributing
a 6Mb runtime library ala VB. It should be possible to only need to
distribute, seperately or within the .exe the functionality required
for the program you are distributing.
--
C.A.Scot
Ubaidullah Nubar
database. You can find more info about Clarion on comp.lang.clarion
Regards,
cas...@sympatico.ca (C.A.Scot) wrote in message news:<3d863098....@news1.on.sympatico.ca>...
Friedrich Dominicus
> Which language in your opinion is best for Microsoft Windows based
> Rapid Application Development, C++ or Delphi? My applications will
> always involve a GUI and will more often than not require database
> functionality.
Well I do think there are other choices. There is Common Lisp
there is suprise Visual Basic. The probably best tool even for Windows
prototyping could too be Smalltalk.
>
> I want to be able to create and distribute standalone .exe files. No
> need for things like 6Mb runtime libraries or Virtual Machine, etc.
> Hence no mention if VB or Java.
Ok than use CAPI from Xanalys.
> Can anyone offer any advice on the best way to jump?
I don't think you gave any good reasond why one should use either C++
or Delphi. So in fact mention it throws out very decent
alternatives. Not a good starting IMHO
Friedrich
Walter
"C.A.Scot" <cas...@sympatico.ca> wrote in message
news:3d863098.3034662363@news1.on.sympatico.ca...
Check out the D Programming Language, at www.digitalmars.com/d/. D is
essentially a modernized C++ with the unproductive legacy baggage removed.
It is well suited to writing systems level apps, small & fast code, with no
multimegabyte runtimes or VM. D offers a long list of improvements that aid
in RAD, in the form of greater type safety, optional runtime checking, unit
testing, and design by contract.
-Walter
gswork
C++ offers a couple of extra OO tricks over Delphi , as I understand
it. If you prefer c++ then Borland Builder is a fine choice.
Delphi has more users than Builder but not as many as VB. I've found
that the general quality of Delphi books and websites outstrips VB,
for instance. The result of Delphi's relative popularity is the huge
amount of visual components and units available, and a great deal of
source. Also, with Kylix you have a chance for RAD on Linux should
you need it (also true of c++ i think)
For those reasons I'd tend to go with Delphi. If you can stretch to
it go with both, or at least get a personal edition download of the
second choice.
Delphi produces more sizeable .exes when using components though I've
found the .exe of even quite complex programs will still often fit on
a floppy (as an arbitrary guide), they tend to 'grow' at a slower rate
as you add more complexity, and there's always compression. It
certainly is neater than fretting over the target machines and sending
out massive runtimes anyway.
Richard Heathfield
>
> >C++ Builder and Delphi are pretty much of a muchness. After all, Builder
> >is the "C++ port" of Delphi. So which language do you like best, C++ or
> >Pascal? If you prefer Pascal, go for Delphi. If you prefer C++, go for
> >C++ Builder. They are just about as good as each other - i.e. excellent.
>
> Thanks for your reply Richard.
>
> I was asking about the languages themselves
Delphi is not a language. C++ *is* a language, but it doesn't specify an
interface to Windows. Nor does Pascal, the language behind Delphi. If
you insist on discussing the core languages, the answer is "can't write
Windows programs in those languages"; you have to take the
implementations into account, given the nature of your subject matter.
<snip>
> I know a little bit of Pascal from college courses in the distant
> past, but basically I would be starting either from scratch.
Then it really doesn't make more than a ha'penny of difference. If you
have access to Builder and Delphi, try them both for a couple of weeks
each, and see which fits you best. If you go for Visual C++ instead,
that's entirely up to you; my own experiences of it are too painful to
recall.
Robin Kinge
I have been using it 100% since the eighties, and have never looked back.
Robin
M. Gessner
I can't speak for the C++ part of Windows (other than to say that I've
seen people have to write in MS VC++, and that it's been extremely
painful just to *watch* them.). I've never used C++ Builder, so I can't
say how much of the painful Windows programming process it simplifies.
I can speak very highly of Delphi. I enjoyed programming under Delphi.
I would program in it again if I had the need. I happen to like
Pascal as a structured language because it gives you some flexibility,
but to really screw things up takes effort.
I'm a big fan of programming in C, partly because I've done it for so
long on so many different platforms. That said, it is much easier for
beginners to make certain kinds of mistakes in C that Pascal simply
won't let you make (or maybe it's more accurate to say that you really
have to *work* at making the same kinds of mistakes). Two words: string
handling.
Anyway, I always liked Delphi. I saw V6 in a mag for $15, so I may have
to pick it up just so I can have something cool to play with on my work
machine :).
HTH.
Alex Kouznetsov
> cas...@sympatico.ca (C.A.Scot) writes:
>
> > Which language in your opinion is best for Microsoft Windows based
> > Rapid Application Development, C++ or Delphi? My applications will
> > always involve a GUI and will more often than not require database
> > functionality.
> Well I do think there are other choices. There is Common Lisp
> there is suprise Visual Basic. The probably best tool even for Windows
> prototyping could too be Smalltalk.
Have a look to Euphoria, http://www.rapideuphoria.com. It is simple
and powerfull. It looks like a combination of Lisp, Pascal and C.
Regards
Alex
Laotseu
> "C.A.Scot" wrote:
> >
> > >C++ Builder and Delphi are pretty much of a muchness. After all, Builder
> > >is the "C++ port" of Delphi. So which language do you like best, C++ or
> > >Pascal? If you prefer Pascal, go for Delphi. If you prefer C++, go for
> > >C++ Builder. They are just about as good as each other - i.e. excellent.
> >
> > Thanks for your reply Richard.
> >
> > I was asking about the languages themselves
>
> Delphi is not a language. C++ *is* a language, but it doesn't specify an
> interface to Windows. Nor does Pascal, the language behind Delphi. If
> you insist on discussing the core languages, the answer is "can't write
> Windows programs in those languages"; you have to take the
> implementations into account, given the nature of your subject matter.
>
>
> <snip>
>
> > I know a little bit of Pascal from college courses in the distant
> > past, but basically I would be starting either from scratch.
>
> Then it really doesn't make more than a ha'penny of difference. If you
> have access to Builder and Delphi, try them both for a couple of weeks
> each, and see which fits you best. If you go for Visual C++ instead,
> that's entirely up to you; my own experiences of it are too painful to
> recall.
One could add that calling VisualC++ a RAD Tool is a mere lie, and the
only visual thing in it is the name...
Laotseu
bogus...@nospamhere.com
<bin...@eton.powernet.co.uk> wrote:
>"C.A.Scot" wrote:
>>
>> >C++ Builder and Delphi are pretty much of a muchness. After all, Builder
>> >is the "C++ port" of Delphi. So which language do you like best, C++ or
>> >Pascal? If you prefer Pascal, go for Delphi. If you prefer C++, go for
>> >C++ Builder. They are just about as good as each other - i.e. excellent.
>>
>> Thanks for your reply Richard.
>>
>> I was asking about the languages themselves
>
>Delphi is not a language.
Beg your pardon. The "dl7_datasheet.pdf" for Delphi 7 Studio uses the
word "language", eight times. Three of those times it is used a
"Delphi language". You do know the underlying language to Delphi is
Pascal and now you know that Borland, the designer of Delphi, calls it
a language.
>C++ *is* a language, but it doesn't specify an
>interface to Windows. Nor does Pascal, the language behind Delphi. If
>you insist on discussing the core languages, the answer is "can't write
>Windows programs in those languages"; you have to take the
>implementations into account, given the nature of your subject matter.
>
>
><snip>
>
>> I know a little bit of Pascal from college courses in the distant
>> past, but basically I would be starting either from scratch.
>
>Then it really doesn't make more than a ha'penny of difference. If you
>have access to Builder and Delphi, try them both for a couple of weeks
>each, and see which fits you best. If you go for Visual C++ instead,
>that's entirely up to you; my own experiences of it are too painful to
>recall.
Steve
----
CBFalconer
> On Tue, 17 Sep 2002 07:43:26 +0100, Richard Heathfield wrote:
>
... snip ...
> >
> >Delphi is not a language.
>
> Beg your pardon. The "dl7_datasheet.pdf" for Delphi 7 Studio uses
> the word "language", eight times. Three of those times it is used
> a "Delphi language". You do know the underlying language to
> Delphi is Pascal and now you know that Borland, the designer of
> Delphi, calls it a language.
While Delphi may be a language to Borland, it has no standard, and
thus never has a guarantee of compatibility with anything. The
underlying language has some resemblances to Pascal, but is not
Pascal. It fails to implement a great deal of minimal Pascal, as
defined by ISO7185 (which IS an international standard).
All known Delphi implementations are geared to the
x86/MSDOS/Windoze world. I suspect that this is the reason (basic
incompatibilities) that Borland has chosen a new name for the
Linux variant (Kylix).
Without an agreed language specification, it is impossible to
check code for correctness. With a specification, it remains
hard, but at least it is possible to attach a meaning to a
statement.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
bogus...@nospamhere.com
wrote:
>bogus...@nospamhere.com wrote:
>> On Tue, 17 Sep 2002 07:43:26 +0100, Richard Heathfield wrote:
>>
>... snip ...
>> >
>> >Delphi is not a language.
>>
>> Beg your pardon. The "dl7_datasheet.pdf" for Delphi 7 Studio uses
>> the word "language", eight times. Three of those times it is used
>> a "Delphi language". You do know the underlying language to
>> Delphi is Pascal and now you know that Borland, the designer of
>> Delphi, calls it a language.
>
>While Delphi may be a language to Borland, it has no standard,
Speaking of standards, were there ever any standards for "Assembly
Languages?" To make a programming language does not require a
standard.
>and thus never has a guarantee of compatibility with anything.
That isn't a requirement to be a programming language. That's nice
for standardization purposes, but there are many languages that exist
without it.
>The underlying language has some resemblances to Pascal, but is not
>Pascal. It fails to implement a great deal of minimal Pascal, as
>defined by ISO7185 (which IS an international standard).
I don't believe that Borland ever met any Pascal standards. They set
their own goals. It pretty much implements its own versions of Pascal.
>All known Delphi implementations are geared to the
>x86/MSDOS/Windoze world.
All of my world has revolved around these platforms, and will probably
stay there, at least for my programming life.
>I suspect that this is the reason (basic
>incompatibilities) that Borland has chosen a new name for the
>Linux variant (Kylix).
I wouldn't know why they named it Kylix or how closely Delphi and
Kylix fit together.
>Without an agreed language specification, it is impossible to
>check code for correctness.
With all the specs in the world that the US goverment comes up with it
has repeatedly happened to NASA's programming efforts in the past in
the space program. Errors have occur no matter how many safeguards
that they put into writing programming code. You just can't cover all
bases or expect programmers to insure that these standards are met all
the time.
>With a specification, it remains
>hard, but at least it is possible to attach a meaning to a
>statement.
People that can't "scratch their behinds" without a "universally
accepted language bible" explaining how to do it, are going to
procrastinate instead of code.
My own Borland Pascal and "Delphi" programming code has been working
for me for many a year without an ISO.
Steve
----
CBFalconer
> CBFalconer <cbfal...@yahoo.com> wrote:
> >bogus...@nospamhere.com wrote:
> >
> >
> >While Delphi may be a language to Borland, it has no standard,
>
> Speaking of standards, were there ever any standards for "Assembly
> Languages?" To make a programming language does not require a
> standard.
In that each machine had a list of instructions, with a
description of what that instruction did, what flags it affected,
what register or storage it used or altered, yes, every assembly
language has a standard.
>
... snip ...
>
> People that can't "scratch their behinds" without a "universally
> accepted language bible" explaining how to do it, are going to
> procrastinate instead of code.
>
> My own Borland Pascal and "Delphi" programming code has been working
> for me for many a year without an ISO.
But, lacking a standard, you can't immediately port it to other
machines, nor can you even build a compiler etc. system or an
interpreter to do such porting. In the assembly case you can
build an exact simulator.
I too have used Borland Pascal. My code tends to stick to ISO
standards, and I have made and published code to make Borland more
or less adhere to some critical portions of the standard,
especially the semantics of text i/o.
Marco van de Voort
> bogus...@nospamhere.com wrote:
>
> All known Delphi implementations are geared to the
> x86/MSDOS/Windoze world. I suspect that this is the reason (basic
> incompatibilities) that Borland has chosen a new name for the
> Linux variant (Kylix).
This is not true. FPC compiles Delphi to m68k, and is quite far with PPC
compability.
CBFalconer
Interesting. Do you mean someone can take their collection of
Delphi sources, with all the Windoze interface gubris
specifications and layout, and pump it through FPC?
Frank
even without visual comps FPC is not 100% compatible.
Frank
CBFalconer <cbfal...@yahoo.com> wrote in message news:<3D9E7A1B...@yahoo.com>...
Marco van de Voort
> Marco van de Voort wrote:
>> In article <3D99E022...@yahoo.com>, CBFalconer wrote:
>> >
>> > All known Delphi implementations are geared to the
>> > x86/MSDOS/Windoze world. I suspect that this is the reason
>> > (basic incompatibilities) that Borland has chosen a new name
>> > for the Linux variant (Kylix).
>>
>> This is not true. FPC compiles Delphi to m68k, and is quite far
>> with PPC compability.
>
> Interesting. Do you mean someone can take their collection of
> Delphi sources, with all the Windoze interface gubris
> specifications and layout, and pump it through FPC?
The windows interface gubris is outside the language scope (they are
platform dependant).
If you had such system with some rubberstamped dialect of Pascal, it
wouldn't run there either.
As said before, the number of truly platform dependant language constructs
and core library functions is quite limited.
Marco van de Voort
> FPC compiles delphi source aslong no visual comps are involved, and
> even without visual comps FPC is not 100% compatible.
Which version do you use?
CBFalconer
> In article <3D9E7A1B...@yahoo.com>, CBFalconer wrote:
> > Marco van de Voort wrote:
> >> In article <3D99E022...@yahoo.com>, CBFalconer wrote:
> >> >
> >> > All known Delphi implementations are geared to the
> >> > x86/MSDOS/Windoze world. I suspect that this is the reason
> >> > (basic incompatibilities) that Borland has chosen a new name
> >> > for the Linux variant (Kylix).
> >>
> >> This is not true. FPC compiles Delphi to m68k, and is quite far
> >> with PPC compability.
> >
> > Interesting. Do you mean someone can take their collection of
> > Delphi sources, with all the Windoze interface gubris
> > specifications and layout, and pump it through FPC?
>
> The windows interface gubris is outside the language scope (they
> are platform dependant).
>
> If you had such system with some rubberstamped dialect of Pascal,
> it wouldn't run there either.
But, as far as I know, Delphi includes the windows gubris as an
integral part. Which comes back to my original statement about
using the Kylix name for the Linux variant. I think you are
saying that FPC can compile the Pascal-like part of Delphi, which
does not appear to be Delphis raison d'etre.
For example I believe (and I am prepared to be corrected) that the
Cygwin system can take the original inputs to VC (resource files,
etc), manipulate them, and come up with a functional Windows
executable.
Marco van de Voort
>>
>> People that can't "scratch their behinds" without a "universally
>> accepted language bible" explaining how to do it, are going to
>> procrastinate instead of code.
>>
>> My own Borland Pascal and "Delphi" programming code has been working
>> for me for many a year without an ISO.
>
> But, lacking a standard, you can't immediately port it to other
> machines, nor can you even build a compiler etc. system or an
> interpreter to do such porting. In the assembly case you can
> build an exact simulator.
Odd, it runs fine on my 68k.
Marco van de Voort
> Marco van de Voort wrote:
>> > specifications and layout, and pump it through FPC?
>>
>> The windows interface gubris is outside the language scope (they
>> are platform dependant).
>>
>> If you had such system with some rubberstamped dialect of Pascal,
>> it wouldn't run there either.
>
> But, as far as I know, Delphi includes the windows gubris as an
> integral part.
No. They are <libraries>, just like e.g. GPC comes with libraries that
aren't described in the language-standard.
It is not that Delphi/Object Pascal doesn't have language extensions that
are Windows centric (sometimes reusable for Corba though), but those aren't
the real problem. The libraries are.
This is btw the problem of _any_ Windows product. All use platform libraries,
which are inheritly unportable.
> Which comes back to my original statement about
> using the Kylix name for the Linux variant. I think you are
> saying that FPC can compile the Pascal-like part of Delphi, which
> does not appear to be Delphis raison d'etre.
No I don't. This is universally for every language. If you use windows
specific libraries, you are bound to windows. To windows/x86 often, since
people seem to forget the non-x86 Windows versions.
> For example I believe (and I am prepared to be corrected) that the
> Cygwin system can take the original inputs to VC (resource files,
> etc), manipulate them, and come up with a functional Windows
> executable.
On NetBSD/PPC ?
Fantasist
visual develompment with Delphi. Your can create really small and fast
programms with it. No VCL needed. For details:
http://bonanzas.rinet.ru/ .
Mark Lassiter
C++ builder without a problem.
And if you stick with the CLX components (instead of VCL), you can
create portable apps. Delphi/Kylix will even warn you if you write
code that does not port.
So in theory, you could write a Delphi app and compile it under Delphi
6/7 for windows or Kylix for Linux.
Also, Kylix is not available in a C++ flavor. Not sure if C++ Builder
ports or not.
Good luck.
eLearner
> I prefer Delphi.
> create portable apps. Delphi/Kylix will even warn you if you write
> code that does not port.
> So in theory, you could write a Delphi app and compile it under Delphi
> 6/7 for windows or Kylix for Linux.
Delphi6 for converting a legacy Clipper DOS based appliction user
interface to change it to a window based application user interface
--- my task is to convert these legacy DOS-interface applications to
windows user interfaces and from what I've seen on the web I'm leaning
towards using Delphi but can you give me some good reasons ---- my
special concern is to reduce the network traffic and load on the
network servers as the applications may be used in a 30 user or more
environment .
Thanks.
Mark Lassiter
> I have a different kind of issue really ---- would you recommend
> Delphi6 for converting a legacy Clipper DOS based appliction user
> interface to change it to a window based application user interface
> --- my task is to convert these legacy DOS-interface applications to
> windows user interfaces and from what I've seen on the web I'm leaning
> towards using Delphi but can you give me some good reasons ---- my
> special concern is to reduce the network traffic and load on the
> network servers as the applications may be used in a 30 user or more
> environment .
> Thanks.
Well, I can try. I'll warn you that I am a bit bias. I've had great
success with Delphi and love it.
Delphi provides excellent support for any type of database you can
image. Furthermore, it provides support for scaling from a simple
local database (MS-Access, Dbase, etc) to a client-server paradigm
(Oracle, MS-SQL, MySQL) to n-tiered (pick your middleware).
It can move from one paradigm to the next rather easily because the
VCL framework used by Delphi generalizes the database access and
controls rather nicely.
Important Question: do you plan to convert the clipper database to
something else? MS-SQL, Oracle, MySQL?
The reason I ask is that your concerns about network traffic and
scalability are more a function of your database at this point than
the windows development tool you choose.
Databases like Clipper, Dbase, MS-Access, etc, do not scale well for
large numbers of simultaneous users unless you introduce a middleware.
I'd recommend a cost-effective solution: Put together a cheap windows
or linux server running the open source version of interbase or mysql.
Convert your clipper databases to these SQL compliant database
servers.
Then, make a decision on RAD tool and go from there. Delphi has
direct support for Interbase and ODBC or ADO support for MySQL.
Let me know if you have more questions. Feel free to email since this
might be drifting off the thread a bit.
Thanks,
Mark
mtm
Delphi is a fine tool - I love it. I have rewritten several legacy
Clipper apps with Delphi. Mark is right - plain old dbfs do not
scale - to put it mildly. What I use is Advantage Database Server
from Extended Systems. You can either use dbfs and ntxs or convert
them to adts (ADS's data files). You have your old data with the same
field names with a rock solid database manager taken care of you data.
ADS has servers for Linux, Novell, and of course NT/Windows (go with
the Linux version). It also has a local server for working on your on
PC. It is not cheap (the local server is free - no BDE) but when you
are used to dbfs you have to consider it. To much to cover here -
email if you want....
be cool
mtm