Re: [lmi] boost::filesystem oddity

[Vadim Zeitlin]

On Sun, 15 Jan 2006 11:46:15 +0000 Greg Chicares <address@hidden> wrote:

GC> Vadim--Here's something that puzzles me. I think this code should run
GC> without throwing any exception. But I can't get it to work that way
GC> on msw when the boost filesystem library is built as a dll. I think
GC> you've got a version of boost built with their 'jam' build system;
GC> would you mind trying it and letting me know what happens?
GC> 
GC> #include <boost/filesystem/path.hpp>
GC> #include <exception>
GC> #include <iostream>
GC> #include <ostream>
GC> 
GC> int main()
GC> {
GC>     try
GC>         {
GC>         boost::filesystem::path::default_name_check
GC>             (boost::filesystem::windows_name
GC>             );
GC>         boost::filesystem::path p0("C:/AUTOEXEC.BAT");
GC>         std::cout << p0.string() << std::endl;
GC>         boost::filesystem::path p1("C:\\AUTOEXEC.BAT");
GC>         std::cout << p1.string() << std::endl;
GC>         }
GC>     catch(std::exception const& e)
GC>         {
GC>         std::cerr << e.what() << std::endl;
GC>         }
GC> }
GC> 
GC> I get
GC>   boost::filesystem::path: invalid name "C:" in path: "C:/AUTOEXEC.BAT"
GC> which seems unexpected.

 I get exactly the same when using boost-filesystem-mgw.dll. I also get the
same result with cygwin FWIW.

GC> I've found a way to make code like this work in lmi, but I'd really
GC> like to understand the problem that I appear to have fixed.
GC> 
GC> For the record, here's a problem report that I posted:
GC>   http://sourceforge.net/mailarchive/message.php?msg_id=14476898

 Concerning the very first paragraph of this mail: I am not at all
surprized that comparing the function pointers doesn't work. In Win32 PE
(portable executable) file format, the calls to DLL functions are indirect
as this allows the loader to adjust the real address of the function (which
may differ from execution to execution) only in one place instead of
scanning the entire program.

 And so the implementation of path::m_path_append() in
path_posix_window.cpp doesn't risk to work under Windows. But wait, there
is more: AFAICS it's just plainly buggy as well as using windows_name in
the way you do above can't work at all. If you look at the code you can see
that the checker is compared to no_check and native only, so passing it
windows_name can never work -- yet results in no compile warnings.

 If you modify the example above to do default_name_check(native), then it
does work in static builds. It doesn't work in shared ones because of the
problem with comparing function pointers above.

 In passing, I must say that I'm quite upset by boost::filesystem::path API
as using function pointers like this is really ugly. Not forgetting that it
doesn't work. And the code is littered with #ifdef BOOST_WINDOWS like a
first attempts at portable programming of freshman student. I expected
better from boost...

GC> and here's another that may be related:
GC>   
http://groups.google.com/group/boost-list/browse_thread/thread/6e40af492f800509/37bbeddaec4db0bd

 I don't believe this is related. The only link I can see is that boost
doesn't use declspec with gcc (but relies on its autoimport apparently?)
but I don't think this is a problem here.


 Anyhow, to summarize, there are 2 problems:

1. using windows_name instead of native: although IMHO this is also a
   problem with boost (API), it is discussable and, anyhow, easily fixed

2. function pointer comparison: I don't know what to do about this one
   unfortunately... the idea of using function pointers like this just
   seems to be fundamentally flawed

 If we still have a real problem with this, I could spend more time on it,
of course.

 Regards,
VZ