- Boost - lists.boost.org

Errors in source
by Silex 30 May '06

30 May '06

In compiler_config.hpp, I found the following line: #include "boost/date_time/locale_config.hpp" Maybe it'd be more conventionnal if it used <> instead of "" but that's a minor issue, the problem is when I open this include file I see : #ifndef DATE_TIME_LOCALE_CONFIG_HPP___ #define DATE_TIME_LOCALE_CONFIG_HPP____ This could maybe lead to linker errors as multiple inclusions could occurs. Philippe

2 3

[filesystem] xlC error compiling operations.hpp
by K. Noel Belcourt 30 May '06

30 May '06

Hi, The xlC compiler on the IBM issues a severe error when compiling operations.hpp. The compile error appears to be legitimate (use of an undefined class). Unfortunately I don't have a patch to offer, just the bug report. Thanks. -- Noel Belcourt vacpp.compile.c++ ../../../bin.v2/tools/regression/build/vacpp/ release/link-static/process_jam_log.o "../../../boost/filesystem/operations.hpp", line 732.72: 1540-1118 (S) The declaration of "end_itr" uses the undefined class "boost::filesystem::basic_directory_iterator<boost::filesystem::basic_pa th<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,boost::filesystem::path_traits> >" when the class must be complete. "../../../boost/filesystem/operations.hpp", line 730.21: 1540-0700 (I) The previous message was produced while processing "boost::filesystem::detail::remove_all_aux<boost::filesystem::basic_path <std::basic_string<char,std::char_traits<char>,std::allocator<char> >,boost::filesystem::path_traits> >(const basic_path<std::basic_string<char,std::char_traits<char>,std::allocator< char> >,boost::filesystem::path_traits> &)". "../../../boost/filesystem/operations.hpp", line 473.11: 1540-0700 (I) The previous message was produced while processing "boost::filesystem::remove_all<boost::filesystem::basic_path<std::basic_ string<char,std::char_traits<char>,std::allocator<char> >,boost::filesystem::path_traits> >(const basic_path<std::basic_string<char,std::char_traits<char>,std::allocator< char> >,boost::filesystem::path_traits> &)". "../../../boost/filesystem/operations.hpp", line 689.16: 1540-0700 (I) The previous message was produced while processing "boost::filesystem::remove_all(const path &)". mpCC -c -DBOOST_ALL_NO_LIB=1 -DNDEBUG -O3 -qstrict -qinline -qeh - qrtti -I"../../.." -o "../../../bin.v2/tools/regression/build/vacpp/ release/link-static/process_jam_log.o" "../process_jam_log.cpp"

1 0

Re: [boost] Infinite precision integer draft
by Jarrad Waterloo 30 May '06

30 May '06

Thanks for the welcome of all the other enhancements, especially in the area of conversion, to make your integer library easy to use for everyone. Further, don't get discouraged as your colleagues discuss the meaning of 0, life and the universe while people who actually would use it already understand what 0 means because we have been without, 0, this library for so long. 'Feed a mouse a cookie and he will ask for a glass of milk.' > Creating integers with variable size on the stack, > that is in any case something that I will not > specify, but users that want to use these tricks > can just override the integer_allocator. Currently you have an integer class which takes an integer_allocator base class. Even though the spec doesn't mention this or I glossed over reading it but you probably are going to provide a heap_integer_allocator class that could be named whatever but exists as the default integer_allocator for the integer class. This way users can just start using the library right away instead creating there own allocator the first time they use this library. What I was suggesting was not a change to the integer, integer_allocator base class or the currently unnamed heap_integer_allocator! Rather the addition of a stack_integer_allocator<size_t> : public integer_allocator. The reasons for the library to provide this instead of the end user is as follows: 1) Performance, stack based allocations are faster than heap based and in some field domains one will know the upper limit on size. This generates the need for multiple people wanting to do this especially when performance matters. 2) Standardization, if you foresee that many people are going to need this functionality than your library becomes easier because you can go ahead and provide the class instead of a large unsigned integer of people having to reinvent the wheel and create the exact same class themselves. 3) Maintain ease of use as complexity increases, in just this one area this library could suffer from the opposite problem of the standard library. The standard library algorithms was all passing 2 iterators around which allows for maximum flexibility for more complicated scenarios but lacked the overrides like boost Range where you could pass the collection and the algorithm uses begin and end for the more common and simple scenarios. Integer library does the opposite which is mostly good, it provides the heap allocator for the most common and general use but as complexity increases and someone needs stack based allocator the user is left in the lurch and have to right there own, over and over again from user to user. I just believe this library would be more feature complete if it would just go ahead and provide the both implementations up front. 4) Architectural consistency, this library is designed to behave like existing integer types that can be created both on the stack and on the heap.

1 0

Problem with range?
by Neal Becker 30 May '06

30 May '06

STL iterators are designed so that ordinary pointers can be iterators. Can we do the same with boost::range? With STL we can do: int x; std::copy (&x, &x+1, output); Does this work for range? #include <boost/range.hpp> template<typename in_t> void F (in_t const& in) { typename boost::range_const_iterator<in_t>::type i = boost::begin (in); for (; i != boost::end (in); ++i) ; } int main() { int x; F (boost::sub_range<int*> (&x, &x+1)); } usr/local/src/boost.cvs/boost/range/sub_range.hpp:26: instantiated from ‘boost::sub_range<int*>’ test.cc:11: instantiated from here /usr/local/src/boost.cvs/boost/range/mutable_iterator.hpp:37: error: ‘int*’ is not a class, struct, or union type How do I turn the 'int x' into a 'range'?

3 3

Physical quantities (was re: Infinite precision integer draft)
by Jonathan Ray 30 May '06

30 May '06

>> Here's three: >> 1. Counting *anything* >This is more a case where you restrict yourself to addition, >and therefore never *need* negative numbers. But why would you want >a type for which operator- is not defined? I was neither supporting unsigned intergers nor supporting a type for which - is not defined. I was just pointing out flaws in the form of your argument. There are plenty of physical quantities that are always natural numbers and can be ridiculously large. For example, the number of microstates in a hot cup of tea. The unsigned integer might me useful if it asserted something on underflow to help the programmer debug, but barring that it's just a hack to save a bit. Refusing to define - on a numerical type wouldn't save anybody any trouble except the library writer. > Quantum states are solutions to equations. Those solutions are > discrete and therefore countable. Literally everything that can be represented on a computer in a finite space (e.g. Earth) is one of a finite number of possible values, so that line of reasoning is irrelevant.

1 0

[Boost-bugs] [ boost-Patches-1489352 ] evc4 port: Interlocked*-functions without volatile
by SourceForge.net 30 May '06

30 May '06

Patches item #1489352, was opened at 2006-05-16 10:20 Message generated for change (Settings changed) made by pdimov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489352&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: Accepted Priority: 5 Submitted By: Michael Fink (vividos) Assigned to: Peter Dimov (pdimov) Summary: evc4 port: Interlocked*-functions without volatile Initial Comment: This patch fixes the definition of the Interlocked*-functions when using Windows CE (_WIN32_WCE is defined). The functions use the "old" (VC6 without platform SDK) forms of the functions without the volatile keyword. The patch can be applied to both CVS HEAD and the 1_34 branch, since the file wasn't modified since then. ---------------------------------------------------------------------- Comment By: Peter Dimov (pdimov) Date: 2006-05-18 01:41 Message: Logged In: YES user_id=305912 Applied to 1.34 and HEAD. ---------------------------------------------------------------------- Comment By: Michael Fink (vividos) Date: 2006-05-17 10:57 Message: Logged In: YES user_id=124874 I added a new version of the patch that avoids WINAPI (replaced by __cdecl, as used by the BOOST_MSVC part of the file. Including <windows.h> is not needed here, I think. In evc4 there are no intrinsics for the Interlocked-functions and the pragmas produce errors telling so. The _WIN32_WCE part of the file provides the BOOST_INTERLOCKED_ macros in its own section now. ---------------------------------------------------------------------- Comment By: Peter Dimov (pdimov) Date: 2006-05-16 13:42 Message: Logged In: YES user_id=305912 The patch doesn't look correct to me. Using WINAPI would require inclusion of <windows.h>; in this case just defining BOOST_USE_WINDOWS_H would be a better approach. It also patches the intrinsic section without also declaring the functions as intrinsics; is this intended? Does evc4 have intrinsic support for these functions? If it doesn't, we need to disallow the intrinsic path for _WIN32_WCE and patch the WIN32 section instead. ---------------------------------------------------------------------- Comment By: Michael Fink (vividos) Date: 2006-05-16 10:40 Message: Logged In: YES user_id=124874 Changed summary: it's only evc4 of course, since evc3 is too non-standard to support boost. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489352&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1489713 ] Adjusts mpl::pair concept to be compatible with STL pairs
by SourceForge.net 30 May '06

30 May '06

Patches item #1489713, was opened at 2006-05-16 12:40 Message generated for change (Settings changed) made by david_abrahams You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489713&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tobias Schwinger (t_schwinger) >Assigned to: Aleksey Gurtovoy (agurtovoy) Summary: Adjusts mpl::pair concept to be compatible with STL pairs Initial Comment: WHAT: ===== The patch changes the MPL pair concept, so STL pairs and Fusion pairs also work as MPL pairs. The old type members have been added after testing for backward compatiblity with 3rd party code. STL pair: first (value) second (value) first_type (type) second_type (type) Fusion pair: second (value) first_type (type) second_type (type) MPL pair (CVS): first (type) second (type) MPL pair (after applying this patch): first_type (type) second_type (type) AFFECTED LIBRARIES: =================== - MPL (numerous files, code and documentation) - Variant (2 files) - Parameter (1 file) FILES: ====== - boost/mpl.patch - boost/parameter.patch - boost/variant.patch - libs/mpl.patch TESTED WITH: ============ - MSVC 8.0 - MSVC 7.1 - GCC 3.4.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489713&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] Infinite precision integer draft
by Martin Bonner 30 May '06

30 May '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Ben Artin Sent: 28 May 2006 19:23 To: boost(a)lists.boost.org Subject: Re: [boost] Infinite precision integer draft > In article <4479A423.8010904(a)getdesigned.at>, > Sebastian Redl <sebastian.redl(a)getdesigned.at> wrote: > >> David Abrahams wrote: >> >>> Sebastian Redl <sebastian.redl(a)getdesigned.at> writes: >>> >>>> The main (only, really, when it comes down to it) difference >>>> between a signed and an unsigned integer is that an unsigned >>>> integer is defined never to have a value less than 0. There are >>>> very valid reasons to enforce such a restriction, >>> >>> For example? >>> >> Various physical quantities only make sense for non-negative values. > > Wait a minute... please name one physical quantity that is > > a) Always integer > b) Never negative > c) Not just an enum (i.e., not just a finite set of possible values) > > I can't think of one, which makes me think that your argument about > physical values is irrelevant, as you'd never use an unsigned > *integer* for a physical value. Stretching "physical" slightly, but how about "the number of elements of a given set"? (Where such a set could be "the number of people alive today"). The only difficulty I see with that, is that a 64-bit "long long" would be more than enough for my example. That raises the question, what are the use cases for the integer class? -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

1 0

[Boost-bugs] [ boost-Bugs-1497329 ] documentation mistake
by SourceForge.net 30 May '06

30 May '06

Bugs item #1497329, was opened at 2006-05-30 15:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1497329&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mpl Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sergey Shandar (sergey_shandar) Assigned to: Aleksey Gurtovoy (agurtovoy) Summary: documentation mistake Initial Comment: In the document http://www.boost.org/libs/mpl/doc/refmanual/vector.html --- push_front<v,x>::type | A new vector of following elements: [begin<v>::type, end<v>::type), x; see Front Extensible Sequence. --- Should be --- push_front<v,x>::type | A new vector of following elements: x, [begin<v>::type, end<v>::type); see Front Extensible Sequence. --- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1497329&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1489359 ] [config] evc4 port
by SourceForge.net 30 May '06

30 May '06

Patches item #1489359, was opened at 2006-05-16 09:38 Message generated for change (Comment added) made by mloskot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489359&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Fink (vividos) Assigned to: John Maddock (johnmaddock) Summary: [config] evc4 port Initial Comment: This patch is a port for evc3/4 targeting Windows CE. Reason for the changes in auto_link.hpp: STLport with evc4 cannot be compiled in _STLP_DEBUG mode; the compiler issues wrong ARM code and _STLP_DEBUG mode cannot be used with evc4 ARM. I also introduced a new file wince.hpp in boost/config/platform/, since the defines in the _WIN32_WCE part got too big. ---------------------------------------------------------------------- Comment By: Mateusz Loskot (mloskot) Date: 2006-05-30 04:52 Message: Logged In: YES user_id=736047 Hi, Michael: Thanks for your effor to make Boost more Windows CE-friendly. Some time ago, I also started to use Boost with eVC++/VC++8. John: VC++ 8.0 brings the whole set of compilers for Winodows CE platform: clarm.exe, clmips.exe, etc. Here is a list with preprocessor macros to check target arch: http://www.smartphonedn.com/qa/checkos.html Here is a table that explains how to map devie arch from eVC++ 3/4 to VC++ 8.0: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/h… Also, biuld system should define appropriate symbols: -D _ARM_ -D ARM -D _arm_ -D _MIPS_ -D MIPS -D _mips_ etc. Cheers ---------------------------------------------------------------------- Comment By: Michael Fink (vividos) Date: 2006-05-17 15:22 Message: Logged In: YES user_id=124874 The only change I made is to rename "evc8" to "msvc8-arm", but since I don't know exactly how to differentiate processors in msvc8 I simply put "msvc8-arm". A possible msvc8 porter has to decide that. I updated the patch since I found another issue: there's no static C runtime for Windows CE, so autolinking always chooses "-gdp" now. Please disregard the first patch. ---------------------------------------------------------------------- Comment By: John Maddock (johnmaddock) Date: 2006-05-17 11:51 Message: Logged In: YES user_id=14804 I notice that the patches are arm-specific, surely VC8 can be used to target other processors? John. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489359&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0