Errors in library?

Started by
5 comments, last by Sandman 19 years, 8 months ago
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?
Advertisement
Don't use those headers, they're depreciated.
Chess is played by three people. Two people play the game; the third provides moral support for the pawns. The object of the game is to kill your opponent by flinging captured pieces at his head. Since the only piece that can be killed is a pawn, the two armies agree to meet in a pawn-infested area (or even a pawn shop) and kill as many pawns as possible in the crossfire. If the game goes on for an hour, one player may legally attempt to gouge out the other player's eyes with his King.
Quote:Original post by NewbJ
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


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.
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(...)'

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.
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?
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.

This topic is closed to new replies.

Advertisement