access violation ifstream class?

I don't understand why i receive access violation, when my constructor shouldn't be deleting?

[HEADER FILE]
1
2
3
4
5
6
7
8
9
10
11
12
#include <iostream>
#include <fstream>
#include <string>
#include <ctime>

class P035Y 
{
public:
	std::ifstream ifstream;
	std::string openTextFile(std::string filePath, std::string errorMsg);
private:
};


[SOURCE FILE 1]
1
2
3
4
5
6
7
8
9
10
#include "P035Y_COMMANDS.h"

std::string P035Y::openTextFile(std::string filePath, std::string errorMsg)
{
	ifstream.open(filePath);
	if(ifstream.fail())
	{
		return errorMsg;
	}
}


[SOURCE FILE 2]
1
2
3
4
5
6
7
8
9
10
11
#include "P035Y_COMMANDS.h"

int main()
{
	P035Y P035Y;

	P035Y.openTextFile("English\\adjectives\\1syllableadjectives.txt", "Failed to open English\\adjectives\\1syllableadjectives.txt!");

	system("pause");
	return 0;
}
Last edited on
What does openTextFile return if it doesn't return an errorMsg?

Also, your source code doesn't completely sync. Your code shouldn't even compile if that's actually the code. On line 3 of your first source file, it shows your class is called "OBJ" but your class is called "MYCLASS", so it should be

1
2
3
4
std::string MYCLASS::openTextFile(std::string filePath, std::string errorMsg)
{
    // ...
}
Last edited on
I uploaded the since modified data, nothing gets returned in console. The program jumps to an exception error and fails to terminate.
What does the function openTextFile return, if it doesn't return an errorMsg?
Your function is supposed to return a std::string. Does it?
Last edited on
+ + P035Y::openTextFile returned <Error reading characters of string.> std::string
std::ifstream ifstream;
^^^even if that works, this is horrible. give it a variable name. I wonder if any of your problems are caused by using the type as a variable name.

passing in error message is silly if its just going to echo the input path. its not an error, but its weird/pointless.

something like:
if(ifstream.fail())
{
string s = "Failed to open: "+filePath ;
return s;
}
Last edited on
+ + P035Y::openTextFile returned <Error reading characters of string.> std::string
Sorry, but I'm failing to communicate properly.
I'm not talking about runtime. I'm just talking about a static analysis of the code itself.

Your openTextFile does not return anything if the failure branch is not reached. Not returning something from a non-void function is undefined behavior.

As an alternative to what jonnin said, you might want to return bool instead, and pass an error message as a reference parameter (this comes down to opinion/style, there is no right answer).
1
2
3
4
5
6
7
8
9
10
bool P035Y::openTextFile(std::string filePath, std::string& errorMsg)
{
	ifstream.open(filePath);
	if(ifstream.fail())
	{
		errorMsg = "Failed to open " + filePath + "!";
		return false;
	}
	return true;
}


1
2
3
4
5
6
7
8
9
10
11
12
13
14
int main()
{
	P035Y p;

	std::string error_msg;
	if (!p.openTextFile("English\\adjectives\\1syllableadjectives.txt", errorMsg))
	{
		std::cout << errorMsg << '\n';
	}
	else
	{
		std::cout << "Success!\n";
	}
}


Also, enable warnings in your project settings. They will warn you if not all paths return a value from a function.
Last edited on
I see, I opted to use the boolean example as it makes more sense. Thank You for your input, I will also rename variables. Thank You, Ganado
Last edited on
the bool is the 'right' way to do it, IMHO.
Now your code can be used in a GUI without being changed:

if(!p.open.... blah blah)
{
do_that_pop_up_ok_button_with_mesage_thingy(errormsg);
}

whereas embedding cout in the routine limits it to only console programs.
I don't normally go into all that for what is clearly homework, but its a good thing to put in the back of your head: decouple the UI from the "work", always (well, once you get past getting your feet wet, its not critical in your first course).

returning a string works too, but its more flexible to allow the user to make their own messages rather than try to make a canned one that attempts to work for every user later. Then the user has to trap your message and rewrite it if they don't like what you provided.
Last edited on
Topic archived. No new replies allowed.