|
Boost Users : |
From: John B. Williston (yg-boost-users_at_[hidden])
Date: 2002-09-16 11:08:16
Greetings,
I'm sorry for my earlier post. I didn't realize that the dir_it beta
stuff was not what was being referred to as the "filesystem". I now
know better, and I'm trying to make the filesystem stuff work instead.
Unfortunately, I'm having no better luck. Consider the following code:
#include "boost/filesystem/operations.hpp" // includes
boost/filesystem/path.hpp
#include "boost/filesystem/fstream.hpp" // ditto
#include <iostream> // for cout
int main(int iArgc, char** pArgv)
{
namespace fs = boost::filesystem;
int iNumNodes = 0;
fs::directory_iterator end_itr; // default construction yields
past-the-end
for (fs::directory_iterator itr("debug"); itr != end_itr; ++itr)
{
if (fs::is_directory(*itr))
std::cout << (*itr).file_path() << " (dir)" << std::endl;
else
std::cout << (*itr).file_path() << std::endl;
iNumNodes++;
}
std::cout << iNumNodes << " total." << std::endl;
return 0;
}
That's a relatively brain-dead use, I should think, to enumerate the
contents of the debug folder to the console. Unfortunately, when I try
compiling this, the linker complains horribly about all kinds of
symbols already being defined in the filesystem object modules. To
ditch the linker errors, I've temporarily used the /force switch, but
that's hardly illuminating. First, can anyone tell me how to avoid
getting a plethora of multiply-defined symbol errors? Or is /force my
only real option?
Second, if I use the /force switch, I get all kinds of unhandled
exception errors when the directory iterator is constructing. Changing
the string I pass to it at construction just changes which exception
it emits. With the code above as written, the culprit is:
template<typename Y> void reset(Y * p) // Y must be complete
{
BOOST_ASSERT(p == 0 || p != px); // catch self-reset errors
this_type(p).swap(*this);
}
That's lines 181-185 of boost/shared_ptr.hpp, and I haven't a clue why
it's freaking out. Tracing through all the code shows that the
exception is occurring AFTER the swap seems to succeed. I'm stumped as
to what the problem might be. But I sure would appreciate any advice
y'all can offer. So far I have to say that I'm impressed with the
Boost library features, but it seems a cast-iron bitch to make it
actually compile and link in any real-world programs.
John
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net