On Tue, 13 Nov 2001, Frank Heckenbach wrote:
However, maybe there should be a third result of a test, 'warning'; which would test non-portable behavior?
What a coincidence, just yesterday I implemented `WARN' as a test suite flag!
We may be the same Zodiac sign or somethin'? :-)
And second, shouldn't compiler *WARN* me about accessing the value of non-initialized variable with IN operator? I've tried and even with -Wall gpc was quiet.
It's a known issue that the uninitialized-warnings don't work with global variables and some non-simple types (strings, sets, ...). I hope we can fix this sometime (but currently, there are more important issues) ...
I will always vote for that when asked, since this warnings help a lot when writting complex programs and save tons of time of debugging.
In the mean time, with your permission, I just might submit a test that gives a WARN if a variable of non-simple type is not initialized on platform?
2. BTW, I've seen FPC bindist shiping with Mandrake 8.* ... How is the situation with GPC and Linuxes? I mean with Mandrake 8.1 CD's you get even Haskell functional language HUGS interpreter, which is IMHO far more exotic than GPC compiler. IMHO, with such extensive testsuite that passes without complaint on Solaris box - GPC may be just enough stable to include in official Linux releases?
Of course, users (and admins) can always build the compiler from source dist - but having it out of the box and running immediatelly might just be the difference between using it or not!!
And BTW, in my not so humble opinion GPC is much better than FPC, at least in the area which I love most in PASCAL: SETS! FPC can't be convinced easily to construct SET with more than 256 elements, so I can't see any use beyond testing character ranges.
I was thinking also about the issue - sparsely filled sets of large numbers; and now when I saw then on TODO list I was very excited. I think that they are definitely a good thing, worth implementing (I offer my assistance, as an experienced programmer in C and C++, even worked on great commercial projects for banking software, also knowing PASCAL).
On the other hand, I'd agree with '??' remark in TODO list, because sparse sets bring difficult and vexing algorythmic problems; so I thought of multiple ways of internal representation: from items numbered in a simple list; to multiple ranges of bits representing set items (a very simple extension to current algorythm with MedCards in p/rts/sets.pas) - to some SF features such as something resembling UNIX filesystem internal structure and organization (of course optimized for in-memory operation). Of course, the emphasys would be on speed and conservative memory use - so making all ends meet might be an art!?!
Actually, I had in mind a combination of all above, with a number on head representing the version of algorythm used to represent particular set (extra byte or word or long), with also "negative image set" - this would be representation of the complement of the set (used only when this would be opportune - in situation such as "full_set - [one_lement] and like).
But off course, these is just rough thinking - a true analisys of the problem *should* involve simulations of average use etc. etc. ...
Then again, that would lead to increase in code complexity comparing to elegance shown in p/rts/sets.pas ...
However, SPARSE SETs seem to me like an excellent challenge for a programmer, but they *do* introduce new issues, for example memory allocation problems - since their size can't be computed at compile time since it depends on actual # of set members; and so on and so on ...
Frank, what do you think of these thoughts of mine? Anybody?
mirsad
-- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.