Re: Question about Delphi versus other languages
From: Marco van de Voort (marcov_at_stack.nl)
Date: 10/13/04
- Next message: Francis: "Re: Component Resource Usage"
- Previous message: AlanGLLoyd: "Re: Reading serial port lines"
- In reply to: VBDis: "Re: Question about Delphi versus other languages"
- Next in thread: Maarten Wiltink: "Re: Question about Delphi versus other languages"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 13 Oct 2004 11:25:08 +0000 (UTC)
On 2004-10-13, VBDis <vbdis@aol.com> wrote:
> Im Artikel <slrncmncff.16kk.marcov@turtle.stack.nl>, Marco van de Voort
><marcov@stack.nl> schreibt:
>
>>How do you verify that? And what compilers do you use?
>
> gcc, BCB and VC.
That's the second question answered. What about the first.
>> I assume you have an internal preprocessor for the C side?
>
> I assume so ;-)
How do you do it for gcc then that has an external one? How did you
eliminate the effects of the multiple header inspection, external
preprocessors etc etc? (and even then I have to assume that the overhead of
the C compiled/cached header system is zero)
>>And anyway, while there is a difference in theory, but it should be pretty
>>much unnoticable compared to the factors what you say you have singled out.
>
> The difference exists in practice. During the development of my C
> preprocessor I could find some of the time consuming "features" built into
> the C language.
Nobody will deny that. However the question is if that is noticable, and the
reason for the apparant slowliness of C compiler.
... or that that is because the complicated build process requires headers being
read multiple times, compilers to reinit per sourcefile, external
preprocessor (double lexing) etc etc?
> Another problem, not necessarily related to C, are different libraries on
> different target platforms. Here the library development usually is
> bottom-up for popular languages, so that different implementations of the
> same or similar functions are developed on various systems, and later
> these functions are ported to other systems where they may conflict with
> existing approaches. Then the affected applications must be made
> platform-aware, resulting in a quite complex and unreliable installation
> procedure for open source C packages, accompanied by almost unsystematic
> fixes and workarounds in the code itself.
> For Java, in contrast, the development of the standard libraries is top-down,
> i.e. all the libraries are provided by the same source (Sun), with little
> chances for unwanted platform differences.
There was also MS Java, and we had enough problems with that ;-)
And this approach has other big problems:
- The libraries only support a subset of an OS system, and can't be easily
extended with platform dependant parts.
- the libraries are immensely large and complicated.
- The products feel alien on all platforms. At least the other approach
keeps its native feel on the original system.
> For Pascal there exist also
> different libraries (TP, FPC, Delphi...), so that porting code to different
> platforms may become difficult.
This is multivendor stuff. Has nothing to do with the top down/bottom up.
Moreover, code portability is quite good. Worse, such problems even exist
between different java versions, not only between vendors.
> I really would appreciate a PPL (Portable Pascal Library), for use in
> projects that are intended to be ported to multiple platforms. Any
> opinions?
Would only work with consent of Borland as the major player by far. There is
no need for a new set. If Borland would open up (LGPL or MPL, no GPL) the
relevant sources, and FPC merged in some stuff for portability, we would
come a long way.
However Borland lost focus on portability, (see Kylix), so don't get your
hopes up.
- Next message: Francis: "Re: Component Resource Usage"
- Previous message: AlanGLLoyd: "Re: Reading serial port lines"
- In reply to: VBDis: "Re: Question about Delphi versus other languages"
- Next in thread: Maarten Wiltink: "Re: Question about Delphi versus other languages"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
