Re: PRF & PLR flags max 32?

From: Elie Rosenblum (
Date: 01/20/02

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,   And with strange aeons even death may die.
Admin / Mercenary / System Programmer             - _The Necronomicon_

   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT