- Boost - lists.boost.org

[MPL.Math] numeric concepts
by Cromwell Enage 01 Nov '05

01 Nov '05

--- Andy Little wrote: > BTW, I have found that the ability to convert a > rational to an integral_constant if possible is a > useful utility too, though I'm not quite sure > what purists would make of it as the resulting > ::type may be an integral_constant or maybe a > rational constant. I currently call it > "simplify_rational_or_numeric". The resulting ::type > works ok if accessed using the numerator and > denominator functions, and this allows me to make > lists of dimensions using both integral_constants and > rationals. Maybe there is room for such a concept as > an "mpl rational or numeric concept"? In my yet-to-be-submitted documentation, I have the following numeric metatype hierarchy: Numeric Constant | +--Real Numeric Constant | | | +--Discrete Constant--Bitwise Constant | | | | | | +--Integral Constant------+ | | | | | | +--Big Integral Constant--+ | | | +--Continuous Constant | | | +--Rational Constant | | | +--Mixed Numeric Constant | +--Complex Numeric Constant Each concept is defined in terms of the metafunctions that can operate on it, and their semantics. In this scheme, both Integral Constants and Rational Constants are Real Numeric Constants. Not only do the arithmetic metafunctions (negate, plus, minus, times, divides), a few comparison metafunctions (equal_to, not_equal_to), and a few numeric metafunctions (is_zero, zero, real_part, imaginary_part) work on them as they do on other Numeric Constants; but all the other comparison metafunctions (less, greater, less_equal, greater_equal) and all the other numeric metafunctions (is_negative, abs, numerator, denominator, whole_part, fractional_part) work on them as well. A few metafunctions have different semantics for Discrete Constants; e.g. the numerator or whole_part of an Integral Constant is itself, its denominator is always one, and its fractional_part is always zero. To obtain the corresponding run-time values, use the runtime_value facility, which is required to operate on all Numeric Constants. Let me know of any details that need to be fleshed out for you. Cromwell D. Enage __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com

2 2

Re: [boost] VC++ 7.1 build options lead to AV
by Ashok Thirumurthi 01 Nov '05

01 Nov '05

> > Ashok Thirumurthi wrote: > > Dear Boost, > > > > The following call stack leads to an access violation when I link a VC 7.1 DLL > > to the release build of the boost signals 1_33_0 DLL. In comparison, > > there is no access violation when I link to the debug build of the same > > library. Similarly, when I add the signals source to my own release > > DLL, there is no access violation. I attempted to disable all compiler > > optimizations in msvc.jam as follows. However, after running bjam -a > > in signals\build and installing the output, the AV still occurs. > > You were commenting out BBv2 code. Boost.Signals is being build with > BBv1 (if you were building it from the boost root), use "bjam -a --v2" > to build with BBv2. Also, you can use: > > bjam -a --v2 optimization=off > > to turn off the optimization? > Thanks. Disabling all optimizations prevents the access violation. > > How can I alter the release build to avoid the access violation? > > > > Access violation reading location 0x00000004 > > (*((k2).content)).__vfptr is 0x00000000 > > > > bool operator()(const any& k1, const any& k2) const > > { > > if (k1.type() == typeid(front_type)) > > return !(k2.type() == typeid(front_type)); > > if (k1.type() == typeid(back_type)) > > return false; > > > >> if (k2.type() == typeid(front_type)) > > This looks to be an issue with either Boost.Any or your code. What is > any::type() returning? Actually, the () operator is crashing with the access violation. When I run without optimizations, k1.type is front_type and k2.type is back_type. If I optimize for speed (/O2), k1.content is null and k2.content.__vfptr is null. So, type() cannot be evaluated. If I optimize for size (/O1), I observe an invalid lock sequence exception (0xC000001E) when constructing a _Tree_ptr. > Have you made sure that RTTI is enabled for everything (including your > own project -- is there a difference in the vcproj Configurations?) Yes. > > Are you doing something in the Debug version that is not in the Release > version? > > Are you linking with the right variant of the boost libraries? Is there > a conflict with the run-time library being used? I can reproduce the problem and the work-around by compiling the boost source into a DLL using a VC++ 7.1 project. Initially, I had used the bjam scripts without any modification after installing the full 1_33 source. I was able to reproduce the problem with boost 1_32. However, I'm not sure how to determine if a conflict exists. Thanks to your advice regarding bjam, I have a work-around in hand, - Ashok > > - Reece > > > > ------------------------------ > > Message: 4 > Date: Sat, 29 Oct 2005 10:43:59 +0100 > From: "Paul A Bristow" <pbristow(a)hetp.u-net.com> > Subject: Re: [boost] Documentation Wizard > To: <boost(a)lists.boost.org> > Message-ID: <E1EVnFw-0007Bf-Oz(a)he304war.uk.vianw.net> > Content-Type: text/plain; charset="us-ascii" > > > > | -----Original Message----- > | From: boost-bounces(a)lists.boost.org > | [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart > | Sent: 27 October 2005 23:21 > | To: boost(a)lists.boost.org > | Subject: [boost] Documentation Wizard > | > | Quite some time ago, Dave Abrahams announced that I was the new > | Boost Documentation Wizard. I said I'd write something on the > | subject and that is long overdue. Herewith, I describe what I > | think the DocWiz should do and what is needed from volunteers to > | make it happen. That is, I'm trying to document the new DocWiz > | role and solicit your help. > > My first impression is that this is a bit over-bureaucratic. You obviously > need this sort of style managing 8 offspring ;-) , but Boosters are all > volunteers and we have to be greatful for all the help we can get. > > Authors are severely handicapped when writing documentation by knowing too > much. > > And they are often exhausted by the process of getting the code to work on > the myriad of inconsistent platforms and versions. > > So _any_ documentation editing is likely to be an improvement. > > So I think you should just ask for someone (usually only one - we don't have > _common_ tools for handling versioning and changes well) willing to > contribute to editing each library. The code author and the editor will have > to try to agree: only if they are uncertain should theygo out to the wider > Boost audience. > > Since I have the advantage of having English as my first language (and not > the corrupted version of those renegage ex-colonials ;-), and I have enough > knowledge of other languages to greatly admire those whose first language is > not English struggling with the erudite esoteric elite Boost discussions, I > may offer to edit some documentation. > > HTH > > Paul > > PS And I've read Eats, Shoots and Leaves. > > -- > Paul A Bristow > Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB > Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 > mailto: pbristow(a)hetp.u-net.com www.hetp.u-net.com > > > > > > ------------------------------ > > Message: 5 > Date: Sat, 29 Oct 2005 12:01:29 +0100 > From: "Marcin Kalicinski" <kalita(a)poczta.onet.pl> > Subject: [boost] How to run boost regressions? > To: boost(a)lists.boost.org > Message-ID: <djvkq7$ej5$1(a)sea.gmane.org> > > Hi, > > How can I run boost regression tests at home? > > cheers, > Marcin > > > > > > ------------------------------ > > Message: 6 > Date: Sat, 29 Oct 2005 05:57:41 -0700 > From: "SourceForge.net" <noreply(a)sourceforge.net> > Subject: [boost] [Boost-bugs] [ boost-Bugs-1341560 ] crach build bjam > from mingw 3.4.4 > To: noreply(a)sourceforge.net > Message-ID: <E1EVqHF-00048m-K1(a)sc8-sf-web2.sourceforge.net> > Content-Type: text/plain; charset="ISO-8859-1" > > Bugs item #1341560, was opened at 2005-10-29 19:57 > 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=1341560&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: Alexandr Zamaraev (shura_zam) > Assigned to: Nobody/Anonymous (nobody) > Summary: crach build bjam from mingw 3.4.4 > > Initial Comment: > OS:Windows XP pro rus + sp2 > gcc: (GCC) 3.4.4 (mingw special) > ld: GNU ld version 2.16.91 20050827 > Source: latest csv > > Command line: > >build.bat mingw > Output (last 3 line): > don't know how to make mingw > ...found 1 target... > ...can't find 1 target... > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1341560&group_… > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Boost-bugs mailing list > Boost-bugs(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/boost-bugs > > > ------------------------------ > > Message: 7 > Date: Sat, 29 Oct 2005 06:12:26 -0700 > From: "SourceForge.net" <noreply(a)sourceforge.net> > Subject: [boost] [Boost-bugs] [ boost-Bugs-1341568 ] crach build bjam > from mingw 3.4.4 with python > To: noreply(a)sourceforge.net > Message-ID: <E1EVqVW-0005Zb-Rw(a)sc8-sf-web1.sourceforge.net> > Content-Type: text/plain; charset="ISO-8859-1" > > Bugs item #1341568, was opened at 2005-10-29 20:12 > 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=1341568&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: Alexandr Zamaraev (shura_zam) > Assigned to: Nobody/Anonymous (nobody) > Summary: crach build bjam from mingw 3.4.4 with python > > Initial Comment: > OS: Windows XP pro rus + sp2 > gcc: (GCC) 3.4.4 (mingw special) > ld: GNU ld version 2.16.91 20050827 > Python: Python 2.4.2 > Source: latest csv > > I try build bjam with python. > Bat I have crach in linking. > > Command line: > >bjam -f build.jam --toolset=mingw > --with-python=C:\Lang\Python24 > > Output (latest 8 lines) > C:\TEMP\Shura/ccaSyaaa.o:builtins.c:(.text+0x334e): > undefined reference to `_imp__PyCallable_Check' > C:\TEMP\Shura/ccaSyaaa.o:builtins.c:(.text+0x337c): > undefined reference to `_imp___Py_NoneStruct' > collect2: ld returned 1 exit status > > "gcc" -o bin.ntx86\bjam.exe -DNDEBUG > -DOPT_HEADER_CACHE_EXT -DOPT_GRAPH_DEBUG_EXT > -DOPT_SEMAPHORE -DOPT_FIX_TARGET_VARIABLES_EXT > -DOPT_IMPROVED_PATIENCE_EXT -DNT -DYYSTACKSIZE=5000 > -DHAVE_PYTHON -s -O3 -finline-functions > -IC:\Lang\Python24\include > "C:\Lang\Python24\libs\python24.lib" command.c > compile.c debug.c expand.c glob.c hash.c hcache.c > headers.c hdrmacro.c jam.c jambase.c jamgram.c lists.c > make.c make1.c newstr.c option.c parse.c regexp.c > rules.c scan.c search.c subst.c w32_getreg.c > timestamp.c variable.c modules.c strings.c filesys.c > builtins.c pwd.c class.c native.c modules/set.c > modules/path.c modules/regex.c modules/property-set.c > modules/sequence.c modules/order.c execnt.c filent.c > pathunix.c > > ...failed [COMPILE] bin.ntx86\bjam.exe... > ...failed updating 1 target... > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1341568&group_… > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Boost-bugs mailing list > Boost-bugs(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/boost-bugs > > > ------------------------------ > > Message: 8 > Date: Sat, 29 Oct 2005 09:40:28 -0500 > From: Douglas Gregor <doug.gregor(a)gmail.com> > Subject: Re: [boost] How to run boost regressions? > To: boost(a)lists.boost.org > Message-ID: <66D002ED-12FC-40F7-A0AC-BD3AE3A8CA0C(a)cs.indiana.edu> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Oct 29, 2005, at 6:01 AM, Marcin Kalicinski wrote: > > How can I run boost regression tests at home? > > There are some instructions here: > > http://www.boost.org/tools/regression/xsl_reports/runner/ > instructions.html > > Doug > > > > ------------------------------ > > Message: 9 > Date: Sat, 29 Oct 2005 09:51:08 -0500 > From: Douglas Gregor <doug.gregor(a)gmail.com> > Subject: Re: [boost] [GCC 2.95.3] Boost regression notification > (2005-10-28 [HEAD]) > To: boost(a)lists.boost.org > Message-ID: <C805154E-5675-42B4-A0D9-2F42C8920BF1(a)cs.indiana.edu> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Oct 28, 2005, at 5:11 PM, Beman Dawes wrote: > > A lot of these failures are for gcc-2.95.3-linux. Do we care enough > > about > > 2.95.3 nowadays to consider it a release platform? > > I vageuely remember trying to kill GCC 2.95.3 support at one point, > but was convinced otherwise. We could just mark it as unusable on new > libraries/tests that support it but retain backward compatibility on > those libraries that do. > > Doug > > > ------------------------------ > > Message: 10 > Date: Sat, 29 Oct 2005 17:04:16 +0100 > From: "John Maddock" <john(a)johnmaddock.co.uk> > Subject: Re: [boost] [range][1.33.1] last few regressions. > To: <boost(a)lists.boost.org> > Message-ID: <015001c5dca2$7118cab0$6f2e0d52@fuji> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > > In that case we might as well just roll-back the changes from the RC > > branch to > > the main branch. > > There haven't been any changes to the test itself, and the only changes in > the headers appear to be: > http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/range/end.hpp?r1=1.… > and related changes. > > I'd still rather see this fixed than just rolled back (I presume these > changes were in there for a reason?), or we could disable them for broken > compilers if that works (but we need to know why they were in there in the > first place, this could be a fix for VC6/7 for all I know). > > BTW I don't have a Boost source tree (or compiler) to work with at present > to test this out, since I've just replaced my hard drive! > > Hopefully this narrows the problem down a bit? > > John. > > > > ------------------------------ > > Message: 11 > Date: Sat, 29 Oct 2005 12:24:53 -0400 > From: David Abrahams <dave(a)boost-consulting.com> > Subject: Re: [boost] [GCC 2.95.3] Boost regression notification > (2005-10-28 [HEAD]) > To: boost(a)lists.boost.org > Message-ID: <uy84cl296.fsf(a)boost-consulting.com> > Content-Type: text/plain; charset=us-ascii > > Douglas Gregor <doug.gregor(a)gmail.com> writes: > > > On Oct 28, 2005, at 5:11 PM, Beman Dawes wrote: > >> A lot of these failures are for gcc-2.95.3-linux. Do we care enough > >> about > >> 2.95.3 nowadays to consider it a release platform? > > > > I vageuely remember trying to kill GCC 2.95.3 support at one point, > > but was convinced otherwise. We could just mark it as unusable on new > > libraries/tests that support it but retain backward compatibility on > ^ > don't?? > > > those libraries that do. > > If not "don't," how will we know we're retaining backward > compatibility? > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > > ------------------------------ > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > End of Boost Digest, Vol 1260, Issue 1 > ************************************** >

1 0

Re: [boost] [range][1.33.1] last few regressions.
by boost.regex＠virgin.net 31 Oct '05

31 Oct '05

>I need to spend some more time on the range library before I feel>comfortable about releasing it together with boost.foreach.>I need to change the concept requirements and update the docs and won't have>time until the weekend.Understood, but please remember we're talking about patching the 1.33 release source here, *not* a new updated version: that's a different thing entirely.John.

4 7

Boost regression notification (2005-10-30 [RC_1_33_0])
by Douglas Gregor 31 Oct '05

31 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-30T14:55:09Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 8 failures in 4 libraries: date_time (1) filesystem (2) range (3) serialization (2) |date_time| testtz_database: intel-win32-8_1 |filesystem| operations_test: intel-win32-8_1 operations_test_dll: intel-win32-8_1 |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_demo_xml_load: intel-win32-8_1 test_shared_ptr_132_text_warchive: intel-win32-8_1

6 7

What the?
by Dan McLeran 31 Oct '05

31 Oct '05

Yesterday, I tried upgrading from Boost 1.30 to 1.33 and I got the weirdest reaction from my linker. Some background: I am using MSVC6SP6; The code in question is a dll that runs under PharLap 9.1. I am linking against libcmt as well as a lib called cellexe.lib, which provides all of the C runtime stuff and PharLap-specific OS stuff. With Boost 1.30, everything compiles and links just peachy. When I pointed the project at Boost 1.33, I had to make a couple of small code changes: 1. I had to change boost::mpl::apply_if to boost::mpl::eval_if. 2. I had to stop using TrivialIteratorConcept and switched to ForwardIteratorConcept or RandomAccessIteratorConcept. That's really the only code changes I can think of but now my linker gives me a bunch of warnings and 1 error message, which is what's really killing me: Linking... LIBCMT.lib(typinfo.obj) : error LNK2005: "const type_info::`vftable'" (??_7type_info@@6B@) already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(strtol.obj) : error LNK2005: _strtoul already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(chkstk.obj) : error LNK2005: __chkstk already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(xtoa.obj) : error LNK2005: __ultoa already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(atox.obj) : error LNK2005: _atoi already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(typinfo.obj) : warning LNK4006: "const type_info::`vftable'" (??_7type_info@@6B@) already defined in cellexe.lib(Cellexe.exe); second definition ignored LIBCMT.lib(strtol.obj) : warning LNK4006: _strtoul already defined in cellexe.lib(Cellexe.exe); second definition ignored LIBCMT.lib(chkstk.obj) : warning LNK4006: __chkstk already defined in cellexe.lib(Cellexe.exe); second definition ignored LIBCMT.lib(xtoa.obj) : warning LNK4006: __ultoa already defined in cellexe.lib(Cellexe.exe); second definition ignored LIBCMT.lib(atox.obj) : warning LNK4006: _atoi already defined in cellexe.lib(Cellexe.exe); second definition ignored Creating library PharLapRelease/Devo.lib and object PharLapRelease/Devo.exp LIBCMT.lib(crt0.obj) : error LNK2001: unresolved external symbol _main PharLapRelease/Devo.dll : fatal error LNK1120: 1 unresolved externals Error executing link.exe. I can't understand why the linker is now searching for _main when the project is a dll and I have all the necessary stuff: .def file, /dll switch, etc. I have compiled and run this dll for literally years when using Boost 1.30. Can anyone think of anything in this Boost library upgrade that could cause this? Keep in mind that I did not change any project setting other than the include directories to point the compiler at the directories containing Boost 1.33 and that I have been using this code along with Boost 1.30 for years.

3 4

Boost regression notification (2005-10-31 [HEAD])
by Douglas Gregor 31 Oct '05

31 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-31T06:00:27Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 290 failures in 14 libraries: concept_check (12) filesystem (2) graph (2) io (1) mpl (1) python (1) serialization (30) spirit (8) thread (4) tr1 (147) tuple (1) type_traits (58) typeof (18) xpressive (5) |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 vc-7_1 |filesystem| operations_test: intel-win32-9_0 operations_test_dll: intel-win32-9_0 |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |python| exec: intel-win32-9_0 |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin |spirit| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tr1| run_complex_overloads: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux run_random: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux std_test_array: gcc-2.95.3-linux std_test_array_tricky: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 vc-7_1 std_test_bind: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 std_test_bind_tricky: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 vc-7_1 std_test_boost: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_complex: gcc-2.95.3-linux std_test_function: gcc-2.95.3-linux std_test_function_tricky: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 vc-7_1 std_test_hash: gcc-2.95.3-linux std_test_mem_fn: gcc-2.95.3-linux std_test_mem_fn_tricky: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 vc-7_1 std_test_random: gcc-2.95.3-linux std_test_reference_wrapper: gcc-2.95.3-linux std_test_reference_wrapper_tricky: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 vc-7_1 std_test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux std_test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_shared_ptr: gcc-2.95.3-linux std_test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tuple_tricky: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 vc-7_1 std_test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_algorithm: gcc-2.95.3-stlport-4.6.2-linux test_array_tricky: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 vc-7_1 test_bind: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 test_bind_tricky: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 vc-7_1 test_complex: gcc-2.95.3-linux test_exception: gcc-2.95.3-stlport-4.6.2-linux test_function_tricky: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 vc-7_1 test_functional: gcc-2.95.3-linux test_hash: gcc-2.95.3-linux test_mem_fn_tricky: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 vc-7_1 test_memory: gcc-2.95.3-linux test_new: gcc-2.95.3-stlport-4.6.2-linux test_reference_wrapper_tricky: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 vc-7_1 test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_tuple_tricky: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 vc-7_1 test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_utility: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |tuple| tuple_test_bench: gcc-3_4_3-sunos |type_traits| tr1_add_const_test: gcc-2.95.3-linux tr1_add_cv_test: gcc-2.95.3-linux tr1_add_pointer_test: gcc-2.95.3-linux tr1_add_reference_test: gcc-2.95.3-linux tr1_add_volatile_test: gcc-2.95.3-linux tr1_aligned_storage_test: gcc-2.95.3-linux tr1_alignment_of_test: gcc-2.95.3-linux tr1_extent_test: gcc-2.95.3-linux tr1_has_nothrow_assign_test: gcc-2.95.3-linux tr1_has_nothrow_constr_test: gcc-2.95.3-linux tr1_has_nothrow_copy_test: gcc-2.95.3-linux tr1_has_trivial_assign_test: gcc-2.95.3-linux tr1_has_trivial_constr_test: gcc-2.95.3-linux tr1_has_trivial_copy_test: gcc-2.95.3-linux tr1_has_trivial_destructor_test: gcc-2.95.3-linux tr1_has_virtual_destructor_test: gcc-2.95.3-linux tr1_is_abstract_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin tr1_is_arithmetic_test: gcc-2.95.3-linux tr1_is_array_test: gcc-2.95.3-linux tr1_is_base_of_test: gcc-2.95.3-linux tr1_is_class_test: gcc-2.95.3-linux tr1_is_compound_test: gcc-2.95.3-linux tr1_is_const_test: gcc-2.95.3-linux tr1_is_convertible_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tr1_is_empty_test: gcc-2.95.3-linux tr1_is_enum_test: gcc-2.95.3-linux tr1_is_floating_point_test: gcc-2.95.3-linux tr1_is_function_test: gcc-2.95.3-linux tr1_is_fundamental_test: gcc-2.95.3-linux tr1_is_integral_test: gcc-2.95.3-linux tr1_is_member_func_test: gcc-2.95.3-linux tr1_is_member_obj_test: gcc-2.95.3-linux tr1_is_member_pointer_test: gcc-2.95.3-linux tr1_is_object_test: gcc-2.95.3-linux tr1_is_pod_test: gcc-2.95.3-linux tr1_is_pointer_test: gcc-2.95.3-linux tr1_is_polymorphic_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tr1_is_reference_test: gcc-2.95.3-linux tr1_is_same_test: gcc-2.95.3-linux tr1_is_scalar_test: gcc-2.95.3-linux tr1_is_signed_test: gcc-2.95.3-linux tr1_is_union_test: gcc-2.95.3-linux tr1_is_unsigned_test: gcc-2.95.3-linux tr1_is_void_test: gcc-2.95.3-linux tr1_is_volatile_test: gcc-2.95.3-linux tr1_rank_test: gcc-2.95.3-linux tr1_remove_all_extents_test: gcc-2.95.3-linux tr1_remove_const_test: gcc-2.95.3-linux tr1_remove_cv_test: gcc-2.95.3-linux tr1_remove_extent_test: gcc-2.95.3-linux tr1_remove_pointer_test: gcc-2.95.3-linux tr1_remove_reference_test: gcc-2.95.3-linux tr1_remove_volatile_test: gcc-2.95.3-linux |typeof| data_member_native: cw-9_4 function_native: cw-9_4 function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 template_type_native: cw-9_4 type_native: cw-9_4 |xpressive| test3u: gcc-3_3-darwin test4u: gcc-3_3-darwin test5u: gcc-3_3-darwin test6u: gcc-3_3-darwin test9u: gcc-3_3-darwin

1 0

[Boost-bugs] [ boost-Support Requests-1343952 ] object tracking
by SourceForge.net 31 Oct '05

31 Oct '05

Support Requests item #1343952, was opened at 2005-10-31 14:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1343952&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: Luke (jla2w) Assigned to: Nobody/Anonymous (nobody) Summary: object tracking Initial Comment: I upgraded my compiler from VC7 to VC7.1. I rebuilt boost using the new compiler and rebuilt my application. No code relating to use of boost (I use it for it's serialization library) changed, and it worked in VC7, but now I get an assertion in the file oserializer.hpp BOOST_STATIC_ASSERT(check_tracking<T>::value) it says I need to check my object tracking settings...My question is why would it not do this for vc7.0, but it does this for VC7.1? What can I do to remedy this? I use default object tracking settings throughout and I do serialize through pointers a lot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1343952&group_… ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Support Requests-1343929 ] object tracking
by SourceForge.net 31 Oct '05

31 Oct '05

Support Requests item #1343929, was opened at 2005-10-31 14:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1343929&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: Luke (jla2w) Assigned to: Nobody/Anonymous (nobody) Summary: object tracking Initial Comment: I upgraded my compiler from VC7 to VC7.1. I rebuilt boost using the new compiler and rebuilt my application. No code relating to use of boost (I use it for it's serialization library) changed, and it worked in VC7, but now I get an assertion in the file oserializer.hpp BOOST_STATIC_ASSERT(check_tracking<T>::value) it says I need to check my object tracking settings...My question is why would it not do this for vc7.0, but it does this for VC7.1? What can I do to remedy this? I use default object tracking settings throughout and I do serialize through pointers a lot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1343929&group_… ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[MPL.Math] big_integral and unsigned_big_integral
by Cromwell Enage 31 Oct '05

31 Oct '05

Once again, the latest offering is at <http://boost-consulting.com/vault/>, inside Template Metaprogramming. The ability to write constants like big_integral<positive_sign,1,0,4,8,5,7,6> has returned. In addition, you can also write a constant like unsigned_big_integral<1,0,4,8,5,7,6>, which is equivalent to the above. The two missing pieces wrt full functionality are division and human-readable output. The latter is easier to tackle but will most likely require a corresponding runtime big-integer class. Is anybody (e.g. Christopher Diggins) still working on one? If so, I might use it as a value_type. In a future version I'll probably get rid of positive_sign and negative_sign and just have the user specify '+' or '-'. Peder, I've made changes to the following files: * <boost/mpl/math/numerator.hpp> * <boost/mpl/math/denominator.hpp> * <boost/mpl/math/whole_part.hpp> * <boost/mpl/math/rational_part.hpp> * <boost/mpl/math/big_integral_tag.hpp> * <boost/mpl/math/big_integral_fwd.hpp> * everything in boost/mpl/math/big_integral_ and boost/mpl/math/big_integral_/aux_ * <boost/mpl/math/big_integral.hpp> * <boost/mpl/math/rational.hpp> * <boost/mpl/math/mixed_number.hpp> * <boost/mpl/math/complex_number.hpp> * examples/big_integral.cpp * test/big_integral.cpp Cromwell D. Enage __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 3

[mpl::math Rational] type member
by Andy Little 31 Oct '05

31 Oct '05

Hi Cromwell, in <boost/mpl/math/rational.hpp> In the definition for mpl::math::rational would it not be better to make the nested type member using the numerator and denominator rather than the input parameters.eg for: typedef rational<integral_c_<int,2>,integral_c<int,8> >::type type; currently type is a rational<integral_c_<int,2>,integral_c<int,8> > in the second case type is a rational<integral_c_<int,1>,integral_c<int,4> > I believe the second is superior. Can supply a patch if you like ... Secondly, are the next and prior members necessary? IMO they only make sense for integers. Thirdly, It should be noted that there is a <boost/mpl/math/rational_c.hpp> header, but as rational_c is defined in <boost/mpl/math/rational.hpp> I think its now both redundant and confusing. Cheers Andy Little

5 18