Nabble - Boost - Dev

Re: [LibrariesUnderConstruction] Boost.Numeric_Bindings

2009-11-27T08:09:00Z

> Apologize if I miss this library.
>
> wiki page updated :
> http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.NumericBindings

Could you add Karl Meerbergen, Krešimir Fresl, and Toon Knapen as authors? This is taken from http://www.cs.kuleuven.be/~karlm/glas/

Karl Meerbergen, Krešimir Fresl, and Toon Knapen. C++ bindings to external software libraries with examples from BLAS, LAPACK, UMFPACK, and MUMPS. Report TW 506(
http://www.cs.kuleuven.be/publicaties/rapporten/tw/TW506.abs.html
). Department of Computer Science, KU Leuven. October, 2007. (See revision of February 9, 2009
http://www.cs.kuleuven.be/~karlm/glas/tw506-revision.pdf
). Accepted for publication in ACM Transactions on Mathematical Software.

> Do you have some online documentation?

http://svn.boost.org/svn/boost/sandbox/numeric_bindings-v1/libs/numeric/bindings/doc/index.html
http://svn.boost.org/svn/boost/sandbox/numeric_bindings/libs/numeric/bindings/doc/html/index.html

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Boost.Array Maintainer

2009-11-27T07:58:33Z

John Maddock wrote:

>> Question: does someone have to be a maintainer of an existing library
>> (or author of one of the accepted libraries) to become a maintainer of
>> an existing (orphaned?) library?
>
> This is a very interesting question. Some lingering tickets with patch
> could be cleared faster if soem orphaned components of bosot were
> assignated new manager.

Indeed. Something that occurred to me earlier was "how many tickets were
looked at in the last sprint, assigned a patch, but haven't been looked at
since?" That would be a good test of the owner being missing-in-action!

Re Boost.Array, I seem to remember Alisdair Meredith taking this on, I'm
cc'ing him just in case my memory isn't what it once was ! ;-)

It seems to me though that the bug sprints would be a good opportunity to
widen the maintainer list a little - what if we assigned an interested
volunteer to act as temporary maintainer for an orphan library during the
sprint. (S)he fixes whatever they can fix, then gets another bug sprint
volunteer to review the changes, if all looks well, and the tests are all
passing on Trunk, only then merge to release.

Thoughts? John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi,

I don't know if this is the best way, but it is clear that we have a problem with very old tickets.
It will be great to identify the libraries that will need this kind of help, and make a call for volunteers.

Best,
Vicente

Re: warning policy issue

2009-11-27T07:56:11Z

On Fri, Nov 27, 2009 at 7:51 AM, Vicente Botet Escriba <
vicente.botet@...> wrote:

>
> what do you think if in addition to setting up the Maintenace Guidelines
> wiki page we setup some test that proves these gides really work?
>

Great idea. All documentation should have tests.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: warning policy issue

2009-11-27T07:51:56Z

Daniel James wrote:

2009/11/26 Paul A. Bristow <pbristow@hetp.u-net.com>:
>
> My recollection (dim!) is that 7.1 works the same.
>
> Are you quite sure you are casting to the right type?
>
> Or is suppressing the line of least resistance (sounds a bit dodgy to me).

There are a few warning conditions in Visual C++ 7.1 that were removed
in later versions. I think their removal is a good indication of their
worth (the ones I've come across were certainly buggy). They should
probably just be suppressed with something like the following.

#if defined(BOOST_MSVC)
#pragma warning(push)
#if BOOST_MSVC < 1400
#pragma warning(disable:4244)
#endif
#endif

// ....

#if defined(BOOST_MSVC)
#pragma warning(pop)
#endif
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi,

what do you think if, in addition to setting up the Maintenace Guidelines wiki page, we setup some test that proves these gides really work?

Best,
Vicente

Re: warning policy issue

2009-11-27T07:51:29Z

Daniel James wrote:

2009/11/26 Paul A. Bristow <pbristow@hetp.u-net.com>:
>
> My recollection (dim!) is that 7.1 works the same.
>
> Are you quite sure you are casting to the right type?
>
> Or is suppressing the line of least resistance (sounds a bit dodgy to me).

There are a few warning conditions in Visual C++ 7.1 that were removed
in later versions. I think their removal is a good indication of their
worth (the ones I've come across were certainly buggy). They should
probably just be suppressed with something like the following.

#if defined(BOOST_MSVC)
#pragma warning(push)
#if BOOST_MSVC < 1400
#pragma warning(disable:4244)
#endif
#endif

// ....

#if defined(BOOST_MSVC)
#pragma warning(pop)
#endif
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi,

what do you think if in addition to setting up the Maintenace Guidelines wiki page we setup some test that proves these gides really work?

Best,
Vicente

Re: Status of the bug sprint....

2009-11-27T07:47:09Z

for Friday, November 27

Nov 18: 859 open tickets.
Nov 19: 861 open tickets.
Nov 20: 862 open tickets.
Nov 21: 849 open tickets.
Nov 22: 849 open tickets.
Nov 23: 828 open tickets.
Nov 24: 836 open tickets.
Nov 25: 827 open tickets.
Nov 26: 834 open tickets.
Nov 27: 828 open tickets.

That's more like it... heading down again.

For those who want just to count bugs:

Nov 24: 516 open bugs
Nov 25: 511 open bugs
Nov 26: 514 open bugs
Nov 27: 510 open bugs

-- Marshall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Boost.Array Maintainer

2009-11-27T07:42:55Z

On Nov 27, 2009, at 3:02 AM, John Maddock wrote:

>>> Question: does someone have to be a maintainer of an existing library
>>> (or author of one of the accepted libraries) to become a maintainer of
>>> an existing (orphaned?) library?
>>
>> This is a very interesting question. Some lingering tickets with patch
>> could be cleared faster if soem orphaned components of bosot were
>> assignated new manager.
>
> Indeed. Something that occurred to me earlier was "how many tickets were looked at in the last sprint, assigned a patch, but haven't been looked at since?" That would be a good test of the owner being missing-in-action!
>
> Re Boost.Array, I seem to remember Alisdair Meredith taking this on, I'm cc'ing him just in case my memory isn't what it once was ! ;-)
>
> It seems to me though that the bug sprints would be a good opportunity to widen the maintainer list a little - what if we assigned an interested volunteer to act as temporary maintainer for an orphan library during the sprint. (S)he fixes whatever they can fix, then gets another bug sprint volunteer to review the changes, if all looks well, and the tests are all passing on Trunk, only then merge to release.

I think that this is a great idea....

-- Marshall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [LibrariesUnderConstruction] Boost.Numeric_Bindings

2009-11-27T07:42:51Z

Rutger ter Borg-2 wrote:

Hello all,

I see the Numeric_Bindings library is missing on the
LibrariesUnderConstruction trac page. This library is under development
since 2002. Herewith a short description of the library.

Boost.Numeric_Bindings is a C++ library for numeric computing. It is a
generic layer between data containers and linear algebra algorithms.

For the data container part, it supports both compile-time statically sized
and run-time dynamically sized vectors, matrices, through a traits system.
Currently it includes traits for C-arrays, for standard vectors, for uBLAS'
containers, Eigen containers, TNT, Boost.Array, to name a few. It offers
compile-time inspection, iterators, and views on all mentioned containers.

For the algorithm part, it provides a C++ interface to algorithms offered by
BLAS, LAPACK, and more. This covers algorithms from most vendor-provided
math libraries, such as the reference BLAS, ATLAS, Intel's MKL, AMD's CML,
NVidia's CUDA, etc..

The "stable" release is available at
http://svn.boost.org/svn/boost/sandbox/numeric_bindings-v1/

The current development version is available at
http://svn.boost.org/svn/boost/sandbox/numeric_bindings/

Questions and/or comments are welcomed.

Thanks,

Rutger

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi,

Apologize if I miss this library.

wiki page updated : http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.NumericBindings

Do you have some online documentation?

Best,
Vicente

Re: [LibrariesUnderConstruction]Mirror - update

2009-11-27T07:28:58Z

Matus Chochlik wrote:

Hi,

I would like to ask the admins to update the info about the Mirror library
on the LibrariesUnderConstruction page in particular to add the links
to the C++0x version of Mirror on sourceforce:
http://sourceforge.net/projects/mirror-lib/

and to add a link to the online docs for the C++0x version:
http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/

TIA

________________
::matus_chochlik
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi,

Thanks for giving updated information for your library.

wiki page updated : http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Mirror

Best,
Vicente

Re: Boost.Integer makeover

2009-11-27T07:21:34Z

John Maddock wrote:
>
> Boost.Integer has had a quick makeover in Trunk - starting
> from the "last
> known good" release - and then fixing all outstanding issues
> filed since
> that release. New-look docs are visible here:
> https://svn.boost.org/svn/boost/trunk/libs/integer/doc/html/index.html

The main overview section doesn't include an introduction for the purpose of the library. The table there doesn't serve the purpose as well since it is the text of the third column of each row that, in aggregate, documents the purpose.

I suggest the following:

Boost.Integer provides integer type support, particularly helpful in generic programming. It provides standard C99 integer types, such as might be found in <stdint.h>, without requiring that header. It provides the means to select an integer type based upon its properties, like the number of bits or the maximum supported value, as well as compile-time bit mask selection. There is a std::numeric_limits derivate that provides constant expressions for min and max. Finally, it provides two compile-time algorithms: determining the highest power of two in a compile-time value; and computing min and max of constant expressions.

(Why are some headers in boost/integer and others in boost? That's awkward.)

_________________________________
Standard Integer Types

________________
Overview

s/specifications are/specifications for these types are/
s/The 64-bit types...in the C++ standard./The 64-bit types required by the C standard are used as models. If <stdint.h> is available on a given platform, those typedefs are used as the definitions for the boost namespace typedefs. Otherwise, or if long long is not provided, <boost/cstdint.hpp> provides its own definitions.

________________
Rationale

s/resorting to/resulting in/
s/As always, the intension/The intention/

________________
Exact-width integer types

"if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, it shall define the corresponding typedef names"

Sounds like text from a standard and its application to cstdint.hpp isn't clear. I think the following is clear, assuming I inferred the right meaning:

However, if a platform supports integer types with widths of 8, 16, 32, 64, or any combination thereof, <boost/cstdint.hpp> provides the corresponding typedefs.

________________
Minimum-width integer types

s/int_least32_t denotes a signed integer type with a width of at least 32/int_least32_t denotes the smallest signed integer type with a width of at least 32/

s/Required minimum-width integer types/The following minimum-width integer types are provided for all platforms/

s/The types:/The following types are available only if, after including <boost/cstdint.hpp>, the macro BOOST_NO_INT64_T is not defined:/
s/Are available only if, after inclusion of <boost/cstdint.hpp>, the macro BOOST_NO_INT64_T is not defined.//

________________
Fastest minimum-width integer types

s/Required fastest minimum-width integer types/The following fastest minimum-width integer types are provided for all platforms/

s/The types:/The following types are available only if, after including <boost/cstdint.hpp>, the macro BOOST_NO_INT64_T is not defined:/
s/Are available only if, after inclusion of <boost/cstdint.hpp>, the macro BOOST_NO_INT64_T is not defined.//

________________
Greatest-width integer types

s/These types are required/These types are provided for all platforms/
("Required" implies the reader must do something rather than that the library always does it, at least when I read it in these contexts.)

_________________________________
Integer Traits

________________
Synopsis

integer_traits has all private members. Should it have been declared a struct?

________________
Description

s/In general, it/The primary specialization/
s/Note: A flag is_integral/Note: The is_integral flag/
s/nonetheless/while/
s/cannot be provided for that user-defined class/are not provided for that user-defined class, unless boost::integer_traits is also specialized/

_________________________________
Integer Type Selection

(Throughout this section, s/class member/nested type/ to clarify that the "member" is a type.)

________________
Easiest-to-Manipulate Types

"Unsigned integral types can be used, as well as signed integral types, despite the name. The output type is given as the class member fast."

These are not doc comments: I would think adding uint_fast_t would be less confusing, though using int_fast_t with unsigned types must probably continue to work for backward compatibility. The output type ought also to be accessible as "type."

s/conditionalized/customized/

________________
Sized Types

This is not a doc comment: The output type ought to be accessible as "type," though you'd probably need to retain "least" for backward compatibility.

s/smallest built-in signed integral type/smallest, built-in, signed integral type/g
s/smallest built-in unsigned integral type/smallest, built-in, unsigned integral type/g
s/0 - V/0-V/ or s/V-0/V - 0/

_________________________________
Integer Masks

________________
Table 2. Members of the `boost::high_bit_mask_t` Class Template

s/smallest unsigned built-in type/smallest, unsigned, built-in type/
s/quick-to-manipulate/easiest-to-manipulate/
s/A least constant of the desired bit-masking value/A least constant with the value 2<sup>Bit</sup>/

________________
Group Bit-Mask Class Template

s/lowest bits of a certain amount/lowest Bits bits/

(I couldn't figure out what the original phrasing meant and took a guess.)

s/The bit amount/Bits/
s/largest unsigned built-in integral type/largest, unsigned, built-in integral type/

________________
Table 3. Members of the [^boost::low_bits_mask_t] Class Template

s/smallest unsigned built-in type/smallest, unsigned, built-in type/
s/quick-to-manipulate/easiest-to-manipulate/

_________________________________
Compile time log2 Calculation

s/Compile time log2 Calculation/Compile Time log2 Calculation/ or s/Compile time log2 Calculation/Compile-time log2 Calculation/

________________
Usage

s/truncated base-two logarithm/truncated, base-two logarithm/

________________
Example

What in the world is "is_it_what" supposed to convey? The name is nonsensical to me.

________________
Rationale

s/statically (i.e. at compile-time) available/available statically (i.e. at compile-time)/

_________________________________
Compile time min/max calculation

________________
Usage

In "signed or unsigned (long) parameters," the formatting of "signed" and "unsigned (long)" differ and are confusing.

_____
Rob Stewart robert.stewart@...
Software Engineer, Core Software using std::disclaimer;
Susquehanna International Group, LLP http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[1.42.0] Release branch open for merges

2009-11-27T06:50:55Z

The release branch (https://svn.boost.org/svn/boost/branches/release)
is open for merging all stable changes from trunk, including bug fixes
and major upgrades to existing libraries. Breaking changes should be
coordinated via the mailing list with the developers of the other
libraries affected. New libraries may be added, but require permission
of a release manager.

In other words, merging *does not* require permission from a release
manager, except for new libraries.

Boost Calendar with the release schedule:
http://www.boost.org/development/index.html

Release schedule explanation:
http://svn.boost.org/trac/boost/wiki/ReleaseSchedule

Release practices for developers:
http://svn.boost.org/trac/boost/wiki/ImprovingPractices

-- The Release Managers,

Beman Dawes
Daniel James
Eric Niebler
Rene Rivera
Vladimir Prus
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[LibrariesUnderConstruction]Mirror - update

2009-11-27T05:59:33Z

Hi,

I would like to ask the admins to update the info about the Mirror library
on the LibrariesUnderConstruction page in particular to add the links
to the C++0x version of Mirror on sourceforce:
http://sourceforge.net/projects/mirror-lib/

and to add a link to the online docs for the C++0x version:
http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/

TIA

________________
::matus_chochlik
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Boost.Array Maintainer

2009-11-27T03:36:37Z

2009/11/27 John Maddock <john@...>:

Thanks for this John, I have to admit I didn't even bother looking at
the code or the list of maintainers before I asked the question -- I
just saw that in Trac, those tickets assigned to Boost.Array were
assigned to 'no-maintainer'. :)

> It seems to me though that the bug sprints would be a good opportunity to widen the maintainer list a little - what if we assigned an interested volunteer to act as temporary maintainer for an orphan library during the sprint. (S)he fixes whatever they can fix, then gets another bug sprint volunteer to review the changes, if all looks well, and the tests are all passing on Trunk, only then merge to release.
>
> Thoughts? John.

This sounds reasonable to me. :)

--
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: warning policy issue

2009-11-27T03:23:10Z

> -----Original Message-----
> From: boost-bounces@... [mailto:boost-bounces@...] On
Behalf Of Daniel James

> Sent: Thursday, November 26, 2009 11:07 PM
> To: boost@...
> Subject: Re: [boost] warning policy issue
>
> There are a few warning conditions in Visual C++ 7.1 that were removed
> in later versions. I think their removal is a good indication of their
> worth (the ones I've come across were certainly buggy). They should
> probably just be suppressed with something like the following.
>
> #if defined(BOOST_MSVC)
> #pragma warning(push)
> #if BOOST_MSVC < 1400
> #pragma warning(disable:4244)
> #endif
> #endif
>
> // ....
>
> #if defined(BOOST_MSVC)
> #pragma warning(pop)
> #endif

If the problem is only with version 7.1, I agree this is the best policy.

The https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines
effectively suggest this (but using the BOOST_WORKAROUND macro)
"
If the warning is only for a specific compiler version, use this approach:

#if BOOST_WORKAROUND(BOOST_MSVC, >= 1400)
#pragma warning(push)
#pragma warning(disable:4512) //assignment operator could not be generated
#endif

...

#if BOOST_WORKAROUND(BOOST_MSVC, >= 1400)
#pragma warning(pop)
#endif
"

Does anyone have a problem with this guidance?

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal, UK LA8 8AB
+44 1539 561830, mobile +44 7714330204
pbristow@...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Boost.Integer makeover

2009-11-27T03:14:22Z

>> Setting chunker.output.encoding to US-ASCII might fix this. I'll try it
>> later.
>
> OK, I've changed html.xsl to do that. I'm not sure if it's a good
> idea, we'll see how it goes.
>
> https://svn.boost.org/trac/boost/changeset/57964/

That gets it, thanks!

Of course changes only come into effect once the docs are regenerated and
checked in...

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [math] Comeau can't match math::tools::fmod_workaround

2009-11-27T03:10:27Z

> Could any one confirm if it is an error indeed?

These all look to be related, and indicate a genuine issue:

fabs(long_double_value)

is returning a double (ie truncated) result :-(

Can you confirm whether #include <cmath> results in fabs(long double) being
defined?

Thanks, John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Boost.Array Maintainer

2009-11-27T03:02:51Z

>> Question: does someone have to be a maintainer of an existing library
>> (or author of one of the accepted libraries) to become a maintainer of
>> an existing (orphaned?) library?
>
> This is a very interesting question. Some lingering tickets with patch
> could be cleared faster if soem orphaned components of bosot were
> assignated new manager.

Indeed. Something that occurred to me earlier was "how many tickets were
looked at in the last sprint, assigned a patch, but haven't been looked at
since?" That would be a good test of the owner being missing-in-action!

Re Boost.Array, I seem to remember Alisdair Meredith taking this on, I'm
cc'ing him just in case my memory isn't what it once was ! ;-)

It seems to me though that the bug sprints would be a good opportunity to
widen the maintainer list a little - what if we assigned an interested
volunteer to act as temporary maintainer for an orphan library during the
sprint. (S)he fixes whatever they can fix, then gets another bug sprint
volunteer to review the changes, if all looks well, and the tests are all
passing on Trunk, only then merge to release.

Thoughts? John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Any interest in static plugins?

2009-11-27T02:55:26Z

Hi Dave,

You may get more response if you posted or linked to some motivational
examples.

Regards,
Christian.

On Fri, Nov 27, 2009 at 11:45 AM, Dave van Soest <dsoest@...> wrote:

> Hi all,
>
> I created a template-based header-only library for creating static plugin
> systems. I'm wondering whether there would be any interest to include such
> a library in Boost.
>
> About static plugins:
> Static plugins are not as common as dynamic plugins, but they have some
> useful applications. Static plugins are a way to extend the functionality
> of a program or library without having to change the existing source
> files, just by adding a source file or object file, which is then linked
> statically against the already existing object files. Some reasons you
> might be doing this:
> - You don't have permission to change the existing source files.
> - You don't have the source files, only the object and header files. - You
> don't want to have to change existing sources every time you extend
> functionality.
> - Simply including or excluding the object file from the linking process
> adds or removes functionality from the program or library, leaving no
> traces inside.
> - Different configurations can be build easily this way.
> - Testing only the required functionality without having to build the
> full application.
> - And some other advantages it shares with dynamic plugins.
>
> If there appears to be any interest I will post more information and some
> code and code examples.
>
> Best regards,
> Dave van Soest
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [unordered] 1.41.0 unordered_map doesn't allow declaration with incomplete type.

2009-11-27T02:40:03Z

2009/11/19 Jon Spencer <dev@...>:
> The new version of the unordered library doesn't allow you to declare an
> unordered
> map with an incomplete type. The following code would compile with the old
> version
> but not the new:

Sorry, about the slow reply. Support in the old version wasn't
intentional, I think it was just a result of the restricted templates
use in order to support older compilers. I think it's fixed in trunk
now, although I need to do more testing to make sure. It should be
fixed in the next release.

Daniel
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [serialization] polymorphic archives + boost_class_exportgenerates linker errors

2009-11-27T02:33:07Z

Robert,

> Have your tried runnig the tests/demos included with the package that
> use polymorphic archives? Do they build and run?

I've run all tests and polymorphic examples successfully. This however
does not solve my problem:

My initial linker error was due to the included headers in my previous
example: including <boost/archive/polymorphic_xml_archive.hpp> or any
other concrete polymorphic archive before a call to BOOST_CLASS_EXPORT
fails with the named linker error. I was not aware of the the fact
that including <boost/polymorphic_iarchive.hpp> and
<boost/polymorphic_oarchive.hpp> suffices to enable export for all
polymorphic archives. Maybe this should go into documentation?

Based on demo_polymorphic.cpp I've re-created minimal test example,
which I think is correct, that fails with the runtime assertion

it != m_map.end(), file libs\serialization\src\basic_serializer_map.cpp, line 72

on load. The demo consists of 5 files that create the following
scenario: class B inherits from polymorphic base class A. An object of
B is allocated on the heap and serialized through a base pointer A
using a polymorphic xml archive. Saving runs without problems. Next, B
is loaded from the stream through a base pointer to A. This fails with
the mentioned assertion.

What makes me wonder is that changing the from
polymorphic_xml_iarchive to xml_iarchive and from
polymorphic_xml_oarchive to xml_oarchive will not produce the named
assertion.

As mentioned in my previous post, I tested this with boost 1.40.0 and msvc 9.0.

I would be really, really, grateful if you could give the demo a try.
I've prepared everything so that it is just a matter of copying the
files to libs/serialization/example and adding

[ demo_bsl_run demo_polymorphic_cheind : cheind_a cheind_b ]

to the jamfile. I hope it is ok to attach the files directly to this message.

With best regards,
Christoph

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

cheind_a.cpp (992 bytes) Download Attachment
cheind_a.hpp (614 bytes) Download Attachment
cheind_b.cpp (1012 bytes) Download Attachment
cheind_b.hpp (574 bytes) Download Attachment
demo_polymorphic_cheind.cpp (874 bytes) Download Attachment

Re: Core libraries should separated from experimentallibraries

2009-11-27T02:13:10Z

Hi Christian,

Christian Schladetsch wrote:
> Coming from a game-dev background I think I have something to add here.
>
> It may be surprising, but traditional game development, rather than being
> all glamorous and using the latest technology, is quite the opposite. Sure,
> we use the latest hardware and API's, but those API's are often written in
> C, or, lately, very conservative C++.
>
> No game middleware that I am aware of uses even STL let alone boost.

Thank you for your insight...hopefully, it doesn't get you into trouble
with your former employers. :-)

My initial thought is that companies would want to use their own tools
because they can optimize it [in terms of speed] for what they need it
for. I think an often used English expression is to not re-invent the
wheel; but one reason for re-inventing the wheel is that you know
everything about the wheel [you made]... :-)

Ray

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [unordered] unordered_set::erase() complexity bug?

2009-11-27T02:03:10Z

John Zwinck skrev:

> Jeffrey Bosboom wrote:
>> Getting back to this specific case, I think the two versions of
>> erase() are different enough in performance to warrant providing both.
>> Unfortunately, I don't know of a good alternate name for whichever one
>> isn't named erase().
>
> A name which is simply synonymous with "erase" may leave people confused.
> I do think that creating a new function name is what's needed here so
> that we may move forward with an obviously-viable solution (as opposed
> to ones which may raise substantive objections, such as lazy evaluation).

I don't think we have sufficient reason for adding two functions. (The
obvious name remove() is needed for the purpose of getting a unique_ptr
to a node).

> I suggest augmenting the existing name: something like "erase_fast"
> or even "erase_void" would be fine (at least until someone else comes up
> with something better, for which there will no doubt be plenty of time).

We can just do

m.erase(++it)

like we do with std::map, so I don't see the need for non-void return.

> As for the production code which I mentioned in my previous message, we
> decided to deploy a solution which erases by key. This solution is
> almost tragic, for we have the iterator in hand when we decide to
> erase() it, but at least the performance doesn't blow up now.

That is tragic.

-Thorsten
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[LibrariesUnderConstruction] Boost.Numeric_Bindings

2009-11-27T00:58:20Z

Hello all,

I see the Numeric_Bindings library is missing on the
LibrariesUnderConstruction trac page. This library is under development
since 2002. Herewith a short description of the library.

Boost.Numeric_Bindings is a C++ library for numeric computing. It is a
generic layer between data containers and linear algebra algorithms.

For the data container part, it supports both compile-time statically sized
and run-time dynamically sized vectors, matrices, through a traits system.
Currently it includes traits for C-arrays, for standard vectors, for uBLAS'
containers, Eigen containers, TNT, Boost.Array, to name a few. It offers
compile-time inspection, iterators, and views on all mentioned containers.

For the algorithm part, it provides a C++ interface to algorithms offered by
BLAS, LAPACK, and more. This covers algorithms from most vendor-provided
math libraries, such as the reference BLAS, ATLAS, Intel's MKL, AMD's CML,
NVidia's CUDA, etc..

The "stable" release is available at
http://svn.boost.org/svn/boost/sandbox/numeric_bindings-v1/

The current development version is available at
http://svn.boost.org/svn/boost/sandbox/numeric_bindings/

Questions and/or comments are welcomed.

Thanks,

Rutger

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Boost.Array Maintainer

2009-11-27T00:51:28Z

Dean Michael Berris wrote:
> Question: does someone have to be a maintainer of an existing library
> (or author of one of the accepted libraries) to become a maintainer of
> an existing (orphaned?) library?

I think the current system of library "ownership" is a big problem for
Boost. When the owner/maintainer is around, things work fine, but
simply letting libraries rot because their owner moved on to other
projects is not acceptable. We shouldn't advertise that they're of
"Boost quality" when bugs are not being addressed (particularly when
patches are provided, and all that has to be done is commit, watch the
tests cycle, and merge -- users end up having to maintain these patches
themselves against their local installation of Boost). Either
unmaintained libraries should be removed from Boost, or anyone else
willing to take responsibility for them should be allowed to do so.

--Jeffrey Bosboom
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [function] Using boost::function when rtti isnot available

2009-11-27T00:49:41Z

"David Genest" <david.genest@...> wrote in message
news:E7F3301F6AF1F341AB107794F4F80A6F197FC350@......

> Hi Domagoj,
>
> I am on xbox 360 with visual 2005, PS3 with SNSystems SNC compiler and gcc
> compiler v 4.1.1.
>
> I have tried your implementation and compilation fails at a STATIC_ASSERT:
> BOOST_STATIC_ASSERT( is_stateless<base_empty_handler>::value );
>
> A simple declaration of boost::function<void ()> f; will create this error.
>
> A similar assert happens with SN systems compiler for the PS3.

hmm...according to
http://www.boost.org/doc/libs/1_40_0/libs/type_traits/doc/html/boost_typetraits/reference/is_stateless.html
the is_stateless<> trait should work properly on msvc++ 8...

can you try replacing is_stateless<> with
has_trivial_constructor<base_empty_handler>::value &&
has_trivial_destructor<base_empty_handler>::value &&
is_empty<base_empty_handler>::value
?

> When I use gcc, there are a slew of errors mostly pertaining to
> declaration order in function_template.hpp. I am not very familiar
> with this issue, but have tried to move code around, and defining
> functions out of class scope. Some errors go away, but there are
> a lot of compiler problems at least on my machine.

i was afraid of that...i relied on lazy template instantiation in several
places and used forward declarations of member types (with out-of-body
definitions) to improve readability...this worked properly on msvc++ (as it is
pretty lazy with template instantiations) but gcc is obviously much less
'liberal'/permissive about that (i don't know what the standard has to say
about it?)...

> Here is the error on xbox 360:
...
> 1> myFile.cpp(64) : see reference to class template instantiation
> 'boost::function<Signature>' being compiled
> 1> with
> 1> [
> 1> Signature=void (void)
> 1> ]

this part looks 'wrong'...as if myFile.cpp still used "some part of the old
headers"...because in the new implementation the main bf template has the
following 'signature' boost::funciton<Signature, PolicyList>...perhaps you
should do a clean rebuild...(you must also rebuild boost if you use any
non-header-only libraries that internaly use boost::function)...

> There were also some trouble when compiling templates that end in ">>" which
> AFAIK is not fixed on my version of gcc.
>
> Do you know if your changes made boost.function less robust to older
> compilers ?

well...obviously/most probably they did unfortunately...besides avoiding sfinae
in a few places i did not spend too much effort on old compiler compatibility
issues...

i tested only on msvc++ 9.0 sp1 and 10.0b1...there it compiled without
warnings and worked correctly...but yes, this is just a prototype, draft
version on which only a limited number of, my own, tests were run (i did not
run the official boost tests...because i have yet never run those tests and do
not know how they work and because allocator support is still/currently
disabled)...

without ignoring the old-compilers-backward compatibility issue...considering
that the two compilers, msvc++ and gcc, you are using are ('semi') free i would
truly recommend an upgrade...yes i know you would probably have to fight some
'semi-irrational'/paranoid corporate rules and 'stiff chains of command' but,
atleast when msvc++ is concerned, it will be worth the effort as it might
actually save you time...not just on issues like these but because the msvc++
9.0 compiler is about twice as fast as the 8.0 one plus it has a working
multicore mode (the /mp switch) so on a dual core machine you get a ~4 times
faster compilation (and for almost 0 cost...the upgrade is just a reinstall...
nothing much was changed...its not like the 7.1 -> 8.0 upgrade with all the
secure crt and secure stl mess ;)

i do actually have a dusty msvc++ 8.0 sp1 installation (do you have all the
patches installed on your installation) on a different computer...so if i get
the time i'll test my code on it today and see what i can do...
(i'll start using gcc on mac osx in the following year but i doubt that is of
much use right now :)

ps. thanks for testing and reporting the errors with your tool chain ;)
...and glad to see the 'major' gaming industry is using boost ;-)

pps. found a bug:
the line
function_base.hpp :
manager_trivial_heap::clone()

{

...

std::memcpy( functor_ptr( out_buffer ), functor_ptr( in_buffer ),
storage_array_size );

}

should be:

...

std::memcpy( functor_ptr( out_buffer ), functor_ptr( in_buffer ),
storage_array_size * sizeof( storage_atom ) );

...

--
"That men do not learn very much from the lessons of history is the most
important of all the lessons of history."
Aldous Huxley

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [function] Using boost::function when rtti isnot available

2009-11-27T00:49:27Z

"David Genest" <david.genest@...> wrote in message
news:E7F3301F6AF1F341AB107794F4F80A6F19746B05@......

> Domagoj Saric Wrote:
>> it has various other space and time optimizations besides no-typeid
>> support as
>> well as cofigurability through policies (although it seemes to have
>> sparked
>> little interest)...
>
> I read most of the thread and I'm surprised to see that you are right
> regarding interest. I'm surely interested which means there must be
> others. I'm impressed by the depth of your analysis/optimisations.
> Will this effort be brought in a new version of boost soon ?

sorry...i cannot know that ;)
there seem to be several more 'higher-level' discussion threads active at the
moment...perhaps 'resurrecting' the topic at a more peaceful time would be a
good idea...

>> hope it helps...:
>
> It will!

glad to hear that ;)

>> http://thread.gmane.org/gmane.comp.lib.boost.devel/194514/focus=195351
>> ;)
>
> I didn't find any attachments in gmane, but found the vault version
> (
> http://www.boostpro.com/vault/index.php?action=downloadfile&filename=new_function_implementation_proposal.tgz&directory=Function%20Objects& )
> .
> Is this the latest version ?

pretty much...i paused the work on bf until there is atleast some discussion on
the work so far (what's 'good' and what's 'bad') and any 'semi-official' hints
that the changes/ideas might eventually be accepted...

>Can I just apply the new files over the current function directory?

yes...it should be a drop in replacement...

--
"That men do not learn very much from the lessons of history is the most
important of all the lessons of history."
Aldous Huxley

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Review Request: boost.lockfree

2009-11-27T00:46:42Z

strasser@... wrote:

> Zitat von Tim Blechmann <tim@...>:
>
>
>> since my first review request for boost.lockfree [1] was completely
> ignored
>
> I have stated that multiple times, I think a mailing list is the wrong
> format for boost. important posts are missed in the noise.
>
> is this still a mailing list for historical reasons only or was there
> a decision against a message board?

[off-topic]

I don't know about any specific decisions, but message boards (internet
forums) are often terrible for following threads of conversation (at least
technical ones).

Using the mailing list directly might not be the best alternative either,
but accessing mailing lists over nntp using gmane works really, really well
for me.

HTH / Johan

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Review Queue Needs Attention

2009-11-26T23:21:07Z

Tim Blechmann wrote:

>>>>>>>> (And a state not damned with faint praise like 'unstable' - which is perhaps
>>>>>>>> better described as 'likely_to_be_improved' rather than actively 'not stable').
>>>>>>
>>>>>> The apache incubator might be a more appropriate inspiration than
>>>>>> Debian unstable.
>>>>>
>>>>> the current sandbox layout has the disadvantage, that single projects
>>>>> are present as sandbox/mylib, which do not run or compile on their own,
>>>>> but require a full set of the boost headers. in order to try out one
>>>>> sandbox library, you need to get the boost checkout/tarball and copy it
>>>>> to sandbox/mylib or vice versa ...
>>>>
>>>> Just to clarify -- what is wrong with starting with checkout of 'main'
>>>> Boost tree, and then doing 2 "svn co" per any sandbox library you want
>>>> to try?
>>>
>>> not sure, whether i understand it correctly. if i check out trunk and
>>> sandbox/mylib to myboost/ ... then myboost would contain 2 independent
>>> svn checkouts ... does `svn diff' show the diff with trunk or with
>>> sandbox/mylib then?
>>
>> "svn diff" without arguments will show difference in 'main boost'
>> "svn diff boost/mylib libs/mylib" will show the difference for the specified
>> library -- but this is probably obvious.
>>
>> Is this a problem and what alternatives do you suggest?
>
> well, both checkouts wouldn't be synchronized ...
> a distributed version
> control system would fit for this use case way better ... i don't want
> to start a scm flamewar, but for me svn appears to be very limited
> compared to tools like git ...

We could probably indeed start a nice flamewar on version control, but before
we go that route, I wanted to double check. Is this inconvenience of
combining sanbbox libraries with main release the primary issue with the current
organization of sandbox? Or there are other issues? Could you list them?

Because if it's the only issue, we're doing pretty well ;-)

- Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Boost.Array Maintainer

2009-11-26T23:19:41Z

Dean Michael Berris wrote:
> Question: does someone have to be a maintainer of an existing library
> (or author of one of the accepted libraries) to become a maintainer of
> an existing (orphaned?) library?

This is a very interesting question. Some lingering tickets with patch
could be cleared faster if soem orphaned components of bosot were
assignated new manager.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Review Request: boost.lockfree

2009-11-26T23:18:40Z

Am Friday 27 November 2009 06:35:48 schrieb Dave Abrahams:

> > is this still a mailing list for historical reasons only or was there a
> > decision against a message board?
>
> Speaking for myself, nobody has ever explained to me why a message
> board would be significantly different, so I don't see any upside in
> switching.

most important, visibility of important threads over a longer period of time.
there would be a subforum "Proposed libraries", with threads with new messages
at the top.

I understand that there is no difference from a technical viewpoint and that
some mailreaders can display a mailing list exactly like that, but I don't
think a proposal like lockfree would have been fergotten on a board.
you rarely see replies to threads more than two weeks old on this mailing
list, so people do read it either on a day to day basis, or not at all.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Review Request: boost.lockfree

2009-11-26T21:35:48Z

On Tuesday, November 24, 2009, <strasser@...> wrote:

> Zitat von Tim Blechmann <tim@...>:
>
>
>
> since my first review request for boost.lockfree [1] was completely
>
> ignored
>
> I have stated that multiple times, I think a mailing list is the wrong format for boost. important posts are missed in the noise.
>
> is this still a mailing list for historical reasons only or was there a decision against a message board?

Speaking for myself, nobody has ever explained to me why a message
board would be significantly different, so I don't see any upside in
switching.

--
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Core libraries should separated from experimentallibraries

2009-11-26T18:43:49Z

2009/11/26 Christian Schladetsch <christian.schladetsch@...>

> Coming from a game-dev background I think I have something to add here.
>
> It may be surprising, but traditional game development, rather than being
> all glamorous and using the latest technology, is quite the opposite. Sure,
> we use the latest hardware and API's, but those API's are often written in
> C, or, lately, very conservative C++.
>
> No game middleware that I am aware of uses even STL let alone boost. I
> worked at EA for a while, and they had their own version of STL called
> EASTL.
>
>

I've worked in the game industry for past ten years, and even if I have a
background in the assembler swamp I can't argue today that it's productive.
We're using boost libraries everywhere, from shared_ptr, function,
bind,algorithms, regex, filesystem,multiindex, etc, etc. These are easy
libraries, but we also use a bunch of traits usage, mpl, asio (our main
network backend is all asio, who can say it's efficient to write network
code without it) and the past few years fusion has become a life-safer.

I hate to see that our middle end engine have reinvent the same broken
wheels over and over that we need fixing with modern c++, and having trivial
tasks solved in an extremely complex and often inefficient way. Still it's
one of the few 'giants', with a giant price tag to it.

>
> Again; Why is that? Why is it that the game development community, lauded
> for being on the bleeding edge, rejects what we would call modern C++? How
> can we build all this quite obviously complicated software without the
> latest and greatest methodologies?
>

It's a mystery, I agree. Because people are working overtime too much I
guess. Personally I don't think it's bleeding edge, except from the graphics
side which is being pushed by numbers of transistors and the somewhat
organized effort of nVidia and Microsoft (on PC, at least).

>
> Thanks for bearing with me to my punchline: the gamedev community only
> cares
> about results and deadlines. They don't have time to risk new things until
> and unless they have become ubiquitous.
>

As a result the gamedev community has horrible code, at best, and therefor
development time isn't exactly short and thirdparty libraries very
expensive. I was surprised first time I read about EASTL, it seemed like the
only sane effort in years (solving typical gamedev related concerns in a
reusable generic way).
I truly dislike the game industry's general approach to software
development, it's inefficient, expensive, and doesn't lead anywhere.
Whenever we integrate a new third party library we need to wrap it to become
usable. How many IFile have I wrapped in my life, just because companies
can't read up on how to implement streambuf? They save time but waste mine.
Their pricetag reflects the amount of work as well, since everything is
nicely 'handcrafted' (i.e. expensive and likely buggy).

>
> Boost has suffered from the opposite of the game-dev scenario: rather than
> being too conservative, boost has been too liberal and academic. Where
> gamedev eschews fancy meta-programming for a basic bison or ANTLR script or
> fast and accurate and specific solutions, and while it does actually care
> for cross-platform support[1], boost is necessarily confined to the pure
> C++
> model and genericity.
>
> You can never be too liberal. The more techniques added to the mix the

greater chance of finding ones typical problem already solved, and one can
move on improving things instead.
I think every game company out there, after having put their product out on
the shelf, feels like: "ah, finally, this mess is out the door. Now let's
start the next one from scratch and this time do it 'right'. " Except maybe
for companies who need to maintain their code because they iterate their
product titles over the years. Like EA, who probably figured they needed
something like STL but with some additional requirements (they mostly
reworked the allocators, I think?).

My 2 gamedev cents,
Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Serialization] deserialize stl container,complier error

2009-11-26T17:43:30Z

Hi all,

boost:1.4.0
compiler: vs 2005
code:

#define Data_Io_Load_Save(class_name, members) \
friend class boost::serialization::access; \
template<class Archive> \
void serialize(Archive & ar, const unsigned int version) \
{ ar members; }

#define Data_Io_Load_Save_Base(base_class)
BOOST_SERIALIZATION_BASE_OBJECT_NVP(base_class)
#define Auto_Value_Decl(type) BOOST_SERIALIZATION_NVP(type)

struct TestStruct
{
int type;

int ina[10];
std::map<std::string, std::string> mapstr;

Data_Io_Load_Save(TestStruct, &Auto_Value_Decl(type)

&Auto_Value_Decl(ina)
&Auto_Value_Decl(mapstr)
);
};

void TestSerial()
{
TestStruct ts, its;
ts.type = 2222;
ts. mapstr ["str1"] = "str1";
ts. mapstr ["str2"] = "str2";
ts. mapstr ["str3"] = "str3";
ts. mapstr ["str4"] = "str4";

// save
std::ofstream ofs("proto.txt");
boost::archive::xml_oarchive oa(ofs);
oa << Auto_Value_Decl(ts. mapstr); //
oa << Auto_Value_Decl(ts); //

ofs.close();
//load
std::ifstream ifs("proto.txt");
boost::archive::xml_iarchive ia(ifs);

ts.mapint.clear();
ia & Auto_Value_Decl(ts. mapstr); // error
ia & Auto_Value_Decl(its); // error

ifs.close();
}

because loading " std::map<std::string, std::string> mapstr;", the compiler
stop at stack_constructor.hpp:64, the line is " this->address()->~T(); "
so, I changed "stack_constructor.hpp"

template<typename T >
struct stack_allocate
{
T * address() {
return static_cast<T*>(&storage_/*.address()*/);
}
T & reference() {
return * address();
}
private:
//typedef BOOST_DEDUCED_TYPENAME boost::aligned_storage<
// sizeof(T),
// #if BOOST_WORKAROUND(__BORLANDC__,BOOST_TESTED_AT(0x560))
// 8
// #else
// boost::alignment_of<T>::value
// #endif
//> type;
T storage_;
};

// construct element on the stack
template<class Archive, class T>
struct stack_construct : public stack_allocate<T>
{
stack_construct(Archive & ar, const unsigned int version){
//// note borland emits a no-op without the explicit namespace
//boost::serialization::load_construct_data_adl(
// ar,
// this->address(),
// version
//);
}
~stack_construct(){
//this->address()->~T(); // undo load_construct_data above
}
};

then, all be ok.

Regards.
Simon Cheung.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Any interest in static plugins?

2009-11-26T16:45:09Z

Hi all,

I created a template-based header-only library for creating static plugin
systems. I'm wondering whether there would be any interest to include such
a library in Boost.

About static plugins:
Static plugins are not as common as dynamic plugins, but they have some
useful applications. Static plugins are a way to extend the functionality
of a program or library without having to change the existing source
files, just by adding a source file or object file, which is then linked
statically against the already existing object files. Some reasons you
might be doing this:
- You don't have permission to change the existing source files.
- You don't have the source files, only the object and header files. - You
don't want to have to change existing sources every time you extend
functionality.
- Simply including or excluding the object file from the linking process
adds or removes functionality from the program or library, leaving no
traces inside.
- Different configurations can be build easily this way.
- Testing only the required functionality without having to build the
full application.
- And some other advantages it shares with dynamic plugins.

If there appears to be any interest I will post more information and some
code and code examples.

Best regards,
Dave van Soest

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [unordered] unordered_set::erase() complexity bug?

2009-11-26T15:58:50Z

2009/11/26 John Zwinck <jzwinck@...>:
>
> I suggest augmenting the existing name: something like "erase_fast"
> or even "erase_void" would be fine (at least until someone else comes up
> with something better, for which there will no doubt be plenty of time).

'erase' would be better. But as a temporary measure I'll add something
like that, you might want to file a ticket to make sure I don't forget
and track what I do.

Daniel
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost