Xcode: where will a c++ program look for a .dat file

[jimcath]

Is there a special place I have to put a .dat file in order for it to
be read by a C++ program in Xcode? or is there an environment setting
I need to change to find the place I put the .dat file? I tried all
sorts of paths and nothing worked (yet). The file opens in TextEdit
so I know its a vilid text file.

This is the code that is supposed to open the file oct.dat
------------------------------------------------
void Profile::readFile(char *name) {

int a;
ifstream inProfileFile(name, ios::in); //open curve data file

if (!inProfileFile){
cerr << "File could not be opened - PROFILE" << endl;
exit(1);
}
------------------------------------------------
and I always draw the error. The debugger tells me that name
is oct.dat which is the correct file Any ideas?

[Jøhnny Fävòrítê (it means "halo, then resonate")]

Post by jimcath
Is there a special place I have to put a .dat file in order for it to
be read by a C++ program in Xcode?

if we were to tally up all the questions in this and all other
programming groups, i'd bet the "why isn't the current directory set to
what i want it to be" would be the most-asked, with a bullet.

here's the best way to fix it: never use relative paths. don't try to
open "file.dat", open "/Users/me/file.dat". that way, your app won't
get surprised on those occasions when the current directory isn't what
you expected.

let's assume you want your file in the current user's home directory,
that's a good general-purpose default location. you're writing in c++,
so here's a fairly portable way to build up a fully-qualified pathname
on most unix-like systems (error checking removed for brevity):

const char* home = getenv("HOME");
std::string path;

path.assign(home);
path.append("/file.dat");

now you can use path.c_str() as the string to pass to your file-opening
function. and incidentally,

void Profile::readFile(char *name);

is not good. should be:

void Profile::readFile(const char* name);

which indicates that the function does not modify the 'name' string. if
you're going to use std::string to build up path strings, then you HAVE
to do it that way, or else your program won't compile.

the getenv("HOME") call might fail if no user is currently logged in,
which might happen if your program is running in a "headless"
environment, i'm not sure. and if it were me, i'd check to make sure
that the 'home' string doesn't already end in a slash, because you
wouldn't want to paste in a redundant one. but then i'm paranoid.