JoshyFun schrieb:
> Hello Jonas,
>
> Sunday, November 23, 2008, 6:14:11 PM, you wrote:
>
>>> //LowerCase arrays size: 2376 bytes
>>> const UnicodeLowerCaseArraySource: array [0..593] of WORD=(
>>> //UpperCase arrays size: 2408 bytes
>>> const UnicodeUpperCaseArraySource: array [0..601] of WORD=(
JoshyFun schrieb:
> Hello Graeme,
>
> Sunday, November 23, 2008, 9:21:09 AM, you wrote:
>
> GG> So UTF8Decode only supports UCS2 output! Now this is why I think
> GG> supporting UTF-8 in fpGUI and Lazarus LCL was a good idea. By design
> GG> (utf-8), you have to support the whole unicode range.
Graeme Geldenhuys schrieb:
> On Sat, Nov 22, 2008 at 9:07 PM, Florian Klaempfl
> <[EMAIL PROTECTED]> wrote:
>> See http://bugs.freepascal.org/view.php?id=11791
>
> OK, but that bug report is about an invalid sequence and getting out
> NULL. I'm testing perfectl
Graeme Geldenhuys schrieb:
> On Sat, Nov 22, 2008 at 10:51 AM, Florian Klaempfl
> <[EMAIL PROTECTED]> wrote:
>> function UTF8Decode(const s : UTF8String): UnicodeString;
>
> Is there some hard-coded limit on UTF8Decode? I am writing some unit
> tests for these met
Graeme Geldenhuys schrieb:
> Hi,
>
> Has anybody written these conversions functions yet? If not, I am
> about to port the ConvertUTF.c file from Unicode.org to Object Pascal.
>
> UTF-32 to UTF-16
> UTF-32 to UTF-8
> UTF-16 to UTF-32
> UTF-16 to UTF-8
> UTF-8 to UTF
Folks, before your waste your time again with endless discussions, have
a look at Yury's work on an unicode rtl, test it and help with patches
and suggestions, it's available in svn at
http://svn.freepascal.org/svn/fpc/branches/unicodertl
___
fpc-devel ma
Felipe Monteiro de Carvalho schrieb:
> On Fri, Nov 21, 2008 at 7:30 AM, Florian Klaempfl
> <[EMAIL PROTECTED]> wrote:
>> This is easily said, please create examples and descriptions how fully
>> working is defined.
>
> It would be really good if there was a guide
Felipe Monteiro de Carvalho schrieb:
> On Fri, Nov 21, 2008 at 7:30 AM, Florian Klaempfl
> <[EMAIL PROTECTED]> wrote:
>> This is easily said, please create examples and descriptions how fully
>> working is defined.
>
> // Should actually convert from widestring to u
Felipe Monteiro de Carvalho schrieb:
> On Thu, Nov 20, 2008 at 9:05 AM, Daniël Mantione
> <[EMAIL PROTECTED]> wrote:
>> On the other hand Lazarus may want to move to a "string depending on
>> platform" too, to attract both Delphi < 2009 and Delphi >= 2009 users.
>
> I don't see this change any tim
Graeme Geldenhuys schrieb:
> Hi
>
> How am I supposed to handle unicode characters for locale variables?
> All locale variables like ThousandSeparator is type Char and there is
> no overloaded UnicodeChar versions. This causes problems in Russian
> locales as the example below shows.
>
>
> c
Graeme Geldenhuys schrieb:
> On Thu, Nov 20, 2008 at 4:10 PM, Aleksa Todorovic <[EMAIL PROTECTED]> wrote:
>> Or... it could be implemented using generics, so one can choose:
>>
>> TStringList
>> TStringList
>> TStringList
>>
>> (sorry for C++ish syntax, but I hope you understand)
>
>
> I somehow
Graeme Geldenhuys schrieb:
> Hi,
>
> Is there any list of missing features for UnicodeString in the RTL?
>
> For example:
>
> * I can't seem to find a UnicodeString version of TStrings or TStringList
>
>
> Any more such cases?
No idea, nobody complainted so far ;) Just create one.
> I wo
Graeme Geldenhuys schrieb:
On Thu, Nov 20, 2008 at 11:12 AM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
Ok, two questions for the example above:
- how do you maintain backward compatibility?
- how do you load a plain old ansi file?
If the file is UTF-8 or ANSI, the above should work.
Graeme Geldenhuys schrieb:
Hello again,
We are seeing more and more "hacks" being applied to projects trying
to scramble around the missing FPC feature - no built-in Unicode
supporting.
A simple example in Lazarus Loading a UTF-8 encoded file into a TMemo.
Normally you would write code as
Alexander Klenin schrieb:
On Mon, Nov 17, 2008 at 05:39, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
No, just look at the actual assignment:
i:=v;
By const/reference it generates 5 instructions, by value only 4. The rest is
entry code. If you've only one access, passing by reference
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
My point was that this could be a missing optimization
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
My point was that this could be a missing optimization opportunity:
pass by reference a 8 bytes parameter when the pointer size
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
My point was that this could be a missing optimization opportunity:
pass by reference a 8 bytes parameter when the pointer size is 4.
Don't forget that this makes an extra memory access
Luiz Americo Pereira Camara schrieb:
Jonas Maebe escreveu:
On 16 Nov 2008, at 14:52, Florian Klaempfl wrote:
Luiz Americo Pereira Camara schrieb:
Maybe the documentation
(http://www.freepascal.org/docs-html/ref/refsu50.html#x126-13300011.4.4)
can be modified to clarify this since the
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
While discussing if is worth using const parameters for string and
double types in a Lazarus bug report (
http://bugs.freepascal.org/view.php?id=12642 ), it was noticed that
does not make
Luiz Americo Pereira Camara schrieb:
While discussing if is worth using const parameters for string and
double types in a Lazarus bug report (
http://bugs.freepascal.org/view.php?id=12642 ), it was noticed that does
not make difference using constant parameters or not for double types.
So is
Graeme Geldenhuys schrieb:
> On Tue, Nov 11, 2008 at 6:21 PM, Florian Klaempfl
> <[EMAIL PROTECTED]> wrote:
>>> Some conversions are correct or seem to be correct in that case.
>> It has been already pointed out several times that lazarus abuses the
>> anstring ty
Michael Schnell schrieb:
>
>> I set no special options in FPC
> Lazarus does.
>> and I don't use WideString at all.
>> UTF-8 fits perfectly in the standard String type.
>>
> Some conversions are correct or seem to be correct in that case.
It has been already pointed out several times that laz
Michael Schnell schrieb:
>
>> Lazarus has a set of utf-8 ready routines, using utf-8 inside of a
>> ansistring.
>>
> I see. But it's really ugly that you need to use those instead of just
> writing clean old school code and have the compiler care for the nasty
> details.
Having unicode support
Michael Schnell schrieb:
>
>> OK, so here goes again yet another discussion... :-)
>>
> No wonder, as the current state is working, but rather disappointing :).
> (No idea if D2009 is different / better: this seems to be the cause of
> the new thread.)
We can implement a D2009 like solution an
Sergei Gorelkin schrieb:
Hello,
The attached patch fixes two opcodes generated by i386 internal assembler.
The first one fixes the "mov ax, word ptr [somevar]" command which was
generated without $66 prefix (reported by freepascal.ru forum user,
don't know if it is in bugtracker).
The second o
Dmitry Lizorkin schrieb:
>> I agree, no real life need.
>
> Except probably for my 150 students to whom i can no longer recommend
> FPC as a reference implementation.
Hopefully they won't be schocked when being hit by another real world
programming language implementing mod like it is implemented
Thaddy schrieb:
I consider parallel as syntactic sugar:
- the same effect can be achived by some thread classes
- it gives the compiler no opportunity to generate better code
- the use cases are limited, it is nothing being used hundred of times
in a typical program
- it solves none of the real MT
Felipe Monteiro de Carvalho schrieb:
> On Tue, Nov 4, 2008 at 8:10 AM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>> Well, I gave up PIC24 since they don't contain motorcontrol,
>
> I've always wanted to know what does a microcontroller with
> motorcontrol is supposed to do different from a nor
Michael Schnell schrieb:
>
> This would just provide another language for GCC and for hopefully allow
> me to use FPC-Pascal for any processor architecture supported by GCC.
Already finding skilled contributors to FPC is hard. If deep C knowledge
would be also a requirement it would be even harde
Michael Schnell schrieb:
>
>> Moving things in the language without a notable advantage which can be
>> solved by a library is not a good thing.
>>
> Don't you think "ease of use" _is_ a notable advantage of a programming
> language ?
It is. But as pointed out, parallel does not solve any of t
Michael Schnell schrieb:
>
>> You still didn't show any example which shows the real power of parallel
>> which cannot be solved by a T(Pooled)Thread.Create and
>> T(Pooled)Thread.WaitFor statements.
>>
> As I said several times, I don't suggest that any other implementation
> (be it OpenMP or
Michael Schnell schrieb:
>
>> If you want to have good multicore scaling you are lost with OpenMP.
> As I said, that is my POV, too.
>
> I did not start this discussion for preaching for OpenMP. In fact I know
> close to nothing about it. My starting point were the rather poor
> results for FPC i
Michael Schnell schrieb:
>
>> Each tool simply has its place and usage ;-) , so does OpenMP . That
>> does not mean that it is the magic wand for solving MT, it is just
>> another tool that we can use.
> That is my POV, as well.
>
> OpenMP seems to be a relatively quite easy "add-on" for compiler
Boian Mitov schrieb:
> Very nice wrap on this one Michael.
> While architectures such as OpenMP or CUDA do not solve and don't even
> try to solve the general case of MT development, they are very powerful
> in the areas of image processing and DSP. Indeed we are already
> researching CUDA for usag
Mattias Gaertner schrieb:
On Mon, 03 Nov 2008 16:29:01 +0100
Michael Schnell <[EMAIL PROTECTED]> wrote:
Great and you really believe this accelerates a program? Starting a
thread takes a lot of time and such loops are usually memory
throughput bound.
OK, I should not have used 10 as the elem
Peter Popov schrieb:
I hope this will helps the discussion.
Thanks for this well written explanation. If you've precise ideas how OP
could be extended to solve the mentioned problems, I'd to be happy to
know them and we can also discuss if it can be implemented.
___
Michael Schnell schrieb:
>
> And writing "parallel" together with "for" is just adding a single
> keyword. Providing easy support for common tasks (such as exploiting the
> benefit of an SMP system) is exactly what everybody expects from a
> decent programming language.
... and as said before, he
Michael Schnell schrieb:
>
>> For a big vector operation the number of used threads should be
>> adapted to the memory architecture,
> With the C #pragma opm_ this can be done statically by the
> programmer using the "schedule" keyword, defining "chunks" (there seem
> to be more sophisticate
Michael Schnell schrieb:
> IMHO any technology that enables FPC to compile a loop like (using
> Oxygen syntax):
>
> for parallel i := 0 to 10 do begin
> a[i] := a[i] + b[i];
> end;
>
> in a way that it on a multicore processor runs as fast as the
> appropriate GNU C construct:
>
> #pragma ocm_p
Daniël Mantione schrieb:
>
>
> Op Mon, 3 Nov 2008, schreef Florian Klaempfl:
>
>> Michael Schnell schrieb:
>>> IMHO any technology that enables FPC to compile a loop like (using
>>> Oxygen syntax):
>>>
>>> for parallel i := 0 to 10 do beg
Michael Schnell schrieb:
>
>> I don't see how Mandelbrot requires OpenMP. One can easily launch n
>> threads depending on the number of the available cores.
>>
> (We are discussing this in the German Lazarus Forum right now...)
>
> I feel that OpenMP is never _required_ to optimize a problem,
Michael Schnell schrieb:
>
>> Maybe it would be good to first start the OpenMP library part - a unit
>> providing some functions to easily use light weight threads.
>
> I just read that as of v4.2, GNU C supports OpenMP by language
> constructs (seemingly preprocessor directives). When looking at
Dmitry Lizorkin schrieb:
>> That FPC never claims to be iso compliant. -1 mod 3 evalutes to -1 for
>> most modern programming languages.
>
> Thank you for the clarification. A pity that FPC has no iso conformance
> mode.
Well, it doesn't seem a big pity else somebody would have made one ;)
__
Dmitry Lizorkin schrieb:
> Hello!
>
> I was surprised to find out that the expression (-1 mod 3) yields -1 in
> Free Pascal. On the other hand, Pascal ISO 7185:1990, section 6.7.2.2)
> explicitly defines the `mod' operation "such that 0 <= i mod j < j".
> What do i miss here?
That FPC never claim
Michael Schnell schrieb:
>
>> Bidi stuff? You are aware of the fact that unicode strings can contain
>> e.g. bidi markers?
> Sorry, never heard of bidi :(
>
http://www.unicode.org/reports/tr9/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
h
Michael Schnell schrieb:
>
>> More importantly, most of such routines will be implicitely tied to a
>> certain language or language group already.
>>
> Which kind of UCS2 based function do you think are tied to a
> language(group) ?
Bidi stuff? You are aware of the fact that unicode strings ca
Michael Schnell schrieb:
>
>> The conversion
>> utf-8<->utf-16 is a very expensive operation and the compiler has to
>> insert it all over the place and people would cry about the performance
>> of their programs.
> Of course I do agree.
>
> If you want to care about performance you need to know
Michael Schnell schrieb:
>
> A decent system should be able to do the necessary conversions
> automatically:
This is a simplified view which ignores the resource wasting of this
apporoach not visible in the academical example below. The conversion
utf-8<->utf-16 is a very expensive operation and
Daniël Mantione schrieb:
> The issue might be the UCS-2 encoding of your source, perhaps try to
> feed the compiler UTF-8, I didn't even know the compiler accepts UCS-2,
> it may not work correctly.
>
The compiler definitively eats no ucs-2 encoded sources.
Bernd Mueller schrieb:
> Hello,
>
> I am trying hard to avoid C on an ARM7TDMI/ARMv4T Controller
> (AT91SAM7Sx) ;-)
What about simply supporting the interrupt keyword on arm? Point me to
some description and I'll implement it.
___
fpc-devel maillist -
Graeme Geldenhuys schrieb:
> Hi,
>
> Could anybody using 64bit FPC under Windows comment on this? I'm only
> now able to setup 64bit FPC under Linux, but haven't had the
> opportunity to run 64bit Windows and FPC for that matter. I thought
> 64bit support in FPC was done and dusted? [for Linux a
Karl-Michael Schindler schrieb:
> Hi
>
> I have some suggestions regarding the use of viewvc for publishing the
> svn repository to the web.
>
> 1) update to viewvc 1.06. CHANGELOG:
> http://viewvc.tigris.org/source/browse/viewvc/trunk/CHANGES?rev=HEAD
Since ViewVC 1.0.6 is not yet in the ubuntu
Felipe Monteiro de Carvalho schrieb:
> Hello,
>
> Could someone please upload 1 snapshot of the latest FPC 2.2.3 to
> ftp://ftp.freepascal.org/pub/fpc/snapshot/fixes/i386-macosx/ ? I would
> be imensely grateful.
Try to repeat the static keyword in the body, this could work with 2.2.0
too.
>
>
Florian Klaempfl schrieb:
What I could not find was, how to create that ppcross386. I remember
it worked with a previous 2.2.0 install, but since I switched to 2.3.1
I couldn't get it to work.
I'am working on a patch to fix this. For now do
make all CPU_TARGET=i386 FPC=fpc
Shoul
Lukas Gradl schrieb:
Marco van de Voort schrieb:
In our previous episode, Lukas Gradl said:
At the moment, I'm developing on a i386 Linux machine. For some
servers I need x86_64 binaries, so I have a second machine with
x86_64 linux I use just for compiling.
It would be great to compile ever
Mehmet Erol Sanliturk schrieb:
Dear Sirs ,
Please add such fixes to the bug tracker (http://bugs.freepascal.org/)
so it won't get lost.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-deve
Graeme Geldenhuys schrieb:
> On Fri, Sep 26, 2008 at 9:27 AM, Florian Klaempfl
> <[EMAIL PROTECTED]> wrote:
>> Being honest, imo UTF-8 is only a hack to get unicode on platforms like
>> unix.
>
> I don't know where you get that information,
Rather simple: init
Graeme Geldenhuys schrieb:
> On Fri, Sep 26, 2008 at 9:04 AM, Graeme Geldenhuys
> <[EMAIL PROTECTED]> wrote:
>> So has anybody actually done a timing comparision? Do you have your
>> test code available? Do you have your results published? I'm
>> interested to see the timing results using different
Graeme Geldenhuys schrieb:
> On Thu, Sep 25, 2008 at 10:33 PM, Florian Klaempfl
> <[EMAIL PROTECTED]> wrote:
>> Who says that? UTF-16 is simply chosen because it has features (supporting
>> all characters basically) ANSI doesn't?
>
> Sorry, my message was
Graeme Geldenhuys schrieb:
Hi,
Yes I know we have had lengthy discussions about this before.
Everybody (whoever they might be) keeps saying that UTF-16 was chosen
for Tiburon's UnicodeString because it makes "significant speed gains"
when calling the Windows API based on UTF-16 - compared to the
Inoussa OUEDRAOGO schrieb:
Hi
This program prints "tkUString". Is this by design or should it had
print tkWString ?
No, this is currently by design. In 2.3 widestring is a synonym for
unicodestring on non windows systems. Only on windows, widestring is a
special string being compatible with
Yury Sidorov schrieb:
We discussed this once and concluded, that something like this hurts
more than it helps because an overloaded assignment operator allows
the compiler always to mess really around :)
Maybe.
But you stated that it is possible to create fully functional utf8string
type f
Yury Sidorov schrieb:
From: "Florian Klaempfl" <[EMAIL PROTECTED]>
Yury Sidorov schrieb:
From: "Florian Klaempfl" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Thursday, September 18, 2008 4:14 PM
Subject: Re: [fpc-devel] Bug in FPC and d
Graeme Geldenhuys schrieb:
On Thu, Sep 18, 2008 at 3:40 PM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
What rule do you apply to say this?
Compiler treats '1234' as ansistring constant. Therefore ansistring
overload must be choosen here.
No, '1234' is taken as gene
Yury Sidorov schrieb:
From: "Florian Klaempfl" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Thursday, September 18, 2008 4:14 PM
Subject: Re: [fpc-devel] Bug in FPC and declaring distinct types
Yury Sidorov schrieb:
Yes. But it works only partially. Fo
Yury Sidorov schrieb:
Yes. But it works only partially. For example the following code is
not compilable:
Well, I wouldn't know either what you expect :)
I expect that compiler will choose DoTest with ansistring parameter in
that case.
What rule do you apply to say this?
//--
type
Graeme Geldenhuys schrieb:
eg: #2
type
MyType = type Double;
MyOtherType = type Double;
Otherwise, what's the different between a "alias" type (eg #1) and a
"distinct" type (eg #2)??
As I said: overloading. It means: compatible but not equal. If you want
distinct: use as said, classes
Yury Sidorov schrieb:
From: "Florian Klaempfl" <[EMAIL PROTECTED]>
Michael Van Canneyt schrieb:
On Thu, 18 Sep 2008, Graeme Geldenhuys wrote:
Hi,
I was following a discussion in the delphi.non-technical newsgroup.
They raised an issue about distinct types. I tried the f
Graeme Geldenhuys schrieb:
On Thu, Sep 18, 2008 at 10:11 AM, Michael Van Canneyt
<[EMAIL PROTECTED]> wrote:
And it is also very annoying because
Type
MyString = type string;
Const
AString = 'something';
Var
M : MyString;
begin
M:=AString;
end.
Will no longer compile if you are too stric
Michael Van Canneyt schrieb:
On Thu, 18 Sep 2008, Graeme Geldenhuys wrote:
Hi,
I was following a discussion in the delphi.non-technical newsgroup.
They raised an issue about distinct types. I tried the following
example under FPC and unexpectedly, FPC doesn't raise any errors!
If you declare
Martin Schreiber schrieb:
On Sunday 14 September 2008 19.22:13 Florian Klaempfl wrote:
Martin Schreiber schrieb:
I tried with trunk, same result. The problem is probably that the second
constant string parameter has a wrong reference count. It is initially 0
instead of -1. The incref call at
Martin Schreiber schrieb:
On Thursday 11 September 2008 23.18:07 Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I have a crash in MSEide startup in a procedure finalization section:
[...]
I saw that you merged unicodestring to
Daniël Mantione schrieb:
Op Sun, 14 Sep 2008, schreef Florian Klaempfl:
Daniël Mantione schrieb:
Op Sun, 14 Sep 2008, schreef Jonas Maebe:
On 14 Sep 2008, at 14:49, Markus Beth wrote:
this patch rewrites code of ArrayRTTI and fpc_Copy to allow the
compiler to generate faster code (at
Daniël Mantione schrieb:
Op Sun, 14 Sep 2008, schreef Jonas Maebe:
On 14 Sep 2008, at 14:49, Markus Beth wrote:
this patch rewrites code of ArrayRTTI and fpc_Copy to allow the
compiler to generate faster code (at least on i386).
The change in ArrayRTTI yields a performance gain of ~4% for
Daniël Mantione schrieb:
>
>
> Op Fri, 12 Sep 2008, schreef listmember:
>
>> This search needs to be NOT case-sensitive.
>>
>> How can you do this?
>>
>> Is it doable if TCharacter (or wahtever you call it) has no 'langauge'
>> attribite?
>
> 'I am on FoolStrasse' versus 'I am on FoolStraße' is
Martin Schreiber schrieb:
On Saturday 30 August 2008 13.37:42 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
Marco van de Voort schrieb:
In our previous episode, listmember said:
> else
> DrawCaption(0,0,AsUTF8(Caption), flags);
> end;
>
> In other words where is the benefit from OOP in this ?
IMO, both are deficient as they both assume that a string block (text)
is either RTL or LTR.
Markus Beth schrieb:
> Hi,
>
> latest profiling of one of our FPC applications showed ReadInteger (in
> rtl/objpas/sysutils/sysformt.inc) to be a performance bottleneck. Using
> Pos(Fmt[chpos],'1234567890')<>0 to check if Fmt[chpos] is a digit is
> somewhat time consuming. I replaced it with two c
listmember schrieb:
compiler guys all the same} and ask, instead, to give us
reference-counted 4-byte (actually, preferably 6-bytes) per cell
arrays/strings.
What's wrong with an dyn. array of DWord?
Much like what's wrong with dynamic array of Word (as opposed to
Widestring) or with dynami
listmember schrieb:
>>> But, I could write a gigantic data mining application, a database
>>> application
>>> or a myriad of such apps that uses the above class without doing a
>>> single
>>> pixel of GUI stuff.
>>
>> I'd like to see that: it will be guaranteed dog slow :(
>
> Hmm.. may be, maybe
Graeme Geldenhuys schrieb:
> Remember, Unicode support is much more that simply storing and
> displaying text. You have various encodings, RTL or LTR direction etc.
> I can't see how a simple type can keep track of all such information
> - but then, I don't know the internals of FPC either. ;-)
Marco van de Voort schrieb:
> In our previous episode, Ivo Steinmann said:
>> 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:
>
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
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
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 imple
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.freep
Martin Schreiber schrieb:
On Sunday 07 September 2008 10.58:03 Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Saturday 06 September 2008 21.08:50 Florian Klaempfl wrote:
Martin Schreiber schrieb:
Next problem is that pmsechar(msestring) returns a NIL pointer if
msestring = '
Martin Schreiber schrieb:
On Saturday 06 September 2008 21.08:50 Florian Klaempfl wrote:
Martin Schreiber schrieb:
Next problem is that pmsechar(msestring) returns a NIL pointer if
msestring = ''. As designed? The behaviour of ansistring and widestring
was very useful, I
Martin Schreiber schrieb:
On Friday 05 September 2008 22.50:23 Florian Klaempfl wrote:
[...]
This should be fixed.
Thanks, FPC and MSEide compile now.
Attached an "emergency" patch that I could load the MSEgui forms, not finished
and not tested.
Thanks.
Is TTypekind = (... tkIn
Martin Schreiber schrieb:
Florian,
On Saturday 30 August 2008 13.37:42 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
Adriaan van Os schrieb:
Florian Klaempfl wrote:
Adriaan van Os schrieb:
Interface definitions
--
@@ -86,9 +92,10 @@
Level : 2
Class : (24) Nil
Procsym : (26) SymId 57
- File Pos : 1 (94,10)
+ File Pos : 1 (3411,10
Adriaan van Os schrieb:
Interface definitions
--
@@ -86,9 +92,10 @@
Level : 2
Class : (24) Nil
Procsym : (26) SymId 57
- File Pos : 1 (94,10)
+ File Pos : 1 (3411,10)
For the record, File Pos changes and is crc'ed.
Graeme Geldenhuys schrieb:
On Sat, Aug 30, 2008 at 4:07 PM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
I don't know what is "core", so would you mind forwarding the related
messages to this group?
Not really, we had enough useless and time wasting discussions about
JoshyFun schrieb:
Hello Florian,
Saturday, August 30, 2008, 1:37:42 PM, you wrote:
FK> I've continued to work on support of an unicodestring type in fpc. It's
FK> currently in an svn branch at:
FK> http://svn.freepascal.org/svn/fpc/branches/unicodestring
FK> and will be merged later to trunk. T
Graeme Geldenhuys schrieb:
On Sat, Aug 30, 2008 at 3:45 PM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
And why utf-16 ? Unix
uses UTF-8 by default, which means that a conversion must be done each
time you interface to the OS ?
Can you explain some of the decisions ?
See my post on cor
Michael Van Canneyt schrieb:
On Sat, 30 Aug 2008, 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 unicodes
Felipe Monteiro de Carvalho schrieb:
Will there be a new set of RTL routines designed to work with this
string type? Probably with the same name as normal RTL routines, just
overloaded.
Not by me. I consider the compiler and helper routines support as my part.
__
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
Sergei Gorelkin schrieb:
Hello,
The attached patch contains three improvements of code generation for
string literals:
Thanks! Applied in 11657. Please try to follow the indention rules other
compiler code uses.
___
fpc-devel maillist - fpc-deve
501 - 600 of 1314 matches
Mail list logo
