Jump to content
  • Advertisement
Sign in to follow this  
Sfpiano

close() not a member of ifstream???

This topic is 4284 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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!