Dev-C++ ignoring new code

[Anonymous]

I've looked and looked and can't seem to find the answer to this, so please forgive me if the answer exists and I overlooked it somehow.

Ok, so I wrote some code, ran it, it didn't work the way I expected, I fixed it, and now the old code is still running. I've had this trouble with Microsoft's compiler before (fixed by closing and reopening the program), but never with Dev-C++. I've closed and reopened, did execute>rebuild all, execute>clean, and even rebooted my computer. Nothing changed in between this working and not working as all the other code I added before this ran (as it should). Now I'm worried that I'm going to lose my couple years of progress on my almost completed game! Please help! Thanks in advance.

[Anonymous]

Sorry for the long response time. I appreciate that you've been keeping up with me on a regular basis. I just had other (non-programming) issues.

Anyway... thanks for the link. However, this leads to another twist. I already did that. Simply because I was taught to do that. Now I know what it's there for and what it does! Yippie! I hate it when books tell you to do something and never tell you why. Ever since the beginning of this project I had:

ifndef _NEATO_H

define _NEATO_H

and the...

endif

I realize the _NAME_H is different than the H_NAME, but I tried the H_NAME and that didn't work either. Now when I compile, it says that all the variables are being redeclared and this is the line of code every error is pointing to:

textprintf(buffer, font, 10, 15, WHITE, "stage:%d", player->stage);

Which is just the last line of the deprecate textprintf. Although technically the compiler says the problem is line 147 (which is the following line, which is blank), it points to this line when double-clicked. It points to this as the first AND multiple declarations of every variable it seems. Now I'm tempted to reinstall my Microsoft compiler again and try the project on that. And before you ask why I uninstalled my Microsoft compiler in favor of Dev-C++, I'll just keep it short and say I had my reasons. But I digress... happen to have any more suggestions?

[cpns]

> I realize the _NAME_H is different than the H_NAME, but I
> tried the H_NAME and that didn't work either.

The name of the macro is irrelevant, so long as it is unique for each header file.

> Now when I compile, it says that all the variables are being redeclared

You know by now to post the log rather than describe the output!

> Now I'm tempted to reinstall my Microsoft compiler again and try the project on that

If you had that, that is what I'd have used from the beginning! However, this is not a compiler problem, it is your code; we just havent figured out what yet. You may have to post the code - although I appreciate that it is large. Perhaps you can zip it and post it to some accessible server?

What version/edition of MSVC++ are you planning to use? VC++2008 Express Edition is free you know?

Clifford

[Anonymous]

"You know by now to post the log rather than describe the output!"

Sorry, just figured it'd be too long because it brings up two issues for many of the variables. But here it is:

Compiler: Default compiler
Building Makefile: "D:\Programs\Games\Neato\Neato\Makefile.win"
Executing make...
make.exe -f "D:\Programs\Games\Neato\Neato\Makefile.win" all
gcc.exe -c main.c -o main.o -I"H:/Programming/Dev-Cpp/include" -DALLEGRO_STATICLINK

gcc.exe main.o logic.o draw.o save.o stages.o Neato_private.res -o "Neato.exe" -L"H:/Programming/Dev-Cpp/lib" -mwindows -lalleg_s -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lole32 -ldinput -lddraw -ldxguid -lwinmm -ldsound

logic.o(.data+0x0):logic.c: multiple definition of music' main.o(.data+0x0):main.c: first defined here logic.o(.data+0x4):logic.c: multiple definition ofvoice'
main.o(.data+0x4):main.c: first defined here
logic.o(.data+0x8):logic.c: multiple definition of fx' main.o(.data+0x8):main.c: first defined here logic.o(.rdata+0x0):logic.c: multiple definition ofKEY_DELAY'
main.o(.rdata+0x0):main.c: first defined here
logic.o(.rdata+0x4):logic.c: multiple definition of EXIT_MODE' main.o(.rdata+0x4):main.c: first defined here logic.o(.rdata+0x8):logic.c: multiple definition ofMENU_MODE'
main.o(.rdata+0x8):main.c: first defined here
logic.o(.rdata+0xc):logic.c: multiple definition of LOAD_MODE' main.o(.rdata+0xc):main.c: first defined here logic.o(.rdata+0x10):logic.c: multiple definition ofPLAY_MODE'
main.o(.rdata+0x10):main.c: first defined here
logic.o(.rdata+0x14):logic.c: multiple definition of `PLAY_RESTART_MODE'

main.o(.rdata+0x14):main.c: first defined here

logic.o(.rdata+0x18):logic.c: multiple definition of PLAY_EXIT_MODE' main.o(.rdata+0x18):main.c: first defined here logic.o(.rdata+0x1c):logic.c: multiple definition ofSCORES_MODE'
main.o(.rdata+0x1c):main.c: first defined here
logic.o(.rdata+0x20):logic.c: multiple definition of `OPTIONS_MODE'

main.o(.rdata+0x20):main.c: first defined here

logic.o(.rdata+0x24):logic.c: multiple definition of CREDITS_MODE' main.o(.rdata+0x24):main.c: first defined here logic.o(.rdata+0x28):logic.c: multiple definition ofNEW_MODE'
main.o(.rdata+0x28):main.c: first defined here
logic.o(.rdata+0x2c):logic.c: multiple definition of WIN_MODE' main.o(.rdata+0x2c):main.c: first defined here logic.o(.rdata+0x30):logic.c: multiple definition ofMAX_STARS'
main.o(.rdata+0x30):main.c: first defined here
logic.o(.bss+0x0):logic.c: multiple definition of temp_rotate' main.o(.bss+0x0):main.c: first defined here logic.o(.rdata+0x34):logic.c: multiple definition ofFADE'
main.o(.rdata+0x34):main.c: first defined here
draw.o(.data+0x0):draw.c: multiple definition of music' main.o(.data+0x0):main.c: first defined here draw.o(.data+0x4):draw.c: multiple definition ofvoice'
main.o(.data+0x4):main.c: first defined here
draw.o(.data+0x8):draw.c: multiple definition of fx' main.o(.data+0x8):main.c: first defined here draw.o(.rdata+0x0):draw.c: multiple definition ofKEY_DELAY'
main.o(.rdata+0x0):main.c: first defined here
draw.o(.rdata+0x4):draw.c: multiple definition of EXIT_MODE' main.o(.rdata+0x4):main.c: first defined here draw.o(.rdata+0x8):draw.c: multiple definition ofMENU_MODE'
main.o(.rdata+0x8):main.c: first defined here
draw.o(.rdata+0xc):draw.c: multiple definition of LOAD_MODE' main.o(.rdata+0xc):main.c: first defined here draw.o(.rdata+0x10):draw.c: multiple definition ofPLAY_MODE'
main.o(.rdata+0x10):main.c: first defined here
draw.o(.rdata+0x14):draw.c: multiple definition of PLAY_RESTART_MODE' main.o(.rdata+0x14):main.c: first defined here draw.o(.rdata+0x18):draw.c: multiple definition ofPLAY_EXIT_MODE'
main.o(.rdata+0x18):main.c: first defined here
draw.o(.rdata+0x1c):draw.c: multiple definition of SCORES_MODE' main.o(.rdata+0x1c):main.c: first defined here draw.o(.rdata+0x20):draw.c: multiple definition ofOPTIONS_MODE'
main.o(.rdata+0x20):main.c: first defined here
draw.o(.rdata+0x24):draw.c: multiple definition of CREDITS_MODE' main.o(.rdata+0x24):main.c: first defined here draw.o(.rdata+0x28):draw.c: multiple definition ofNEW_MODE'
main.o(.rdata+0x28):main.c: first defined here
draw.o(.rdata+0x2c):draw.c: multiple definition of WIN_MODE' main.o(.rdata+0x2c):main.c: first defined here draw.o(.rdata+0x30):draw.c: multiple definition ofMAX_STARS'
main.o(.rdata+0x30):main.c: first defined here
draw.o(.bss+0x0):draw.c: multiple definition of temp_rotate' main.o(.bss+0x0):main.c: first defined here draw.o(.rdata+0x34):draw.c: multiple definition ofFADE'
main.o(.rdata+0x34):main.c: first defined here
save.o(.data+0x0):save.c: multiple definition of music' main.o(.data+0x0):main.c: first defined here save.o(.data+0x4):save.c: multiple definition ofvoice'

main.o(.data+0x4):main.c: first defined here
save.o(.data+0x8):save.c: multiple definition of fx' main.o(.data+0x8):main.c: first defined here save.o(.rdata+0x0):save.c: multiple definition ofKEY_DELAY'
main.o(.rdata+0x0):main.c: first defined here
save.o(.rdata+0x4):save.c: multiple definition of `EXIT_MODE'

main.o(.rdata+0x4):main.c: first defined here
save.o(.rdata+0x8):save.c: multiple definition of MENU_MODE' main.o(.rdata+0x8):main.c: first defined here save.o(.rdata+0xc):save.c: multiple definition ofLOAD_MODE'
main.o(.rdata+0xc):main.c: first defined here
save.o(.rdata+0x10):save.c: multiple definition of PLAY_MODE' main.o(.rdata+0x10):main.c: first defined here save.o(.rdata+0x14):save.c: multiple definition ofPLAY_RESTART_MODE'
main.o(.rdata+0x14):main.c: first defined here
save.o(.rdata+0x18):save.c: multiple definition of PLAY_EXIT_MODE' main.o(.rdata+0x18):main.c: first defined here save.o(.rdata+0x1c):save.c: multiple definition ofSCORES_MODE'
main.o(.rdata+0x1c):main.c: first defined here
save.o(.rdata+0x20):save.c: multiple definition of OPTIONS_MODE' main.o(.rdata+0x20):main.c: first defined here save.o(.rdata+0x24):save.c: multiple definition ofCREDITS_MODE'

main.o(.rdata+0x24):main.c: first defined here

save.o(.rdata+0x28):save.c: multiple definition of NEW_MODE' main.o(.rdata+0x28):main.c: first defined here save.o(.rdata+0x2c):save.c: multiple definition ofWIN_MODE'
main.o(.rdata+0x2c):main.c: first defined here
save.o(.rdata+0x30):save.c: multiple definition of MAX_STARS' main.o(.rdata+0x30):main.c: first defined here save.o(.bss+0x0):save.c: multiple definition oftemp_rotate'
main.o(.bss+0x0):main.c: first defined here
save.o(.rdata+0x34):save.c: multiple definition of FADE' main.o(.rdata+0x34):main.c: first defined here stages.o(.data+0x0):stages.c: multiple definition ofmusic'
main.o(.data+0x0):main.c: first defined here
stages.o(.data+0x4):stages.c: multiple definition of voice' main.o(.data+0x4):main.c: first defined here stages.o(.data+0x8):stages.c: multiple definition offx'
main.o(.data+0x8):main.c: first defined here
stages.o(.rdata+0x0):stages.c: multiple definition of KEY_DELAY' main.o(.rdata+0x0):main.c: first defined here stages.o(.rdata+0x4):stages.c: multiple definition ofEXIT_MODE'
main.o(.rdata+0x4):main.c: first defined here
stages.o(.rdata+0x8):stages.c: multiple definition of MENU_MODE' main.o(.rdata+0x8):main.c: first defined here stages.o(.rdata+0xc):stages.c: multiple definition ofLOAD_MODE'
main.o(.rdata+0xc):main.c: first defined here
stages.o(.rdata+0x10):stages.c: multiple definition of PLAY_MODE' main.o(.rdata+0x10):main.c: first defined here stages.o(.rdata+0x14):stages.c: multiple definition ofPLAY_RESTART_MODE'
main.o(.rdata+0x14):main.c: first defined here
stages.o(.rdata+0x18):stages.c: multiple definition of PLAY_EXIT_MODE' main.o(.rdata+0x18):main.c: first defined here stages.o(.rdata+0x1c):stages.c: multiple definition ofSCORES_MODE'
main.o(.rdata+0x1c):main.c: first defined here
stages.o(.rdata+0x20):stages.c: multiple definition of OPTIONS_MODE' main.o(.rdata+0x20):main.c: first defined here stages.o(.rdata+0x24):stages.c: multiple definition ofCREDITS_MODE'
main.o(.rdata+0x24):main.c: first defined here
stages.o(.rdata+0x28):stages.c: multiple definition of NEW_MODE' main.o(.rdata+0x28):main.c: first defined here stages.o(.rdata+0x2c):stages.c: multiple definition ofWIN_MODE'
main.o(.rdata+0x2c):main.c: first defined here
stages.o(.rdata+0x30):stages.c: multiple definition of MAX_STARS' main.o(.rdata+0x30):main.c: first defined here stages.o(.bss+0x0):stages.c: multiple definition oftemp_rotate'
main.o(.bss+0x0):main.c: first defined here
stages.o(.rdata+0x34):stages.c: multiple definition of `FADE'
main.o(.rdata+0x34):main.c: first defined here
collect2: ld returned 1 exit status

make.exe: *** [Neato.exe] Error 1

Execution terminated

"Perhaps you can zip it and post it to some accessible server?"

Here ya go... all code and the data file with the graphics:
http://rapidshare.com/files/144694960/neato.zip.html
Good luck to you if you decide to try and look through. Although I do try to keep my code organized and well commented.

"What version/edition of MSVC++ are you planning to use?"

MSVC++ 2003. Wait, '08 is free! But what do they mean "Express Edition?" Does it have any limitations? I looked it up and couldn't find anything about that. Well, then I guess that raises my next question of which you would suggest: MSVC'03 or MSVC'08 EE?

[Anonymous]

Well I got the day off from work today, and I'm trying to figure this out. Did some searching on google and found multiple websites mentioning this... "Avoid defining variables in header files." So that seems to be the problem. All variables that have been assigned a value in my header are bringing up multiple-definition errors. But I tried the fix that most people suggested ("extern int" in the header and "int" in one of the c code files) and that gives me an error of multiple declaration as well. Hmmm... getting closer, but not quite there yet. And I'm wondering how I never heard about this before if it's such an important rule.

[cpns]

You previously said "variables are being redeclared", but there is a difference between multiple declaration and multiple definition - which is why you should always post the log.

> "Avoid defining variables in header files."

Yes, if you did that, each separately compiled module that includes the header will have a copy of that variable in its object code. When the linker combines the object modules, it sees multiple instances which it cannot resolve. Otherwise each separate module would see a different copy of the variable rather than one global one.

Besides global data is indicative of poor design in any case, and you seem to have a great many of them. See this article: http://www.embedded.com/columns/breakpoint/193101156?_requestid=151258 it relates to embedded systems, but only because some embedded systems developers consider globals necessary (they are wrong), the points made apply to all software development.

> and that gives me an error of multiple declaration as well.

Which generally indicates that you do not have your include guards right.

> And I'm wondering how I never heard about this before if it's such an important rule.

A case of two wrongs cancelling each other. Your eschewing of the linker by #include'ing your .c files was hiding your other bad habits. ;-)

Example:

foo.h:

if !defined FOO_H

define FOO_H

// These are declarations only; nothing is instantiated
extern int aNastyGlobalInt ;
extern int anotherNastyGlobalInt ;

// Note the use of extern for function global
// declarations here is strictly optional, the lack of
// a function body makes it implicit.
extern int aGlobalFunction( int x ) ;

endif

---

foo.c

// include the modules own interface
// for consistency checking

include "foo.h"

int aNastyGlobalInt = -1 ; // Explicitly initialised instantiation
int anotherNastyGlobalInt ; // Implicitly initialised to zero

static int aModuleLocalVariable = 0 ; // This is visible only in this module

// Local function prototype; cannot be called outside this module
static void aModuleLocalFunction( void ) ;

// The function definition
int aGlobalFunction( int x )
{
return 0 ;
}

// The local function. Do not put 'static' here if already prototyped
void aModuleLocalFunction( void )
{

}

---

main.c

include "foo.h" // Include foo interface

int main( void )
{

// Some nonsense to use all of foo's exposed interface
anotherNastyGlobalInt = aGlobalFunction( aNastyGlobalInt ) ;

return 0 ;
}

---

> But what do they mean "Express Edition?" Does it have any limitations?

Not compared to Dev-C++. It only supports Windows Forms and .NET for visual GUI development, there are no 'visual' tools or resource editor for Win32 and no MFC, but in that respect it is no worse than Dev-C++

> I looked it up and couldn't find anything about that.

Not so easy find, but a detailed comparison is provided here: http://msdn.microsoft.com/en-gb/vs2008/products/cc149003.aspx

> I guess that raises my next question of which you would suggest: MSVC'03 or MSVC'08 EE?

It depends whether you use the tools and integration that the paid for version gives you. If you are happy to use Dev-C++ it seems unlikely. You get all the Dev-C++ has to offer, and more. Most importantly you get a first class usable debugger. In terms of the compiler VC++ 2008 does have stronger ISO compliance, but the C compiler and library have hardly changed since VC++ 6. The Express Editions have been available since VC+2005 - where have you been hiding?

Clifford

[cpns]

I've currently got a problem with my broadband. Looking at your code will have to wait. Is it still the latest (at the time of this post)?

[Anonymous]

Okay, got it up and running again! Woot! Use extern on my declarations in my header, and DEFINED my variables in main.c. Now, time to figure out why the code isn't running like I expect it to. To paraphrase some of my code in stages.c...

//stages.c

include "neato.h"

//function declarations here

void loadstage(int x)
{
switch(x)
{
//cases 1-80
case 81:
endgame(); //for some reason, endgame() isn't running
break;
}
}

void endgame()
{
//various commented expletives because this function doesn't seem to run
//along with code that doesn't seem to be running
}

Oh, and here's the compile log. Not sure if it'll help now that I've got no errors popping up, but what it does reveal has surprised me as of late.

Compiler: Default compiler
Building Makefile: "D:\Programs\Games\Neato\Neato\Makefile.win"
Executing make...
make.exe -f "D:\Programs\Games\Neato\Neato\Makefile.win" all
gcc.exe -c main.c -o main.o -I"H:/Programming/Dev-Cpp/include" -DALLEGRO_STATICLINK

gcc.exe -c logic.c -o logic.o -I"H:/Programming/Dev-Cpp/include" -DALLEGRO_STATICLINK

gcc.exe -c draw.c -o draw.o -I"H:/Programming/Dev-Cpp/include" -DALLEGRO_STATICLINK

gcc.exe -c save.c -o save.o -I"H:/Programming/Dev-Cpp/include" -DALLEGRO_STATICLINK

gcc.exe -c stages.c -o stages.o -I"H:/Programming/Dev-Cpp/include" -DALLEGRO_STATICLINK

windres.exe -i Neato_private.rc --input-format=rc -o Neato_private.res -O coff

gcc.exe main.o logic.o draw.o save.o stages.o Neato_private.res -o "Neato.exe" -L"H:/Programming/Dev-Cpp/lib" -mwindows -lalleg_s -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lole32 -ldinput -lddraw -ldxguid -lwinmm -ldsound

Execution terminated
Compilation successful

[Anonymous]

Oh, almost forgot. You get to be on the credits page of my game for your help. I know it's not exactly the hall of fame, but it's the least I could do. It'll just be Clifford I guess, since that's about all I know of your name.

[cpns]

> You get to be on the credits page of my game for your help.

It had better be damn good then! ;-)

> It'll just be Clifford I guess

Its no secret. Last name Slocombe.

[cpns]

> Ok, so I wrote some code, ran it, it didn't work the way I expected, I fixed it, and now the old code is still running.

Presumably you have concrete evidence that the code has indeed not changed, and you did not just implement a bad fix that has no effect on execution?

Cleaning should delete the executable file, so if it runs it must have been rebuilt from something! Have you checked that the clean successfully deleted the object files and the executable, and that after a build a new executable is created?

Have you performed the obvious step of intentionally writing a junk line in the code to force the build to fail? If the code is truly being ignored, the build will succeed regardless.

Are you sure that the file you edited is part of the project. And not another file or a copy in some other directory?

Post the "Compile Log" (as requested in the "PLEASE READ BEFORE POSTING A QUESTION" thread). The log you post should be that from a "Rebuild All".

Now recalling similar issues, and without the benefit of the Compile Log or answers tor teh questions above, I would on the evidence suggest that this may be the result of the activity of security software. Spybot S&D's "Teatimer" feature is a common culprit for causing such odd behaviour. Try switching that off if you are running it. I hesitate to suggest disabling your anti-virus, but you might test that too just temporarily after disconnecting the Internet. In the unlikly event that it is the AV software, I would not advocate switching it off. Try different AV software or a different development tool.

> Now I'm worried that I'm going to lose my couple years of progress on my almost completed game!

That is very unlikely and somewhat of an overreaction, you'd have to loose the source code. The effort is in the source code, not the build tool. You could always use a different tool. If this is two years worth of effort I really hope that you are using a version control system.

Clifford

[Anonymous]

"Have you checked that the clean successfully deleted the object files and the executable, and that after a build a new executable is created?"

To be honest, I did not know exactly what clean did. Checked, and ya, those files were removed.

"Have you performed the obvious step of intentionally writing a junk line in the code to force the build to fail? If the code is truly being ignored, the build will succeed regardless."

Yes, I got rid of all the new code and threw this in:

set_gfx_mode(GFX_TEXT, 0, 0, 0, 0);
allegro_message("Checkpoint01", allegro_error);
return 1;

Which should pop up a message box saying "Checkpoint01" followed by the program's termination. Yet, it still draws a screen with a background and information, and the entirety of the program still operates fine.

"Are you sure that the file you edited is part of the project. And not another file or a copy in some other directory?"

Oh, good idea. Umm... ok, here's the tricky part. When I open up the project, it opens and all my code is there (just as I left it). But if I open the stages.c file alone (the exact one included in my project because it has the same path as the one in my project) it's a version of stages.c from a long time ago. Which is odd, because if the program is using THAT version it wouldn't even get as far as it does in the program. Meaning, that old stages.c file only goes up to stage 11, and I can still play up to stage 80; but after that is where the code is acting oddly. Hmm, I'm going to investigate more on this and hopefully find the problem. I will update if I figure out this is the problem.

"Post the "Compile Log" (as requested in the "PLEASE READ BEFORE POSTING A QUESTION" thread). The log you post should be that from a "Rebuild All"."

Sorry, at first the compile totally ignored the "Return 1." Now it's recognizing it, but still not executing the new code.

Compiler: Default compiler
Building Makefile: "D:\My Programs\Games\Neato\Neato\Makefile.win"
Executing make...
make.exe -f "D:\My Programs\Games\Neato\Neato\Makefile.win" all
gcc.exe -c main.c -o main.o -I"H:/Programming/Dev-Cpp/include" -DALLEGRO_STATICLINK

In file included from main.c:12:
stages.c: In function loadstage': stages.c:1582: warning:return' with a value, in function returning void

main.c: In function _mangled_main': main.c:28: warning:textprintf' is deprecated (declared at H:/Programming/Dev-Cpp/include/allegro/alcompat.h:177)
main.c:42: warning: textprintf' is deprecated (declared at H:/Programming/Dev-Cpp/include/allegro/alcompat.h:177) main.c:45: warning:textprintf' is deprecated (declared at H:/Programming/Dev-Cpp/include/allegro/alcompat.h:177)
main.c:147: warning: `textprintf' is deprecated (declared at H:/Programming/Dev-Cpp/include/allegro/alcompat.h:177)

windres.exe -i Neato_private.rc --input-format=rc -o Neato_private.res -O coff

gcc.exe main.o Neato_private.res -o "Neato.exe" -L"H:/Programming/Dev-Cpp/lib" -mwindows -lalleg_s -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lole32 -ldinput -lddraw -ldxguid -lwinmm -ldsound

Execution terminated
Compilation successful

"That is very unlikely and somewhat of an overreaction, you'd have to loose the source code. The effort is in the source code, not the build tool. You could always use a different tool. If this is two years worth of effort I really hope that you are using a version control system."

Sorry if it is an overreaction. I was correlating it to some bad experiences in the past where I couldn't get the darned thing working again. And... um... okay... stupid question... what is a version control system? Is that like saving a copy of an older version of the code just in case? Sadly I had forgone that strategy on this program; however, that is probably something I should keep in mind on future projects.

[Anonymous]

Thought I'd add this...
Trying to get that file to act normal. Did a file>save as from the project (the correct code), saved it as stages_b.c, opened it up alone, and it's the old code! Saved a copy outside of the project folder, opened it, and it's the old code! Opened stages_b.c, copy/pasted the new code in, saved again, closed, opened it up, and it's still the old code? Huh? If I open the file with the project the code is correct, but if I open the file alone, the code is not what it should be.

As for Spybot's teatimer, Ctrl+Alt+Del does not reveal it to be currently running. If there is an option to disable teatimer, I'm sure I've done it already. It was so long ago I got Spybot, I don't recall if it had that option.

[cpns]

> Yes, I got rid of all the new code and threw this in: [...]

Not what I suggested. Add a line that will not compile, something like:

jhfksdfkhgsdfjg

for example. If your code still builds, then the code you are changing is simply not part of the project.

> In file included from main.c:12:
> stages.c: In function `loadstage':

You have included "stages.c" in "main.h". Don't do that, stages.c is not a header file. That is what the linker is for! You have given control of what stages.c file is used to the compiler rather than the project manager. Depending on how you included it it may pick either
H:\Programming\Dev-Cpp\include\stages.c or
D:\My Programs\Games\Neato\Neato\stages.c
(if either exist). Show us main.c line 12.

The better way to project development is to add stages.c to the project (Menu: Project|Add File...), create a header file for it containing the declarations needed my main.c, and include that in main.c. Then stages.c and main.c will be separately compiled and linked, and you get precise control over which is used.

> But if I open the stages.c file alone (the exact one included in my project
> because it has the same path as the one in my project) it's a version of
> stages.c from a long time ago.

Then the file in your project is not the one you are opening. The impossible cannot happen.

> Sorry if it is an overreaction.

Maybe it is not an overreaction after all, you do seem to have lost the correct code for stages.c (or at least the code that is being used by your build). I suggest that you search your entire machine for instances of the file stages.c and figure out which one is the correct one! However this is certainly a file management and source control issue on your part and not a Dev-C++ bug.

> If I open the file with the project the code is correct, but if
> I open the file alone, the code is not what it should be.

Your build log shows that you have included stages.c rather than adding it to the project for separate compilation, so I have no idea what you are referring to by "open the file with the project", but as I said teh project is not controlling it the compiler is, because of you ill-advised method of including stages.c.

Other issues:

> Building Makefile: "D:\My Programs\Games\Neato\Neato\Makefile.win"

While you were reading "PLEASE READ BEFORE POSTING A QUESTION" did you spot the advice warning against paths containing spaces?

> stages.c:1582: warning: `return' with a value, in function returning void

You should fix that. If you have a problem you cannot see, always fix the problems you can see first! It may be related, to it may just be noise. You could do without either.

And yikes stages.c is very long. That is not your problem, merely a comment of good coding practice. Apart from anything else, if you do loose stages.c, it looks like you are going to loose pretty much everything! That is not the way to code.

Clifford

[Anonymous]

First, I want to say... Thanks very much for your assistance.

"Not what I suggested. Add a line that will not compile, something like: jhfksdfkhgsdfjg"

You're right, my bad. Ya, it stopped when I entered that line. Which makes me second-guess my coding (not Dev). I'll take a closer look in the morning, but something still seems fishy.

"Stages.c warning... You should fix that"

I know that's wrong. I put it in just to test if it would kick out at that point. Or at least point out that that part runs. Maybe it's not the best method. Either way, that's not part of my normal code.

"You have included "stages.c" in "main.h". Don't do that."

Sorry, I have been taught something to that effect for Dev-C++. Either I misunderstood or I was taught incorrectly. Although the book I used said (at the time of writing anyway, things may have changed) that Dev-C++ has trouble linking the files and to not link them and just include them. Sorry, but I cannot find that exact info in my book right now. I'll fix that and get back to you on it tomorrow.

"Then the file in your project is not the one you are opening. The impossible cannot happen."

If I open Neato.dev, and right click on stages.c under the Project tab, go to properties, and the absolute path matches the path of the ONLY stages.c file in that folder, then, unless I am mistaken, it is the same file. Although I agree with you, that IS impossible.

"While you were reading "PLEASE READ BEFORE POSTING A QUESTION" did you spot the advice warning against paths containing spaces?"

Yes, I did. But I assumed since everything worked up till now, that it was a non-issue. Anyways, I changed "My Programs" to "Programs" now.

"And yikes stages.c is very long."

In case you may have not been able to tell yet, I am mostly self-taught. I'm not familiar with many traditional coding practices. I'm not sure how long is long, especially in a game. However, I do tend to space things out line-wise so I can better understand my code. For example, I don't do the...

if(a<b){
}

I do...

if(a<b)
{
}

That, and the stages.c file is coded stages/levels of eighty 3x3 matrices, so I expect it to be a little long I guess. I'm still practicing with file-handling so in this game I just coded the stages into it.

Anyway, tomorrow I'll try and get this done and get back to ya on it. Thanks again.

[cpns]

> Although the book I used said (at the time of writing anyway, things may have
> changed) that Dev-C++ has trouble linking the files and to not link them and
> just include them.

Throw away your book. That has never been the case. It is more likely that the author did not know what he was doing. Dev-C++ is an IDE for the GNU toolchain. Linux for example is built using this toolchain, imagine what a mess that would be if it could not link separately compiled files.

If that were the case, the author should have rejected Dev-C++ as a tool rather than directed you toward bad habits! If that were the case we'd have all rejected Dev-C++ and noone would use it.

What book is this (name, author, edition)?

> If I open Neato.dev, and right click on stages.c under the Project tab [...]

I am wondering how you have managed to have stages.c in the project tab, but not have it separately compile. You must have set the properties to exclude that file from the build. So it may be the correct file, but not the file that is being built. That said your other evidence indicates that your 'fix' is merely not doing what you expect.

> [...]matches the path of the ONLY stages.c file in that folder[...]

I am interested in any stages.c in any location on your computer or accessible via a network map. That is why I suggested searching your whole computer. If you have XP sp3 you may have installed the "Desktop Serach" feature, use that, other wise use the traditional and slow search tool in Windows Explorer.

> I'm not sure how long is long, especially in a game.

Let's not get into that too much now, but I'd suggest that in C one global function per source file is not an unreasonable fragmentation. And function sizes greater than 50 lines should be considered long. However you'd have to be using separate compilation properly to benefit. It is just a rule of thumb, sometimes it is justifiable or necessary to be longer, but not often. For good coding practice in general I'd recommend "Code Complete" by Setve McConnell (Microsoft Press). Worth the investment.

One other point: are you sure that the code you 'fixed' is actually executed? I hesitate to suggest using the debugger and stepping to setting a break-point because Dev-C++'s debugger sucks, but that is the correct way to do this. One technique is to switch off the console window suppression (which will remove the -mwindows option), and you will get both your graphical window and a console to which you can printf(). I suggest defining teh following macro:

if defined _NDEBUG

define HERE()

else

define HERE() do{ printf( "%s:%d (%s)\n", FILE, LINE, FUNCTION ) ; } while(0)

endif

Then for debug builds, everywhere you place:

HERE() ;

when executed, the console will display <filename>:<line> (<function>), e.g.:

stages.c:1582 (loadstage)

Litter your code with that at strategic points (such as the start of functions, before, after and within conditionals an loops etc. and you can get a simple trace of your code's execution. Start by adding then around the code you think should be running but isn't. If that is not executes, start adding them in the path you think should be executed, and when it does something unexpected add more debug to figure out why.

Clifford

[Anonymous]

"What book is this (name, author, edition)?"

I'm not going to post information on the book or author unless I find that text. I'll see if I can find it. It may have been through an email with the author, I don't know. But I remember someone else calling him out once on not following traditional conventions or other good programming habits.

"I am wondering how you have managed to have stages.c in the project tab, but not have it separately compile."

I added the file to the project, went to Project>Options, Files tab, and told the compiler not to link or compile the files.

"I'd recommend "Code Complete" by Setve McConnell (Microsoft Press)."

Thanks! I've been looking for a good source on that. I will check that out.

"I'd suggest that in C one global function per source file is not an unreasonable fragmentation."

You're kidding. Really? I believe my stages.c is programmed like that, but I know I have other c-code file that have multiple global functions.

"You have included "stages.c" in "main.c". Don't do that, stages.c is not a header file."

So I did the fix you suggested here. Got rid of the c-file includes and linked the files with the project. Remind me (I've been out of practice on this form of programming for a long while now), is it okay to include the same header for multiple c-code files in the same project? If I remember correctly, you're only supposed to include a header once in all of a project. If I include it once, all of the other c-code files' variables aren't declared. If I include it in all of the c-code files, then it complains about multiple variable declarations. Are you suggesting a separate header for each c-code file?

[cpns]

> You're kidding. Really?

It seems extreme perhaps, but in large projects the fragmentation makes incremental builds faster, and software version control easier (and more useful, since it is file oriented, not line oriented). It is especially useful when building a system as part of a team of programmers - you cannot all work on the same source file at once! If you will never work in that kind of environment, you can relax somewhat.

> is it okay to include the same header for multiple c-code files in the same project?

It is essential (if you've done it right). When they are separately compiled, the only thing one compilation unit knows about another is what is in the header. However complex nesting requires the use of 'include guards' to prevent multiple declarations: http://en.wikipedia.org/wiki/Include_guard

Clifford

[cpns]

> Now, time to figure out why the code isn't running like I expect it to.

That's when you need a good debugger. Dev-C++ does not have one that fits that description, but you may make it work for you. If you want to use Dev-C++ I recommend using an external debugger - specifically MinGW/Insight: https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82725

> case 81:
> endgame(); //for some reason, endgame() isn't running

Put a break point there to see if the case even occurs. Make sure you have a default case to trap unhandled cases, and put a breakpoint in that too. Failing a break point, at least a printf or message box.

Actually I took a quick look at your code and logic.g contains:

> if(player->stage < 80)
> {
> player->stage++;//move onto next stag

which will prevent state ever becoming 81. I reckon that is your problem right there.

The method of finding this is simple.

1) Hypothesis: If endgame() is not running x is never 81.
2) What is x? ... A: The parameter passed to loadstage()
3) What gets passed to loadstage()? ... A: player->stage?
4) Where is player->stage modified?
5) How is it constrained?
6) What is it constrained to?

That required no debugger in fact, just Occam's razor, clarity of thought, and a text search or source browser tool.

Clifford

[Anonymous]

Yay, it works again. Just wanted to say thanks a bunch for your time, and for those references.