Am 09.03.2015 um 14:36 schrieb bla...@blaise.ru:
FPC trunk r30150, compiled with EXTDEBUG, emits a debug warning for
the following program:
--8--
type T = interface
procedure Bar;
end;
function Foo: T;
begin
result := nil
end;
begin
Foo().Bar()
// ^--
Am 14.12.2014 um 16:51 schrieb Marco van de Voort:
In our previous episode, Adriaan van Os said:
reveals 0 for False and -1 for True, where I had expected 0 for False and
1 f
according to http://msdn.microsoft.com/en-us/library/eke1xt9y.aspx the
same
respectively in Visual Studio 2013.
There
Using FPC trunk, Lazarus on WinXP, file and $codepage UTF-8,
DefaultSystemCodePage is 1252.
Then AnsiString variables can contain either UTF-8 or cp1252 strings
(inconsistent), but that's an already known problem :-(
Now I found another bug with AnsiString(1252), which IMO should behave
IMO the Insert procedure should change the encoding of the
string-to-insert into the CP of the target string. Else the target
string can become unusable, containing an mix of characters from
different codepages. While a RawByteString can have any encoding, it
cannot have two encodings at the
The following console program demonstrates various problems with the new
(encoded) AnsiStrings (FPC trunk):
program litTest2;
{.$codepage UTF8} //off for now
uses Classes,SysUtils;
var A: AnsiString;
begin
a := 'äöü';
//a := a+' '; //uncomment later
WriteLn(a,'äöü');
Tomas Hajny schrieb:
On Tue, December 2, 2014 08:31, Hans-Peter Diettrich wrote:
When I compile a console program on the commandline, most strings are
readable in the console (see previous answer). But when I compile using
Lazarus, all strings (including UnicodeString!) are shown
Mattias Gaertner schrieb:
On Tue, 02 Dec 2014 04:05:59 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
Many things affect string literals. Source codepage, system codepage,
string type, defaultsystemcodepage, library, compiler version.
I started a table for UTF-8 literals:
http
Michael Schnell schrieb:
On 11/28/2014 09:15 PM, Hans-Peter Diettrich wrote:
Apart from that, every encoding-tolerant code will execute much slower
than code without a need for checks and conversions everywhere.
As I pointed out I don't agree at all.
- The check is only two ASM instructions
Sven Barth schrieb:
Am 01.12.2014 10:33 schrieb Hans-Peter Diettrich drdiettri...@aol.com
mailto:drdiettri...@aol.com:
Another one:
Delphi XE does not export the CP_xxx encoding constants from
System.pas. This means that the encoding constants are not available in
(compatible) user code
Jonas Maebe schrieb:
Hans-Peter Diettrich wrote on ma, 01 dec 2014:
To get behaviour that is compatible with Delphi2009+, compile with
-Mdelphiunicode or {$modeswitch delphiunicode}.
The compiler option (-M) works, but the $modeswitch is not accepted by
the compiler (2.7.1): Illegal
Jonas Maebe schrieb:
On 28/11/14 21:30, Hans-Peter Diettrich wrote:
I prefer to specify and document everything *before* coding, so that
everybody can expect that the code will behave as specified.
If certain behaviour is explicitly undefined, it *is* specified and
documented. It means
In response to another thread (this should start an new thread):
CP_NONE: this value indicates that no code page information has been
associated with the string data. The result of any explicit or implicit
operation that converts this data to another code page is undefined.
After rereading I
Jonas Maebe schrieb:
I'm sorry, but I simply cannot discuss with people that, when I
literally state the result is undefined, think that I may actually
have meant the result is defined and if you change the
implementation and/or keep it stable across compiler releases, then
it will also conform
Michael Schnell schrieb:
I fear that there will be code that relies on the flawed behavior of
RawByteString (it's a feature, not a bug) and using the same name with
different behavior would brake same. And a really usable DynmicString
would not adhere to that description.
How can somebody
Michael Schnell schrieb:
On 11/27/2014 03:44 PM, Hans-Peter Diettrich wrote:
An *efficient* implementation would be based on a single program-wide
string representation, with different encodings being handled only in
an exchange with external data sources.
Yep. But it would result in severe
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
While it certainly is a stupid (Microsoft) idea to use UTF-16 for file
storage, we'll have to take that into account.
(16-bit codepages were designed into OS/2 and Windows NT before utf-8 even
existed)
Right
Sven Barth schrieb:
At my old company our Delphi application handled runtime changes to
these settings rather well. For display the normal XToY (e.g. DateToStr)
functions are used which use the DefaultFormatSettings which are updated
automatically (the VCL's message loop triggers a repaint
Michael Schnell schrieb:
I now understand that the Element Size field in the String header is
quite dummy, as under the hood there are two completely separate
concepts for one-byte-Strings and 2-Byte Strings and none for other
Element sizes.
After a code review I realized that the element
Frederic Da Vitoria schrieb:
2014-11-26 16:54 GMT+01:00 Hans-Peter Diettrich drdiettri...@aol.com
mailto:drdiettri...@aol.com:
2) Formatted numbers, as enterd by the user (maybe by copypaste
from other applications), can have various encodings. Before a
conversion into binary
Michael Schnell schrieb:
On 11/26/2014 07:13 PM, Hans-Peter Diettrich wrote:
Not all codepages have a fixed number of bytes per character.
The string preamble contains the *element size* (1 for AnsiString),
just like with every dynamic array.
Sorry for sloppy wording. Of course I did mean
Jonas Maebe schrieb:
On 26/11/14 23:41, Hans-Peter Diettrich wrote:
In this case the implementation is compiler specific, somewhat
different from undefined (in a RawByteString):
CP_NONE: this value indicates that no code page information has been
associated with the string data. The result
Michael Thompson schrieb:
I hear you, but this issue is so much wider than separators. I know one
software package that will only successfully export data to excel if the
system regional is one of the English (xxx) variations (Australian
guaranteed to work, not really played with the
Michael Schnell schrieb:
On 11/26/2014 06:37 PM, Hans-Peter Diettrich wrote:
An AnsiString consists of AnsiChar's. The *meaning* of these char's
(bytes) depends on their encoding, regardless of whether the used
encoding is or is not stored with the string.
I understand
Mattias Gaertner schrieb:
On Wed, 26 Nov 2014 11:23:17 +0100
Michael Schnell mschn...@lumino.de wrote:
Seemingly here the bytes per character setting implicitly is thought
of as a port of the code-page definition. correct ?
Code page define bytes per character.
Huh?
Not all codepages
Michael Schnell schrieb:
On 11/26/2014 11:40 AM, Mattias Gaertner wrote:
Ansistring supports only one byte per character code pages.
Even more confused. Am I wrong thinking that with code aware Strings,
for Delphi XE compatibility, in Windows CP_ACP needs to be UTF16 (if not
right, than
Michael Schnell schrieb:
On 11/26/2014 12:09 PM, Sven Barth wrote:
In Delphi (and FPC) CP_ACP corresponds by default with the current
system codepage (e.g. CP1252 on a German Windows).
OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as
String(CP1252) but different from String
Mattias Gaertner schrieb:
Hi,
The page about FPC Unicode support mentions what has already been
updated to preserve character data.
http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes
Is there already a page about what has not (yet) been updated aka does
not work with all code pages?
Michael Schnell schrieb:
I fail to understand some of the text.
It seems to be unavoidable to use the name ANSIString even though I
always though up when seeing a thing called ANSI containing Unicode
(e. g. UTF8String = type AnsiString(CP_UTF8) ).
Seemingly here the bytes per character
Ewald schrieb:
Of the OS/window manager actually. You are of course right in that there
are a certain set of separators that can be used, but the exact
separator to use is dependent on the system.
Sounds easy, but just yesterday I ran into a bunch of related problems.
Even if the following
Mattias Gaertner schrieb:
For example:
CP_ACP=0, DefaultSystemCodePage=1252
That means static code page is always 0, while dynamic code page can be
0 or 1252. Both describe the same encoding.
A *dynamic* encoding *never* can be CP_ACP nor CP_NONE (in Delphi).
These values are allowed only
Michael Schnell schrieb:
So seemingly you could do MyStringType = type
AnsiString(CP_UTF16), and seemingly the size information is set
according to this.
Not in Delphi XE.
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Jonas Maebe schrieb:
On 26/11/14 17:41, Tomas Hajny wrote:
BTW, in this context - can users choose UTF16BE on little endian
platforms (and vice versa)?
No, because we do not have any routines that allow a user to set/change
the codepage of a unicodestring (either at run time or at compile
Jonas Maebe schrieb:
Technically, that section literally states that they will be
concatenated without data loss and that the result is then converted to
the target string's encoding (except in case the target is
RawByteString). How that is implemented exactly is undefined; again in
the meaning
Michael Van Canneyt schrieb:
The ThousandSeparator is char and supports only 1 byte characters.
For example French and Russian need more.
Are there any plans to extend it?
Plans: yes. Time: no.
Maybe a widechar is sufficient ? Making it a string is more invasive
than making it a widechar.
Mattias Gaertner schrieb:
Does concatenating a string and a WideChar create a UnicodeString? Can
this become a problem?
Concatenation requires 2 strings, so everything depends on the concrete
code. Regardless of eventual compiler magics, something like this will
happen:
var c: WideChar;
Vsevolod Alekseyev schrieb:
Hi all,
in the FPC reference at
http://www.freepascal.org/docs-html/ref/refse68.html#x127-13700012.1 ,
the formal grammar spec only goes down as far as factor. Can I please
see the grammar for variable reference? A variable reference can be an
arbitrarily complex
Vsevolod Alekseyev schrieb:
Hi all,
in the FPC reference at
http://www.freepascal.org/docs-html/ref/refse68.html#x127-13700012.1 ,
the formal grammar spec only goes down as far as factor. Can I please
see the grammar for variable reference? A variable reference can be an
arbitrarily complex
Paul Breneman schrieb:
I think 100Mb is a bit small.
You'll need cross-binutils, X, cross-dev libs and whatnot.
650Mb would be feasable, I guess.
Thanks for that info, but couldn't most of that be download into the VM
*after* it is running? Seems to me I'd like the *smallest* VM and then
Sven Barth schrieb:
On 28.10.2014 10:15, Michael Schnell wrote:
On 10/27/2014 05:17 PM, Hans-Peter Diettrich wrote:
Something like ShortString and AnsiString?
Only that ShortStrings can easily be avoided (AFAIK, no great
performance advantage to use them) and hence are seldom used right now
Sven Barth schrieb:
On 28.10.2014 10:19, Michael Schnell wrote:
On 10/27/2014 07:59 PM, Sven Barth wrote:
- in code that does not use ARC (modeswitch arc off - the default;
or maybe better a local directive) all instance variables are
considered weak
While I do have a vision what weak means
Sven Barth schrieb:
On 28.10.2014 09:57, Hans-Peter Diettrich wrote:
Something like ShortString and AnsiString?
Take unit Typinfo for example where quite some methods take a TObject
instance.
The TypInfo methods can determine the exact type of their arguments, and
act inside
Sven Barth schrieb:
On 30.10.2014 04:14, Hans-Peter Diettrich wrote:
I wonder how difficult it would be to implement the existing Interface
refcounting model for TObject, so that this runtime variation could be
tested and benchmarked as well, in addition to the current compiletime
approach
Sven Barth schrieb:
Am 27.10.2014 21:00, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
Am 27.10.2014 17:20 schrieb Hans-Peter Diettrich
drdiettri...@aol.com mailto:drdiettri...@aol.com:
Something like ShortString and AnsiString?
With the difference that Short- and AnsiString
Boian Mitov schrieb:
In general the C/C++ notion of doing as little in the language as
possible, and as much in library has worked very well for it over the
years.
Yes, pluggable languages concept has existed at least since C ;-) . I
agree, and as I said has worked well.
AFAIR such languages
Sven Barth schrieb:
Am 27.10.2014 23:41 schrieb Boian Mitov mi...@mitov.com
mailto:mi...@mitov.com:
Well... we may differ on this one. I absolutely love attributes, but
I guess that is just me :-D .
I think attributes are the greatest thing that has happened to Delphi
ever, I just wish
Paul Breneman schrieb:
I've spent a bit of time during the past 7 years trying to figure out
how to simplify things by avoiding cross-compiling. This page has many
of the details:
http://turbocontrol.com/monitor.htm
I think there is a way to simplify cross-compiling. Levinux is a small
Jonas Maebe schrieb:
Additionally, as mentioned before, I still believe it's a very bad idea
to be able to inherited from a regular class and turn it into a
reference counted class. Reference counted and non-reference-counted
classes are different language entities with different behaviour and
Sven Barth schrieb:
Am 27.10.2014 17:20 schrieb Hans-Peter Diettrich drdiettri...@aol.com
mailto:drdiettri...@aol.com:
Something like ShortString and AnsiString?
With the difference that Short- and AnsiString are assignable to
eachother while Jonas does not want that for reference counted
Kostas Michalopoulos schrieb:
On Mon, Oct 27, 2014 at 5:17 PM, Hans-Peter Diettrich
drdiettri...@aol.com mailto:drdiettri...@aol.com wrote:
Then the compiler can safely generate refcounting code for *all*
objects and non-weak references, and the counting methods take care
Sven Barth schrieb:
A semicolon has the problem that you need to distinguish between it
being a modifier and a normal following identifier as not every keyword
is a keyword in every context (like for example read and write for
properties).
In this discussion I almost miss the elementary
Sven Barth schrieb:
Am 25.10.2014 03:17 schrieb Hans-Peter Diettrich drdiettri...@aol.com
mailto:drdiettri...@aol.com:
- a class instance is destroyed once the reference count reaches
zero (and Free does not work for them)
Shouldn't Free be usable as a finalizer, clearing all
Sven Barth schrieb:
Hello together!
I've now finished my Proof of Concept ARC implementation which is based
on the RFC I published a few weeks back:
http://lists.freepascal.org/fpc-devel/2014-September/034263.html
Fine :-)
To recap:
[...]
- a class instance is destroyed once the
Sven Barth schrieb:
At least at first sight there don't seem to be any real (technical)
reasons to not covariance for return values. Parameters would be a
different topic though...
Just so I get the idea right:
=== code begin ===
type
TBar = class
function Test: TObject; virtual;
Mark Morgan Lloyd schrieb:
Boian Mitov wrote:
I think parallel processing belongs in library implementations.
I have reservations, based in part on the fact that other language
implementations are prepared to assume responsibility for
parallelisation, in part on experience with e.g. APL
Florian Klämpfl schrieb:
If the time spent in this thread had been spent in coding, FPC would have
already ARC. The list has
approx. 600 members, 200 message were written. If each of the 600 members spent
on average 1 min
reading this thread, this is 2000 man-hour, i. e. approx. 1 MY :)
Sven Barth schrieb:
There are however some nasty problems inside constructors and
destructors, because Self is reference counted as well (and should be
after all as we don't want the instance to be destroyed behind our backs
suddenly).
IMO before the end of a constructor, and before the
Marco van de Voort schrieb:
In our previous episode, Sven Barth said:
It looks to me like inside methods Self doesn't deserve refcounting,
because a method can be invoked only with an existing instance, which
will stay alive at least until the call returns.
That's the thing I'm not yet entirely
Sven Barth schrieb:
On 21.09.2014 21:09, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
[...]
I'd add a _RefCount field to TObject, regardless of whether it's really
used later; this will fix the field offset - just like the VMT reference
is fixed in TObject, but not in Object types
Sven Barth schrieb:
Am 22.09.2014 09:47 schrieb Michael Schnell mschn...@lumino.de
Why not use interface to add ref-counting to an object ? This seems
to work nicely even though the name interface in not speaking on
that behalf.
Because you'll need to declare an interface for each class
Marco van de Voort schrieb:
(to Sven)
So the cycle break mechanism is going to be marking potential cycle cases
as weak.
Do you still plan to at least detect cycles for debugging purposes?
Or is the cycle detection itself already too hard?
IOW I'm wondering what will happen (and what to do)
Sven Barth schrieb:
Am 22.09.2014 12:59 schrieb Hans-Peter Diettrich drdiettri...@aol.com
That's why I also suggested an compiler option, useful for all people
which care about program size or ARC at all.
The problem with the compiler option is that you'd need to rebuild the
complete RTL
Boian Mitov schrieb:
In general, records and classes are inherently the same thing (and in
C++ are indeed practically interchangeable).
This model might have been the reason for introducing Object at all, for
compatibility with CBuilder.
The only real difference in
Delphi/FPC is that
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
IMO Weak references should be reserved for users who accept possible
consequential problems, but should never be used in standard libraries.
At least I'd suggest to make weak references subject to an compiler
Sven Barth schrieb:
On 20.09.2014 13:42, Sven Barth wrote:
On 20.09.2014 13:11, Peter Popov wrote:
- to remedy this TObject is extended with non-virtual methods that allow
manual reference counting and would rely on the RTTI data I mentioned
(let's call the methods AddRef, Release,
Florian Klämpfl schrieb:
Am 21.09.2014 um 07:22 schrieb Hans-Peter Diettrich:
Boian Mitov schrieb:
That is easy. it gets incremented when it gets assigned. The running threads
have no way of
accessing it if there is no reference (assignment) already in place.
The problem arises when
Fabrício Srdic schrieb:
Hello,
In platforms with managed code (.NET, Java), objects are automatically
freed by the memory manager / garbage collector.
Would not it be interesting to have a similar feature in FPC?
AFAIK some Delphi XE made TObject itself managed, by reference counting.
It
Sven Barth schrieb:
Am 20.09.2014 01:52 schrieb Hans-Peter Diettrich drdiettri...@aol.com
It's up to the coder to make all properties etc. published, when he
*intends* to ever use RTTI on them. That't the way to tell the compiler
what to do.
The extended RTTI introduced with Delphi 2010
Sven Barth schrieb:
On 20.09.2014 12:36, Hans-Peter Diettrich wrote:
AFAIK some Delphi XE made TObject itself managed, by reference counting.
It would be easy to introduce the same feature in FPC, so that no
special base class would be required. Like with extended RTTI a decision
should
Boian Mitov schrieb:
The short story is that any approach has issues.
The component container approach has issue of a single ownership with
the easy loss of pointers.
The ref counting has the danger of circular references.
The GC has the non deterministic behavior (Actually I proposed a
Sven Barth schrieb:
Am 20.09.2014 20:34 schrieb Giuliano Colla
A general mechanism to be reliable should take into account all
possibilities. If it does, it will block threads even when unnecessary.
If it doesn't, it will be unsafe.
That would work the same way as it does in interfaces,
Giuliano Colla schrieb:
Hi Boian,
I'm easily convinced that you've developed a lot of things using
reference counting. Design is the art of compromise, and possibly in
your class of application that's the best compromise.
But we should never forget that our class of applications isn't the
Boian Mitov schrieb:
That is easy. it gets incremented when it gets assigned. The running
threads have no way of accessing it if there is no reference
(assignment) already in place.
The problem arises when an object is destroyed, or even elected for
destruction in _Release, while another
Boian Mitov schrieb:
On Fri, 19 Sep 2014, Adriaan van Os wrote:
Your remarks seem to imply that you think RTTI can be used to inspect
any aspect of an object.
It was/is not meant for that.
Quite incorrect. All languages with modern RTTI allow for full object
inspection, and that includes
Dmitry Boyarintsev schrieb:
How about introducing a default parameter?
The parameter keeps the method backward compatible, allowing write a
string without the prefix.
public procedure TStream.WriteAnsiString(
const S: string;
withLength: Boolean = true;
How should a string without a
Giuliano Colla schrieb:
If you're using relative times and not absolute ones, then you may avoid
the search, without need to resort, using a slightly different scheme,
i.e. entering in a sorted list the times *relatives to the previous one*.
Then your queue can run out of sync with the
Ewald schrieb:
On 03 Mar 2014, at 00:29, Hans-Peter Diettrich wrote:
`-1` would then be $1 , whereas $
would be $0 . It really is quite
easy to store it like that and `fix` things [picking a fitting
datatype] afterwards.
The datatype
Ewald schrieb:
On 03 Mar 2014, at 12:49, Hans-Peter Diettrich wrote:
How (which data type) does *your* parser store untyped numerical
constants?
Roughly like this (syntax may be a bit awry, but you get the point):
TIntegerNumber = Record Case SignedNess: TSignedNess of snPositive:
UValue
Ewald schrieb:
Talking about principles: If hexadecimal is actually used to
represent bit patterns (as Hans-Peter Diettrich wrote), then the
decision to use a signed type here seems to violate this (represent
bitpatterns) principle, since the highest bit in a signed number has
a different
Michael Schnell schrieb:
On 02/28/2014 02:18 AM, Hans-Peter Diettrich wrote:
So the lack of Self seems to apply to static; methods, not to
class methods. I'll ask in an EMBT group for a description of
static;, the OH seems to reflect the C++ meaning only,
In ANSI C static with functions
Ewald schrieb:
On 28 Feb 2014, at 20:39, Jonas Maebe wrote:
All hexadecimal constants are (conceptually) parsed as int64, so
this is by design. int64($) is not -1.
By the way, what do you do when you want to port fpc to a one's
comlement machine (if they still exist)?
Michael Van Canneyt schrieb:
So what's the special use of a *class* property? If it exists for
Delphi compatibility only, why then is it handled differently from
property?
The reason is explained in the upcoming docs.
Namely: a static method cannot be overridden.
Sure, but virtual methods
Michael Van Canneyt schrieb:
The reason is explained in the upcoming docs.
Namely: a static method cannot be overridden.
Sure, but virtual methods (including class methods) can be overridden.
The class property is part of this particular class, and descendent
classes should not be able to
Sven Barth schrieb:
Am 27.02.2014 15:35, schrieb Hans-Peter Diettrich:
Also self is no more known inside class methods in XE. In D7 it was
the class type instead of the instance pointer. Thus a too restrictive
compiler, geared towards compatibilitiy with *new* Delphi versions,
may break
Jonas Maebe schrieb:
Error: Only class methods, class properties and class variables can be
referred with class references
You have to declare an instance and then call its property. You don't
have to instantiate the instance if the property maps to a class method.
Technically there's
Martin Frb schrieb:
http://www.freepascal.org/docs-html/ref/refse67.html#x124-13400012.4
In general, the type size of the expression and the size of the type
cast must be the same. However, for ordinal types (byte, char, word,
boolean, enumerates) this is not so, they can be used
Martin Frb schrieb:
Further, it appears that ^ has a higher precedence than unary -
IMO pointer/address arithmetic (should) follows its own rules.
Unary - and @ should not be applicable to addresses. @ also is
restricted to arguments which *do* have an address, i.e. not applicable
to
Maciej Izak schrieb:
Following by current logic, this example should not compile:
--begin code--
TA = class
procedure Foo;
end;
TB = class(TA)
procedure Foo(A: Integer = 0); overload;
end;
var
b: TB;
begin
b := TB.Create;
b.Foo; // should raise Error: Can't determine which
Thaddy schrieb:
Well, I have a statement from their legal dating from 2005 amounting to:
we use it as you intended (sic) and see no reason to quote that this
sourcecode is yours. Furthermore, the two units that contain said
sourcecode you refer to are protected under U.S. copyright law and are
Thaddy schrieb:
It happened to me once or twice ;) that a certain company with ever
changing names used my sourcecode and licensed it under their own closed
terms because i included the term: use as you like.
Better: free for private use.
If the owner wants that not to happen,, choose any
Mark Morgan Lloyd schrieb:
Hans-Peter Diettrich wrote:
If the owner wants that not to happen,, choose any of these licenses
mentioned.
This is really important. Without huge legal fees I can't get my
intellectual property back
Sorry, that's nonsense. You still have all rights on your
Jonas Maebe schrieb:
http://wiki.freepascal.org/FPC_Unicode_support (only Sections 1 to 3; 4
and later are older and mostly either incomplete or wishful thinking).
Just a note on RawByteString concatenation:
Delphi concatenates RawByteStrings to the dynamic encoding of the
*first* string,
Sven Barth schrieb:
Am 08.01.2014 15:58 schrieb Hans-Peter Diettrich drdiettri...@aol.com
mailto:drdiettri...@aol.com:
Delphi concatenates RawByteStrings to the dynamic encoding of the
*first* string, the appended strings eventually are converted before
concatenation. Special handling
Sven Barth schrieb:
On 08.01.2014 19:57, Hans-Peter Diettrich wrote:
It looks to me, however, that no conversion occurs at all!
The strings are only concatenated as they are.
Same for a concatenation of (global) RawByteString variables.
This of course were not a desireable implementation
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
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
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
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
Paul Ishenin schrieb:
30.12.2013 9:07, Hans-Peter Diettrich пишет:
Do you think that FPC should really reproduce all this inconsistent
behaviour? Who would test or even specify the compatible behaviour,
when every new variation will result in more unexpected results? IMO
it's much easier
Michael Van Canneyt schrieb:
On Sun, 29 Dec 2013, Hans-Peter Diettrich wrote:
Inspired by the current Lazarus discussion I'd like to learn more
about the current state of the implementation of the new AnsiStrings.
In case nothing has be done yet, I'd suggest to extend TAnsiRec by the
new
Michael Van Canneyt schrieb:
On Sun, 29 Dec 2013, Hans-Peter Diettrich wrote:
This will be combined with the dotted unit filenames, to be Delphi
2010+ compatible.
sigh.sigh
How do I create source files for use with both versions?
What do you mean by this statement ?
I'm not familiar
1 - 100 of 951 matches
Mail list logo
