- Boost - lists.boost.org

Solaris/gcc integer_traits #error on build
by Christopher Wiedel 07 Feb '05

07 Feb '05

I ran into a problem with the integer_traits.hpp file in the boost subdirectory at build time, specifically while trying to build the libboost_python-* files. It seems to be the same problem that was earlier encountered here: http://lists.boost.org/MailArchives/boost/msg76535.php I downloaded the patched version of integer_traits.hpp from CVS, but the problem persisted. I checked the #if statement beginning on line 87 of the newer version of the file, and there didn't appear to be any case for Solaris. I was building on a Solaris 8 machine, using gcc 3.3.2. I modified the file to add another case (line 101): 87 #ifndef BOOST_NO_INTRINSIC_WCHAR_T 88 template<> 89 class integer_traits<wchar_t> 90 : public std::numeric_limits<wchar_t>, 91 #if defined(WCHAR_MIN) && defined(WCHAR_MAX) 92 public detail::integer_traits_base<wchar_t, WCHAR_MIN, WCHAR_MAX> 93 #elif defined(__BORLANDC__) || defined(__CYGWIN__) || defined(__MINGW32_ _) || (defined(__BEOS__) && defined(__GNUC__)) 94 // No WCHAR_MIN and WCHAR_MAX, whar_t is short and unsigned: 95 public detail::integer_traits_base<wchar_t, 0, 0xffff> 96 #elif (defined(__sgi) && (!defined(__SGI_STL_PORT) || __SGI_STL_PORT < 0 x400))\ 97 || (defined __APPLE__)\ 98 || (defined(__OpenBSD__) && defined(__GNUC__))\ 99 || (defined(__NetBSD__) && defined(__GNUC__))\ 100 || (defined(__FreeBSD__) && defined(__GNUC__))\ 101 || (defined(__sun__) && defined (__GNUC__) && (__GNUC__ == 3)\ 102 || (defined(__hpux) && defined(__GNUC__) && (__GNUC__ == 3) && !defined(__SGI_STL_PORT)) 103 // No WCHAR_MIN and WCHAR_MAX, wchar_t has the same range as int. 104 // - SGI MIPSpro with native library 105 // - gcc 3.x on HP-UX 106 // - Mac OS X with native library 107 // - gcc on FreeBSD, OpenBSD and NetBSD 108 public detail::integer_traits_base<wchar_t, INT_MIN, INT_MAX> 109 #elif defined(__hpux) && defined(__GNUC__) && (__GNUC__ == 2) && !defined(__SGI_STL_PORT) 110 // No WCHAR_MIN and WCHAR_MAX, wchar_t has the same range as unsigned int. 111 // - gcc 2.95.x on HP-UX 112 // (also, std::numeric_limits<wchar_t> appears to return the wrong values). 113 public detail::integer_traits_base<wchar_t, 0, UINT_MAX> 114 #else 115 #error No WCHAR_MIN and WCHAR_MAX present, please adjust integer_traits< > for your compiler. 116 #endif 117 { }; 118 #endif // BOOST_NO_INTRINSIC_WCHAR_T The file then compiled without a problem when inluded in the python libraries. The question I still have is whether this has the potential to break something somewhere else in the code. -- Christopher Wiedel Software Installs Group University of Southern California

2 1

RE: [boost] Re: Problem with code in common_factor_ct.hpp
by Brian Braatz 07 Feb '05

07 Feb '05

> -----Original Message----- > On Behalf Of David Abrahams > Daryle Walker <darylew(a)hotmail.com> writes: > > > On 2/2/05 5:24 PM, "David Abrahams" <dave(a)boost-consulting.com> wrote: > > > >> Daryle Walker <darylew(a)hotmail.com> writes: > >> > >>> On 1/31/05 4:29 PM, "David Abrahams" <dave(a)boost-consulting.com> > wrote: > >>> > >>>> "John H. Spicer" <jhs(a)edg.com> writes: > >>>> > >>>>> This file includes the code below in an #else for > >>>>> BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION. We give an error on that > code > >>>>> because of a missing "template" keyword (between :: and helper). > >>>>> > >>>>> What is the proper channel for reporting things like this? > >>>> > [Dave Abrahams] > Yes, we still have compilers with > BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION. Not every library has > officially dropped support for vc6/7 yet. [Brian Braatz] Humble request from the "Front Lines" :) Please continue supporting vc7. I am currently in the unenviable position of BACK PORTING code that uses boost from vc7.1 to vc7. The first thing to go was lambda. The funny thing is about 6 months ago I was thinking it seemed silly to keep things like boost.bind around. But now I am using that heavily instead of lambda. My situation is we have 1.7 million lines of code we are trying to upgrade. Unfortunately we have about 40-50 people who have had vc7 purchased for them by the project and we do not have the budget to upgrade compilers. Vc7 is, in my opinion probably (unfortunately) still a compiler many folks are stuck with.

1 0

Re: Problem with code in common_factor_ct.hpp
by David Abrahams 07 Feb '05

07 Feb '05

"John H. Spicer" <jhs(a)edg.com> writes: > This file includes the code below in an #else for > BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION. We give an error on that code because > of a missing "template" keyword (between :: and helper). > > What is the proper channel for reporting things like this? http://www.boost.org/more/bugs.htm shows several alternatives. > template < unsigned long Value2 > > struct helper > { > BOOST_STATIC_CONSTANT( unsigned long, value > = static_gcd_helper2_t<Value2>::helper<Value1 % Value2>::value ); > }; > -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 4

Re: [boost] Re: [boost.tr1?] request for a hash<> implementation
by JOAQUIN LOPEZ MU?Z 07 Feb '05

07 Feb '05

Hi Daniel, ----- Mensaje original ----- De: Daniel James <daniel(a)calamity.org.uk> Fecha: Domingo, Febrero 6, 2005 7:12 pm Asunto: [boost] Re: [boost.tr1?] request for a hash<> implementation > JOAQUIN LOPEZ MU?Z wrote: > > What I'm interested in in the short term is the hash<> functor > > alone. Of course unordered containers are much more interesting, > > but this will have to undergo the usual review process, I guess. > > Do you think we can put your hash<> implementation under > > boost/functional/hash.hpp and have some short docs for it? > > I've just uploaded a new version. I've rewritten the hash > functions > based on Peter's design. I'll write some documentation and some > more > tests soon. > You've been fast! I've taken a look at your stuff and have a couple of concerns/suggestions: 1. Now the file is boost/hash/functional.hpp. Wouldn't it be better to call it boost/functional/hash.hpp? As I see it, hash<> is part of TR1 future <functional>, so the naming I propose looks more consistent. 2. The header includes <set> and <map>, which can be quite heavy if the user has no intention to use the corresponding hash_value overloads. Alas, I don't know of any way to avoid the inclusions, since a forward declaration of these containers can fail due to the freedom stdlib implementers have to add additional template parameters to those specified by the standard. Any idea? I'll soon bundle your header with a preview of hashed indices for Boost.MultiIndex, probably the next week. Thank you so much for your effort, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

RE: [boost] Boost Profiler Proposal
by Brian Braatz 07 Feb '05

07 Feb '05

Yes. I would use this library. Though, personally, I would like a greater scope of what it does. The details of other things I would like to see from this library or a companion library are here: http://tinyurl.com/5sbyx > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > Sent: Monday, February 07, 2005 7:38 AM > To: Boost mailing list > Subject: [boost] Boost Profiler Proposal > > I have updated the Profiler (and done some testing using Visual C++, 7.1) > at > http://www.cdiggins.com/profiler/ . I have mostly decided to freeze the > features for the profiler mini-library as described and posted at > http://www.cdiggins.com/profiler/ . My question to the group is: would you > use this library as it is? If you don't want to mail the group, I would > appreciate even just a quick note: yes, no, maybe. > > If anyone has a POSIX high-resolution timer modeled on the Boost.Timer > concept to share, it would be greatly appreciated! I would also appreciate > new profiling policies, to include as examples. > > PS: this profiling tool seems to be a natural fit for the Boost.Test > macros > like BOOST_CHECK_NO_THROW, I currently use something like: > > BOOST_PROFILE_AND_CHECK_NO_THROW(TKN) > BOOST_CHECK_NO_THROW(BOOST_PROFILE(TKN)) > > Christopher Diggins > Object Oriented Template Library (OOTL) > http://www.ootl.org > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] Re: [boost.tr1?] request for a hash<> implementation
by JOAQUIN LOPEZ MU?Z 07 Feb '05

07 Feb '05

----- Mensaje original ----- De: Daniel James <daniel(a)calamity.org.uk> Fecha: Sábado, Febrero 5, 2005 5:36 pm Asunto: [boost] Re: [boost.tr1?] request for a hash<> implementation > John Maddock wrote: > > Anyone else want to throw in their thoughts? What's the > timescale on > > the unordered container development, how much is there left to do? > > I'll upload a new version to the file vault later today, or maybe > tomorrow, which should be compliant to the draft. I haven't > written any > documentation yet, I guess I'll probably just write an > introduction and > refer to the draft for reference (as Beman Dawes suggested), if > that's okay. > > There are a few areas which could do with some improvement, such > as the > hash functions, which are pretty basic. But I guess they can be > left for > later if you want to get it in soon. > Hi Daniel, What I'm interested in in the short term is the hash<> functor alone. Of course unordered containers are much more interesting, but this will have to undergo the usual review process, I guess. Do you think we can put your hash<> implementation under boost/functional/hash.hpp and have some short docs for it? Are you planning to improve the hashing algorithms (in particular for strings, which I guess it's the most improvable part)? If I could have this in time for Boost 1.33 I'd be extremely grateful, since Boost.MultiIndex hashed indices (practically finished now) need a hash<>, and I don't think it is convenient that each library ships with its own version. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 8

ANN: new ml dedicated to Generic Linear Algebra
by Toon Knapen 07 Feb '05

07 Feb '05

Hi all, I would like to inform you that a new mailinglist has been created that is dedicated to Generic Linear Algebra Software (GLAS). The aim of the glas-ml is to define a generic interface for linear algebra operations and to provide a reference implementation for this interface in C++. This forum is intended for people with a strong interest in numerics and/or C++ (actually the combination of both is absolutely necessary to achieve our goals). The list was created a few weeks ago and it has been suggested already to join the MTL3 (a new rewrite of MTL) effort and this glas effort. So you might want to dive into the archives already to read some more about the initial design discussions. The ml is hosted by the Open Systems Lab of Indiana University (thanks!) and you can join the list at: http://lists.boost.org/mailman/listinfo.cgi/glas. Toon Knapen

3 3

program_options docs on options_description_easy_init( value_sema ntic * )
by Michiel Salters 07 Feb '05

07 Feb '05

The class options_description_easy_init is supposed to provide "convenient creation syntax to option_description" but I find it's a bit less convenient than advertised. The problem is that the class isn't documented, and that's a serious problem if you take raw pointers. I found out that a value_semantic object was being desroyed by a shared_ptr<value_semantic> dtor, even though I had passed the address of a local object. Besides the fact that it's undocumented, shouldn't it take a shared_ptr<value_semantic> in the first place? The orginal owner miught like to keep a pointer to the object as well. ( I'm porting Wave to boost 1.32, so I'm not writing the program_options code from scratch. Even so, I found the documentation under par - wouldn't use it myself. For instance, the 'overview' section talks a lot about the value_semantic class but uses the value<T> class. ) Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

2 1

Documentation error for program_options::positional_options_description::add
by Lars Iversen 07 Feb '05

07 Feb '05

In boost/boost/libs/program_options/doc/overview.xml revision 1.14, examples state that function program_options::positional_options_description::add accepts three parameters, but the function in boost/boost/boost/program_options/positional_options.hpp revision 1.3 only accepts two parameters. Regards, Lars

2 1

Configuration bug (xcode on OS X)
by Benjohn 07 Feb '05

07 Feb '05

Compiling with xcode on OS X, and targeting a cocoa, objective c++ application, we've had some configuration trouble with boost (shared_ptr in particular) not compiling with multithreaded support. This seems to come down to a problem in the "file boost/config/platform/macos.hpp" which has the lines: # ifndef TARGET_CARBON # include <boost/config/posix_features.hpp> # endif Because TARGET_CARBON is defined as part of Apple's framework (which I think is normal for a cocoa application), "posix_features.hpp" doesn't get a chance to make sure BOOST_HAS_THREADS gets defined. Posting [1] to this list indicates that the "ifndef TARGET_CARBON" was added as a work around for codewarrior's environment, and [2] mentions that there's a problem with it as a solution. I've patched this based on a suggestion by Glen Simmons (thanks) by: * creating a modified copy of "macos.hpp" that always includes "posix_features.hpp", * define BOOST_PLATFORM_CONFIG (in our prefix file) to point at the patch. Of course, it would be splendid if boost figured all this out itself. I'd be more than happy to test out an official fix. Cheers, Benjohn Barnes [1] http://lists.boost.org/MailArchives/boost-users/msg02664.php [2] http://lists.boost.org/MailArchives/boost-users/msg07979.php

2 3