Re: [boost] RealNetworks is using boost

From: John Maddock (john_at_[hidden])
Date: 2005-06-08 06:55:34

Many thanks for the info, some of your comments are a little verbose to 
include wholesale on the web page, but I think we can use quite a few.  I 
have a few comments on your comments as well if you'll bare with me:

>      boost.filesystem
>                      Not so happy here. This library looks promising,
>                      but there are a sum of little issues that makes
>                      me wonder if I should avoid using it in the
>                      future.
>                      1- There is a bug on win98 when iterating a root
>                      drive. I sent a mail
> 
> [http://lists.boost.org/MailArchives/boost-users/msg10391.php] about
>                      the problem on boost-users with a fix and never
>                      received a response. I might get better results
>                      by rephrasing the mail.
>                      2- short-hand to build native paths using
>                      operator "/" is broken if
>                      you don't set the default name check to
>                      boost::filesystem::native.
>                      3- What we really need
>                      is the reverse of the default library mode : have the 
> library always
>                      work with native name-check and at the
>                      programmer's control, switch it to portable
>                      paths. There are WAY too many cases where we
>                      want to only work in native mode and portable
>                      path is the exception.

I think that's going to be fixed soon.

>                      4- Lack of wstring/unicode support will become a 
> problem
>                      very soon.

Likewise.

>                      6- as noted in the do-list : "Windows: Some
>                      files seem to be poisoned to the point where you 
> can't even do is_directory() on them without an access error. For example, 
> pagefile.sys. Should directory_iterator ignore these files?"
>                      This is really a problem. A user must be very
>                      careful for exceptions when using iterators.
>                      They will throw.

It looks like a lot of the problems can be summed up by "The Windows 
filesystem API's have lots of gotchas, and the Boost folks haven't dealt 
with them all yet."

Are there other libraries that do better that we can learn from (does .NET 
handle it better for example?), is the current state better than a (quite 
possibly naive) "do it yourself" approach?

>      boost.date_time
>                     Simple to use, effective, does the job. I love the
>                     flexible input string parsing facilities, and the
>                     human readable ISO output. I created utilities to tie 
> in
>                     with boost.filesystem so I can perform date_time
>                     calculations on files.

That's on my wish list as well, care to make it a submission?

>                     Also had to create a layer
>                     to interface nicely with native locale date/time
>                     conversions api. I am sure every users of
>                     date_time that had to build UI apps ended up
>                     writing similar facilities.

Again, if it's a common problem, why not share if you can?

>      boost.array
>      boost.optional
>                    Originally considered to implement an interface to
>                    value access of an embedded database but was
>                    discarded because of the _horrible_ compile times
>                    that appeared when introduced. Also considered for
>                    its visitation facility as a means to transport
>                    complex data to be rendered in UI controls. Again,
>                    dropped because of the compile times.

I'm not sure if these comments apply to array as well as optional (I'd be 
very surprised if it does, it's a pretty lightweight header).

For optional: have you tried separate file template compilation (by 
declaring the templates you're using as "extern" in VC++ or g++)?  I realise 
it sucks as a workaround, but compile times can really benefit enormously.

>      boost.thread
>                  Used to implement the monitor pattern in key areas.
>                  The 2 most desired features : static linking of
>                  boost.threads and ability to kill a thread.

Static linking is fixed, killing threads is much harder.

Thanks for the feedback,

John.