30 Jan, 2009, Banner wrote in the 1st comment:
Votes: 0
I'm using SWRFUSS 1.2 and attempting to add extended bitvectors. I've looked at the code from 3 separate codebases and I'm pretty sure I've copied the code correctly, IE the macros, definitions, and typedef structures in mud.h, the code from misc.c, but I seem to be missing something as I'm getting this error:

make -s swreality
Compiling o/act_comm.o….
In file included from act_comm.c:27:
mud.h:1904: error: field `speaks' has incomplete type
mud.h:1905: error: field `speaking' has incomplete type
mud.h:2037: error: field `speaks' has incomplete type
mud.h:2038: error: field `speaking' has incomplete type



int attacks;
int defenses;
EXT_BV speaks; // 1904
EXT_BV speaking; // 1905
short position;
short defposition;


Anyone have any clue what I may have missed to generate this error?
30 Jan, 2009, Kayle wrote in the 2nd comment:
Votes: 0
This probably isn't the answer you're looking for.. But it'll be less of a headache for you to upgrade to g++ and use std::bitset to handle your flags. It's a lot more diverse, and there's no limit (that I've found) to the number of flags you can have in a single bitset. Also, it's just easier to remember and you don't need bulky macros.

xIS_SET( ch->speaks, LANG_TWILEK );

vs.
ch->speaks.test( LANG_TWILEK );


I like the second one. Even if it does require some additional work.
30 Jan, 2009, Banner wrote in the 3rd comment:
Votes: 0
My C++ isn't as good as my C. :-/
30 Jan, 2009, Lobotomy wrote in the 4th comment:
Votes: 0
It sounds to me as though the struct information for the EXT_BV is not being included in mud.h. I.e, the compiler is telling you that mud.h is telling you that it doesn't know what type "EXT_BV" is; it wants that information. You should check and see where EXT_BV is defined.

I may be wrong, but considering the limited information you've given all I can do is guess.
30 Jan, 2009, Banner wrote in the 5th comment:
Votes: 0
Lobotomy said:
It sounds to me as though the struct information for the EXT_BV is not being included in mud.h. I.e, the compiler is telling you that mud.h is telling you that it doesn't know what type "EXT_BV" is; it wants that information. You should check and see where EXT_BV is defined.

I may be wrong, but considering the limited information you've given all I can do is guess.


typedef struct extended_bitvector EXT_BV;


Already done. And I've given as much information as I can without c&ping every define and declaration I've posted. If you need more information, ask, or simply give me a list of spots I may have missed.
30 Jan, 2009, Lobotomy wrote in the 6th comment:
Votes: 0
Banner said:
Already done. And I've given as much information as I can without c&ping every define and declaration I've posted. If you need more information, ask, or simply give me a list of spots I may have missed.

Not just the typedef line; it also needs the actual struct "extended_bitvector". Have you made sure to include that information in mud.h?
30 Jan, 2009, Banner wrote in the 7th comment:
Votes: 0
Lobotomy said:
Banner said:
Already done. And I've given as much information as I can without c&ping every define and declaration I've posted. If you need more information, ask, or simply give me a list of spots I may have missed.

Not just the typedef line; it also needs the actual struct "extended_bitvector". Have you made sure to include that information in mud.h?


/*
* Defines for extended bitvectors
*/
#ifndef INTBITS
#define INTBITS 32
#endif
#define XBM 31 /* extended bitmask ( INTBITS - 1 ) */
#define RSV 5 /* right-shift value ( sqrt(XBM+1) ) */
#define XBI 4 /* integers in an extended bitvector */
#define MAX_BITS XBI * INTBITS

/*
* Structure for extended bitvectors – Thoric
*/
struct extended_bitvector
{
int bits[XBI];
};
30 Jan, 2009, Kayle wrote in the 8th comment:
Votes: 0
Banner said:
My C++ isn't as good as my C. :-/


They're the same thing. C++ just has the STL. And it's a little stricter.
30 Jan, 2009, Banner wrote in the 9th comment:
Votes: 0
Kayle said:
Banner said:
My C++ isn't as good as my C. :-/


They're the same thing. C++ just has the STL. And it's a little stricter.

I've seen a C++ base before and it looked a lot different from C.
30 Jan, 2009, Lobotomy wrote in the 10th comment:
Votes: 0
Ok, I see that you've defined the struct. However, here's the kicker: Did you define it before or after the "speaks" and "speaking" variables within mud.h? If you've defined it after that code, the code ahead of it won't have the type information available to it.
30 Jan, 2009, Kayle wrote in the 11th comment:
Votes: 0
Uh.. The current FUSS bases are in C++ we just don't utilize all of the C++ Features. Like Polymorphism, Inheritance, and it's certainly not Object Oriented. The only difference between C and C++ is that C++ has the STL to make life easier, and it's support for object orientation.

Anything compiling under g++ is utilizing the C++ standards. It's all the same.
30 Jan, 2009, Banner wrote in the 12th comment:
Votes: 0
Lobotomy said:
Ok, I see that you've defined the struct. However, here's the kicker: Did you define it before or after the "speaks" and "speaking" variables within mud.h? If you've defined it after that code, the code ahead of it won't have the type information available to it.

Great, never even bothered to check that. Much thanks, Lobotomy.
30 Jan, 2009, Lobotomy wrote in the 13th comment:
Votes: 0
No problem. :smile:
30 Jan, 2009, Kayle wrote in the 14th comment:
Votes: 0
Banner said:
I've seen a C++ base before and it looked a lot different from C.


Wait, Are you talking about things like…
/*
* It is very important that this be an equivalence relation:
* (1) A ~ A
* (2) if A ~ B then B ~ A
* (3) if A ~ B and B ~ C, then A ~ C
*/
bool is_same_group( CharData * ach, CharData * bch )
{
if( ach->getLeader( ) )
ach = ach->getLeader( );
if( bch->getLeader( ) )
bch = bch->getLeader( );
return ach == bch;
}


versus
/*
* It is very important that this be an equivalence relation:
* (1) A ~ A
* (2) if A ~ B then B ~ A
* (3) if A ~ B and B ~ C, then A ~ C
*/
bool is_same_group( CHAR_DATA * ach, CHAR_DATA * bch )
{
if( ach->leader )
ach = ach->leader;
if( bch->leader )
bch = bch->leader;
return ach == bch;
}



These are the same thing. They do exactly the same thing. The first one is just from my base, where I utilize encapsulation. Which is possible to some extent in C. I just don't think you can do member functions in C where you can in C++.
30 Jan, 2009, Banner wrote in the 15th comment:
Votes: 0
Kayle said:
Banner said:
I've seen a C++ base before and it looked a lot different from C.


Wait, Are you talking about things like…
/*
* It is very important that this be an equivalence relation:
* (1) A ~ A
* (2) if A ~ B then B ~ A
* (3) if A ~ B and B ~ C, then A ~ C
*/
bool is_same_group( CharData * ach, CharData * bch )
{
if( ach->getLeader( ) )
ach = ach->getLeader( );
if( bch->getLeader( ) )
bch = bch->getLeader( );
return ach == bch;
}


versus
/*
* It is very important that this be an equivalence relation:
* (1) A ~ A
* (2) if A ~ B then B ~ A
* (3) if A ~ B and B ~ C, then A ~ C
*/
bool is_same_group( CHAR_DATA * ach, CHAR_DATA * bch )
{
if( ach->leader )
ach = ach->leader;
if( bch->leader )
bch = bch->leader;
return ach == bch;
}



These are the same thing. They do exactly the same thing. The first one is just from my base, where I utilize encapsulation. Which is possible to some extent in C. I just don't think you can do member functions in C where you can in C++.


No, it wasn't that. I can't even remember what codebase I seen it in. Maybe AFKMUD? But it was quite different.
30 Jan, 2009, Kayle wrote in the 16th comment:
Votes: 0
AFKMud makes heavy use of the STL. And yes, heavy use of the STL will make the code look foreign, but I assure you, it makes life a whole lot easier.
30 Jan, 2009, Banner wrote in the 17th comment:
Votes: 0
It'd probably be worth my while to learn it, then. ^_^ But you say it's basically the same, just easier?
30 Jan, 2009, Kayle wrote in the 18th comment:
Votes: 0
Once you get the hang of the way the use of the STL looks, yes, it's a lot easier. And in most cases safer.
30 Jan, 2009, Lobotomy wrote in the 19th comment:
Votes: 0
You know, the way you guys pounce on anyone using C, trying to coerce them into using C++, really makes it look like some kind of freakish cult. Do I have to start calling you the Plus's Witnesses? :tongue:
30 Jan, 2009, David Haley wrote in the 20th comment:
Votes: 0
Don't worry Lobotomy, you will be assimilated… eventually…
0.0/77