- Boost-users - lists.preview.boost.org

Re: [Boost-Users] Re: Re: Slight Alteration to Boost Directory Structure
by William E. Kempf 08 Jan '03

08 Jan '03

> From: "Paul Mensonides" <yg-boost-users(a)m.gmane.org> > "William E. Kempf" <wekempf(a)cox.net> wrote in message > news:20030108172855.VIMZ4411.lakemtao01.cox.net@smtp.east.cox.net... > > > > I believe that he is talking about the root Boost directory which is the > > > parent directory of the Boost headers. If, for instance, I have a > directory > > > "include" that I want to put all my library headers in and have a single > > > environment variable to specify the header search paths. This cannot be > > > done with Boost because the Boost headers are located at > > > "boost/boost/*.hpp", not "boost/*.hpp". Furthermore, you can't even put > > > Boost in the same directory as other includes, because you might get a > > > conflict between "include/boost" and "include/boost/boost". It doesn't > > > bother me personally, but I see the point that he is getting at. > > > > If that's the point (which doesn't seem to be, since he talks about "new > boost libraries" doing the right thing), I can't agree. Moving Boost > headers out of a boost subdirectory and into the top-level include directory > (so <boost/shared_ptr.hpp> becomes <shared_ptr.hpp>) would only result in > name clashes with other headers. > > That is not what he (or I) means. He is suggesting that the path to > "shared_ptr.hpp" should be "$INCLUDE/boost/shared_ptr.hpp" rather than > "$INCLUDE/boost/boost/shared_ptr.hpp", which is the way it is now. > Everything would still be the same for including headers except that only a > single search path is necessary to setup with the compiler. That's the way it is now *only* if you set your include directories incorrectly. When they are properly set to $BOOST_ROOT then it's only <boost/shared_ptr.hpp>, not <boost/boost/shared_ptr.hpp>. William E. Kempf wekempf(a)cox.net

2 1

Re: [Boost-Users] Re: Slight Alteration to Boost Directory Structure
by William E. Kempf 08 Jan '03

08 Jan '03

> From: "Paul Mensonides" <yg-boost-users(a)m.gmane.org> > Date: 2003/01/08 Wed PM 12:18:35 EST > To: boost-users(a)yahoogroups.com > Subject: [Boost-Users] Re: Slight Alteration to Boost Directory Structure > > "William E. Kempf" <wekempf(a)cox.net> wrote in message > > > > 2. Each library bundled with boost means another #include search > > > path needs to be added. > > > > No, there's only one path added for all Boost libraries, > $BOOST_ROOT/boost. > > Here I think he is talking about libraries other than Boost. How can anything we do to the Boost directory structure effect this? I don't really think that's what he meant. > > > Proposed solution: > > > 1. Create a single boost include directory instead of having the two > > > nested ones that there are now. > > > > What two nested ones? > > I believe that he is talking about the root Boost directory which is the > parent directory of the Boost headers. If, for instance, I have a directory > "include" that I want to put all my library headers in and have a single > environment variable to specify the header search paths. This cannot be > done with Boost because the Boost headers are located at > "boost/boost/*.hpp", not "boost/*.hpp". Furthermore, you can't even put > Boost in the same directory as other includes, because you might get a > conflict between "include/boost" and "include/boost/boost". It doesn't > bother me personally, but I see the point that he is getting at. If that's the point (which doesn't seem to be, since he talks about "new boost libraries" doing the right thing), I can't agree. Moving Boost headers out of a boost subdirectory and into the top-level include directory (so <boost/shared_ptr.hpp> becomes <shared_ptr.hpp>) would only result in name clashes with other headers. William E. Kempf wekempf(a)cox.net

2 1

Re: [Boost-Users] Slight Alteration to Boost Directory Structure
by William E. Kempf 08 Jan '03

08 Jan '03

> From: "Simon Bailey <conic(a)bigpond.com>" <conic(a)bigpond.com> > > I've been using boost for about a year now. I upgraded from 27 to > 28 and appreciated the backwards compatability. But I'm wondering > if a slight modification to the directory structure is in order? > > I have written a cross-platform class library. The library provides > high-level business objects and comes bundled with boost 1.28.0 to > provide support for threads, CRC, shared_ptr, and function (or > whatever else the end user might want). > > Currently, users need to add two directories to their #include > search path: > include/boost > include/sb_library > > Then, in their source code: > #include <boost/shared_ptr.hpp> > #include <boost/thread/thread.hpp> > #include <sb_library/business_facet/business_object.h> > > Two problems (albeit very minor ones!) > 1. Boost has two levels of includes (due to it's history of course). Two levels? There's only one, $BOOST_ROOT/boost. To avoid name clashes, many libraries are located in library specific directories off of this, as you see with <boost/thread/thread.hpp>. Something that many libraries do (and Boost.Threads will be updated to do shortly) is to have a single header in the root include directory that includes all of the headers from the library directory, thus for Boost.Threads you'd include only <boost/thread.hpp> instead of <boost/thread/thread.hpp>, <boost/thread/mutex.hpp> etc. > 2. Each library bundled with boost means another #include search > path needs to be added. No, there's only one path added for all Boost libraries, $BOOST_ROOT/boost. > Proposed solution: > 1. Create a single boost include directory instead of having the two > nested ones that there are now. What two nested ones? > 2. Put all boost headers into a sub-directory of boost > eg <boost/ptr/shared_ptr.hpp>, <boost/thread/thread.hpp>. (It's a > small change for existing users to change their includes). This is mostly how it is now... though many headers don't live in library specific subdirectories (which is probably how it should be). > 3. Place all src, documentation etc. into a directory within boost > called "private" or something. > > Suggested directory structure: > > --include // This is the only directory needed to be specified in > the #include search path > ----other_library1 > ----other_library2 > ----boost > -------ptr > -------thread > -------private > ----------documentation > ----------src > ----------thread > > In other words, you will have <boost/ptr/...> and <boost/thread/...> > but never <boost/private/...>. This is just a variation on what's currently done, and I can't see how it buys you anything, and actually is a more confusing layout IMHO. > I think it's worth breaking the backwards compatability a little in > order to bring the older boost headers in line with the directory > structure of the newer ones like thread. I also think enabling a > single include path for multiple libraries is useful. Boost.Threads followed existing directory guidelines (as do all libraries). There's no difference between it and "older" libraries (note that Boost.Threads is not that new). William E. Kempf wekempf(a)cox.net

2 1

is_convertible and array size question
by globeordi＠free.fr 08 Jan '03

08 Jan '03

Hello all, Just perhaps a silly question but who knows ? I have a small class that encapsulates a char[] type such as: template <const unsigned int n> struct C_Array { enum { size = n }; typedef char (&Array)[size]; typedef const char (&ConstArray)[size]; C_Array() { memset(&v[0], 0, 30); v[0] = '6'; v[1] = '7'; v[2] = '8'; v[3] = '9'; } char v[n]; int toto; char & operator[](const unsigned int i) { return v[i]; } const char & operator[](const unsigned int i) const { return v[i]; } operator Array () { return v; } operator ConstArray () const { return v; } }; Thanks to the operator Array, the objects of this class can be converted to references to arrays and the following pseudo-code works fine as expected: C_Array<30> obj; cout << boost::is_convertible<obj, char[]>::value << endl; But what I want to get is the actual size of the converted array. In the example the size is 30. It is not very important (workaround exists), just curious to see how it can be done without telling to compiler more information. Best regards Joseph Canedo

1 0

RE: [Boost-Users] Problem with BOOST_STATIC_ASSERT
by Randy Bowen 08 Jan '03

08 Jan '03

Some further follow-up on this. I've created a minimal program that exhibits the new problem behavior: /******************************************/ #include <boost/type_traits.hpp> #include <boost/static_assert.hpp> template < typename ValueType > struct A { BOOST_STATIC_ASSERT(boost::is_integral<ValueType>::value); }; extern "C" int main(int argc, char* argv[]) { return 0; } /******************************************/ The fact that this assertion fails is counter-intuitive to me, since there is no instantiation to compile. Note that this behavior seems limited to the use of "is_integral" as the type predicate. Constructing a similar program using "is_POD" behaves as expected: /******************************************/ #include <boost/type_traits.hpp> #include <boost/static_assert.hpp> template < typename ValueType > struct B { BOOST_STATIC_ASSERT(boost::is_POD<ValueType>::value); }; struct C {}; extern "C" int main(int argc, char* argv[]) { // B<int> Bint; /* OK to add */ // B<C> BC; /* causes error */ return 0; } /******************************************/ Here, no error occurs until there is an attempt to instantiate B<C>. Randy Bowen -----Original Message----- From: Randy Bowen Sent: Tuesday, January 07, 2003 1:40 PM To: Boost-Users(a)yahoogroups.com Subject: [Boost-Users] Problem with BOOST_STATIC_ASSERT I'm in the process of updating some applications from use of Boost 1.28.0 to 1.29.0, using MSVC7. I've noticed that a number of static assertions that used to compile now generate errors. The assertions all use is_integral to perform a type validation - e.g.: BOOST_STATIC_ASSERT(::boost::is_integral<value_type>::value); This produces an error of the form: c:\Perforce\Development\Web\cppinclude\domestic\Application Framework\State Machine Engine\StringSerializer.h(145) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' with [ x=false ] c:\Perforce\Development\Web\cppinclude\domestic\Application Framework\State Machine Engine\StringSerializer.h(143) : see reference to class template instantiation 'sme::StringSerializer<_StringType,>::StringWriter<<template parameter>>' being compiled c:\Perforce\Development\Web\cppinclude\domestic\Application Framework\State Machine Engine\StringSerializer.h(169) : see reference to class template instantiation 'sme::StringSerializer<_StringType,>' being compiled I believe that the data type is integral, and is complete at compile time. Any known reason why this would happen? Randy Bowen

2 1

Severe bugs in lambda/algorithm.cpp
by Markus Werle 08 Jan '03

08 Jan '03

Hi! I wonder whether this file ever was included by anyone else but me and which compiler did let this pass without complaint. Besides the #include <utilities> which never ever happens we have 2 errors in struct count struct count { template <class Args> struct sig { typename ::std::iterator_traits< // **************************************************** // ERROR: typedef is not allowed here typedef typename boost::remove_const< typename boost::tuples::element<1, Args>::type >::type >::difference_type type // ERROR: semicolon missing }; Same errors in count_if beginning at line 172. ----------------------------------------------------- In line 613: a duplicate parameter name c operator()(A a, B b, C c, D c) const Same on line 681 best regards, Markus

1 0

lambda/algorithm.hpp: #include <utilities>?
by Markus Werle 08 Jan '03

08 Jan '03

Hi! Line 23 in lambda/algorithm.hpp reads #include <utilities> // for std::pair IMHO (and that of intel's C++ and SGI's documentation) this line should be #include <utility> // for std::pair right? best regards, Markus

1 0

Slight Alteration to Boost Directory Structure
by Simon Bailey <conic＠bigpond.com> 07 Jan '03

07 Jan '03

I've been using boost for about a year now. I upgraded from 27 to 28 and appreciated the backwards compatability. But I'm wondering if a slight modification to the directory structure is in order? I have written a cross-platform class library. The library provides high-level business objects and comes bundled with boost 1.28.0 to provide support for threads, CRC, shared_ptr, and function (or whatever else the end user might want). Currently, users need to add two directories to their #include search path: include/boost include/sb_library Then, in their source code: #include <boost/shared_ptr.hpp> #include <boost/thread/thread.hpp> #include <sb_library/business_facet/business_object.h> Two problems (albeit very minor ones!) 1. Boost has two levels of includes (due to it's history of course). 2. Each library bundled with boost means another #include search path needs to be added. Proposed solution: 1. Create a single boost include directory instead of having the two nested ones that there are now. 2. Put all boost headers into a sub-directory of boost eg <boost/ptr/shared_ptr.hpp>, <boost/thread/thread.hpp>. (It's a small change for existing users to change their includes). 3. Place all src, documentation etc. into a directory within boost called "private" or something. Suggested directory structure: --include // This is the only directory needed to be specified in the #include search path ----other_library1 ----other_library2 ----boost -------ptr -------thread -------private ----------documentation ----------src ----------thread In other words, you will have <boost/ptr/...> and <boost/thread/...> but never <boost/private/...>. I think it's worth breaking the backwards compatability a little in order to bring the older boost headers in line with the directory structure of the newer ones like thread. I also think enabling a single include path for multiple libraries is useful. Cheers Simon

1 0

Problem with BOOST_STATIC_ASSERT
by Randy Bowen 07 Jan '03

07 Jan '03

I'm in the process of updating some applications from use of Boost 1.28.0 to 1.29.0, using MSVC7. I've noticed that a number of static assertions that used to compile now generate errors. The assertions all use is_integral to perform a type validation - e.g.: BOOST_STATIC_ASSERT(::boost::is_integral<value_type>::value); This produces an error of the form: c:\Perforce\Development\Web\cppinclude\domestic\Application Framework\State Machine Engine\StringSerializer.h(145) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' with [ x=false ] c:\Perforce\Development\Web\cppinclude\domestic\Application Framework\State Machine Engine\StringSerializer.h(143) : see reference to class template instantiation 'sme::StringSerializer<_StringType,>::StringWriter<<template parameter>>' being compiled c:\Perforce\Development\Web\cppinclude\domestic\Application Framework\State Machine Engine\StringSerializer.h(169) : see reference to class template instantiation 'sme::StringSerializer<_StringType,>' being compiled I believe that the data type is integral, and is complete at compile time. Any known reason why this would happen? Randy Bowen

1 0

uBLAS - Calculation of Inverse and/or Least Squares
by jonny5cents <jon_nichols95＠hotmail.com> 07 Jan '03

07 Jan '03

Hello All, Can anyone suggest the best way to use uBLAS to calculate the inverse of a matrix?? One of the reasons I want to do this is to solve a linear least squares problem, which I know can be done without explicitly solving for the inverse. Does anyone know if this is possible?? thanks, jon

3 2