[SOLVED] Using records inside the class

[lucamar]

This approach has overheads, but works good and fast. Gset instance holds only  pointer to the root node.  But my question remains.

You're responding to yourself there: It has overheads. When it's for yourself it may not matter (much) but when writing general code that  may be used by thousands of programmers for thousands of different applications it matters quite a lot.

For example, I know people that use an advanced record implementing the minimum imprescindible (for their use) for a list of strings because their applications can't cope with the overhead of using TStringList.

[julkas]

When it's for yourself it may not matter (much) but when writing general code that  may be used by thousands of programmers for thousands of different applications it matters quite a lot.

That's right. Assume for different reasons we want augment, extend Node in gset class. Can we do this? Can we subclass gset class and add other fields to the inner record. If yes , how?

[mas steindorff]

OK. My question is not from the user side, but from learner and programmer. I try to understand pros and cons of gset implementation.

well, one "pro" to this is by by placing all of my variables in a record, I can use a call to fillchar(my,sizeof(my),0) => "fill memory with 0" in my Clear() procedure. My warning anyone using this trick is you can only have simple variables in your record. Strings, classes, and even arrays defined within the record should not be cleared in this manor so I keep them outside the record.

@mas steindorff:
Look at this thread "Weird Memory Leak!!". Martin_fr suggested to use this code:

Code: Pascal  [Select][+][-]

1. procedure FillerByte(out x; count: SizeInt; value: byte);
2. begin
3.    FillByte(x, count, value);
4. end;
5.  

And now I can't live without that code (by the way this month was the birthday of such a great procedure, now it has 7 years and 20 days old  )

thank you for this tidbit. if I read this correctly, that thread says you are using fillchar on strings?  from what I understand, a string may be broken across 2 areas of memory and is likely to live outside it's record's memory block. I can see how it may work on a string at startup or if it's fixed size but have you tried it on one that has changed 10 to 20 times with different lengths?    (your code in the other thread look like you used setlength() to fix it's size and thus it's location)

[garlar27]

@mas steindorff:

... but have you tried it on one that has changed 10 to 20 times with different lengths? ...

I use it everywhere in my code inside functions, methods, and loops of every flavor, and with ever changing string lengths and never had a single problem. It also works fine with dynamic arrays.

(your code in the other thread look like you used setlength() to fix it's size and thus it's location)

I use it the same way as I used FillByte:

Code: Pascal  [Select][+][-]

1. FillerByte(variable, SizeOf(variable), 0);

I even have a code template for it:

Code: INI  [Select][+][-]

1. [filleb0 | FillerByte(x, SizeOf(x), 0);]
2. $(AttributesStart)
3. EnableMakros=true
4. $(AttributesEnd)
5. FillerByte($param(variable), SizeOf($param(variable,sync=1)), |0);
6.  

thank you for this tidbit. if I read this correctly, that thread says you are using fillchar on strings?  from what I understand, a string may be broken across 2 areas of memory and is likely to live outside it's record's memory block. I can see how it may work on a string at startup or if it's fixed size but have you tried it on one that has changed 10 to 20 times with different lengths?    (your code in the other thread look like you used setlength() to fix it's size and thus it's location)

I think the assign count is cleaned safely because x is an out parameter. Then the FillByte works as it where the first time cleaning that record.

If you think it is possible to fail in some circumstances, then it would be a good idea to do a test to confirm if it behaves correctly or not.