On Sun, Jan 20, 2002 at 12:02:35PM +0100, Henrik Stuart wrote: > > On Sat, Jan 19, 2002 at 12:36:58PM +0100, Templar Viper wrote: Actually, I wrote it...your attribution is odd. > > I decided to be a complete freak and switch to C++. I created a new > > 'bitvect' class, and typedefed bitvector_t to it. Internally, the > > bitvect class is stored as an array of longs. > > [snip] > > Nice work, I'd just like to make you take notice that you have > actually reinvented the wheel. :o) > The C++ standard template library contains two classes handing > arbitrarily large "bitvectors", one being able to be dynamically > resized and the other being of static size, decided at > compile-time. The two classes are vector<bool> (overloaded template > instantiation) and bitset, located in the files vector and bitset > respectively. I've looked at them both, and they're interesting, but they're not as close to drop in replacements for the current bitvector_t. My goal was to make something that involved less changes on a global scale than this would require and much less than bitfields or the ugly 128 bits patch. > Since you rarely want to dynamically resize the item types, add new > character preferences, etc. at runtime using bitset would probably > the more sane way to go (which incidently is what I use in my > source). :o) How much of a conversion issue did you run into? > Now with a bitset you would do something like: > > #define AFF_CHARM 0 > #define AFF_CURSE 1 > #define NUM_AFFECTIONS 2 > > Then instead of the affected bitvector you'd have this: > std::bitset<NUM_AFFECTIONS> affected; > > (If you really want to use c++ changing the above defines to an > enum would probably be nice too). :o) I am actually trying to restrict my C++ usage as much as possible. The only reason I am using C++ at all at this time is for operator overloads that make the bitvect class behave properly with existing code. > bitset supports a long range of wonderful functions: any (to test > whether any bit is set at all), test (to test whether a bit is > set), to_string (to convert to a string of 1's and 0's), to_ulong > (you guess) :o) Kindly enough bitset can also take a std::string > as argument in its constructor so saving is merely a trivial matter > of using to_string and passing the read string to the constructor. > > I hope that might help you to see a few simplifications to your > model, and guide others who want to take the same direction to not > spend too much time validating routines and whatnot in code they > didn't have to write. :o) I also don't want to use the bitset templates because I don't like the extra overhead involved above and beyond the extra overhead I'm already getting the way I do it. Having looked at the code for the template, it's rather useful generally but I would end up gutting it anyway just to get an optimized version. > I might just add that using c++ really can simplify a lot in places > due to the data abstraction - particularly working with linked > lists is nice compared to c. I want to remain as close to the original in style and thought as possible, while twisting it to my own strange goals. :) Part of the goal is to make it extremely easy to port in whatever latest changes are released in a patch level, and make sharing code from this codebase easier with the general public who haven't made sweeping changes. I've put a lot of work into maintaining compatibility while extending overall capabilities, and using C++isms anywhere but in the guts of the bitvect logic does not appeal to me. -- Elie Rosenblum That is not dead which can eternal lie, http://www.cosanostra.net And with strange aeons even death may die. Admin / Mercenary / System Programmer - _The Necronomicon_ -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | | Newbie List: http://groups.yahoo.com/group/circle-newbies/ | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/25/03 PDT