Jump to content
Eternal Lands Official Forums
Sign in to follow this  
Grum

C Question, Map Editor

Recommended Posts

   Dir[dc].Names[Dir[dc].nf][i]=temp[i++];

a) who is responsible for this piece of beauty?

B) when is i supposed to be incremented, before or after the assignment has taken place?

Share this post


Link to post
Share on other sites

a- O_O Really descriptive variable names, I'm guessing that comes from the browser, and therefore must be sadez's... But I can guarantee it's not mine B)

b- And i is and should be incremented after the assignment, as in almost any assignment of this type... I use that method all the time B)

Edited by crusadingknight

Share this post


Link to post
Share on other sites

ad B) if you really use i on both the left and the right hand side of the assignment in this construct, you should no longer be allowed to touch a computer. Or look at it, for that matter.

 

Here's another pretty one, i personlly kinda like it B)

   if(mouse_x < win->pos_x+win->len_x-20 && mouse_x > win->pos_x+win->len_x
     && mouse_y > win->pos_y && mouse_y < win->pos_y+20)

Share this post


Link to post
Share on other sites
   Dir[dc].Names[Dir[dc].nf][i]=temp[i++];

For the possibility to use such constructs without forcing the compiler to suicide I really love C :P

Share this post


Link to post
Share on other sites
Dir[dc].Names[Dir[dc].nf]=temp[i++];

That was sadez.

 

if(mouse_x < win->pos_x+win->len_x-20 && mouse_x > win->pos_x+win->len_x
    && mouse_y > win->pos_y && mouse_y < win->pos_y+20)

That was committed by sadez, but written by crusadingknight.

Share this post


Link to post
Share on other sites
ad B) if you really use i on both the left and the right hand side of the assignment in this construct, you should no longer be allowed to touch a computer. Or look at it, for that matter.

Well, there goes everyone who wrote the string manipulations library :P.

 

 

Here's another pretty one, i personlly kinda like it :D

   if(mouse_x < win->pos_x+win->len_x-20 && mouse_x > win->pos_x+win->len_x
     && mouse_y > win->pos_y && mouse_y < win->pos_y+20)

158819[/snapback]

Yeah, I'll own up to that one, but it does it's job, since SOMEONE still has yet to merge in a newer version of elwindows to the map editor. :D

Share this post


Link to post
Share on other sites

Oh, I have no problem with the code (though I am cleaning it up a bit), it's the logic that's at fault here.

mouse_x < win->pos_x+win->len_x-20

but at the same time

mouse_x > win->pos_x+win->len_x

 

Anyway, not pointing fingers here, I make too many mistakes for that myself :P

Share this post


Link to post
Share on other sites

It is so easy to get those < and > backwards it is ridiculus! You should have seen some of the interesting bugs I had when I first revamped the Windows so it was really a system instead of lots of repeated code.

Share this post


Link to post
Share on other sites

I agree, we should got to a system like

IF(MOUSEX.LT.WPOSX+WLENX-20.AND.MOUSEX.GT.WPOSX+WLENX)THEN

and we'll never make this mistake again :D

Share this post


Link to post
Share on other sites

if and (<) mouse_x (-) (+) (->) win pos_x (->) win len_x 20 (>) mouse_x (+) (->) win pos_x (->) win len_x

:twisted: *

 

*) We need more emoticons :D

Share this post


Link to post
Share on other sites
if and (<) mouse_x (-) (+) (->) win pos_x (->) win len_x 20 (>) mouse_x (+) (->) win pos_x (->) win len_x

:twisted: *

 

*) We need more emoticons :)

159030[/snapback]

Lol. Took me a while to decipher because the (->) set me on the wrong track, but cute. very cute.

Share this post


Link to post
Share on other sites
Dir[dc].Names[Dir[dc].nf][i]=temp[i++];

 

This is undefined behaviour and a bad thing. Undefined behaviour means the compiler is free to make anything it wants including setting fire to your house :) , so this should be avoided.

Share this post


Link to post
Share on other sites
Oh, I have no problem with the code (though I am cleaning it up a bit), it's the logic that's at fault here.

mouse_x < win->pos_x+win->len_x-20

but at the same time

mouse_x > win->pos_x+win->len_x

 

Anyway, not pointing fingers here, I make too many mistakes for that myself :P

158879[/snapback]

That essentially means "If we've not clicked on the little x" :o

Share this post


Link to post
Share on other sites

Then I guess it should be

if(mouse_x < win->pos_x+win->len_x-20 /* && mouse_x > win->pos_x+win->len_x

      && mouse_y > win->pos_y && */||  mouse_y > win->pos_y+20)

 

P.S. Grum was faster than me :o

Edited by Lachesis

Share this post


Link to post
Share on other sites

Lol...too much discussion for a piece of code which

a) always returns false

B) if corrected, never occurs because clicking on the close button is caught earlier :D

 

EDIT: B) is not correct, it will still evaluate this piece of code.

Edited by Grum

Share this post


Link to post
Share on other sites

Just to get back to the original code snippet:

   Dir[dc].Names[Dir[dc].nf][i]=temp[i++];

Simplified:

   f[i] = g[i++];

 

This is a classic example of undefined behaviour. While the expression 'i++' evaluates to the prior value of 'i', the incrementation of 'i' can occur anywhere between the previous and next sequence points. Therefore, the value of 'i' used on the rhs is undefined.

 

It may produce the desired behaviour under certain sets of conditions (compiler, version, optimisations), but there is no guarentee that it will always do so.

 

 

Reference: ISO C standard, sections 6.5 (P2), 6.5.2.4 (P2).

 

Reference: Reasonable article on sequence points.

 

 

Update (observation):

My installation of EL (gentoo linux) suffers from the 'missing letters' problem in a lot of the text (not all text windows, just the major ones inc. chat). The symptoms of this are any character in the first column of the font bitmap is rendered as a blank space, and some other characters have slight errors (pixels missing).

 

According to disussion on these forums, a work around is to compile without optimisation. This behaviour is exactly as one would expect from code containing undefined behaviour like this... Particularly since this lookes like an obtuse integer error.

 

Currently I just run a console with 'tail -f .elc/chat.txt' to get around the chat side...

Edited by trollson

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×