- Boost - lists.boost.org

RE: [boost] [filesystem] size() on directory?
by Powell, Gary 03 Feb '04

03 Feb '04

Beman wrote: How should size( "foo" ) behave if "foo" is a directory? 1) Throw. The function should be renamed file_size(). 2) Return 0. Directories don't strictly speaking have a size. 3) Return the number of entries in the directory. Directories are really just containers; so of course they have a size. ------------------------------------------------- Gary Replies: #1, while an OS can implement directories as a file of information, I think its conceptually wrong for this function to ask for its "size". When iterating through a file system you should first guarantee that the file name is a file and not that of a sub directory. The 4th answer would be to return the total size of all the files within the directory. But I think that's also conceptually confusing as well. Yours, -Gary-

1 0

RE: [boost] 4 more associative containers.
by Powell, Gary 03 Feb '04

03 Feb '04

I'm interested. I ran into the same issues with std::set that you have and because of it, switched to a map when it wasn't really necessary. Regarding acceptance by boost... I'm interested and will take a look at the code. -Gary-

1 0

RE: [boost] should boost::ref forward some operators?
by Powell, Gary 03 Feb '04

03 Feb '04

-------------------------------------------- I ran into the following problem. I have an algorithm which looks like: template<typename in_t, typename out_t> void Alg (in_t in, in_t inend, out_t out) { for (; in != inend; in++, out++) do_something() } Now if I want to call this algorithm more than once, it would be convenient to pass out by ref, so it would be incremented: Alg (v.begin(), v.end(), boost::ref (out)) that is, pass a reference to some kind of output iterator this fails, because boost::ref doesn't have operator++ defined for reference_wrapper. My question is, should boost::ref forward operators like ++ so that this would work? ---------------------------------------------- Gary Replied: I think you need a different tool, either FC++ or Lambda. "ref()" is just a simple wrapper to make something act like a reference. What you need is the whole operator set and Lambda and FC++ have those. Alg(v.begin(), v.end(), boost::lambda::var(out) ); Should work as you want. Yours, -Gary-

1 0

[filesystem] file_size() added
by Beman Dawes 03 Feb '04

03 Feb '04

I've added a file_size() function to the CVS HEAD. It has been tested only on Windows. It hasn't even been compiled on other systems. Testing is a bit difficult. The regular operations_test has been updated to cover several cases, but it would place a burden on testers to test the cases of file sizes requiring 32-bit and greater than 32-bit representations. In other words: * File sizes between 2,147,483,648 and 4,294,967,295. * File sizes greater than 4,294,967,295. boost-root/libs/filesystem/example now contains a program file_size.cpp and a simple Jamfile to build it. Of course it can also be build with your favorite make tool or IDE. When invoked from the command line with a (native) file path, it will display the size of the file in bytes. To know if the value is correct, you have to look at the file size with some system specific tool such as "dir", "ls", or a graphical file explorer. It works with large files on Windows, using Borland 0x0564, CodeWarrior 8.3, GCC 3.3.1 cygming special, Intel 8.0, Microsoft 7.0 and 7.1. It fails to compile on VC++6.0 because of limited 64-bit support. I'd appreciate hearing test results on other systems, particularly a variety of POSIX systems. If it doesn't work for large files on your system, suggestions to get it working will be much appreciated. Thanks, --Beman

1 0

Borland c++6 is compatible with random lib
by Narendran 03 Feb '04

03 Feb '04

Sir, I tried random number generation using boost random. I used uniform_int for my random generation. When I tried with the Borland c++ 6.0 personal it worked correctly. Again same code I tried to compile in Borland c++ 6.0 professional it is showing the error as follows: " [C++ Error] uniform_int.hpp(210): E2404 Dependent type qualifier 'boost::is_float<long>' has no member type named 'value' " Will you please give suggestion in this error. Thanks & Regards, Narendran.

2 1

1.31.0 closed for changes without permission
by Beman Dawes 03 Feb '04

03 Feb '04

Please make no more changes to the RC_1_31_0 branch without the release manager's permission. The one exception is removal of is_abstract code. We need to be totally stable so that the regression tests can cycle one last time. --Beman PS: For the next release, we need to define written "release discipline". What kind of changes are allowed at various points, such as after branch, after release candidates start, etc.

7 21

shared_pointer for C-allocated object?
by Neal D. Becker 03 Feb '04

03 Feb '04

I have some legacy C code that returns a pointer: fftw_plan fftw_create_plan(int n, fftw_direction dir, int flags); where fftw_plan is a pointer. Can I use shared_pointer to wrap it? I guess the issue is that eventually delete will be called on this pointer, but it wasn't allocated with new. Is this a problem?

6 11

Re: [boost] Re: [filesystem] size() on directory?
by Beman Dawes 03 Feb '04

03 Feb '04

At 04:00 AM 2/3/2004, Christoph Ludwig wrote: >I don't know about other filesystems, but in the examples above it >makes perfectly sense to ask for the size of a directory (rather than >the sum of the size of its content). It isn't available on other systems. Windows reports 0, for example. --Beman

1 0

Re: class static constants, mpl, and linker problems
by David Abrahams 03 Feb '04

03 Feb '04

Daniel Krügler <dsp(a)bdal.de> writes: > - Assumption one: Boost does not provide the definitions of > potential static constants hidden by the BOOST_STATIC_CONSTANT > definition (I used only the headers of the library, so my potential > testing bug would be that I had to include the corresponding > translation units of boost providing the constant's definitions, > but sorry - I did not find them!). In general BOOST_STATIC_CONSTANT is used within templates, so the definition of a corresponding member may be given in the header file: template <int N> struct int_ { BOOST_STATIC_CONSTANT(int, value = N); }; #ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION template <int N> int const int_<N>::value; #endif > As I said: If this assumption is false, please blame me straight > for incomplete testing and for trying to spread bad rumors on this > (really!) great library. It's probably not false in most cases. > - Assumption two: Even if Boost does provide these definitions, > there may occur problems due to the VC7.1 flags /Za and /Ze (aka > disabling and enabling language extensions), which I will explain > in the following. The same point applies as to assumptions one, if > I did incomplete testing or testing with rather old boost libraries. > > The nasty thing concerning the /Ze flag is that it effectively does > not "extend" the language in every case. A small testing case is the > following program: > > a.h: ------------------------- > #ifndef A_H_INC > #define A_H_INC > struct A > { > static const int val = 42; // Declaration of a static member variable > }; > #endif > ------------------------- > > a.cpp -------------------- > #include "a.h" > const int A::val; // Definition might be needed, if the program accesses > // the adress of A::val > ------------------------- > > main.cpp -------------------- > #include "a.h" > int main() > { > } > ------------------------- > > Although this is a C++ Standard compliant program, it will not > successfully link with the /Ze flag enabled, which is to my opion a > real compiler bug (which I already posted to m.p.v.language, but got > no reasonable response yet). The obtained error message is: > > error LNK2005: "private: static int const A::val" (?val@A@@0HB) already > defined in a.obj > error LNK2005: "private: static int const A::val" (?val@A@@0HB) already > defined in main.obj Looks like a bug to me. > Question: Is this special deficiency of the VC7.1 compiler taken > account in the current boost library? I doubt it. How would we do that? > I think, it is impossible to demand, that users are enforced to use > either only /Ze or only /Za, because each of these choices has some > considerable drawbacks (at least on Windows systems...) Well, it seems to me that we can only respond to actual problems. Do you have an actual case of using a Boost library where these issues cause you trouble? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 9

[filesystem] On POSIX, any reliable way to find file size?
by Beman Dawes 03 Feb '04

03 Feb '04

There have been requests for a Boost.Filesystem function which returns file size. But I don't want to provide such a function if it will be unreliable. On POSIX compliant 32-bit systems, is there any reliable way to find the size of a file? It looks to me as if stat::st_size's type of off_t isn't large enough on 32-bit systems to cope with large file sizes. Am I wrong, or missing something? How big is the largest possible file on, say, Linux? Isn't it larger than the 2 gigs a 32-bit signed integer can represent? --Beman

5 10