Re: [fpc-devel] strings: a proposeal
On Sunday 04 February 2007 01.23, peter green wrote: > from a low level perspective such a string is just a pointer to an array > plus some compiler magic just like current ansistrings, debugging tools > shouldn't need to be aware of the magic any more than they need to be aware > of it for current ansistrings. > Agreed. To show ansi and widestrings in MSEide watch window correct I must read the string data as binary anyway. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strings: a proposeal
On Sunday 04 February 2007 01.01, peter green wrote: > currently there is some demand for a fast widestring type on windows and i > suspect there will be requirements for more string types in the future. > > So i make a proposal for a new syntax that will allow string types to be > created easilly in libraries or user code. > > my proposal is a statement like > > type > tmystring=string(elementtype,allocator,deallocator,copier,uniquer); > > the allocator,deallocator,copier and uniquer would generally be inline > functions > This is a very good idea. There should be two additional functions, one to set string constants (literals) in the current locale encoding and one in UTF-8 encoding if the compiler runs with -Fcutf8. MSEgui is completely done with widestrings, it suffers from the switch to not reference counted widestrings on windows. Also wanted: a possibility to have wide-resourcestrings. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strings: a proposeal
On Sunday 04 February 2007 01:01, peter green wrote: > currently there is some demand for a fast widestring type on windows and i > suspect there will be requirements for more string types in the future. During the creation of our project, Technetium (www.technetium.dk), we designed a string library that would incorporate support for not only widestrings, but also ansistrings, utf-8 strings, mbcs, etc - and not by compiling to different types, but at the /same/ time. My programming partner, Ivo Steinmann, has done a truly excellent job implementing and perfecting this string library. If used right, it's also faster than FPC's internal strings. We'll discuss licensing options, and try to see if we can make ready a public source collection for testing. The source is directly compatible with FPC in objfpc mode, and should even be /somewhat/ compatible with delphi, if you remove the operator overloading. These overloaded operators does make the library /much/ easier to use, though. Is anyone interested in testing this? -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] strings: a proposeal
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Daniël > Mantione > Sent: 04 February 2007 00:09 > To: FPC developers' list > Subject: Re: [fpc-devel] strings: a proposeal > > > > > Op Sun, 4 Feb 2007, schreef peter green: > > > my proposal is a statement like > > > > type > > tmystring=string(elementtype,allocator,deallocator,copier,uniquer); > > And how should you generate debug information for such a user defined > string? if we require user defined string types to keep the conventions that the underlying pointer points to the first character (with metadata at negative offsets) and that there is a null after the last character in memory then at least for simple element types debugging tools should be able to handle them in the same way they currently do (by treating them as C strings). from a low level perspective such a string is just a pointer to an array plus some compiler magic just like current ansistrings, debugging tools shouldn't need to be aware of the magic any more than they need to be aware of it for current ansistrings. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strings: a proposeal
Op Sun, 4 Feb 2007, schreef peter green: > my proposal is a statement like > > type > tmystring=string(elementtype,allocator,deallocator,copier,uniquer); And how should you generate debug information for such a user defined string? Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] strings: a proposeal
currently there is some demand for a fast widestring type on windows and i suspect there will be requirements for more string types in the future. So i make a proposal for a new syntax that will allow string types to be created easilly in libraries or user code. my proposal is a statement like type tmystring=string(elementtype,allocator,deallocator,copier,uniquer); the allocator,deallocator,copier and uniquer would generally be inline functions the elementtype may be any type that doesn't use any compiler magic the allocator allocates a new string of a given number of elements and returns a pointer to the first element, length refcount the allocator and deallocators jobs are obvious to create new strings and reduce the reference count of/dispose of old ones. the copiers job is to increase the reference count if the string is reference counted or copy the string if not the uniquers job is to copy the contents of the string if it is refcounted and its reference count is greater than 1. indexing of the string would be handled in the same way as current strings, that is normally direct access but call the uniquer automatically before starting writes if my understanding is correct this should allow all the widestrings stuff to be moved to the library and people to implement thier own string types as required (for example maybe a widestring counterpart for some system that is similar to com) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Generics
Hi All, I'm looking for a guide (for people that have slow learning curves like me ;)) regarding understanding generics, and the ability to start using them. Thanks, Ido -- http://ik.homelinux.org/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Differences between fpc and Delphi regarding COM interfaces declarations
Luiz Americo Pereira Camara wrote: While porting some Delphi code i found some differences in the declarations of COM interfaces. 1) In IEnumFORMATETC.Next(Celt:ULong;Out Rgelt:FormatEtc;Out pceltFetched:ULong):HResult; Delphi expects pceltFetched to be a PInteger win32 documentation: *HRESULT Next( ULONG*/ celt/*,* * FORMATETC_com_FORMATETC **/ rgelt/*,* * ULONG **/ pceltFetched/ *);* Sorry, i copied formated code. Here's the accurate declaration HRESULT Next( ULONG celt, FORMATETC_com_FORMATETC * rgelt, ULONG * pceltFetched ); Luiz Delphi code: function Next(celt: Integer; out elt; pceltFetched: PLongint): HResult; My adapted code (Based in activex unit - required to compile): function Next(celt: LongWord; out elt: FormatEtc; out pceltFetched: LongWord): HResult; There are two questions: - Should fpc adapt the code to be delphi compatible?? - Calling this interface from fpc is not allowed to pass a nil parameter in pceltFetched, but it would be possible calling from outside?? C++? (The win32 docs does not specify) I'm asking this because the original code checks if pceltFetched is assigned 2) In the STGMEDIUM definition fpc has the following fields PUnkForRelease, PSTM, PSTG while delphi has UnkForRelease, STM, STG. First i think that fpc translated the win headers wrongly, but after looking for the original code declaration i found that fpc is following win32 api closely (with the "P") - What todo here: stay with win32 api or goto Delphi? Notice that this is only a matter of nomenclature and renaming them was sufficient to fix the code, but i took sometime anyway. PS: I'm documenting all the differences i found and i pretend to create a database with the differences between Delphi and fpc/Lazarus. I'll publish it ASA_F_ . ;-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Differences between fpc and Delphi regarding COM interfaces declarations
While porting some Delphi code i found some differences in the declarations of COM interfaces. 1) In IEnumFORMATETC.Next(Celt:ULong;Out Rgelt:FormatEtc;Out pceltFetched:ULong):HResult; Delphi expects pceltFetched to be a PInteger win32 documentation: *HRESULT Next( ULONG*/ celt/*,* * FORMATETC_com_FORMATETC **/ rgelt/*,* * ULONG **/ pceltFetched/ *);* Delphi code: function Next(celt: Integer; out elt; pceltFetched: PLongint): HResult; My adapted code (Based in activex unit - required to compile): function Next(celt: LongWord; out elt: FormatEtc; out pceltFetched: LongWord): HResult; There are two questions: - Should fpc adapt the code to be delphi compatible?? - Calling this interface from fpc is not allowed to pass a nil parameter in pceltFetched, but it would be possible calling from outside?? C++? (The win32 docs does not specify) I'm asking this because the original code checks if pceltFetched is assigned 2) In the STGMEDIUM definition fpc has the following fields PUnkForRelease, PSTM, PSTG while delphi has UnkForRelease, STM, STG. First i think that fpc translated the win headers wrongly, but after looking for the original code declaration i found that fpc is following win32 api closely (with the "P") - What todo here: stay with win32 api or goto Delphi? Notice that this is only a matter of nomenclature and renaming them was sufficient to fix the code, but i took sometime anyway. PS: I'm documenting all the differences i found and i pretend to create a database with the differences between Delphi and fpc/Lazarus. I'll publish it ASA_F_ . ;-) Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
