Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
On Friday 13 April 2012 23:51:12 Sieghard wrote: countless. And often I switch to the C-notation (pchar(pointer (thepascalstring)) [index]) because of performance and convenience reasons. Yes, that's exactly the opposite of my style. I prefer the Pascal way, as introduced by UCSD Pascal and generalized and made public by former Borland. I prefer _safe_ string handling, and it's been fast enough for my purposes everytime in the past. Agreed. And if Pascal string index would be zero based such C-style tricks would not be necessary. Anyway, I don't think it will happen other than Embarcadero changes it. :-) Martin -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
On Friday 13 April 2012 00:05:07 Sieghard wrote:
That's nonsense. Implemented correctly, _any_ index base gives identical
speed - you _don't_ implement it using offset calculation from the first
_existing_ element, but instead, you calculate the offset from a virtual
element corresponding to the (invalid) index 0. No additional operations
neccessary. (And without index range checking, you can access _any_ address
anyway.)
You probably should have a look into the disassembler listings of your
programs and the FPC RTL.
Why do you think Pascal string index is one based in the first place? Because
it is a zero based index to the old shortstring data where shortstring[0]
denotes the length byte, do you remember? An AnsiString is
(rtl/inc/astrings.inc):
{
AnsiString is defined as a 'silent' pchar :
a pchar that points to :
@-8 : SizeInt for reference count;
@-4 : SizeInt for size;
@: String + Terminating #0;
Pchar(Ansistring) is a valid typecast.
So AS[i] is converted to the address @AS+i-1.
}
Type
TAnsiRec = Packed Record
Ref,
Len : SizeInt;
First : Char;
end;
Often one needs the next character in a string after a starting sequence
of given length, null based index is more convenient here too.
Just as often one needs the character position behind some arbitrary string
at some arbitrary location - there's no advantage to any starting index
then.
How many lines of string manipulating code did you write? I wrote countless.
And often I switch to the C-notation (pchar(pointer(thepascalstring))
[index]) because of performance and convenience reasons.
I'll probably add a recindex property to the datasets.
Sure - you're free to do so, for whatever reason you might imagine. ;-)
Thank you.
Martin
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
Hallo Martin, Du schriebst am Fri, 13 Apr 2012 08:10:15 +0200: That's nonsense. Implemented correctly, _any_ index base gives identical speed - you _don't_ implement it using offset calculation from the first ... You probably should have a look into the disassembler listings of your programs and the FPC RTL. That was not a description of the actual implementation by FPC, but one giving the state of the art (a very old art, indeed, as it was common knowledge half a century ago - not longer though, it seems?). Why do you think Pascal string index is one based in the first place? Because it is a zero based index to the old shortstring data where shortstring[0] denotes the length byte, do you remember? I _know_ this, as I used this over and over for getting and setting the length of strings in Tubo Pascal, until around version 6 it was deprecated (as it's called today) and replaced by SetLength for setting - getting was always possible by the Length function. But the original justification for the indexing scheme was said to be that the actually used character data should be counted naturally, starting at 1, and the 0th element was simply used because then it could be implemented as a simple array. With the shortstring type, accessing the count by index thus always required/s a type conversion between byte and char (functions ord and chr). shortstring[0] denotes the length byte, do you remember? An AnsiString Anistrings were presented as opake types, where it was _not_ meant to be possible to access the fields directly, specifically not the length value. The _order_ and arrangement of the fields was not even officially specified in the beginning. How many lines of string manipulating code did you write? I wrote Don't know. countless. And often I switch to the C-notation (pchar(pointer (thepascalstring)) [index]) because of performance and convenience reasons. Yes, that's exactly the opposite of my style. I prefer the Pascal way, as introduced by UCSD Pascal and generalized and made public by former Borland. I prefer _safe_ string handling, and it's been fast enough for my purposes everytime in the past. I also prefer _static_ strings (and other data types), because most of my programming pertains to small systems with limited resources, which often cannot handle the large overhead dynamic memory incurs. (In addition, at least the Pascal string handling is inherently safe in contrast to the C-style way. This means that programs using it are _not_ prone to buffer overflows or out-of-bounds accesses which are so well regarded among the writers of malware programs. Similar safeguards have only recently been added to newer C versions and variants, such as C#.) -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
counting numbers are called cardinal, while numbering numbers (;) are called ordinal. In FPC, the cardinal is =0 (can really be counted on fingers) with twice as higher upper bound. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
Hallo Martin, Du schriebst am Thu, 12 Apr 2012 07:22:32 +0200: MSEgui datasets have a null-based recno already (controller.recnonullbased). Your tribute to C, I guess. I think indexing null or one based should be consistent in a programming Yes, for sure - it should be consistently left to the user, i.e. programmer. (BTW, waht does null based mean here? Did you want to write zero based?) I don't like the one based Pascal string indexes either, null based addressing is faster. That's nonsense. Implemented correctly, _any_ index base gives identical speed - you _don't_ implement it using offset calculation from the first _existing_ element, but instead, you calculate the offset from a virtual element corresponding to the (invalid) index 0. No additional operations neccessary. (And without index range checking, you can access _any_ address anyway.) Often one needs the next character in a string after a starting sequence of given length, null based index is more convenient here too. Just as often one needs the character position behind some arbitrary string at some arbitrary location - there's no advantage to any starting index then. I'll probably add a recindex property to the datasets. Sure - you're free to do so, for whatever reason you might imagine. ;-) -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
Changed in git master e8f1d49de2fc18b898d662cd19a4b2cf3ada3a1e, thanks. BTW, I don't like the one-based FPC recno, I think it should be zero-based. What do you think? I think zero-based is OK such as array concept. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
Hi. Array concept zero-based? not in objectpascal. Why the first element must be 0? You usually think first=1, second=2 first=0? I know there are lots of arguments about starting in 0 or 1 or whatever and I don't want to start a 'war' because it.. My point of view is to follow fpc/fcl direction. Cheers 2012/4/11 wahono sri wahon...@gmail.com Changed in git master e8f1d49de2fc18b898d662cd19a4b2cf3ada3a1e, thanks. BTW, I don't like the one-based FPC recno, I think it should be zero-based. What do you think? I think zero-based is OK such as array concept. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk -- Julio Jiménez Borreguero -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
On Wednesday 11 April 2012 10:23:37 Julio Jiménez wrote: Hi. Array concept zero-based? not in objectpascal. Why the first element must be 0? You usually think first=1, second=2 first=0? All indexes in FPC dynamic arrays are null-based, TList indexes are null based, direct data access in tmsebufdataset is null-based. BTW, do you know tmsebufdataset.currentas* property?. I assume one-based recno is a relict from Borland-BDE-Dbase times. The MSEgui datasets have a null-based recno already (controller.recnonullbased). Martin -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
On 11 April 2012 10:40, Martin Schreiber wrote: All indexes in FPC dynamic arrays are null-based, TList indexes are null based, direct data access in tmsebufdataset is null-based. BTW, do you know tmsebufdataset.currentas* property?. I assume one-based recno is a relict from Borland-BDE-Dbase times. The MSEgui datasets have a null-based recno already (controller.recnonullbased). Maybe you should raise this question in the fpc-pascal mailing list too. Find out why it was 1-based before you make the change - or maybe the change could be done in FPC itself if all agree. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
I have found this link where there is a talk about it. http://www.mail-archive.com/lazarus@miraclec.com/msg06970.html 2012/4/11 Graeme Geldenhuys graemeg.li...@gmail.com On 11 April 2012 10:40, Martin Schreiber wrote: All indexes in FPC dynamic arrays are null-based, TList indexes are null based, direct data access in tmsebufdataset is null-based. BTW, do you know tmsebufdataset.currentas* property?. I assume one-based recno is a relict from Borland-BDE-Dbase times. The MSEgui datasets have a null-based recno already (controller.recnonullbased). Maybe you should raise this question in the fpc-pascal mailing list too. Find out why it was 1-based before you make the change - or maybe the change could be done in FPC itself if all agree. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk -- Julio Jiménez Borreguero -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
Hallo Martin, Du schriebst am Wed, 11 Apr 2012 09:09:42 +0200: BTW, I don't like the one-based FPC recno, I think it should be zero-based. What do you think? That's the distinction between _counting_ and _numbering_. Do you count 0, 1, 2...? Probabely not. How do you number things? Doesn't matter at all, because here, the numbers are just labels. Odered labels, usually, but just labels. You could use any other set of symbols having an oder relation, like letters of the alphabet, or the number names (One, two, three...). There's even a mathematical concept for each of these: counting numbers are called cardinal, while numbering numbers (;) are called ordinal. Calculating is only defined for cardinal numbers, you can add, subtract or multiply them (division is a special case here, because division cannot be defined wholly within the cardinal number's space). With ordinal numbers, you only have distance between them. Usually, this isn't recognized, as one doesn't commonly attempt to multiply, e.g., record numbers or array indices, or even add them together. Subtracting two ordinal numbers produces _not_ an ordinal, but a cardinal, giving the distance between the two. Distance can be positive or negative, because ordinals are ordered - you can always tell whether one comes before the other, is smaller by means of the ordering relation. An implementation of ordinal data are Pascal's enumerations, a typical use are array indices - which, in Pascal, are implemented such that there is a starting value and a sequence defined, where the starting value can be anything allowable for the index value. You can also use enumerations as indices. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bug in msebufdataset.pas
On Wednesday 11 April 2012 21:42:13 Sieghard wrote: Hallo Martin, Du schriebst am Wed, 11 Apr 2012 10:40:40 +0200: All indexes in FPC dynamic arrays are null-based, TList indexes are null based, direct data access in tmsebufdataset is null-based. BTW, do you Which are direct take-overs from C. I assume one-based recno is a relict from Borland-BDE-Dbase times. The Could well be - records are usually sequenced by counting, which traditionally begins at one (1). MSEgui datasets have a null-based recno already (controller.recnonullbased). Your tribute to C, I guess. I think indexing null or one based should be consistent in a programming environment. In tmsebufdataset the record data can be addressed as array with null based index so there should be a null based record number too. Delphi datasets don't provide direct data access without scrolling the dataset AFAIK. I don't like the one based Pascal string indexes either, null based addressing is faster. Often one needs the next character in a string after a starting sequence of given length, null based index is more convenient here too. I'll probably add a recindex property to the datasets. Martin -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
