Jonas Maebe schrieb:
On 07 Jan 2014, at 15:35, Hans-Peter Diettrich wrote:
2) The stupid conversion to CP_ACP in an assignment *to* an
RawByteString should be dropped. This applies in detail to the
assignment to *function results*.
The conversion does not happen for all assignments, it only
On 07 Jan 2014, at 21:41, Florian Klämpfl wrote:
> Am 07.01.2014 14:34, schrieb Jonas Maebe:
>>
>> It's under the header "Old/obsolete sections" and as mentioned above,
>> that's "incomplete or wishful thinking". I didn't want to delete any
>> existing content for now, but yes, what's mentioned
Am 07.01.2014 14:34, schrieb Jonas Maebe:
>
> On 07 Jan 2014, at 14:13, Mattias Gaertner wrote:
>
>> What is this crap:
>> http://wiki.freepascal.org/FPC_Unicode_support#FPC_Unicode_support
>> ?
>
> It's under the header "Old/obsolete sections" and as mentioned above,
> that's "incomplete or wis
Am 07.01.2014 17:00 schrieb "Michael Schnell" :
> - there have been decent discussions in multiple forums showing that
that classes with "automatic reference counting" are dangerous
I like the idea of ARC classes. In fact I'm trying to develop an
implementation that is fully backwards compatible
On 01/07/2014 04:33 PM, Jonas Maebe wrote:
but more regarding descendent classes in existing third party (= user)
source code that override methods using AnsiString parameters.
Automatic type conversion should be able to handle this (as the new type
would preserve and thus dynamically know the
On 01/07/2014 04:24 PM, Craig Peterson wrote:
They're using the mobile compiler as an opportunity to break backwards
compatibility and push the language in the directions they want to go.
A single, 0-based string type, automatic reference counting, no
"with", etc. Apparently the developers they
On Tue, 7 Jan 2014, Craig Peterson wrote:
The compiler supports AnsiStrings, but these are hidden for *mobile*
targets.
Any reason for this strangeness ?
They're using the mobile compiler as an opportunity to break backwards
compatibility and push the language in the directions they want to
On 07 Jan 2014, at 15:35, Hans-Peter Diettrich wrote:
> 1) In a discussion in the Embarcadero groups it turned out that, in an
> assignment of a RawByteString to another AnsiString type, the Delphi compiler
> should (but does not) check and eventually convert the string to the static
> encodin
>> The compiler supports AnsiStrings, but these are hidden for *mobile*
>> targets.
> Any reason for this strangeness ?
They're using the mobile compiler as an opportunity to break backwards
compatibility and push the language in the directions they want to go.
A single, 0-based string type, autom
On 1/7/2014 8:35 AM, Hans-Peter Diettrich wrote:
> Sorting (TStringList) eventually should ignore the dynamic encoding,
> i.e. work on a strictly binary (byte-by-byte) base.
Why would that be desirable? If you sort a *string* list you'd expect
it to do a string based sort, and more than likely, a
On 01/07/2014 03:35 PM, Hans-Peter Diettrich wrote:
What if FPC adds another encoding, similar to RawByteString ($),
but without the Delphi quirks? Or simply fix the RawByteString flaws
in the *Ansi* compiler and RTL?
+1 (in fact I elaborated on that in some older Threads here)
1) In a
On 07 Jan 2014, at 15:54, Jy V wrote:
> n Tue, Jan 7, 2014 at 12:57 PM, Jonas Maebe wrote:
>
>> For this reason I've created an overview that explains the rules that are
>> followed by the RTL/compiler at
>> http://wiki.freepascal.org/FPC_Unicode_support
>
> "it is best to save the source code
On 01/07/2014 02:24 PM, Hans-Peter Diettrich wrote:
The compiler supports AnsiStrings, but these are hidden for *mobile*
targets.
Any reason for this strangeness ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freep
On Tue, Jan 7, 2014 at 12:57 PM, Jonas Maebe wrote:
> For this reason I've created an overview that explains the rules that are
> followed by the RTL/compiler at
> http://wiki.freepascal.org/FPC_Unicode_support
>
"it is best to save the source code in UTF-8 with a BOM."
Is this recommendation is
Jonas Maebe schrieb:
Large parts of the returning discussions about code page-aware
AnsiStrings are related to the fact that many people don't how they
work. For this reason I've created an overview that explains the rules
that are followed by the RTL/compiler at
http://wiki.freepascal.org/FP
Jy V schrieb:
A quick note: the new LLVM Delphi compiler forbid the use of AnsiString
and AnsiChar, (declared in the unit AnsiString.pas, you cannot use this
unit anyway),
The compiler supports AnsiStrings, but these are hidden for *mobile*
targets. There exists a hack to enable AnsiString s
Michael Van Canneyt schrieb:
If you want a TStrings that can hold strings which may differ in their
encoding (i.e. strings[0] has a different encoding from strings[1]) then
you'll be left in the cold.
Just an idea:
What if FPC adds another encoding, similar to RawByteString ($), but
with
On 07 Jan 2014, at 14:13, Mattias Gaertner wrote:
What is this crap:
http://wiki.freepascal.org/FPC_Unicode_support#FPC_Unicode_support
?
It's under the header "Old/obsolete sections" and as mentioned above,
that's "incomplete or wishful thinking". I didn't want to delete any
existing con
> Jonas Maebe hat am 7. Januar 2014 um 12:57
> geschrieben:
>
>
> Hi,
>
> Large parts of the returning discussions about code page-aware
> AnsiStrings are related to the fact that many people don't how they
> work. For this reason I've created an overview that explains the rules
> that are fo
On 01/07/2014 01:23 PM, Jonas Maebe wrote:
... nor an attempt to address every person's wish list written down
previously on that page.
Yep. And as (pure) Delphi XE compatible behavior (at least in my
opinion) is not what is desirable for a portable language/rtl, while
generally Delphi comp
On 01/07/2014 01:24 PM, Michael Van Canneyt wrote:
But like I said: Do not expect us to adapt the RTL to suit any
inappropriate use of strings.
Like I said: I don't ! (With the requested behavior this comes for free
as a side-effect.)
But I do expect decent handling of "locale based 1 Byte A
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 01/07/2014 01:05 PM, Michael Van Canneyt wrote:
This is a mistake. You should use TByteArray for that. "Old" pre-unicode
Delphi also handles this type.
Of course I do know that this sometimes is recommended, but (with pre-Unicode
Delphi) I do
On 07 Jan 2014, at 13:11, Michael Schnell wrote:
On 07 Jan 2014, at 12:57, Jonas Maebe wrote:
[ http://wiki.freepascal.org/FPC_Unicode_support ]
This in fact is in the paragraph " Old/obsolete sections", but it
does not seem to be mentioned in any "current" paragraph:
"Roadmap of RTL Unicod
On 01/07/2014 01:05 PM, Michael Van Canneyt wrote:
This is a mistake. You should use TByteArray for that. "Old"
pre-unicode Delphi also handles this type.
Of course I do know that this sometimes is recommended, but (with
pre-Unicode Delphi) I don't see any point in not using "String", which
This in fact is in the paragraph " Old/obsolete sections", but it does
not seem to be mentioned in any "current" paragraph:
"Roadmap of RTL Unicode support with UnicodeString":
- TStrings Not implemented There is no UnicodeString version
of TStrings
- TStringList Not implemented
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 01/07/2014 12:27 PM, Michael Van Canneyt wrote:
if you have use-case 1 (which I doubt, since it is not possible even today)
then you're better off using unicodestring anyway.
My argumentation is driven by the experience (some myself, a huge lo
Hi,
Large parts of the returning discussions about code page-aware
AnsiStrings are related to the fact that many people don't how they
work. For this reason I've created an overview that explains the rules
that are followed by the RTL/compiler at http://wiki.freepascal.org/FPC_Unicode_suppo
On 01/07/2014 12:27 PM, Michael Van Canneyt wrote:
if you have use-case 1 (which I doubt, since it is not possible even
today) then you're better off using unicodestring anyway.
My argumentation is driven by the experience (some myself, a huge lot by
my colleagues) with doing "embedded" M2M-
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 01/07/2014 11:48 AM, Michael Van Canneyt wrote:
TRawByteString is what you need.
AFAI was told by DXE users, this is not true. That is why i did not test this
yet. But as you state otherwise I will check into that.
But anyway this does not hel
On 01/07/2014 11:48 AM, Michael Van Canneyt wrote:
TRawByteString is what you need.
AFAI was told by DXE users, this is not true. That is why i did not test
this yet. But as you state otherwise I will check into that.
But anyway this does not help, as long as the RTL (especially TStrings,
TS
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 01/07/2014 11:22 AM, Michael Van Canneyt wrote:
There is not much to say.
There will be 2 sets of units:
* Unicode
* AnsiString
for unicode, there is no problem, since everything is 2 bytes (ignoring
some exotic codepoints here) so string enco
On 01/07/2014 11:28 AM, Jonas Maebe wrote:
creating two separate sets of units is a good step regardless of what
happens eventually, since we need the functionality of both in any case.
This sounds like "State 3" is flickering at the horizon t as well :-) :-)
-Michael
_
On 07 Jan 2014, at 11:22, Michael Van Canneyt wrote:
There will be 2 sets of units:
* Unicode
* AnsiString
Or they may be integrated to a large extent. This has not yet been
decided. In any case, creating two separate sets of units is a good
step regardless of what happens eventually, sin
On 01/07/2014 11:22 AM, Michael Van Canneyt wrote:
There is not much to say.
There will be 2 sets of units:
* Unicode
* AnsiString
for unicode, there is no problem, since everything is 2 bytes
(ignoring some exotic codepoints here) so string encoding does not apply.
for ansistring, string=a
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 01/07/2014 10:41 AM, Michael Van Canneyt wrote:
We know this. But that is stage 2.
Sounds great !
Could you elaborate those plans ?
There is not much to say.
There will be 2 sets of units:
* Unicode
* AnsiString
for unicode, there is no pr
On 01/07/2014 10:41 AM, Michael Van Canneyt wrote:
We know this. But that is stage 2.
Sounds great !
Could you elaborate those plans ?
I fear that releasing "stage 1" to the public might introduce another
source of incompatibility.
Explanation: My horror-scenario when trying to convince
On 12/30/2013 12:53 PM, Jy V wrote:
A quick note: the new LLVM Delphi compiler forbid the use of
AnsiString and AnsiChar,
Yuck !
Forking the platforms in that incompatible way a really ugly move of
Delphi's. Hopefully fpc (and Lazarus) is able to continue it's path to
real source code compati
On 12/29/2013 07:26 PM, Hans-Peter Diettrich wrote:
My view on RawByteString:
My view on RawByteString originally had been that it can hold strings of
any encoding and the software that gets such a variable (or function
argument) can detect the actual encoding and behave accordingly. Thus
"dy
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 12/29/2013 10:57 AM, Michael Van Canneyt wrote:
We're way past that stage.
Sorry, but IMHO freezing the current (supposedly DXE compatible) state does
not make much sense.
To decently support creating fully portable applications for multiple
While this behavior is absolutely logical, as a normal procedure could
not use a property in that way.
OTOH just as a courtsey, the _builtin_ procedures inc() and dec() could
be implemented in a way that allows for doing it.
-Michael
___
fpc-devel m
On 12/29/2013 10:57 AM, Michael Van Canneyt wrote:
We're way past that stage.
Sorry, but IMHO freezing the current (supposedly DXE compatible) state
does not make much sense.
To decently support creating fully portable applications for multiple
OSes, "TStrings" and its siblings (e.g. TStri
What is the difference between this and the TUI that comes up when you
start "tp". (Same obviously already is part of the fpc source code
distribution.)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi
42 matches
Mail list logo