Re: Newbie needs help with VC6 & filesystem library

From: Craig Henderson (yg-boost-users_at_[hidden])
Date: 2002-09-16 02:19:50

I think I'm right in saying that the dir_it library has been superseded by
the Boost Filesystem Library. This is currently under formal review under
Sep 23, at which time it will either be accepted into Boost, or rejected

See http://groups.yahoo.com/group/boost/files/filesystem/index.htm

HTH
--Craig

"John B. Williston" <yg-boost-users_at_[hidden]> wrote in message
news:g46aouolac74tc0v0eqepv2u0dnh0s8sd5_at_4ax.com...
> Greetings,
>
> Though I'm an "old hand" at C++, I'm a complete newbie when it comes
> to Boost. The piece that really caught my eye, in light of my current
> project, is the directory iterator. To date, however, I haven't had
> any success getting it to compile and function under Win32 with MSVC6,
> so I thought I would post here. I first have a couple of general
> questions about using Boost, and then one specific question about the
> problems with my project at hand.
>
> (1) Is there a "right" way to include Boost stuff with VC6? Adding the
> Boost base directory to my list of include directories seems to work
> for the official stuff, but it clearly doesn't work for the filesystem
> stuff because Directory.h is not in the base\boost directory. I can
> put it there myself, of course, but I'm wondering if there is some
> intended way to use the beta libraries before they become a part of
> the whole.
>
> (2) Is there a "right" way to link Boost stuff with VC6? The
> filesystem stuff, like the regex stuff and some other pieces, requires
> actual compilation and cannot simply be included as header files. I
> have already built all the official libraries using the bjam utility,
> but I cannot help noticing they're each stored in hideously long paths
> beneath the boost base directory. Is there a "right" directory under
> the Boost hierarchy into which the resulting libs should be copied for
> ease of inclusion in VC6? Or should I copy them into my project
> directories as needed? Or should I simply come up with my own system?
>
> To get to the more specific question, let me explain how I've
> addressed (1) and (2) for the time being. Regarding (1), I've copied
> Directory.h and Boost.h into the base\boost directory so that they may
> be included without changing the existing source code. That was simple
> enough. Regarding (2), I've decided to add Directory.cpp to my project
> and compile it as a module, rather than try to get the linking to work
> externally. Having said that, consider the following code:
>
> #include <windows.h>
> #include "boost/directory.h"
>
> int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
> lpCmdLine, int nCmdShow)
> {
> using namespace boost::filesystem;
> std::string strFilename;
>
> for (dir_it it("./"); it != dir_it(); ++it)
> if (!get<is_hidden>(it))
> strFilename = *it;
>
> return 0;
> }
>
> This is an extremely minimal test case of integrating the filesystem
> stuff into a Win32 application. When compiling the application, I get
> the following lengthy and inscrutable (to me, at least) error message:
>
> WinMain.obj : error LNK2001: unresolved external symbol
> "__declspec(dllimport) public: __thiscall
> boost::filesystem::get<struct
> boost::filesystem::is_hidden>::get<struct
> boost::filesystem::is_hidden>(class boost::filesystem::dir_it const
> &)" (__imp_
>
??0?$get_at_Uis_hidden_at_filesystem@boost@@@filesystem_at_boost@@QAE_at_ABVdir_it_at_12@@Z
)
>
> The error message seems to suggest that the filesystem stuff isn't
> available in my project. I find that confusing because the
> Directory.cpp module compiles without any errors, and I am thus
> inclined to think that, in fact, all of the filesystem stuff is in my
> project. Thus, I must also ask the third question:
>
> (3) Can anyone explain to me what I might be doing wrong and, more
> importantly, how I might correct it?
>
> Thanks much to all the Boost authors for an interesting set of tools.
> And thanks in advance to any who respond for all the help with my
> specific issue.
>
> John
>
>
>
>