RE: [boost] Re: New design proposal for boost::filesystem

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-09-06 03:15:04

Vladimir Prus wrote:
>Martin wrote:
>
> > Vladimir Prus <ghost <at> cs.msu.su> writes:
> > The current path implementation doesn't
> > allow you to handle more than one type (i.e. winfs or posixfs). You 
>can't
> > store a registrypath in a fs::path since it can't handle a hkey.. root.
>
>Why? Can't I put literal "HKEY_CURRENT_USER" in boost::path?

I don't think he's questioning that, but the case where you can use a HKEY 
handle as the root, for example:

   // note: not sure on exact calls
   HKEY hkCU, hkBase;
   ::OpenKey( null, "HKEY_CURRENT_USER", &hkCU );
   ::OpenKey( hkCU, "software\\microsoft\\windows", &hkBase );

   boost::fs::path regwin( hkBase ); // oops: error
   boost::fs::path spyware = regwin / "CurrentVersion" / "Run" / 
spyware_app;
   if( exists( spyware )) // does the registry key exist
   {
      // display the value
      std::cout << "removing: " << boost::fs::get_regval( spyware ) << '\n';
      boost::fs::delete( spyware ); // delete the registry entry
   }

Also, iterating through registry entries requires different API calls to 
that of iterating through files.

> >> Actually, I think it is very desired to have boost::path usable in more
> >> contexts than the filesystem. For example
> >>
> >>    fs::path base("http://my_site.org");
> >>    ..... get_file(base / "foo" / "bar") .....
> >>
> >> would be great. But I'm just don't sure this requires all that drastic
> >> changes.
> >
> > Why do you think it is a drastic change?
> > Changing operations will not take much time since it is only to move the
> > things inside "#ifdef BOOST_POSIX" and "#ifdef BOOST_WINDOWS" into
> > separate overloads.
>
>And #ifdef the overloads ;-) I don't think Win32 API calls can be compiled
>on Linux.
>
>I really think that win32/posix distinction should say as it is. For other
>types of path, I'm not sure. I *think* that boost::fs::path can accomodate
>all of them. Of course, if you stick URL into boost::fs::path, the name
>'native_file_path' becomes questionable ;-)

Why not have a class like std::char_traits (e.g. boost::fs::path_traits) 
that abstracts the API used by path. That way, you can have:

   template< typename CharT > struct posix_path_api
   {
      typedef ... file_handle;
      typedef ... directory_iterator_handle;
      static bool exists( file_handle );
      static void delete( file_handle );
      static directory_iterator_handle get_next( directory_iterator_handle 
);
   };

This would then simplify the Win32/posix API problems and allow for 
internet_api, winregistry_api, etc. to be included, e.g.

   boost::fs::path< char, internet_api< char > >
     boostweb( "http://www.boost-consulting.com/boost" );

Regards,
Reece

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/