11 Feb, 2011, Thinoth wrote in the 1st comment:
Votes: 0
Hey guys, having a bit of trouble with this error. Not a big fan of lvalue errors too much… So from the top, this is what I know.

cygwin said:
effect.c:4817: error: lvalue required as left opperand of assignment


I know that lvalue errors are an error with the equasion set in the code. Here is the equasion

(int) item_mana = mana2;


Once again this worked at one time so I am not entely sure what the problem is. The book I have on C basicly says when you compile a lvalue error to go cry in a corner.

There are two errors in this function I will Hi-light the one that I am working on. The entire function is as follows:
inline OBJ_DATA* get_mobj(CHAR_DATA* ch, int* mana, bool both)
{
OBJ_DATA* obj;
OBJ_DATA* prim;
OBJ_DATA* sec;

int item_mana = 0;
int mana1 = 0;
int mana2 = 0;

//This is where we check for the items.
if ((prim = get_eq_char(ch, WEAR_WIELD)) != NULL)
mana1 = is_mcharged(prim);


if ((sec = get_eq_char(ch, WEAR_HOLD)) != NULL)
mana2 = is_mcharged(sec);
else if ((sec = get_eq_char(ch, WEAR_SECONDARY)) != NULL)
mana2 = is_mcharged(sec);

//check if the items are even charged.
if ((mana1 < 1) && (mana2 < 1) )
return NULL;

//check if both items are loaded.
if (mana1 > 0 && mana2 > 0 && both)
{
//we destroy the object with more mana
if (mana1 >= mana2)
{
act("As you tap into your mana pools $p begins to emit a high pitched noise and explodes!", ch, prim, NULL, TO_CHAR);
act("Suddenly $p beggins to shiver and emit a high pitched sound, exploding in $n's hands!.", ch, prim, NULL, TO_ROOM);
mana_flare(ch, mana1);
extract_obj(prim);
//set the object to use the one left over.
obj = sec;
THIS LINE—>>> (int) item_mana = mana2;[/color] <—THIS LINE
}//and if mana1
else
{
act("As you tap into your mana pools $p begins to emit a high pitched noise and explodes!", ch, sec, NULL, TO_CHAR);
act("Suddenly $p beggins to shiver and emit a high pitched sound, exploding in $n's hands!.", ch, sec, NULL, TO_ROOM);
mana_flare(ch, mana2);
extract_obj(sec);
//set the object to use the one left over.
obj = prim;
(int) item_mana = mana1;
}//end else
}//end if mana1&&mana2
else
{
//only one item was charged we check which.
if (mana1 > 1)
{obj = prim; (int) item_mana = mana1;}
else
{obj = sec; (int) item_mana = mana2;}
}//end else

//DEBUG
// sendf(ch, "`3Prim charge:%d Sec Charge:%d Return Charge: %d\n\r``", mana1, mana2, (int)item_mana);

*mana = item_mana;
return obj;
}


It should also be noted that I didnt write this line of code. I am not sure what the protocals are on giving credit in this fassion but it was done by Viri
11 Feb, 2011, Tyche wrote in the 2nd comment:
Votes: 0
should be:
item_mana = mana2;
not
(int) item_mana = mana2;
12 Feb, 2011, Thinoth wrote in the 3rd comment:
Votes: 0
Really? its that simple? Really wish there was a smiley bashing its head into the wall right now… Ok now the question that I dread asking because I will look like an idiot, why shouldnt it be there?

Not that I want to seem like I am questioning it, I just want to know so I dont have to keep bugging you guys and I truly want to learn and understand.
12 Feb, 2011, Runter wrote in the 4th comment:
Votes: 0
A) the type is understood. B) you don't cast like that.

So really the question should be "Why should you?" Once you realize what the casting is doing you'll see it just doesn't make sense.

int i;
(int) i = 10; // there's no need to cast it like this even if it were valid code.


int i;
i = 10; // valid


Typically the reason things are cast is when you want to specify the type of arbitrary data.

void *c = (void*)10;
printf("\n%d", (int)c);


The above isn't very practical but it clearly shows forcing the data to fit the types expected. All in all, there's few places you must cast. There's actually a lot of places casting is dirty.

Also, once you understand the relationship between data and variables for what variables really are things start to get much clearer.
12 Feb, 2011, Thinoth wrote in the 5th comment:
Votes: 0
Cool, I think I got it. I hope it pops up again later so I test myself :tongue:

Thank you again everyone.
12 Feb, 2011, Tyche wrote in the 6th comment:
Votes: 0
Thinoth said:
Really? its that simple? Really wish there was a smiley bashing its head into the wall right now… Ok now the question that I dread asking because I will look like an idiot, why shouldnt it be there?

Not that I want to seem like I am questioning it, I just want to know so I dont have to keep bugging you guys and I truly want to learn and understand.


Welll the actual conversion from old gcc code to gcc 4.x code is…
(type) x = n;
*(type*)&x = n;

I recognized that since x and n were both int in the code, it was meaningless anyway.
However, I couldn't say with certainty that it was meaningless in prior iterations of the code.
Under the C specification this was always undefined behavior, however some compiler implementations did do things with it.
I cannot remember what, but it affected the bit patterns in the result.

You'll sometimes see:
int i;
(unsigned int) i = something;

In which case you should use the conversion above.
12 Feb, 2011, Vigud wrote in the 7th comment:
Votes: 0
0.0/7