Jump to content
  • Advertisement
Sign in to follow this  
Sfpiano

close() not a member of ifstream???

This topic is 4374 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

#include <fstream>
#include <iostream>
using namespace std;

ifstream inFile(filename.c_str());
	if( inFile.bad() ) {
		inFile.close();
		return;
	}

	while(!inFile.getline(line, 1024).eof()) {
		str a;
		if( line[0] == '#' )
			continue;

		PerlString perl;
		perl.Split(line, NULL, NULL);

	}

	inFile.close();
warning C4003: not enough actual parameters for macro 'close' error C2039: 'win32_close' : is not a member of 'std::basic_ifstream<_Elem,_Traits>' This is news to me, am I missing something?

Share this post


Link to post
Share on other sites
Advertisement
You have a macro for "close" in scope that is resolving to "win32_close." What other headers are you including in that file?

Share this post


Link to post
Share on other sites
This is exactly why macros are bad. Somebody somewhere defined "close" as one, mapping it to win32_close. The preprocessor doesn't actually know anything about C++ syntax, so it can't tell that inFile.close() should remain the way it is.

Who did this, I don't know. It shouldn't be in either of your example headers. Are you missing a few in your examples?

CM

Share this post


Link to post
Share on other sites
It's probably the perl headers I've included. Is there a way to explicitly tell the compiler which function to use when?

Share this post


Link to post
Share on other sites
Quote:
Original post by Sfpiano
It's probably the perl headers I've included. Is there a way to explicitly tell the compiler which function to use when?

Of course. But macros make use of the preprocessor, which does all its work before the compiler even sees your code. You need to get rid of the macro. Check the documentation for whatever library you're using...perhaps they have a way to supress the macro generation.

*edit: failing that, you could just put a #undef close command after the offending headers, but that might cause additional problems if you're supposed to use this close macro. It also hides the underlying problem, so you might have problems later if there are other macros defined you don't know about.

CM

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!