Gpc

gpc@gnu.de

5400 discussions

Packing strings ()
by Contestcen＠aol.com 13 Jul '05

13 Jul '05

>> If the strings are not known until run time, the most >> efficient way is to allocate a large block of storage, and move the >> strings in end-to-end, using a separate array to hold either pointers or >> indices into the large block. >> >> When the block is full, allocate another large block using New. There >> are two ways to manage the storage. (1) Extension block method: Use a >> second array to point to the set of large blocks. Each string will be >> accessed using two pointers or two indices. The first will point to the >> particular block, and the second will point to the string within the >> block. (2) Single block method: Make the new block twice as large as >> the previous block, move the existing strings into the new block and >> then Dispose the old block. > >Very convoluted. A linked list or string collection would do just fine. >And I am still not sure how you can make the claim that one method or >the other is the "most efficient" way of doing something. In this case I should have said "the most efficient ways that I know." A linked list of strings may or may not be comparably efficient in terms of space usage. In the extension block method, for each block of strings you also need a table of integer indices into the block. The pointers in the linked list are probably twice as large as the integer indices, so they take more room. In addition, the pointers may need to be aligned, so they may take an average of 5.5 bytes, compared to 2 bytes for the indices. On the other hand, you don't know beforehand how many strings you will have, so you might allocate the index table larger than is actually needed. However, the index table offers an advantage. It can be sorted according to the alphabetic order of the strings, so the table can be searched by a binary search, or they may be arranged into a heap, which also makes for log(N) time searching. Both of these methods require no extra storage. On the other hand, the linked list has to be searched serially. If you chose to use a hash table with the linked list, that would occupy even more storage. As I indicated in an earlier posting, the decision to use a hash table, heap or tree to speed up access to the strings is independent of the method used to store the strings. To head off any future argument that doubling the size of the single block can waste a lot of storage, let me point out that doubling is just an example. You could increase it by half, or by 10% each time, at the expense of copying the list of strings more frequently. This is simply a time-vs-space trade-off. Frank Rubin

2 1

Packing strings ()
by Contestcen＠aol.com 13 Jul '05

13 Jul '05

> OTOH, strings must be aligned at least to `Integer' size. (Accessing > the Capacity and Length fields requires alignment on some platforms > and is at least more efficient on others; accessing the characters > can also be more efficient when aligned.) Does your preprocessor > take care of this? > Whether you choose to align the length field on an integer-size boundary or not is a decision you could make based on a time versus space trade-off. The macros that I have written happen to store the strings with no gaps at all, and do not do any alignment. If you decided that for your application and platform aligning the strings was better, then you would not use my macros, you would write your own macros, or modify my macros to align the strings. The Pascal Macro Compiler is a general-purpose preprocessor, and can align or not align as the user wishes. > >> Conclusion: If the strings are known at compile time, the most efficient way >> to store them without gaps is to use the Pascal Macro Compiler. If the >> strings are not known until run time, the most efficient way is to allocate a large >> block of storage, and move the strings in end-to-end, using a separate array >> to hold either pointers or indices into the large block. > > Not necessarily. There are various data structures such as hashes, > lists and trees for a reaons. Each have their particular advantages > and disadvantages. Which one is best, depends on the application and > is not always easy to decide. Claiming that any particular method is > "the most efficient" without qualification doesn't give your > statements much credibility, sorry. > How you store the strings and how you access the strings are completely separate issues. You can decide to use hash tables, threaded lists, heaps, or trees for accessing the strings regardless of whether you store the strings in a fixed-width table of strings, end-to-end in a character array, or each in a separately allocated block of storage. These decisions can be made independently. I am dealing here solely with the issue of how to store the strings with the least possible amount of wasted space. > > At least you got the quoting right this time. :-) > There is no "right" way to do quoting. Different people have different preferences. I simply followed the style that is used in this particular forum. Frank Rubin

2 1

Packing strings ()
by Contestcen＠aol.com 13 Jul '05

13 Jul '05

>> Conclusion: If the strings are known at compile time, the most >> efficient way to store them without gaps is to use the Pascal Macro >> Compiler. > > A very bold claim indeed - and I am not sure how you can make such a > claim, without seeing every string-handling routine that every > programmer has written. > Using the Pascal Macro Compiler you can store the strings with no gaps and no wasted space whatsoever. I don't see how you can improve on that. Moreover, the method requires no code, makes no calls, and takes no time at run time. I don't see how you can improve on that. Frank Rubin

2 1

range checking
by Peter N Lewis 10 Jul '05

10 Jul '05

Ok, I've got my application compiling and linking (all 250+ units). Now I'm trying to test it out. Currently it is crashing out with range checks. The first was one I'm used to with GPC, passing an SInt32 to a UInt32 (often these types are used interchangeably by the system to refer to a generic block of four bytes (eg random number seed) and so ensuring they match is not normally that important, but GPC range checks on these. I've written SafeCast functions for Signed to Unsigned and vice versa. I guess I'll eventually catch them all. The next one is more challenging, since I don't see a good workaround. s: String(255) @s[1] range checks if Length(s) is 0. While this might technically be correct (the subscript is out of bounds), the actual address is valid. This is quite challenging to work around, since I'm often forced to deal with strings as a pointer to chars and a length, and this means that code to say draw a string like: DrawString( @s[1], Length(s) ); now needs to special case for s = ''. I would contend that in the case of @s[x], x should be checked against a range of 1..Length(x)+1 because it should be legal to point to the next free character. Whether this is reasonably doable or not, I don't know. If s were short strings, I could work around it with pointer arithmetic (@s+1), but given it is a Schema, I don't know how I would safely get the address of the first character of the string in the case where s might be empty. More precise control over range checking ,might be helpful, options to disable range checking for strings, or perhaps limit them to capacity range checking, as well as disabling range checking on casts would be nice to get things going (I prefer to run with as much protection as possible generally, but sometimes range checking can be overly enthusiastic). Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

3 2

range checking code generation error
by Peter N Lewis 10 Jul '05

10 Jul '05

The following code works correctly if --no-range-checking, but fails with range checking enabled (as it is by default). % gp --no-range-checking peterY.pas % ./peterY OK % gp peterY.pas % ./peterY failed Looking at the assembly, it seems erroneously pass a local variable address (temporary?) to the var parameter. Thanks, Peter. program peterX; type SInt32 = Integer attribute( size = 32 ); UInt32 = Cardinal attribute( size = 32 ); procedure Doit( var x: SInt32 ); begin x := 5; end; var y: UInt32; begin y := 1; Doit( SInt32(y) ); if y = 5 then begin WriteLn( 'OK' ); end else begin WriteLn( 'failed' ); end; end. -- <http://www.stairways.com/> <http://download.stairways.com/>

1 0

Fwd: Forward defined types (and object
by Frank Heckenbach 09 Jul '05

09 Jul '05

marcov(a)stack.nl: : In gmane.comp.compilers.gpc, you wrote: : : Gale's msg reminded me of more Delphi syntax regarding forward defines. It is not : directly related to Gales remark (I also think that inheriting from forward defined : classes/objects shouldn't be possible, and so does Borland: "class not completely defined yet"). : : The detail I forgot is that inheritance info must match, so: : : Type : ta = class (SomeObject); // define forward : : tb = class : procedure dosomethingwith(a : ta); // I now have inheritance info about ta here. : end; : : ta = class (someobject) : x : integer; : end; : : : and not e.g. : : Type : ta = class; // define forward. However this is effectively class(tobject), inheriting from the base object : : tb = class : procedure dosomethingwith(a : ta); // I now have inheritance info about ta here. : end; : : ta = class (someobject) // ta already defined error here. : x : integer; : end;

1 0

Re: packing strings ()
by Contestcen＠aol.com 08 Jul '05

08 Jul '05

> How can a preprocessor (macro compiler) help here, when it runs at > compile time, while time question was clearly about runtime storing > of strings (mentioning New and block moves etc.)? I assumed that the strings were being stored at runtime because storing them end-to-end at compile time was too tedious. If there is a static set of strings, then the Pascal Macro Compiler can store them without any wasted space. If additional strings need to be added to that set at runtime, it is easy to write a procedure to append them to the character array so that all of the strings are accessed the same way. This avoids the use of the New procedure, except if you use it for handling array overflow. I don't know the internals of the GPC New procedure, but in various environments where I have worked in the past there was no guarantee that successive calls to New would allocate adjacent blocks of storage, hence no guarantee that there would be no gaps or wasted space. It all depended on what sequence of calls to New and Dispose had occurred earlier. Frank Rubin

3 2

Re: Forward defined types (and object references)
by Peter N Lewis 08 Jul '05

08 Jul '05

At 9:07 +0200 6/7/05, Marco van de Voort wrote: > > marcov(a)stack.nl wrote: > >> > Delphi supports this: (remember its object model is similar) >> > >> > Type > > > MyObjectB = class; > > > MyObjectA = class; >> >> This seems to be what `class .. end' is in OOE. >> >> > Must be in one typeblock though, IOW, the same system as pointers. >> >> Yes, same in OOE. > >Does CW work like OOE in this regard? No, CW does not accept either syntax: MyObject = object; nor MyObject = object .. end; CW takes the approach that any unknown type identifier it sees in a type definition is pointer sized (a pointer or object) and must be defined by the end of the type block. type rec = record a: UndefinedA; b: UndefinedB; end; UndefinedA = ^Integer; UndefinedB = object end; Note that UndefinedA = UInt32 is not legal, it must be a pointer or object. It's actually not a bad methodology and makes it easy to write data structures that is self or mutually referential, but it does not add anything over pre defining pointers or object names as EP/Delphi. >Note that afaik there is no solution for BP style objects, and actually you >don't really need it, since in practice you always work with references >(explicit pointers). There is still this case: type proc = procedure ( var o: MyObject ); MyObject = object f: proc; end; But I agree, in practice with non-reference objects, the issue is a lot less prevalent. Enjoy, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

4 9

Stable version?
by Silvio a Beccara 08 Jul '05

08 Jul '05

Good morning everybody, sorry, but still noone has answered my question about the download of a stable source version for GPC. Is there any available? If so, where? Can you give me directions as how to compile and install GCC locally (i.e. as non-root) and then GPC in the same way? Thank you very much, best regards Silvio a Beccara -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Manuali.net pensa alla tua formazione con corsi per tutte le professioni e dal costo contenuto. * Dalla Sicurezza alla Grafica, dal PC alla programmazione....Clicca qui Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3414&d=7-7

3 3

... forgot
by Silvio a Beccara 07 Jul '05

07 Jul '05

Which GCC version should I compile to compile the latest GPC snapshot (the only downloadable file at the time being)? Silvio a Beccara -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Iscriviti GRATUITAMENTE: ci sono 5 Euro che ti aspettano .e decine di corsi... * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3416&d=7-7

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc