0

I had spent some time trying to get simple boost filesystem operations working, and managed successfully by changing the project settings in XCode. For reference, here is my code that uses boost::filesystem:

namespace bfs = boost::filesystem;

std::cerr << "Before bfs calls" << std::endl;

bfs::path levelDir("data/levels/");
std::cerr << "path object created" << std::endl;

try
{
    if (bfs::exists(levelDir) && bfs::is_directory(levelDir))
    {
        std::cerr << "Directory exists according to bfs" << std::endl;
        bfs::directory_iterator endIter;
        std::vector<bfs::path> paths;

        for (bfs::directory_iterator it = bfs::directory_iterator(levelDir); it != endIter; ++it)
        {
            if (bfs::is_regular_file(it->status()))
            {
                paths.push_back(it->path());
            }
        }
    }
}
catch (...)
{
    // Handle exception.
}

std::cerr << "After bfs calls" << std::endl;

A problem I had when debugging, was that attempting to step through the code line by line would behave very strangely. Before I got to any boost::filesystem functions/objects the program would continue running, completely skipping over any boost::filesystem code. Additionally the output for the above would be:

Before bfs calls
After bfs calls

During my investigation, I found that the solution was to change the C++ Language Dialect setting to C++11 and the C++ Standard Library to libc++, both in XCode project settings under the Apple LLVM 6.0 Language C++ section. I assume this has to do with matching the settings that boost filesystem was built under.

My program built normally with no errors, and ran fine except whenever I needed to read files in a directory on the filesystem.

So on to my actual question: Since this has to do with a mismatch in compiler settings, why wasn't there a compile/linker error and is there anything I can change in XCode settings to alert me when this is the case? Since the regression happened when I upgraded boost via Homebrew, is there a way to detect the settings used to build libraries? I am also concerned that an update to XCode and its compiler may cause a similar problem.

I am running boost 1.56.0 installed via Homebrew, and XCode 6.0.1.

usm
  • 245
  • 2
  • 17

1 Answers1

1

To be honest, I don't think I've seen a red herring this big in a while. Of course the C++ Language Dialect does not make some library code "magically" disappear or not-work.

What is far more likely, though, is:

  • you were debugging with optimizations enabled and hence the "current statement" pointer jumped all over the place, seemingly skipping functions (that might have been inlined or simply optimized out).

  • there were other differences in the running environment (e.g. the working directory was different) hence you found different files (e.g. no matching files in that working directory) and you thought you were seeing the library fail ghosts.

  • in an off-chance you could be witnessing Undefined Behaviour. This could in theory happen if parts of your code base were compiled using different compiler version/settings than others. (Google ODR and ABI for background)

sehe
  • 374,641
  • 47
  • 450
  • 633
  • I get the same behavior with optimizations turned off - the current instruction pointer would still just from the first `cerr` statement to the last. I've always set the working directory explicitly. The last point is the one that seems the most relevant to me. I suppose by definition **Undefined Behavior** can fail in any conceivable way. In which case it might be more useful for me to search for the settings used by Homebrew and mimicking those in my own projects. – usm Oct 01 '14 at 19:01