Op Mon, 1 Dec 2008, schreef Felipe Monteiro de Carvalho:
The real world problem is (as Florian wrote): Some platforms have no
choice, because they only support 'ansi'.
This one is trivial to solve. Lazarus supports utf-8 everywhere,
including Windows 98 which doesn't support unicode. All you
Op Tue, 2 Dec 2008, schreef Alexander Klenin:
On Fri, Nov 28, 2008 at 07:59, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
One time, during a programming contest, the jury had written their solution
to a problem in Java. A 10MB output file had to be written. Their
implementation took about 15 mi
On Fri, Nov 28, 2008 at 07:59, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
> One time, during a programming contest, the jury had written their solution
> to a problem in Java. A 10MB output file had to be written. Their
> implementation took about 15 minutes and took about 60 MB of memory.
>
> Duri
register is the name of a calling convention which uses registers when
possible for function parameters.
The register keyword defines that the routine uses this calling
convention, but it normally isn't used because this is the default
calling convention.
--
Felipe Monteiro de Carvalho
_
Hi,
I am wondering what the register keyword does, I am hoping that it is the
same as the c++ register keyword.
In c++ the register keyword tries to make the compiler use the CPU's
registers if possible for the variable being defined.
If anyone knows what the register keyword does and how it is
> The real world problem is (as Florian wrote): Some platforms have no
> choice, because they only support 'ansi'.
This one is trivial to solve. Lazarus supports utf-8 everywhere,
including Windows 98 which doesn't support unicode. All you need is a
best effort approach.
--
Felipe Monteiro de Ca
Luiz Americo Pereira Camara escreveu:
Initially i'm not in favor of using RTLString,, IMO LCL should choose
an encoding UTF16 or UTF8 and then let the compiler convert only the
system calls.
The complete phrase: "Initially i'm not in favor of using RTLString, IMO
LCL should choose an encod
On Mon, 1 Dec 2008 21:23:34 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> In our previous episode, Mattias Gaertner said:
> > > In our previous episode, Mattias Gaertner said:
> > > > >
> > > > > I see this as a theoretic consideration. Please give a real
> > > > > world (!) code ex
Felipe Monteiro de Carvalho escreveu:
I think it's the other way around. If you know what encoding is
expected you have a more predictable result. You know where a
conversion will take place. For example:
MyUTF8String := MyRTLString;
So we get an error that characters are being lost, but only i
Hello
AFAIK, dwarf debug info generation is not yet fully implemented for
the compiler. I'm interseted in CallFrame information, so debugger,
can use it to unwind the call stack. I've tried to compiled hello
world program using "fpc -gw3 hello.pas", and found that there's
.debug_frame section.
Is
Mattias Gaertner wrote:
[...]
Also it would be nice (so I do not know how) not to have to
duplicate code, in order to archive this. Something like generics,
maybe.
The goal of RTLString is to avoid duplicate code in the RTL.
Yes I acknowledged that this would be a probl
On Mon, Dec 1, 2008 at 8:34 PM, Luiz Americo Pereira Camara
> I asked this once and no one did an affirmative. I hope this gets clear
> soon, to avoid problems with code of third part LCL developers (like me).
I'll start a discussion about this in lazarus-dev.
--
Felipe Monteiro de Carvalho
On Mon, 01 Dec 2008 21:50:11 +
Martin Friebe <[EMAIL PROTECTED]> wrote:
> Mattias Gaertner wrote:
>[...]
> Yes I agree, and said so before: If a rtl function is going to pass
> on the data to the OS, and conversation is always needed, then no
> overloading is needed. Use RTLString.
>
> If an
Marco van de Voort escreveu:
In our previous episode, Felipe Monteiro de Carvalho said:
This is the part I like about this approach. The most likely fixed
encoding to be adopted would be UTF-16, and something not very nice
would happen to Lazarus users in UNIXes:
LCL (UTF-8) --> RTL (UTF
On Mon, Dec 1, 2008 at 8:27 PM, Mattias Gaertner
<[EMAIL PROTECTED]> wrote:
> I don't see, how a TLCLStrings will *not* break Delphi and Lazarus
> compatibility. Maybe you can give some more details, how it should work.
It was just a initial idea. I now see that TStrings could be improved.
--
Fe
Graeme Geldenhuys escreveu:
On Mon, Dec 1, 2008 at 10:03 PM, Mattias Gaertner
<[EMAIL PROTECTED]> wrote:
and it avoids unneeded conversions.
I understand it 'avoids unneeded conversions' *inside* the RTL, by
adding implicit conversions to the code accessing the RTL.
This is exa
Point taken.
And point also taken that it's not a solution to to a "half job",
meaning overload only methods based on parameters, but not results. This
would be a false pretence, ending people n a believe they do the right
thing where they do not.
Another idea:
The programmer should be able
On Mon, 1 Dec 2008 18:35:26 -0200
"Felipe Monteiro de Carvalho" <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 1, 2008 at 6:22 PM, Mattias Gaertner
> <[EMAIL PROTECTED]> wrote:
> > Compatibility was always the bigger goal for lazarus. IMHO a
> > TLCLStrings breaks more than it would solve.
>
> You mean
On Mon, Dec 1, 2008 at 8:21 PM, Martin Friebe <[EMAIL PROTECTED]> wrote:
> If you have a function overloaded in utf6 and utf16, then You will not need
> to have it in RTLString. RTLString will be equal to either of the 2?
But it's easier to implement like I proposed, and it seams some people
want
Felipe Monteiro de Carvalho wrote:
On Mon, Dec 1, 2008 at 7:33 PM, Martin Friebe <[EMAIL PROTECTED]> wrote:
I suggested to have a rtl, that has overloaded functions for each string
type.
of course that sounds easier than in fact it will be.
This is about the same as having all string r
On Mon, Dec 1, 2008 at 7:26 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>> A string whose encoding is unknown is very inconvenient for
>> developers.
>
> I don't see that so strongly as most.
I know I spoke only generally, but it's hard to speak about and
foresee the effects of something whi
Marco van de Voort escreveu:
In our previous episode, Luiz Americo Pereira Camara said:
string[index], copy, pos, length have always been part of Pascal.
So keep using ansistring? It doesn't change.
Not true if fpc will follow Delphi. The new AnsiString type will be also
Marco van de Voort wrote:
In our previous episode, Mattias Gaertner said:
Florian Klaempfl wrote:
[...]
My opinion is that it should be the programmers choice. I a
programmer wants or needs a simpler way (keeping all the strings in
is application in one format, which will be known to him) the
Felipe Monteiro de Carvalho wrote:
On Mon, Dec 1, 2008 at 10:13 AM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
I assume that the new variable encoding type would be used for all
unicode routines, am I right?
No, it will be RTLString which type depends on the OS.
The more I thi
Jonas Maebe wrote:
There are an immense amount of similar examples possible (and if you add
operator overloading in the mix, it increases exponentially), and you'd
get a huge amount of "can't decide which overloaded function to call"
errors even if the compiler were hacked to take the use of th
Mattias Gaertner wrote:
On Mon, 01 Dec 2008 15:06:45 +
Martin Friebe <[EMAIL PROTECTED]> wrote
That would mean that in order to avoid conversation, some functions
of the RTL would be needed in overloaded versions for each string
type. IMHO this applies only to those, which do not (or not alw
On 01 Dec 2008, at 22:33, Martin Friebe wrote:
I suggested to have a rtl, that has overloaded functions for each
string type.
of course that sounds easier than in fact it will be.
Florian pointed out a few issues, like overloading by result is not
possible (yet?).
No, it is fundamentally
Felipe Monteiro de Carvalho schrieb:
> On Mon, Dec 1, 2008 at 7:24 PM, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>> So how did people work for years with ansistring?
>
> A ansistring used in the way proposed by FPC is extremely inconvenient
> for any GUI application which will be run in differen
On Mon, Dec 1, 2008 at 7:33 PM, Martin Friebe <[EMAIL PROTECTED]> wrote:
> I suggested to have a rtl, that has overloaded functions for each string
> type.
> of course that sounds easier than in fact it will be.
This is about the same as having all string routines in 3 flavours:
RTLString, utf-8 a
Luiz Americo Pereira Camara wrote:
Martin Friebe escreveu:
All the code
Widestring := RtlFunction;
Utf8string := RtlFunction;
will run, it may just perform badly.
Yes and no.
Let's assume the platforms windows and unix having UnicodeString
(UTF-16) and UTF8String as native types respective
On Mon, Dec 1, 2008 at 7:24 PM, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> So how did people work for years with ansistring?
A ansistring used in the way proposed by FPC is extremely inconvenient
for any GUI application which will be run in different parts of the
globe. You develop a applicatio
In our previous episode, Florian Klaempfl said:
> > A string whose encoding is unknown is very inconvenient for
> > developers. The idea just saves itself in the RTL because of the
> > eventual need to do some extremely high performance applications. For
> > Lazarus it would be simply a useless inc
In our previous episode, Felipe Monteiro de Carvalho said:
> > RTLString, IOW encoding platform dependant. Except maybe selected widgets
> > like
> > synedit. (Borland stores source in utf-8 too on windows)
>
> A string whose encoding is unknown is very inconvenient for
> developers.
I don't se
Felipe Monteiro de Carvalho schrieb:
> On Mon, Dec 1, 2008 at 7:01 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>> RTLString, IOW encoding platform dependant. Except maybe selected widgets
>> like
>> synedit. (Borland stores source in utf-8 too on windows)
>
> A string whose encoding is unkn
On Mon, Dec 1, 2008 at 7:01 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> RTLString, IOW encoding platform dependant. Except maybe selected widgets like
> synedit. (Borland stores source in utf-8 too on windows)
A string whose encoding is unknown is very inconvenient for
developers. The idea
On Mon, Dec 1, 2008 at 7:03 PM, Luca Olivetti <[EMAIL PROTECTED]> wrote:
>> LCL (UTF-8) --> RTL (UTF-16) ---> Operating System (UTF-8)
>
> Is the last step always true? Doesn't qt support utf-16?
This is for operating system calls, not graphical library calls.
--
Felipe Monteiro de Carvalho
En/na Felipe Monteiro de Carvalho ha escrit:
LCL (UTF-8) --> RTL (UTF-16) ---> Operating System (UTF-8)
Is the last step always true? Doesn't qt support utf-16?
Bye
--
Luca
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.f
In our previous episode, Felipe Monteiro de Carvalho said:
> On Mon, Dec 1, 2008 at 6:48 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> > Btw will the LCL remain forcedly UTF-8 ? I thought the current Lazarus
> > unicode support was temporary and all options were still open, depending on
> > t
On Mon, 1 Dec 2008 18:45:46 -0200
"Felipe Monteiro de Carvalho" <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 1, 2008 at 6:38 PM, Marco van de Voort <[EMAIL PROTECTED]>
> wrote:
> > In our previous episode, Graeme Geldenhuys said:
> > IOW, you give the programmer the choice about the type, instead of
>
On Mon, Dec 1, 2008 at 6:48 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> Btw will the LCL remain forcedly UTF-8 ? I thought the current Lazarus
> unicode support was temporary and all options were still open, depending on
> the outcome of FPC unicode support options?
It is certainly not tem
In our previous episode, Felipe Monteiro de Carvalho said:
> This is the part I like about this approach. The most likely fixed
> encoding to be adopted would be UTF-16, and something not very nice
> would happen to Lazarus users in UNIXes:
>
> LCL (UTF-8) --> RTL (UTF-16) ---> Operating Syste
On Mon, 1 Dec 2008 21:07:50 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> In our previous episode, Felipe Monteiro de Carvalho said:
> > > You did nail a big problem though, and a weakness in Delphi's
> > > design. What to do with classes that are used both straight and
> > > in the
In our previous episode, Jonas Maebe said:
> > Do they have some way to indicate that a procedure/method only supports
> > a certain encoding?
>
> No.
>
> > Or do you have to manually force the encoding in that way?
>
> Yes.
Clear. I just wondered how they solved it.
> > I prefer a declarativ
On Mon, Dec 1, 2008 at 6:38 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> In our previous episode, Graeme Geldenhuys said:
> IOW, you give the programmer the choice about the type, instead of forcing
> him an arbitrary one, based on your favorite platform.
This is the part I like about this
In our previous episode, Graeme Geldenhuys said:
> >> and it avoids unneeded conversions.
> >
> > I understand it 'avoids unneeded conversions' *inside* the RTL, by
> > adding implicit conversions to the code accessing the RTL.
>
> This is exactly what I was thinking. The conversion is simply pass
On Mon, Dec 1, 2008 at 6:22 PM, Mattias Gaertner
<[EMAIL PROTECTED]> wrote:
> Compatibility was always the bigger goal for lazarus. IMHO a TLCLStrings
> breaks more than it would solve.
You mean compatibility with Delphi?
With Tiburon I think this will become very hard, if possible at all.
We can
On Mon, Dec 1, 2008 at 10:03 PM, Mattias Gaertner
<[EMAIL PROTECTED]> wrote:
>
>> and it avoids unneeded conversions.
>
> I understand it 'avoids unneeded conversions' *inside* the RTL, by
> adding implicit conversions to the code accessing the RTL.
This is exactly what I was thinking. The convers
In our previous episode, Mattias Gaertner said:
> > encoding.
> >
> > That would actually require less fixups (a few conversions procedures
> > for the rare points where tlclstrings are passed to e.g. registry
> > units. Lazarus already has their own XML units).
>
> Only at places where we had t
On Mon, Dec 1, 2008 at 6:22 PM, Mattias Gaertner
<[EMAIL PROTECTED]> wrote:
> Compatibility was always the bigger goal for lazarus. IMHO a TLCLStrings
> breaks more than it would solve.
I don't fully understand how the Tiburon TStrings works, but consider
that we are used to mixing TStrings with L
On 01 Dec 2008, at 21:17, Marco van de Voort wrote:
In our previous episode, Jonas Maebe said:
(nsstring)
The advantage when using such a type is that you also only need to
convert it (internally, hidden from the user) on demand or when some
helper routine requires it (such as e.g. case-inse
In our previous episode, Mattias Gaertner said:
> > In our previous episode, Mattias Gaertner said:
> > > >
> > > > I see this as a theoretic consideration. Please give a real world
> > > > (!) code example when this causes a problem.
> > >
> > > Can you give a real world example where a differen
In our previous episode, Mattias Gaertner said:
>
> > and it avoids unneeded conversions.
>
> I understand it 'avoids unneeded conversions' *inside* the RTL, by
> adding implicit conversions to the code accessing the RTL.
It allows the user to stay conversion free, and have some control over ho
In our previous episode, Jonas Maebe said:
(nsstring)
> The advantage when using such a type is that you also only need to
> convert it (internally, hidden from the user) on demand or when some
> helper routine requires it (such as e.g. case-insensitive
> comparisons). Otherwise, no convers
In our previous episode, Felipe Monteiro de Carvalho said:
> On Mon, Dec 1, 2008 at 5:40 PM, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> >> What string type will be TStrings.Items and the many other strings in
> >> the classes.pp?
> >
> > Not yet decided though I'd make them RTLString as well.
>
On Mon, 1 Dec 2008 17:53:58 -0200
"Felipe Monteiro de Carvalho" <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 1, 2008 at 5:50 PM, Marco van de Voort <[EMAIL PROTECTED]>
> wrote:
> > You did nail a big problem though, and a weakness in Delphi's
> > design. What to do with classes that are used both stra
On 01 Dec 2008, at 20:57, Felipe Monteiro de Carvalho wrote:
On Mon, Dec 1, 2008 at 5:40 PM, Florian Klaempfl <[EMAIL PROTECTED]
> wrote:
What string type will be TStrings.Items and the many other strings
in
the classes.pp?
Not yet decided though I'd make them RTLString as well.
I think
In our previous episode, Felipe Monteiro de Carvalho said:
> > You did nail a big problem though, and a weakness in Delphi's design.
> > What to do with classes that are used both straight and in the GUI?
>
> You mean like TStrings?
>
> I think we will eventually roll our own TUTF8Strings
>
> We
On Mon, 1 Dec 2008 20:44:32 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> In our previous episode, Mattias Gaertner said:
> > >
> > > I see this as a theoretic consideration. Please give a real world
> > > (!) code example when this causes a problem.
> >
> > Can you give a real wor
On Mon, 01 Dec 2008 20:40:14 +0100
Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> Mattias Gaertner schrieb:
> > On Mon, 01 Dec 2008 16:36:23 +0100
> > Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> >
> >> [...] Martin Friebe schrieb:
> >>> I can not see how I can interpret RtlString[1]. If the resu
On Mon, Dec 1, 2008 at 5:40 PM, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>> What string type will be TStrings.Items and the many other strings in
>> the classes.pp?
>
> Not yet decided though I'd make them RTLString as well.
I think you can't change TStrings because that would break all code
us
On Mon, Dec 1, 2008 at 5:50 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> You did nail a big problem though, and a weakness in Delphi's design.
> What to do with classes that are used both straight and in the GUI?
You mean like TStrings?
I think we will eventually roll our own TUTF8Strings
In our previous episode, Mattias Gaertner said:
> > Florian Klaempfl wrote:
> >[...]
> > My opinion is that it should be the programmers choice. I a
> > programmer wants or needs a simpler way (keeping all the strings in
> > is application in one format, which will be known to him) then he/she
> >
On Mon, Dec 1, 2008 at 10:13 AM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
>> I assume that the new variable encoding type would be used for all
>> unicode routines, am I right?
>
> No, it will be RTLString which type depends on the OS.
The more I think about it the more I like this solution. I
In our previous episode, Mattias Gaertner said:
> >
> > I see this as a theoretic consideration. Please give a real world (!)
> > code example when this causes a problem.
>
> Can you give a real world example where a different RTLString for
> each platform solves a problem?
It avoids pingpong re
On Mon, 01 Dec 2008 15:06:45 +
Martin Friebe <[EMAIL PROTECTED]> wrote:
> Florian Klaempfl wrote:
>[...]
> My opinion is that it should be the programmers choice. I a
> programmer wants or needs a simpler way (keeping all the strings in
> is application in one format, which will be known to hi
In our previous episode, Luiz Americo Pereira Camara said:
> >> string[index], copy, pos, length have always been part of Pascal.
> >>
> >
> > So keep using ansistring? It doesn't change.
>
> Not true if fpc will follow Delphi. The new AnsiString type will be also
> automatically converted i
Mattias Gaertner schrieb:
> On Mon, 01 Dec 2008 16:36:23 +0100
> Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>
>> [...] Martin Friebe schrieb:
>>> I can not see how I can interpret RtlString[1]. If the result is
>>> bigger than 128, then I must know what type it is. If it is ANSI,
>>> it is a sing
On Mon, 01 Dec 2008 16:36:23 +0100
Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>[...] Martin Friebe schrieb:
> > I can not see how I can interpret RtlString[1]. If the result is
> > bigger than 128, then I must know what type it is. If it is ANSI,
> > it is a single byte char. If it is utf8, it is
Martin Friebe escreveu:
All the code
Widestring := RtlFunction;
Utf8string := RtlFunction;
will run, it may just perform badly.
Yes and no.
Let's assume the platforms windows and unix having UnicodeString
(UTF-16) and UTF8String as native types respectively.
You choose to use UnicodeString
Michael Schnell schrieb:
>
>> It is planned to allow users to build ANSI version of RTL which will
>> be fully compatible with existing user code.
>> But if you choose to use unicode RTL, you must keep in mind all
>> unicode specific things...
> This will be very helpful for the time being.
It i
It is planned to allow users to build ANSI version of RTL which will
be fully compatible with existing user code.
But if you choose to use unicode RTL, you must keep in mind all
unicode specific things...
This will be very helpful for the time being. Let's hope that the LCL
will follow the Pat
I don't see you complaining about the fact that
char is not 8 bit anymore, and that that abandons that part of the pascal
syntax.
When doing the most common string stuff like
case s[i] of
'1', 'a', 'ä':
...
This does not really hurt.
even
n := ord(s[i]) - ord('0'); works with 16 bit/char s
So keep using ansistring? It doesn't change.
Only if the bytes in the ANSIString in fact are ANSI (which the compiler
in the moment) does not take care for if doing myANSIString :=
myUTF8String etc.
I feel that with Widestring the pos() etc paradigms stay usable in more
cases than with A
From: "Michael Schnell" <[EMAIL PROTECTED]>
And yes, if you lazy, you lose performance due to automatic
conversions. It
has always been that way (also when mixing short and ansistring)
Of course you are very right here !
If you are lazy and write your code like you are used to, you will
not
And yes, if you lazy, you lose performance due to automatic conversions. It
has always been that way (also when mixing short and ansistring)
Of course you are very right here !
If you are lazy and write your code like you are used to, you will not
get optimum performance with a new compile
Martin Friebe escreveu:
Marco van de Voort wrote:
In our previous episode, Martin Friebe said:
I agree, using RTlString will probably help fpc to optimize your exe
for each OS.
But, using RTLString means you do not know, if you have UTF8 or not.
Correct.
Because UTF8 behaves slightl
Martin Friebe schrieb:
> Marco van de Voort wrote:
>> In our previous episode, Martin Friebe said:
>>
>>> Of course they are still there, to be used in the few parts of your
>>> code, where you specialize on whatever string type you deal with.
>>> But otherwise, using RTLString IMHO will abando
Marco van de Voort escreveu:
In our previous episode, Martin Friebe said:
most cases, it is slowly time to abandon too simplistic thinking about
strings. The best solution is to minimize editing, and localize them in
certain parts of the code, keeping most of the code encoding agnostic.
Marco van de Voort wrote:
In our previous episode, Martin Friebe said:
Of course they are still there, to be used in the few parts of your
code, where you specialize on whatever string type you deal with.
But otherwise, using RTLString IMHO will abandon this part of pascal
syntax.
It
Martin Friebe schrieb:
> That would mean that in order to avoid conversation, some functions of
> the RTL would be needed in overloaded versions for each string type.
- people complain already now about bloat
- you can only overload by parameter type not by result
- you cannot overload types in re
Florian Klaempfl wrote:
Martin Friebe schrieb:
In other words, write pascal code, just do not use some of the (imho)
most common elements of pascal syntax?
I acknowledge a language is a living thing, and needs to be adjusted to
the new things, that come up over time. I only ask, if this is th
In our previous episode, Martin Friebe said:
> > most cases, it is slowly time to abandon too simplistic thinking about
> > strings. The best solution is to minimize editing, and localize them in
> > certain parts of the code, keeping most of the code encoding agnostic.
> >
> True, too. But we a
Martin Friebe schrieb:
> In other words, write pascal code, just do not use some of the (imho)
> most common elements of pascal syntax?
> I acknowledge a language is a living thing, and needs to be adjusted to
> the new things, that come up over time. I only ask, if this is the best
> way?
We're o
Marco van de Voort wrote:
In our previous episode, Martin Friebe said:
I agree, using RTlString will probably help fpc to optimize your exe for
each OS.
But, using RTLString means you do not know, if you have UTF8 or not.
Correct.
Because UTF8 behaves slightly different from other
In our previous episode, Martin Friebe said:
> >
> I agree, using RTlString will probably help fpc to optimize your exe for
> each OS.
>
> But, using RTLString means you do not know, if you have UTF8 or not.
Correct.
> Because UTF8 behaves slightly different from other Strings, many
> oper
Marco van de Voort wrote:
In our previous episode, Martin Friebe said:
Why would you do this and not
MyString := SomeRTLRoutine;
?
If I understand that right, this may cause some overhead, that in
some(few) cases is not needed.
Correct.
If I write an application using str
In our previous episode, Martin Friebe said:
> >>
> >> ?
> >>
> >
> > Why would you do this and not
> > MyString := SomeRTLRoutine;
> > ?
> >
> If I understand that right, this may cause some overhead, that in
> some(few) cases is not needed.
Correct.
> If I write an application using
Florian Klaempfl wrote:
Felipe Monteiro de Carvalho schrieb:
On Mon, Dec 1, 2008 at 10:13 AM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
No, it will be RTLString which type depends on the OS.
Ok, so code would be something like this:
var
OSString: RTLString;
MyString: UTF8
On Mon, Dec 1, 2008 at 10:42 AM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
> Why would you do this and not
> MyString := SomeRTLRoutine;
You are right, that should do it. I was thinking about var parameters.
--
Felipe Monteiro de Carvalho
___
fpc-dev
Felipe Monteiro de Carvalho schrieb:
> On Mon, Dec 1, 2008 at 10:13 AM, Florian Klaempfl
> <[EMAIL PROTECTED]> wrote:
>> No, it will be RTLString which type depends on the OS.
>
> Ok, so code would be something like this:
>
> var
> OSString: RTLString;
> MyString: UTF8String;
> begin
> OSSt
On Mon, Dec 1, 2008 at 10:13 AM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
> No, it will be RTLString which type depends on the OS.
Ok, so code would be something like this:
var
OSString: RTLString;
MyString: UTF8String;
begin
OSString := SomeRTLRoutine;
MyString := OSString;
?
It wil
Felipe Monteiro de Carvalho schrieb:
> Hello,
>
> Some things weren't clear from the previous discussion, so I would
> like to clarify them.
>
> For instance, the GetTempFileName routine:
>
> http://www.freepascal.org/docs-html/rtl/sysutils/gettempfilename.html
>
> The routine is currently ANSI
Hello,
Some things weren't clear from the previous discussion, so I would
like to clarify them.
For instance, the GetTempFileName routine:
http://www.freepascal.org/docs-html/rtl/sysutils/gettempfilename.html
The routine is currently ANSI, but we need a unicode version of it.
How would that uni
Leonardo M. Ramé wrote:
Hi, does anyone knows if somebody is working on something like "Pascal Applets",
Some time ago I learned about VST plugins (Audio engines) done with FPC.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http:/
94 matches
Mail list logo
