At 08:06 PM 8/18/2002, Jeff Garland wrote:

 > I notice that all support for properties has been removed from filesystem
 > with the exception of a broken link to property_maps in the FAQ.

Fixed.

 > Unfortunately, I really need access to the file size for the program I
 > am working on. I take it that the plan is that these properties are not
 > coming back into the library in the near term, or should I be thinking
 > about hacking some sort of extension?

The questions that come to mind are:

*  What type should a size function return?  Trickier than it sounds since 
many operating systems support file sizes larger than can be represented by 
a long. uintmax_t sounds better, but are we promising more than can be 
delivered if uintmax_t is too small (probably 32-bits) to hold the 
platform's maximum file size?

*  Can a size function be reliably implemented on any operating system 
likely to be able to support the Filesystem Library? The answer is yes for 
most modern mainstream OS's, and yes for many small legacy OS's, at least 
if an allowable implementation is to open the file, seek to the end, get 
the position, close the file, and report the result.

*  What would be a good name?  (Remember from prior messages that if the 
function name is foo, and pth is a fs::path, we want foo( pth ) to be 
valid, but pth.foo() to be invalid.)  "file_size" is one obvious candidate.

If the answers to these aren't controversial, I wouldn't mind adding the 
function.

--Beman


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost