Re: [fpc-devel] Pointer cache for fast class/pointer access.
On 01/04/2012 07:14 PM, Hans-Peter Diettrich wrote: Better question: what common capabilitiers are implemented differently in Object and TObject? The funny thing being that TObject is a class and not an Object :-) That makes *what* difference? I once for some reason tried to compile TurboVision with Lazarus. In TurboVision TObject is an object, in Lazarus TObject is a class. As this only was a test, after some lame efforts to solve the problem, I gave up. So it does make a difference :) And the funny thing is just the naming Borland chose when moving from TP to Delphi. There is a concept called Object that is similar but not identical to a concept called class and now they do a type TObject = class. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property cam access private symbol from class in other unit
Martin schrieb: Note, that I am not accessing a private field of the parent class (like in the link). TForm1 = class(TForm) public FFoo: TFoo; property Num: Integer read FFoo.FBar; end; When FFoo is a pointer or reference, it IMO should not be possible at all, to select a member of it in a property. AFAIR Delphi only allows for access to Record (or Object) members, which reside inside the instance. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
Marcos Douglas schrieb: I don't see any reason why the Object type should be dropped. It's close to C++ objects, useful in porting code. It allows for static objects, e.g. in the stack, while TObject is bound to the heap (without tricks). So, Object types is indicated only for compatibility? In your opinion, for the atual code, we have some benefit using Object (stack) instead Class (heap)? Delphi (now) provides Records with methods, but these lack inheritance. Why introduce such a crippled construct, when Objects can do the same and more (virtual methods...). I used Object types to e.g. emulate C bitfields, with a simple typecast of a variable into the according object... What is bitfields? C bitfields are parts of some integral type variable, with each field spanning one or more bits. They allow to e.g. subdivide DWORD parameters, which consist of several parts (combined with OR). DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
Florian Klämpfl schrieb: Am 04.01.2012 19:24, schrieb Hans-Peter Diettrich: Skybuck Flying schrieb: -Original Message- From: Hans-Peter Diettrich Sent: Tuesday, January 03, 2012 14:56 To: FPC developers' list Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access. Skybuck Flying schrieb: vValue := mDepth1.mDepth2.mDepth3.mValue; You can implement such a funny hierarchy in any language. So what? For the performance of the line of code above it matters if TObject or Object is used. Ah, now I understand what you mean. Nonetheless I don't see sane reasons for creating such (deeply nested) structures in real life code - records would serve the same (demonstrated) purpose. If one really suffers from cache misses, then one should consider a better layout of the data structures. In your example a class hierarchy would be better suited, where no additional pointers are required to access base class members. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] simple UTF tests
With Lazarus on Linux, I did some simple tests with UTF strings. I found that the length of an AnsiString(CP_UTF16) is given in terms of bytes and not of Words. Is this like it should ? I found that pchar(s8) with an UTF-8 string works as expected, giving a pointer to the UTF-8 encoded byte array. Anyway: is it obvious, that the encoding of pchar is UTF-8 ? Is this portable ? p16 = pchar(s16) with an UTF-16 gives a pointer to the first byte of the word array, so (with ASCII text), the second byte is zero, thus a C-String length 1. Is this like it should ? Of course re-assigning p16 to an UTF-16 string does not reproduce the original string. What encoding is to be supposed for a pchar ? The Debugger does not show UTF-16-Strings correctly (it shows the same result as pchar() ). Is this just a Lazarus problem, or does FPC need to provide additional support for this ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] simple UTF tests
In our previous episode, Michael Schnell said: With Lazarus on Linux, I did some simple tests with UTF strings. I found that the length of an AnsiString(CP_UTF16) is given in terms of bytes and not of Words. Is this like it should ? Yes. Afaik that is not a sane combination, but Delphi compatible. I found that pchar(s8) with an UTF-8 string works as expected, giving a pointer to the UTF-8 encoded byte array. Anyway: is it obvious, that the encoding of pchar is UTF-8 ? Is this portable ? pchar should give access to the raw data of the default string type. (be it still 8-bit as in FPC, or 16-bit in Delphi). p16 = pchar(s16) with an UTF-16 gives a pointer to the first byte of the word array, so (with ASCII text), the second byte is zero, thus a C-String length 1. Is this like it should ? Yes. This is not sane code (even if you want e.g. the lower byte, this is not endian safe), since s16 is currently not the default string type Of course re-assigning p16 to an UTF-16 string does not reproduce the original string. What encoding is to be supposed for a pchar ? pchar's provide access to memory with the granularity of the default string type. Whatever that is, 8-bit or 16-bit, and in whatever encoding it is stored. When converted to something else, the default system encoding for the corresponding default string is probably used. To force 8 or 16 bits one should use pansichar or pwidechar. This is Delphi compatible. The Debugger does not show UTF-16-Strings correctly (it shows the same result as pchar() ). Is this just a Lazarus problem, or does FPC need to provide additional support for this ? No idea. Both are possible. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
In our previous episode, Michael Schnell said: Better question: what common capabilitiers are implemented differently in Object and TObject? The funny thing being that TObject is a class and not an Object :-) Which tobject do you mean? Objpas.tobject (Delphi) or objects.tobject (TP) ? :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
In our previous episode, Sven Barth said: Object instead Class? They are basically similar to records with methods (which we now have as well...) if you use them directly (this means: not as pointer types): they are located on the stack and nested objects are part of the memory structure of the object. But if you use references to objects you work more like with classes as you have constructors, virtual methods and the objects are then located on the heap (thus you need to care for the memory management yourself). Afaik records with methods is more advanced since they are initialized. Afaik stack based TP Objects are not initialized and thus not safe for automated types. (I looked into upgrading TV with ansistring a few years back) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
05.01.2012 15:45, Marco van de Voort пишет: In our previous episode, Sven Barth said: Object instead Class? They are basically similar to records with methods (which we now have as well...) if you use them directly (this means: not as pointer types): they are located on the stack and nested objects are part of the memory structure of the object. But if you use references to objects you work more like with classes as you have constructors, virtual methods and the objects are then located on the heap (thus you need to care for the memory management yourself). Afaik records with methods is more advanced since they are initialized. Afaik stack based TP Objects are not initialized and thus not safe for automated types. (I looked into upgrading TV with ansistring a few years back) This is no longer correct, stack based objects are initialized and finalized if necessary. There was indeed an issue with inheritance (if both ancestor and descendant contain managed members, then members of ancestor were not handled), but I personally fixed that in r16335 a year ago. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
In our previous episode, Sergei Gorelkin said: Afaik stack based TP Objects are not initialized and thus not safe for automated types. (I looked into upgrading TV with ansistring a few years back) This is no longer correct, stack based objects are initialized and finalized if necessary. There was indeed an issue with inheritance (if both ancestor and descendant contain managed members, then members of ancestor were not handled), but I personally fixed that in r16335 a year ago. Ah, I thought Delphi didn't intialize them either, and therefore it was a won't fix. But anyway, thanks, I updated the relevant wiki page. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
In our previous episode, Sergei Gorelkin said: This is no longer correct, stack based objects are initialized and finalized if necessary. There was indeed an issue with inheritance (if both ancestor and descendant contain managed members, then members of ancestor were not handled), but I personally fixed that in r16335 a year ago. r16335 is a commit by Michael? r16335 | michael | 2010-11-13 16:51:43 +0100 (Sat, 13 Nov 2010) | 1 line * Correction of PAFProtocols (Ivan Shikhalev, bug ID 17924 Mantis 16335 neither, that's about makefiles. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
05.01.2012 16:12, Marco van de Voort пишет: In our previous episode, Sergei Gorelkin said: This is no longer correct, stack based objects are initialized and finalized if necessary. There was indeed an issue with inheritance (if both ancestor and descendant contain managed members, then members of ancestor were not handled), but I personally fixed that in r16335 a year ago. r16335 is a commit by Michael? r16335 | michael | 2010-11-13 16:51:43 +0100 (Sat, 13 Nov 2010) | 1 line * Correction of PAFProtocols (Ivan Shikhalev, bug ID 17924 Mantis 16335 neither, that's about makefiles. Oops... revision 16635 it is (more precisely, both 16632 and 16635). Sorry. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] simple UTF tests
On 01/05/2012 12:32 PM, Marco van de Voort wrote: When converted to something else, the default system encoding for the corresponding default string is probably used. To force 8 or 16 bits one should use pansichar or pwidechar. This is Delphi compatible. Hmm. ( Would it not be more sane to always use the default system encoding (i.e. UTF-8 in Linux) for pchar and auto-convert the string content ? ) After writing this, I suppose this is not possible, as there is no data area where the converted information should be stored. So we are out of luck wanting a sane solution :( . -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
On 01/05/2012 12:44 PM, Marco van de Voort wrote: Which tobject do you mean? Objpas.tobject (Delphi) or objects.tobject (TP) ? :-) even more funny... -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] simple UTF tests
In our previous episode, Michael Schnell said: ( Would it not be more sane to always use the default system encoding (i.e. UTF-8 in Linux) for pchar That depends on how the default string type is defined. Discussions about that is postponed. and auto-convert the string content ? ) pchars are generally not string types. If you need that, you shouldn't be using pchars for it. After writing this, I suppose this is not possible, as there is no data area where the converted information should be stored. So we are out of luck wanting a sane solution :( . First define a solution for what and why. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
Am 05.01.2012 11:22, schrieb Michael Schnell: On 01/04/2012 07:14 PM, Hans-Peter Diettrich wrote: Better question: what common capabilitiers are implemented differently in Object and TObject? The funny thing being that TObject is a class and not an Object :-) That makes *what* difference? I once for some reason tried to compile TurboVision with Lazarus. In TurboVision TObject is an object, in Lazarus TObject is a class. As this only was a test, after some lame efforts to solve the problem, I gave up. AFAIK adding unit objects might have solved that (I have not tested that and thus I am simply guessing!). At least that unit contains a TObject = object declaration (see here at line 250: http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/objects.pp?view=markup). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] simple UTF tests
Am 05.01.2012 12:32, schrieb Marco van de Voort: In our previous episode, Michael Schnell said: With Lazarus on Linux, I did some simple tests with UTF strings. I found that the length of an AnsiString(CP_UTF16) is given in terms of bytes and not of Words. Is this like it should ? Yes. Afaik that is not a sane combination, but Delphi compatible. AFAIK (I'd need to start Delphi for this) AnsiString(CP_UTF16) is not allowed in Delphi. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] simple UTF tests
Am 05.01.2012 14:30, schrieb Sven Barth: Am 05.01.2012 12:32, schrieb Marco van de Voort: In our previous episode, Michael Schnell said: With Lazarus on Linux, I did some simple tests with UTF strings. I found that the length of an AnsiString(CP_UTF16) is given in terms of bytes and not of Words. Is this like it should ? Yes. Afaik that is not a sane combination, but Delphi compatible. AFAIK (I'd need to start Delphi for this) AnsiString(CP_UTF16) is not allowed in Delphi. Ok... one can use the UTF16 code page, but Delphi does NOT define CP_UTF16 (I needed to use 1200, which is the code page ID used by Microsoft). And the following code: type TestString = type AnsiString(1200); var s: TestString; begin s := #$3428#$3828; Writeln(Length(s)); Readln; end; Writes 0 while the same code with AnsiString(CP_UTF8) writes 6. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] simple UTF tests
On 01/05/2012 02:19 PM, Marco van de Voort wrote: First define a solution for what and why. I don't suppose this makes sense, as the Delphi behavior needs to be mimicked. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: [Lazarus] Free Pascal 2.6.0 released!
Am 01.01.2012 16:43, schrieb Marco van de Voort: Changes that may break backwards compatibility are documented at: http://wiki.freepascal.org/User_Changes_2.6.0 I have found something that might be noteworthy as well: If you use sqldb with SQLite then ftDateTime values are now saved differently (changed in this revision: http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fcl-db/src/sqldb/sqlite/sqlite3conn.pp?r1=18031r2=18044 ). This is no problem if you use only FPC 2.6 or newer, but if you need to use an older FPC version or Delphi in parallel to a 2.6 then you need to adjust the values (I had some bug hunting to do the last few hours because of this change). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] simple UTF tests
In our previous episode, Michael Schnell said: I don't suppose this makes sense, as the Delphi behavior needs to be mimicked. It doesn't make sense if your ultimate object is to get FPC changed or amended. It does make sense if you want your problem analysed and want alternate suggestions. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] simple UTF tests
I am just watching the proceeding of FPC and doing some test when I have some spare time to do this. Of course I would like to help making FPC better and - if possible - more sane than Delphi. But I do see the limits. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] simple UTF tests
Marco van de Voort schrieb: In our previous episode, Michael Schnell said: With Lazarus on Linux, I did some simple tests with UTF strings. I found that the length of an AnsiString(CP_UTF16) is given in terms of bytes and not of Words. Is this like it should ? Yes. Afaik that is not a sane combination, but Delphi compatible. Which Delphi version supports AnsiString(CP_UTF16)??? At least XE and successors only support byte-char (AnsiChar) codepages with AnsiString and RawByteString. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] simple UTF tests
In our previous episode, Hans-Peter Diettrich said: With Lazarus on Linux, I did some simple tests with UTF strings. I found that the length of an AnsiString(CP_UTF16) is given in terms of bytes and not of Words. Is this like it should ? Yes. Afaik that is not a sane combination, but Delphi compatible. Which Delphi version supports AnsiString(CP_UTF16)??? At least XE and successors only support byte-char (AnsiChar) codepages with AnsiString and RawByteString. There is a difference between Delphi accepting it and doing something sane. FPC afaik also accepts and afaik also doesn't do anything sane, so that is compatible :-) Btw in this thread it was already mentioned that Delphi doesn't define CP_UTF16, but one easily could define it and create the above code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
On Thu, Jan 5, 2012 at 8:03 AM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Marcos Douglas schrieb: I don't see any reason why the Object type should be dropped. It's close to C++ objects, useful in porting code. It allows for static objects, e.g. in the stack, while TObject is bound to the heap (without tricks). So, Object types is indicated only for compatibility? In your opinion, for the atual code, we have some benefit using Object (stack) instead Class (heap)? Delphi (now) provides Records with methods, but these lack inheritance. Why introduce such a crippled construct, when Objects can do the same and more (virtual methods...). +1 But more about Object type, what do you think to use Object to group routines instead of using procedure/functions, as a 'namespace' to not use the unit name as a prefix? Anyone else? I used Object types to e.g. emulate C bitfields, with a simple typecast of a variable into the according object... What is bitfields? C bitfields are parts of some integral type variable, with each field spanning one or more bits. They allow to e.g. subdivide DWORD parameters, which consist of several parts (combined with OR). Thanks for clarification. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
