Is there a maximum number of affected_by_types you can have, specifically in smaugfuss? .........................
-= DB =-
Nova, an original Science Fiction MUD based on SmaugFUSS

if it is an EXT_BV (which I think the one you mean, is) it's limit is 128 unless you change your EXT_BV to make it handle more .........................
Remcon
Lands of Pabulum

Heh. One of these days we should surprise people with an update to std::bitset but keep the existing macros - unlimited bitvectors without completely messing up the codebase .........................
PDNS-Admin | Sandbox | Arthmoor MUD Hosting Services | The Truth About Medievia: A Saga of Code Theft.

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984

That sounds like a good one to do man Can't wait to see that one lol .........................
Remcon
Lands of Pabulum

I'd second that vote behind Remcon's first, especially if you could figure out how to get it to still compile under gcc rather than g++...

Actually, if I could ever get around to catching up enough with the stuff I feel is more important so I could get around to making my cde compile cleanly under g++ then I'd still consider this a worthwhile idea even the way you intended.

I suppose it'd get classified as a improvement rather than a bug fix, but it could still be a FUSS thing as much as hotboot and some of our other past improvements. .........................
-=Conner=-

Administrator/Coder Primary SysOp
Land of Legends The Castle's Dungeon BBS

telnet://tcdbbs.zapto.org:4000 telnet://tcdbbs.zapto.org:23

std::bitset is part of the C++ STL, so no dice on getting that to work with gcc. .........................
PDNS-Admin | Sandbox | Arthmoor MUD Hosting Services | The Truth About Medievia: A Saga of Code Theft.

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984

Bah, it was worth asking.. like I said, I still think it'd be a good idea, just means that I've got to get around to making my own codebase be able to compile cleanly under g++ sooner. .........................
-=Conner=-

Administrator/Coder Primary SysOp
Land of Legends The Castle's Dungeon BBS

telnet://tcdbbs.zapto.org:4000 telnet://tcdbbs.zapto.org:23

You don't need to use C++ to have a sane bitset implementation. C++ makes it easier, but it's not as if the SMAUG bitsets (even extended bitsets) are the epitome of good design in C. .........................
David Haley
Head Coder, Legends of the Darkstone
BabbleMUD Project
http://david.the-haleys.org

I've taken classes in cobol, fortran, pascal, and for microsoft/comptia certifications, and possibly a few others in the past, but I'm mostly self-taught in C. Should I ask what the best solution would be then? I thought Samson's idea sounded great, but that it'd mean making my code be able to compile under g++, which isn't the same thing as saying that I'm going to convert my full codebase to C++ either, btw. .........................
-=Conner=-

Administrator/Coder Primary SysOp
Land of Legends The Castle's Dungeon BBS

telnet://tcdbbs.zapto.org:4000 telnet://tcdbbs.zapto.org:23

The best solution would be to replace the internal macros with std::bitset usage instead of the EXT_BV stuff. That could also be extended to the standard BV macros as well and in keeping things just to that the rest of the codebase would just chug along as though nothing happened. Except in cases where converting the bits is going to piss things off, like the affect_data structures. .........................
PDNS-Admin | Sandbox | Arthmoor MUD Hosting Services | The Truth About Medievia: A Saga of Code Theft.

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984

Not knowing any C++ really, I can't argue that point, but I really meant within the confines of C since David seemed to be implying that there was a better way to handle affects and such than with bitsets. .........................
-=Conner=-

Administrator/Coder Primary SysOp
Land of Legends The Castle's Dungeon BBS

telnet://tcdbbs.zapto.org:4000 telnet://tcdbbs.zapto.org:23

Well, no. I was just saying that you can get a lot of the benefits while staying in C-land. Going to C++ is a far superior solution in many respects. The only disadvantage really is that it requires learning something new, which takes some time. .........................
David Haley
Head Coder, Legends of the Darkstone
BabbleMUD Project
http://david.the-haleys.org

Oh, I thought you were saying that there was a way to improve things like this while still within the confines of C, otherwise I'm already resolved to the eventuality of trying to learn enough about C++ to be able to at least make my code compile under g++ instead of gcc so that I can begin to incorporate things like std::bitset as a replacement for EXT_BV, but in the meanwhile I'll continue to make do with what I've got. .........................
-=Conner=-

Administrator/Coder Primary SysOp
Land of Legends The Castle's Dungeon BBS

telnet://tcdbbs.zapto.org:4000 telnet://tcdbbs.zapto.org:23

Err... yes... you can improve things like this without leaving C.


You won't get all the benefits, but you can sure improve an awful lot over the current situation. It's very possible to have OOP in C, it's just not as nice.

To illustrate,
obj->method()
can be written as
method(obj)
which can be implemented as a plain old C function.

Basically, make a proper interface to the bitvectors, encapsulate the array of bits, and then the interface functions can do all the nice things you would want them to do, including e.g. automatically growing the bitvector, or allocating more than 32 or 128 or whatever. .........................
David Haley
Head Coder, Legends of the Darkstone
BabbleMUD Project
http://david.the-haleys.org

Geez David, make up your mind already, will ya'?


Um, okay, you've lost me. Allow me to reiterate:




Can you explain any of that to someone who hasn't taken formal classes in programming within the last two decades and who isn't working professionally as a programmer... like me? .........................
-=Conner=-

Administrator/Coder Primary SysOp
Land of Legends The Castle's Dungeon BBS

telnet://tcdbbs.zapto.org:4000 telnet://tcdbbs.zapto.org:23

The problem with the way bitvectors are currently implemented is that they're manipulated through low-level routines that don't distinguish between the intent and the implementation. When you have a set of flags, you shouldn't have to worry about whether or not it's a simple array, an int, an EXT_BV, or whatever. The point is that you should only have to worry about the following high-level operations:
- Is bit X set?
- Set bit X
- Clear bit X

You would do something like this:

struct BitVector {
  char* bits;
  size_t numBytes;
};

BitVector* bv_new(size_t size);
void bv_delete(BitVector* bv);
bool bv_is_set(const BitVector* bv, int bit);
void bv_set_bit(BitVector* bv, int bit, bool value);

And now you no longer have to worry about any of the internal details, and everything "just works" once those (very simple) functions are written. Ideally, nobody except for the above four functions would ever touch the 'bits' field of BitVector objects. (C++ lets you enforce this restriction, which is one reason why it's better.)

Frankly I don't understand why the EXT_BV folks didn't do something like this in the first place, and instead just worsened the problem by doing the same thing, just with a few more bits.


(EDIT: added numBytes to structure definition) .........................
David Haley
Head Coder, Legends of the Darkstone
BabbleMUD Project
http://david.the-haleys.org

I considered doing something similar to this long ago but I thought it would be to much trouble lol. I have also tried once to switch over to C++ bitset, that one is annoying lol. I might give this way a shot sometime. .........................
Remcon
Lands of Pabulum

Ok, you've got more than just my attention now, David. This sounds like a really good thing (and, yes, it makes sense to me now), but I don't quite fully follow how it'd be implimented, though if Remcon's considering giving it a try, maybe he'd share...

...and, Remcon, if you do, feel free to share your findings (as well as the four functions David mentioned, if you're willing) so the rest of us can benefit from it. Frankly, if it's that much of an improvement, maybe it's something that FUSS could/should impliment too, at least as an interim step between the current method and std::bitset. .........................
-=Conner=-

Administrator/Coder Primary SysOp
Land of Legends The Castle's Dungeon BBS

telnet://tcdbbs.zapto.org:4000 telnet://tcdbbs.zapto.org:23

I'll take a look at this sometime soon and see how hard it would be to start the conversion. I'm not sure how much sense it makes to do this in the main FUSS branch seeing that it's already g++-compliant (and so might as well use C++) but it should be pretty easy. But whatever happens with FUSS aside, I can provide the functions for you pretty quickly, I might have them already all written up at home somewhere. I'll see if I can find them. They weren't in the obvious spot, so I might have to do some digging. (It might be easier to just rewrite them from scratch...) .........................
David Haley
Head Coder, Legends of the Darkstone
BabbleMUD Project
http://david.the-haleys.org

Very cool, David, maybe if I can see the functions involved, I'll understand better how they'd have to be used to replace the existing ones. I'm kind of thinking, at this point, that what you're calling bv_is_set could just be installed as IS_SET and what you're calling bv_set_bit coud be installed as SET_BIT to minimize changes throughout the rest of the code. I'm not certain how you're bv_new & bv_delete compare directly to REMOVE_BIT & TOGGLE_BIT... but once I can see where you're going with it, perhaps things will become more clear to me. .........................
-=Conner=-

Administrator/Coder Primary SysOp
Land of Legends The Castle's Dungeon BBS

telnet://tcdbbs.zapto.org:4000 telnet://tcdbbs.zapto.org:23