# Errors in library?

## Recommended Posts

I've just brought someone else's C code into Dev-C++ by starting a new C project and pasting it into a file. the compiler didn't find any errors in their code, but it found over 20 in streambuf.h and 2 in each of iostream.h and alloc.h now, I'm assuming these files don't have errors in them...I mean, I'm sure that they were tested extensively before release...so what could be causing the compiler to find such things as parse errors in streambuf.h?

##### Share on other sites
Don't use those headers, they're depreciated.

##### Share on other sites
Quote:
 Original post by NewbJI've just brought someone else's C code into Dev-C++ by starting a new C project and pasting it into a file. the compiler didn't find any errors in their code, but it found over 20 in streambuf.h and 2 in each of iostream.h and alloc.h

At a guess, I'd say it's because you're trying to compile C++ code in a C environment. iostream.h and streambuf.h are C++ headers.

##### Share on other sites
yeah...well, I still got errors when I tried to compile it in a C++ environment, though they were less...the errors I got then were:

ANSI C++ forbids implicit conversion from void *' in assignment (on every line that they used malloc() )

implicit declaration of function int kbhit(...)'

##### Share on other sites
Have you modified this code yourself, or is this how it came?

It sounds like there's lots of mixed up C and C++ style programming going on. kbhit() and malloc() are C style functions. They should work - it may be that your compiler is being a bit too pedantic and/or the original code is badly written.

You can fix the malloc issue fairly easily by putting in the appropriate casts, or using new e.g

int* myIntPointer = malloc(100 * sizeof(int)); // gives a warning/errorint* myIntPointer = (int*)malloc(100 * sizeof(int)); //okint* myIntPointer = new int[100]; //ok

Not so sure about how to fix the kbhit issue, but you could probably work around it by replacing it with suitable C++ style input, or roll your own equivalent.

##### Share on other sites
it's pure C...here, this might help...I don't think iostream.h and streambuf.h and stuff are actually included...lol in fact, I know they're not, because I'm looking at the includes right now...one of the other files perhaps uses them? here's what's included:

#include <conio.h>
#include <string.h>
#include <stdio.h>
#include <alloc.h>

they all look like C files to me...perhaps the compiler's just screwed up or there's something set wrong in it...idk...but I haven't touched the code...and I kind of don't want to...the reason I've tried to compile it is that I'm reviewing it for bugs and stuff...I'm a C++ programmer, but I understand most of the C stuff, or what its C++ equivalent would be...

EDIT: and when I run it in a C project, it's just more weird...like the compiler doesn't like this statement:

     if (strcmp(command, "exit")==0)  //if command=="exit"       {         //DO EVERYTHING WHEN EXITING GAME, ASK FOR SAVE etc.         EXIT_GAME = 0; //set TRUE       }

it says: Warning: no semicolon at end of struct or union

um...what struct?

##### Share on other sites
Hmmm....

Check your search paths to see if the headers that it's trying to include are valid C headers. Certainly my version of .NET seems to be able to resolve all of those to something sensible, with the exception of alloc.h which doesn't appear to exist at all.

Otherwise, check that there are no standard files or defines (like #define __cplusplus )being included as a result of compiler settings or somesuch. I wouldn't worry too much about weird errors in the actual code, if there's a whole load of errors being generated by the include files these can confuse the compiler and result in nonsensical interpretation of the code. Always fix the 'first' error in the list.

## Create an account

Register a new account

• ## Partner Spotlight

• ### Forum Statistics

• Total Topics
627638
• Total Posts
2978327

• 10
• 12
• 22
• 13
• 34