Summary on Re: [fpc-pascal] Unicode file routines proposal

Marco van de Voort marcov at stack.nl
Tue Jul 1 16:15:57 CEST 2008


> On Tue, 1 Jul 2008, Marco van de Voort wrote:
> 
> > > On Tue, 1 Jul 2008, Felipe Monteiro de Carvalho wrote:
> > > I don't see what is difficult about Florians proposition.
> > > On the contrary, it is the simplest possible solution,
> > > and quite elegant in my eyes.
> > 
> > To be honest, I flabbergasted that the two of you agreed on such a runtime
> > construct. It goes IMHO against Pascal principles.
> 
> Why ? 
> In your opinion, we must get rid of Array of Const, Variants as well,
> as well as RTTI ? They all serve the same purpose.

Those are explicitely meant as layer over existing compiletime systems to
handle exceptions where that is not possible.  (respectively normal
parameter arrays, normal typed vars and pointer based method execution)

Here we are talking about adding runtime construct without typed
alternative.

> No-one will be forced to use the new type, so...

No one is forced to use FPC, but that is also an open door. We both know
that this is a pretty crucial decision, since the only alternative is
handcoding using pointers.

> > That's one of the problems. Having to check and insert code for a Tiburon
> > solution. (that simply will expect UTF-16). The least it should do is have a
> > way to flag a routine (e.g. by directive/ Tiburon mode) to only accept UTF16
> > and insert that call itself.
> 
> Let's first wait to see what Codegear comes up with, and then worry about
> compatibility.

Codegear has an UTF16 type, for .NET compability. See also
http://blogs.codegear.com/abauer/2008/01/28/38853

> In my opinion we'll have to write exactly 0 lines of code
> for this compatibility, with the solution of Florian.

Why don't you point out what I misunderstood above? If I only have a UTF16
routine with a parameter of type "unicodestring" (like T. has), how do I
make sure that it only gets passed UTF-16 system without code changes?



More information about the fpc-pascal mailing list