On 03/05/2014 12:10 PM, Michael Schnell wrote:
(sorry if sounding harsh, but that is what simple logic dictated)
.. And if you think that I am a troll, as I keep nagging on something I
technically can't help to make it happen (because I am not knowledgeable
enough to do any modifications to t
On 02/28/2014 05:06 PM, Sven Barth wrote:
- "non-Raw" does not allow for modifying the type and code-length
fields
Yes, but you can always do it by converting to RawByteString:
Of course but then there is no auto conversion any more.
The start of the discussion was using a type that _both_
On 02/28/2014 05:06 PM, Sven Barth wrote:
Work on final documentation will be started when 2.8/3.0 will be
released. Till then wiki.freepascal.org/FPC_Unicode_Support can be
considered the documentation. Please note that the non existance of a
documentation does not mean that a feature is not c
On 02/28/2014 04:48 PM, Sven Barth wrote:
The string type itself is fully functional as far as I know.
Yep.
The meaning of "fully functional" is what we are discussing here.
No. I would not introduce yet another string type, but try to merge
the existing string types instead as they all sha
Am 28.02.2014 15:42, schrieb Michael Schnell:
On 02/28/2014 03:00 PM, Sven Barth wrote:
As long as not stated differently AnsiString and UnicodeString are
meant as implemented in FPC trunk.
Can you point me to a _final_ documentation on this ?
Work on final documentation will be started when 2.
Am 28.02.2014 15:24, schrieb Michael Schnell:
On 02/28/2014 03:08 PM, Sven Barth wrote:
It is possible as some mails a few months back have shown. If you
have a function that has a RawByteString return type then you can
assign that to a string of any static encoding even if the dynamic
encodin
On 02/28/2014 04:07 PM, Marco van de Voort wrote:
single source two releases, or two source two releases?
Hmm. I suppose also compiler magic is affected and thus the compiler
would needed to be re-compiled for either release.
-Michael
___
fpc-pasca
On 02/28/2014 04:07 PM, Marco van de Voort wrote:
a bit like MSEGUI's Martin Schreiber?
No.
AFAIK, MSEGUI uses the fpc compiler out of the box and "only" provides
an alternate library and IDE.
Martin did draft a new fpc-alike compiler (as discussed in his mailing
list) but he declined to i
On 02/28/2014 04:07 PM, Marco van de Voort wrote:
If you have a working proof of concept ...
As this would need some (even if not much) compiler magic, I will never
be able to provide something like this. Here the help of someone who
understands the internal working of the compiler is necessary
In our previous episode, Michael Schnell said:
> I see that trying different kinds of "Delphi compatibility plus
> OS-independence" (which obviously is a contradiction in itself) makes a
> lot of sense for the fpc / Lazarus combination.
I don't really see it. I'm not even sure if I would like it
On 02/28/2014 03:37 PM, Marco van de Voort wrote:
Fixing that in Lazarus is easier than implementing your case in the
compiler.
Maybe. (Mseide shows how this can be done even without "New Delphi
Strings").
But in many discussions I learned that the Lazarus team is not at all
happy with the
On 02/28/2014 03:00 PM, Sven Barth wrote:
As long as not stated differently AnsiString and UnicodeString are
meant as implemented in FPC trunk.
Can you point me to a _final_ documentation on this ?
Here, The Delphi model does not provide a String encoding type (and
appropriate "compiler magic"
In our previous episode, Michael Schnell said:
>
> > Well, the trick is not to leave that to chance.
>
> I don't understand. When using Lazarus (if it stays similar to what it
> is now) your strings will be UTF8. If pos() requires UTF16 you are out
> of luck.
Fixing that in Lazarus is easier t
On 02/28/2014 03:09 PM, Marco van de Voort wrote:
Yes, but the point is that the programmer that writes the index into
the delete() might not oversee all cases.
You are absolutely right.
But since Unicode is usable in Strings, a "normal programmer" is not
really allowed to "write an index" i
On 02/28/2014 03:08 PM, Sven Barth wrote:
It is possible as some mails a few months back have shown. If you have
a function that has a RawByteString return type then you can assign
that to a string of any static encoding even if the dynamic encoding
is not the same (and then static and dynamic
On 02/28/2014 02:26 PM, Marco van de Voort wrote:
I think it is better to start implementing it in a fork. A fork can
move much faster and make a reconnaissance of all problems and find
solutions for them, and see what you can do to improve compatibility.
One the fork has a functioning Lazarus
In our previous episode, Michael Schnell said:
> > Moreover, will operations that use character access make sense at all
> > if you don't know what the actual encoding is?
> The administrative record of each "New Delphi string" contains the
> encoding type and the byte-count for each code. So "y
Am 28.02.2014 15:01, schrieb Michael Schnell:
On 02/28/2014 01:04 PM, Marco van de Voort wrote:
Moreover, will operations that use character access make sense at all
if you don't know what the actual encoding is?
The administrative record of each "New Delphi string" contains the
encoding type
On 02/28/2014 01:04 PM, Marco van de Voort wrote:
Moreover, will operations that use character access make sense at all
if you don't know what the actual encoding is?
The administrative record of each "New Delphi string" contains the
encoding type and the byte-count for each code. So "you" (the
On 02/28/2014 12:53 PM, Sven Barth wrote:
Problem: there is (currently) no string type that can handle ANSI,
UTF-8 and UTF-16 at once. The first two are handled by AnsiString and
the third by UnicodeString. And those two are not equal which would be
important for overrides/overloads/inheritan
Am 28.02.2014 14:16, schrieb Michael Schnell:
On 02/28/2014 12:53 PM, Sven Barth wrote:
Problem: there is (currently) no string type that can handle ANSI,
UTF-8 and UTF-16 at once. The first two are handled by AnsiString and
the third by UnicodeString. And those two are not equal which would
In our previous episode, Michael Schnell said:
> Here, The Delphi model does not provide a String encoding type (and
> appropriate "compiler magic") that can be used for that purpose (i.e.
> "fully dynamically encoded").
>
> Hence the fpc team _might_ decide to enhance the Delphi imposed model
In our previous episode, Sven Barth said:
> Problem: there is (currently) no string type that can handle ANSI, UTF-8
> and UTF-16 at once. The first two are handled by AnsiString and the third
> by UnicodeString. And those two are not equal which would be important for
> overrides/overloads/inherit
Am 28.02.2014 09:37 schrieb "Michael Schnell" :
>
> ..Continuing the never ending discussion ...
>
> [ In one ore more other threads here I showed that (IMHO) it would be
most sensible (and in fact not performance killing (!) ) way out of the
multiple (statically defined) "new" String types with di
..Continuing the never ending discussion ...
[ In one ore more other threads here I showed that (IMHO) it would be
most sensible (and in fact not performance killing (!) ) way out of the
multiple (statically defined) "new" String types with different encoding
(with auto-conversion) to addition
Am 16.01.2014 15:31 schrieb "Michael Schnell" :
>
> On 01/16/2014 12:04 PM, Sven Barth wrote:
>>
>> If you want to use them in e.g. a class you need to pick a
specialization and thus a code page at compile time.
>
>
> A project might contain different part that handle differently encoded
strings.
On 01/16/2014 12:04 PM, Sven Barth wrote:
If you want to use them in e.g. a class you need to pick a
specialization and thus a code page at compile time.
A project might contain different part that handle differently encoded
strings. Thus a central functionality to store and retrieve strings
Am 15.01.2014 17:19 schrieb "Michael Schnell" :
>
> DXE Strings again :-) ,
>
> What is the relation between Generic Functions and (static) DXE String
encoding schemes ?
>
> Can you (e.g.) do a (silly) Generic Function that takes two strings of
any (but identical) encoding type, concatenates them a
In our previous episode, Michael Schnell said:
> DXE Strings again :-) ,
>
> What is the relation between Generic Functions and (static) DXE String
> encoding schemes ?
Afaik none. Constraints are interfaced based, and strings are no objects.
___
fpc
DXE Strings again :-) ,
What is the relation between Generic Functions and (static) DXE String
encoding schemes ?
Can you (e.g.) do a (silly) Generic Function that takes two strings of
any (but identical) encoding type, concatenates them and outputs the
result in the same (static) encoding t
30 matches
Mail list logo
