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

RE: [Boost-Users] Problem with BOOST_STATIC_ASSERT
by richard_cox＠dell.com 09 Jan '03

09 Jan '03

On Wednesday, January 08, 2003 5:29 PM, Randy Bowen [mailto:rbowen@stamps.com] wrote: > -----Original Message----- > From: > Sent: > To: Boost-Users(a)yahoogroups.com > Subject: RE: [Boost-Users] Problem with BOOST_STATIC_ASSERT > > > Thanks for investigating this, John. I don't have access to > the beta VC7.1 compiler. Do you (or does anyone else) know > if this will still be a problem with the forthcoming version > of the Microsoft compiler? > > Randy Bowen > > > > -----Original Message----- > From: John Maddock [mailto:john_maddock@compuserve.com] > Sent: Wednesday, January 08, 2003 4:17 AM > To: Boost-Users(a)yahoogroups.com > Subject: Re: [Boost-Users] Problem with BOOST_STATIC_ASSERT > > > > 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: > > I can reproduce that with both VC6 and VC7, all the other > compilers I have access to are OK with it. It's clearly a > compiler bug, because the assert is triggered even though no > instance of the template class is ever created. Unfortunately > I don't have any kind of workaround :-( > > John Maddock > http://ourworld.compuserve.com/homepages/john_maddock/index.ht m The code as quoted built without error OK on VC++7.1 RC2 (Final Beta) here... using snapshot of boost taken last weekend. Richard Cox Senior Software Developer Dell Technology Online All opinions and statements mine and do not in any way (unless expressly stated) imply anything at all on behalf of my employer

1 0

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

09 Jan '03

> From: "Simon Bailey <conic(a)bigpond.com>" <conic(a)bigpond.com> > --- In Boost-Users(a)yahoogroups.com, "Paul Mensonides" <yg-boost- > users@m...> wrote: > > "William E. Kempf" <wekempf@c...> wrote in message > > > > > That still misses the point. Boost currently won't help you to > install > > the library, but installation certainly wouldn't entail copying the > entire > > $BOOST_ROOT tree to the $INCLUDE directory on your system. You'd > only copy > > the $BOOST_ROOT/boost tree there. > > > > Yes, and this is why I said that it hasn't been a problem for me. > However, > > I see where the OP is coming from as well. > > > > Paul Mensonides > > Paul understands me correctly. I confused the issue by making two > requests at once. > > Mainly, I want to include other libraries alongside boost and provide > a single include path. That is the first wish. Bill has pointed out > that I could move BOOST_ROOT/boost into my INCLUDE directory. I > didn't know that - I thought it might break things. > > The second thing I was suggesting (and this is quite minor) was that > we make the change to include smart_ptr.hpp (etc.) and thread.hpp > (etc.) at the same directory level. I thought that the > subdirectories (like /thread) were the way of the future. I didn't > realise that the plan was to move all the headers into > BOOST_ROOT/boost. > > So it seems my first wish is not needed and my second wish is already > on the drawing board. :-) No, it's never been planned to move all headers into $BOOST_ROOT/boost. That would be problematic at best. The headers are in subdirectories to avoid name clashes, and that's how it should be for large libraries and/or libraries that use common names. What many of these libraries do, and what Boost.Threads will do with the next release, however, is to have a *single* include header in $BOOST_ROOT/boost that includes all the other headers from the specific sub-library. This (mostly) avoids the dangers of name clashes, gives a simple single include file for many uses, yet retains the ability for users to include only what they need to in order to reduce compilation time, etc. For example, both of the following would be legal: #include <boost/thread/thread.hpp> #include <boost/thread/mutex.hpp> #include <boost/thread/condition.hpp> // ... code using boost::thread, boost::mutex and // boost condition - or - #include <boost/thread.hpp> // ... code using boost::thread, boost::mutex and // boost condition William E. Kempf wekempf(a)cox.net

1 0

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

09 Jan '03

> From: "Simon Bailey <conic(a)bigpond.com>" <conic(a)bigpond.com> > Suddenly I remember why I wanted the directory structure change... > > I could achieve what I want by moving BOOST_ROOT/boost into my > INCLUDE directory. But the disadvantage with that is that I need to > perform a move operation. > > *** In my current development environment, my source control > directory structure mirrors my release directory structure exactly. > *** > > So, in source control I have: > > /include > --/BOOST_ROOT > ----/boost <- headers are here > --/my_lib <- headers are here > > But, in my release I want to have: > /include > ----/boost <- headers are here > ----/my_lib <- headers are here > > I was suggesting the change so that source control and relase could > be the same. This would necessitate that documentation and source > for boost would have to be within the boost (include) directory. > Some might find that a worse alternative I suppose. I think most would. I know I do. William E. Kempf wekempf(a)cox.net

1 0

which boost lib to use for generic list sort by member function ?
by Philippe Guglielmetti 09 Jan '03

09 Jan '03

I try to define a "sortby" method that would sort a list using any member function that fits some constraints (taking no parms, returning a result that can be compared using the > operator and being const) I wrote this: template <class T> class mylist:public std::list<T> { // ... template <typename T2, typename R, R (T2::*F)() const> struct cmp: public std::binary_function<T,T,bool> { bool operator()(const T& f1, const T& f2) {return (f1.F)() > (f2.F)();}; }; template <typename T2, typename R> bool sortby(R (T2::*F)() const) { sort(cmp<T,R,F>()); return true; }; }; // class mylist using VC6 (I know...) I get these 3 errors: algos.h(356) : error C2440: 'specialization' : cannot convert from 'double (__thiscall cadoo::cadFace::*)(void) const' to 'double (__thiscall cadoo::cadFace::*)(void)' algos.h(356) : error C2975: 'cmp' : invalid template argument for 'F', constant expression expected algos.h(356) : error C2514: 'dyl::List<class cadoo::cadFace>::cmp<class cadoo::cadFace,double,0>' : class has no constructors any idea ? I also checked boost.org for help on functors, lambda ... but could not figure out how to use them simply for my application. thanks! Philippe Guglielmetti

1 0

Boost::python + vc + sgistl problem
by yg-boost-users＠m.gmane.org 09 Jan '03

09 Jan '03

I use Boost::Python module with VC and SGI stl. But I got some compile errors like mix\max redefine.... Who know how to solve this problem??? -- CNews 0.4

1 0

HELP: Command line sample.
by Lichun Bao 09 Jan '03

09 Jan '03

Hi, Can someone please provide a sample single command line compile using g++ that generates the final executable binary for a test example? For example, in the unpacked BOOST directory, how to do something like: g++ <options> libs/graph/example/bfs-example.cpp -o \ /tmp/bfs-example for the final executable? Thanks, Lichun

1 0

Re: [Boost-Users] Boostifying GluCat
by William E. Kempf 08 Jan '03

08 Jan '03

Sorry folks, this posting never should have made the list. As one of the moderators, I hit the wrong button here. Sorry for any inconvenience. William E. Kempf wekempf(a)cox.net

1 0

Boostifying GluCat
by Paul C. Leopardi 08 Jan '03

08 Jan '03

Bjorn, GluCat is a new numeric template class library, hopefully destined for promotion to Boost. I would like to know where there is some documentation on how to: 1. Add concepts. Is there such a thing as a non-commutative algebra concept? How do I check concepts? 2. Add numeric limits. Limits of eg. framed_multi<T> would default to limits of T. 3. Add numeric promotion_traits. What are promotion_traits ? There is currently a discussion on ublas-dev mailing list about promotion_traits within uBLAS. 3. Add numeric type_traits. Thanks On Thu, 9 Jan 2003 00:18, you wrote: > Paul, > unfortunately this post is off topic for Boost-Users, and is thus > rejected. While it may well be of interest to some of our subscribers, > and the usage of uBLAS is a nice success story, we do not allow > announcement postings - only topics related to usage of Boost libraries. > > Regards, > Bjorn Karlsson > Moderator

1 0

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