[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnubg] XML matchequity parsing & frustration [was: Crash in 64pt gn
From: |
OJOHANS |
Subject: |
[Bug-gnubg] XML matchequity parsing & frustration [was: Crash in 64pt gnu vs gnu match] |
Date: |
Fri, 12 Jun 2009 16:05:26 +0200 |
>Øystein has replaced the last bit of code that uses libxml,
>I'll see if I can check it in as it's one less (often messy)
>dependency.
(This is about the parsing of XML files containing match equity table data)
Yes, but I was never able to commit this to the main cvs. As I tried, I got
more and more frustrated by the code quality in this area, and I think this
should have a heavy refactorisation. I really wanted to do such a
refactorisation, but lost time and interest...
The big problem: We have one global array of match equity values (aafMET)*,
another global array for post-crawford met values (aafMETPostCrawford), a third
global structure (miCurrent) to hold the filename, name and a description and
the native length (where the description and the native length is not even
used), we have a forth global array to hold gammon prices (aaaafGammonPrices),
and we have a fifth global array to hold the gammon prices post crawford.
I suggest we rather make a GObject class, and make it a singleton object. A
simple interface can be defined with methods like: get_ME(), get_ME_at_score(),
invert(), read(<filename>), etc. A constructor can take a xml filename or
something. Much cleaner? Isn't it?
That's what I wanted to do, but ....
*) Just to mention this as well. The global variable name is prefixed 'aaf' and
not 'aar' which you would expect for an array holding real (float) values. The
'aaf' prefix suggests that this is actually an array of an array of flags!! --
I also suggest that we remove all of this "Hungarianish" naming. (BTW: Most
Hungarians has a name already :-). It does not make the code more readable nor
maintainable in my opinion. Just more mess!
-Øystein
-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you.
Re: [Bug-gnubg] Crash in 64pt gnu vs gnu match, Jonathan Kinsey, 2009/06/12
- [Bug-gnubg] XML matchequity parsing & frustration [was: Crash in 64pt gnu vs gnu match],
OJOHANS <=