Re: new dir_it

From: jan_langer (jan_at_[hidden])
Date: 2001-12-22 18:30:49

--- In boost_at_y..., Darin Adler <darin_at_b...> wrote:
> On 12/21/01 6:29 AM, "jan_langer" <jan_at_l...> wrote:
> > the lib uses a function to_string which converts between
> > basic_strings with different char types and it uses locales,
> > use_facet and ctype. now i don't know how to make this portable,
> > especially with the use of the boost config macros.
> > i think i would be good to take it out of the filesystem stuff.
>
> On deficient platforms, which you can probably detect with one of 
the
> BOOST_NO_XXX macros from Boost.Config, you can probably get away 
with only
> supporting basic_string<char>.
the problem is that one deficient platform is linux/gcc2.95.2
but that leads to another problem: the whole lib uses the 
basic_string template to provide support for different char types but 
since it is no header-only-lib there are template instantiations for 
char and wchar_t in the cpp files. 
wherever a conversion to std::string or char * is needed (as for 
system calls) it is done by str_conv, which also does only work with 
char and wchar_t.
and this concept isn't used everywhere. eg. the file attribute 
filename supports only std::string and it would need lots of 
additional template instantiations to make it available to other char 
types.
one possible solution would be to support only char, but then it is 
less flexible.
to make it a header-only lib is a very bad idea because then you'll 
need all the system headers into your projects.

> > many standard libs don't support the manipulators left and right
> > but i need them. what is the appropriate boost-workaround?
> 
> In what sense do you "need" the left and right manipulators? Is 
there no
> workaround?
yes, of course there is a workaround but i was too lazy to write it 
and i hoped boost knows a better solution.
i typed it now and it looks not that bad as i thought.
and i don't really need the manipulators. they just make the output 
of the testfile looks prettier.

> BOOST_NO_STRINGSTREAM just tells you when <sstream> is not 
available. It
> doesn't tell you what to do. Some Boost libraries have workarounds 
that use
> things like strstream, others omit features.
ok, i wrote a workaround if BOOST_NO_STRINGSTREAM is defined.

> > another task is to port it to the windows environment. but what
> > does it mean? i compiled it with cygwin-g++ and it worked well.
> 
> Porting to the Windows environment means making it compile without 
cygwin.
> Using Windows calls rather than POSIX calls.
what means windows calls? i installed bcc but it also supports only 
the posix calls. or should i really install vc++? 

> And it could use Macintosh support. Under OS X the basic Unix 
implementation
> will work for most things, but won't expose any of the Macintosh-
specific
> file attributes. Under OS 9, we'd need an implementation that used 
Macintosh
> file system calls rather than POSIX calls.
so this must be done definitly by someone else since i have no access 
to a macintosh system.

> > what else is to do on this lib
> 
> To go with the flow of the current library, it would be good for 
the library
> to support a well-chosen set of platform-specific attributes. For 
Unix,
> POSIX is a good set. For Windows and Macintosh there are probably 
others
> that are worth supporting.
i added a list of all currently implemented attributes to the 
filesystem directory. 
i do not really understand the meaning of all of them.
some comments on them and their availability on different platform 
and what they should act like are welcome. also to be helpful for the 
documentation to be done.

> It would be good to give the library a name that is not so cryptic. 
Other
> Boost libraries have names made up mostly of English words.
i changed it to filesystem, because dietmar kuehl already put 
everything into a namespace with this name. any other suggestions?

> This library seems an unlikely candidate for C++ Standard 
standardization,
> at least in part because it can't be built out of the standard C 
I/O stuff,
> and instead requires something platform specific (POSIX, for 
example).
do you mean that this is a reason for the lib not to be accepted into 
boost?

i put the new version into the files section (the new name is 
filesystem)

-- 
jan langer
jan_at_[hidden]