Re: [fpc-devel] TObjectList crash!
On Tue, 9 Sep 2008, Paul Ishenin wrote: Hello, FPC developers' list. We are preparing a next lazarus version and our users are heavily testing thing. One bug report let me found one error which is not a lazarus error, but fpc. This error happen because we used TObjectList to store bitmaps in a list. TObjectList is a useful thing - we dont need to think about object destroying. They will be destroyed on deleting from the list. And everyting works except next call: AList[AIndex] := NewObject I attached a test projects which shows a bug. But in few words this bug happen due to double object destroying: 1. In TObjectList.SetItem (this is *not correct* place to destroy) 2. In TObjectList.Notify (this is *correct* place to destroy) A solution is simple: remove everything from TObjectList.SetItem except Put call. Confirmed, patched as suggested and tested. Revision 11732. Merged to fixes in rev. 11733. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TObjectList crash!
Michael Van Canneyt wrote: Confirmed, patched as suggested and tested. Revision 11732. Merged to fixes in rev. 11733. It was fast as usual :) Thanks. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Florian Klaempfl wrote:
I've continued to work on support of an unicodestring type in fpc.
It's currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk. The unicodestring type is a ref.
counted utf-16 string. On non-windows, widestring is mapped to this
type. If you're interested in unicode support please test, give
feedback here and submit fixes.
An existing working copy of trunk can be switched to this branch by
cd fpc
svn switch http://svn.freepascal.org/svn/fpc/branches/unicodestring
and back with
svn switch http://svn.freepascal.org/svn/fpc/trunk
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
The Pascal huge strings always annoy me.
Since - it is IMPLICIT automatic object with set of overloaded methods,
length and reference count fields etc hidden from developer.
In near future we geat a Zoo of the strings:
AnsiString, WideString, UnicodeString, ShortString, PWideChar, PChar
Some of them with encoding field.
Why not to make it EXPLICIT object
s:=TCoolFPCString.Create('Test');
s2:=TCoolFPCString.Create(''); //UTF8 encoded constant
s.asUtf8+=s2;
SetWindowTextW(WinHandle,s.AsUnicodeString); // i explicitly say - get
me wide string and DO not any compiler magic
if (s1.length=length(s2))... // generic runtime function length returns
the property of cool object
s1.AcquireLock // prevent other threads acccess
s1.Clear;
s1.LoadFromResource(n_ReasourceId); // just use GNU gettext
s1.LoadTranslationFromResource(n_resID,'be_BY');
s1.ReleaseLock // allow other thread access
Anyway I just can subclass standard string and get a new functionality
with reachness of availabel fields and methods.
FPC supports operators - so there is lots of way to represent the
string, assign the string, load it from resource.
Make it thread-safe at implementation level but not at compiler level.
Standard string, unicode string , ansistring, widestring can be
implemented as wrappers along this object.
It seems like in mseGUI it is done.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On 9/9/08, Anton Kavalenka [EMAIL PROTECTED] wrote: The Pascal huge strings always annoy me. Since - it is IMPLICIT automatic object with set of overloaded methods, length and reference count fields etc hidden from developer. In near future we geat a Zoo of the strings: AnsiString, WideString, UnicodeString, ShortString, PWideChar, PChar Some of them with encoding field. I have to say I agree with you The Object Pascal / Delphi language already has way to many string types! At it's just getting worse. I've always liked the Java style of everything being an object - even the string type. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
In our previous episode, Graeme Geldenhuys said: The Pascal huge strings always annoy me. Since - it is IMPLICIT automatic object with set of overloaded methods, length and reference count fields etc hidden from developer. In near future we geat a Zoo of the strings: AnsiString, WideString, UnicodeString, ShortString, PWideChar, PChar Some of them with encoding field. I have to say I agree with you The Object Pascal / Delphi language already has way to many string types! At it's just getting worse. Well, then only use one? What is the problem? As soon as the RTL is unicodestring enabled, throw away anything that is not unicode, create everything new in unicode, and be done with it. Legacy always causes ballast. I've always liked the Java style of everything being an object - even the string type. It creates a lot of troubles (very visible in Java with its need for stringbuilder), but it is not exactly clear what it solves. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On Tue, 9 Sep 2008, Anton Kavalenka wrote:
Florian Klaempfl wrote:
I've continued to work on support of an unicodestring type in fpc. It's
currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk. The unicodestring type is a ref. counted
utf-16 string. On non-windows, widestring is mapped to this type. If you're
interested in unicode support please test, give feedback here and submit
fixes.
An existing working copy of trunk can be switched to this branch by
cd fpc
svn switch http://svn.freepascal.org/svn/fpc/branches/unicodestring
and back with
svn switch http://svn.freepascal.org/svn/fpc/trunk
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
The Pascal huge strings always annoy me.
Since - it is IMPLICIT automatic object with set of overloaded methods, length
and reference count fields etc hidden from developer.
In near future we geat a Zoo of the strings:
AnsiString, WideString, UnicodeString, ShortString, PWideChar, PChar
Some of them with encoding field.
Why not to make it EXPLICIT object
s:=TCoolFPCString.Create('Test');
Nothing stops you from doing this yourself.
But for something as basic as text operations, I think this is bloat.
Imagine that you would have to do
I:=TInteger.Create(1);
J:=TInteger.Create(2);
I.Add(J);
What kind of language do you end up with then ? Utterly unreadable, and
slow, because heavily relying on the heap.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Nothing stops you from doing this yourself. But for something as basic as text operations, I think this is bloat. Imagine that you would have to do I:=TInteger.Create(1); J:=TInteger.Create(2); I.Add(J); What kind of language do you end up with then ? Utterly unreadable, and slow, because heavily relying on the heap. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Bad example Numbers are scalars Strings are vectors += operator in not so straightforward as for numbers. Who else except Pascal developers knows that s:=s1+s2 is the string concatenation and invokes lot of hidden stuff that is out of control. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On Tue, 9 Sep 2008, Anton Kavalenka wrote: Nothing stops you from doing this yourself. But for something as basic as text operations, I think this is bloat. Imagine that you would have to do I:=TInteger.Create(1); J:=TInteger.Create(2); I.Add(J); What kind of language do you end up with then ? Utterly unreadable, and slow, because heavily relying on the heap. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Bad example Numbers are scalars Strings are vectors += operator in not so straightforward as for numbers. bad example for you, but not for me: Handling strings should be as easy as handling integers. Who else except Pascal developers knows that s:=s1+s2 is the string concatenation and invokes lot of hidden stuff that is out of control. This is the beauty of pascal: you don't need to know, and there should be no need. I once asked a C++ programmer how to read a file full of strings. After 2 hourse he came to tell me he didn't know. In Pascal, it takes about 1 minute to code, because strings are a basic type, handled on the stack. And rightly so. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On Tue, Sep 9, 2008 at 2:23 PM, Graeme Geldenhuys [EMAIL PROTECTED] wrote: On 9/9/08, Anton Kavalenka [EMAIL PROTECTED] wrote: The Pascal huge strings always annoy me. Since - it is IMPLICIT automatic object with set of overloaded methods, length and reference count fields etc hidden from developer. In near future we geat a Zoo of the strings: AnsiString, WideString, UnicodeString, ShortString, PWideChar, PChar Some of them with encoding field. I have to say I agree with you The Object Pascal / Delphi language already has way to many string types! At it's just getting worse. Actually I find this to be a good feature. On C for example you will find a lot of typedef that results out of int or long int, and you can understand that time_f is about working with time, while pid_t talks about pids etc... They all are integer types but it is easier to understand their uses. Sure it means that you must have better documentation out there, but I think it is worth it. I've always liked the Java style of everything being an object - even the string type. It is always the thing I dislike in Java. For example on languages such as Ruby/Python everything is a true object (including nil in ruby), however you do not need it when you do not use sub methods, and there for your language like Java and C++ become a bloat ware. Because it have way too much information to compile into binary. On Pascal (using smart linking) you can add only things you use (but on OO it does not work like that). Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Ido -- http://ik.homelinux.org/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Michael Van Canneyt wrote: On Tue, 9 Sep 2008, Anton Kavalenka wrote: Nothing stops you from doing this yourself. But for something as basic as text operations, I think this is bloat. Imagine that you would have to do I:=TInteger.Create(1); J:=TInteger.Create(2); I.Add(J); What kind of language do you end up with then ? Utterly unreadable, and slow, because heavily relying on the heap. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Bad example Numbers are scalars Strings are vectors += operator in not so straightforward as for numbers. bad example for you, but not for me: Handling strings should be as easy as handling integers. Who else except Pascal developers knows that s:=s1+s2 is the string concatenation and invokes lot of hidden stuff that is out of control. This is the beauty of pascal: you don't need to know, and there should be no need. I once asked a C++ programmer how to read a file full of strings. After 2 hourse he came to tell me he didn't know. In Pascal, it takes about 1 minute to code, because strings are a basic type, handled on the stack. And rightly so. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel :-) This not a holy war C++ vs Pascal If C++ programmer don't know about fstream descendants - send him back to school (or actually (he|she) is VB programmer). I only have a dream - controllable way of string assignment without any magic like implicit call of _LStrAddRefCnt ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TSdfDataset does not work with records larger then 255 chars
El Mon, 8 Sep 2008 20:14:44 +0200 Martin Schreiber [EMAIL PROTECTED] escribió: Is Sqlite3 no option for you? MSEgui and FPC sqldb both have a DB-connection component for SQLite3. FWIW I had the problem of string fields limited to 255 characters with sqlite3 and zeos. I hadn't time to test other combinations. Since I only needed the db aware components to display (not even edit) fields of less than 255 chars, I simply used direct queries to manipulate fields longer than 255 chars. Like Felipe I couldn't trace the source of that limitation. Bye -- Luca ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 2.2.2 on Linux/SPARC
Jonas Maebe wrote: On 05 Sep 2008, at 11:29, Mark Morgan Lloyd wrote: Jonas Maebe wrote: I've committed a fix in 2.3.1. If all goes well in the testsuite run tonight, I'll merge it to 2.2.3 over the weekend. I don't know why this bug didn't cause crashes in the nightly tests I run on sparc/solaris (I have gotten other alignment crashes on this machine in the past). Thanks Jonas, I'd missed the earlier comment which must have got lost by the spam filter. I'll keep an eye for 2.2.3 It's been merged to 2.2.3 now. You can either download the source zipfile from ftp://ftp.freepascal.org/pub/fpc/snapshot/v22/source/fpc.zip, or get it from svn as described here: http://www.freepascal.org/develop.var#svn (make sure you use the checkout url mentioned in the Fixes to 2.2.x section). fpc and fp appear to work on linux/sparc. However trying to single-step or run to a breakpoint in fp fails with another bus error or misaligned data access- do I stand any realistic chance of generating a useful backtrace for this? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Anton Kavalenka wrote: I only have a dream - controllable way of string assignment without any magic like implicit call of _LStrAddRefCnt Do you have a real-world sample of usage, ie, where or when the object pascal way is a problem? Joao Morais ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Anton Kavalenka schrieb:
Florian Klaempfl wrote:
I've continued to work on support of an unicodestring type in fpc.
It's currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk. The unicodestring type is a ref.
counted utf-16 string. On non-windows, widestring is mapped to this
type. If you're interested in unicode support please test, give
feedback here and submit fixes.
An existing working copy of trunk can be switched to this branch by
cd fpc
svn switch http://svn.freepascal.org/svn/fpc/branches/unicodestring
and back with
svn switch http://svn.freepascal.org/svn/fpc/trunk
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
The Pascal huge strings always annoy me.
Since - it is IMPLICIT automatic object with set of overloaded
methods, length and reference count fields etc hidden from developer.
In near future we geat a Zoo of the strings:
AnsiString, WideString, UnicodeString, ShortString, PWideChar, PChar
Some of them with encoding field.
Why not to make it EXPLICIT object
s:=TCoolFPCString.Create('Test');
s2:=TCoolFPCString.Create('Проверка'); //UTF8 encoded constant
s.asUtf8+=s2;
SetWindowTextW(WinHandle,s.AsUnicodeString); // i explicitly say - get
me wide string and DO not any compiler magic
if (s1.length=length(s2))... // generic runtime function length
returns the property of cool object
s1.AcquireLock // prevent other threads acccess
s1.Clear;
s1.LoadFromResource(n_ReasourceId); // just use GNU gettext
s1.LoadTranslationFromResource(n_resID,'be_BY');
s1.ReleaseLock // allow other thread access
Anyway I just can subclass standard string and get a new functionality
with reachness of availabel fields and methods.
FPC supports operators - so there is lots of way to represent the
string, assign the string, load it from resource.
Make it thread-safe at implementation level but not at compiler level.
Standard string, unicode string , ansistring, widestring can be
implemented as wrappers along this object.
It seems like in mseGUI it is done.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I fully agree with you. I would like the object oriented way of strings
also - but I stopped asking for that ;) There are a lot of advantages
over the small amount of disadvantages. Of course I dont like this one:
S := TString.Create('');
But a built in class TString that is managed by the compiler.
PS : Maybe i'm a littlebit more up to date about todays concepts of
object oriented languages - maybe because I know him personally
http://en.wikipedia.org/wiki/Bertrand_Meyer
There were a lot of interesting discussions, etc... altough I dont like
Eiffel :)
and also this guy was one of my profs:
http://en.wikipedia.org/wiki/Niklaus_Wirth
greetings
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Ivo Steinmann schrieb: I fully agree with you. I would like the object oriented way of strings also - but I stopped asking for that ;) There are a lot of advantages Which ones? Really, I want to know :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
I fully agree with you. I would like the object oriented way of strings also - but I stopped asking for that ;) There are a lot of advantages over the small amount of disadvantages. Which object orientated way of doing strings? As I see it there are three main ways of doing variable length strings. 1: Let the programmer manage the memory lifetime (the C way), this is tedious, error prone and generally results in lots of unnessacery copying of strings since it is easier for the programmer to have seperate copies owned by different objects than to manage shared strings. 2: Use immutable objects and let the garbage collector clean them up (the java way), this works but since the strings are immutable they must be copied to make any modification. It also relies on a garbage collector will all it's associated problems. 3: Use an automatic reference counting system either implemented in the compiler (the delphi/fpc way) or implemented using a very powerfull operator overloading system (the C++ way, last I checked freepascal did not have sufficiant operator overloading capabilities to implement this) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
peter green schreef: I fully agree with you. I would like the object oriented way of strings also - but I stopped asking for that ;) There are a lot of advantages over the small amount of disadvantages. Which object orientated way of doing strings? As I see it there are three main ways of doing variable length strings. 1: Let the programmer manage the memory lifetime (the C way), this is tedious, error prone and generally results in lots of unnessacery copying of strings since it is easier for the programmer to have seperate copies owned by different objects than to manage shared strings. 2: Use immutable objects and let the garbage collector clean them up (the java way), this works but since the strings are immutable they must be copied to make any modification. It also relies on a garbage collector will all it's associated problems. 3: Use an automatic reference counting system either implemented in the compiler (the delphi/fpc way) or implemented using a very powerfull operator overloading system (the C++ way, last I checked freepascal did not have sufficiant operator overloading capabilities to implement this) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.19/1660 - Release Date: 9/8/2008 6:39 PM Check again... But it is still a bad idea (like c++) How does one recognize a deep vs shallow string copy f.e. This is realy basic. And rather uninformed as well.. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
peter green schrieb: 3: Use an automatic reference counting system either implemented in the compiler (the delphi/fpc way) or implemented using a very powerfull operator overloading system (the C++ way, last I checked freepascal did not have sufficiant operator overloading capabilities to implement this) Even C++'s is not good enough to do a ref. counted string in an efficient way. Just consider the [...] operator which needs to distinguish between reads and writes to avoid unncessary unique calls. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Martin Schreiber schrieb: On Sunday 07 September 2008 21.23:24 Florian Klaempfl wrote: Trunk 11723 does not compile: Trunk or unicodestring branch? Strange, because here it works? Unicodestring branch, sorry, I should change the directory name of my switched checkout. Does your unicodestring branch compile? Fixed in rev. 11734 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
On 09 Sep 2008, at 21:37, Florian Klaempfl wrote: Even C++'s is not good enough to do a ref. counted string in an efficient way. Just consider the [...] operator which needs to distinguish between reads and writes to avoid unncessary unique calls. Can't you have a const and non-const version of the [] operator in C++? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Check again... I have just checked the manual and I don't see anything I can use to make sure my custom type starts at a predictable state initially (nessacery so they assignment operator can safely clean up before making the assignment). Nor do I see anything to do automatic clean up when the variable goes out of scope. But it is still a bad idea (like c++) How does one recognize a deep vs shallow string copy f.e. You don't have to! With the java system the string type is immutable anyway so there is no point in doing a deep copy. With the delphi/fpc system the string type automatically makes a shallow copy initially and then copies the actual data if and when it becomes nessacery to do so. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Jonas Maebe schrieb: On 09 Sep 2008, at 21:37, Florian Klaempfl wrote: Even C++'s is not good enough to do a ref. counted string in an efficient way. Just consider the [...] operator which needs to distinguish between reads and writes to avoid unncessary unique calls. Can't you have a const and non-const version of the [] operator in C++? I tried something similiar once with an older gcc but I didn't get it working. Maybe it's possible with newer ones. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
peter green schreef: I have just checked the manual and I don't see anything I can use to make sure my custom type starts at a predictable state initially (nessacery so they assignment operator can safely clean up before making the assignment). Nor do I see anything to do automatic clean up when the variable goes out of scope. That's the point You don't have to! With the java system the string type is immutable anyway so there is no point in doing a deep copy. Which is imo - in the case of Java, but especially in the case of c++ - proven to be no at very smart idea. You want both and you want them recognizable by the compiler ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Graeme Geldenhuys wrote: I have to say I agree with you The Object Pascal / Delphi language already has way to many string types! At it's just getting worse. I've always liked the Java style of everything being an object - even the string type. The more I look at this Unicode issue, the more I believe we need a fundamental object aproach to it. I mean, before a TString class, we need a TCharacter class in which we need to specify --amongst other things-- what language that character belongs to. This kind of information is needed in order to properly manage the (upper-, lower-, title-, and camel-?) casing issues. On top of this, we also need this information in order to be able to mix and match and display the LTR (left-to-right) and RTL (right-to-left) pieces of strings within the same string. I have done some work on this, but there are at least 2 issues: 1) since each character is a class, memory requirements are increased several fold. 2) Again, the charater-as-class also means that the speed with wich we can create and destroy (and manipulate) a string is a lot slower. I am, at this point, wondering if FPC's object creation/destroy code could be more optimized to be faster to help with this issue. 3) How do you handle the character sets when characters are objects? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
