Re: [boost] Re: xml library
On Friday 29 August 2003 10:36 am, Cédric Naniot wrote: > Well, I find the API quite good, and realy better than the sax one. > So, in other words, you say this API is better than sax? :) pgp0.pgp Description: signature
Re: [boost] 1.30.0->1.30.2: no more thread support for Linux?
On Saturday 23 August 2003 07:18 am, John Maddock wrote: > > One more thing: what exactly can go wrong with 1.30.0 if > > -pthread isn't used? Is it boost specific or a general thing > > (e.g. issues w/ respect to libstdc++)? > > A general thing - without this then: > > Your std lib is not thread safe. > Your C lib is not thread safe. > g++ will not emit thread safe exception handling code. > > Thus while for C programs enabling thread support is just a question of > linking to the right libraries, for C++ you also need to ensure that the > compiler "knows" that you want thread safe code. > You mean I can't just run bjam with no options and get the libs built with thread support? I need to add a command-line option? I am updating my RPM package for 1.30.2, and I'd like to make sure this is correct, and I will forward this to Redhat (they now have a boost rpm). pgp0.pgp Description: signature
[boost] arithmetic traits
I'm thinking that it would be useful to implement a traits class that would give the return type of mixed scalar-complex arithmetic operations. This would allow one to write generic algorithms that operate on both scalar and complex types, inferring the return type. Any opinions? pgp0.pgp Description: signature
[boost] program_options multiple source question
I'm lost with trying to use the (unreleased) program_options lib.
I have no problem to use with just command line, but I'd like to have both
command line and config file.
Here's what I tried:
try {
options_description desc("Allowed options");
desc.add_options()
("help", "", "produce help message")
("esNodB,e", parameter ("value", &esnodB), "Es/No(dB)")
("maxBursts,m", parameter ("value", &maxBursts), "stop after
#bursts")
("maxErrors,M", parameter ("value", &maxErrors), "stop after
#errors")
;
options_and_arguments opts = parse_command_line(argc, argv, desc);
variables_map vm;
store(opts, vm, desc);
ifstream ifs("TestUWP.cfg");
options_and_arguments opts2 = parse_config_file(ifs, desc);
variables_map cfg_file_vm;
store(opts2, cfg_file_vm, desc);
vm.next(&cfg_file_vm);
if (vm.count("help")) {
std::clog << desc << "\n";
return 1;
}
}
catch(std::exception& e) {
std::cerr << "error: " << e.what() << "\n";
return 1;
}
I get this message:
error: config file options should have required parameter
I tried various variations, and also referred to the multiple_sources example,
but I still can't find out what's wrong. Any clues?
pgp0.pgp
Description: signature
Re: [boost] Iterator adaptor question
On Wednesday 06 August 2003 01:41 pm, Thomas Witt wrote: > gpgkeys: WARNING: this is an *experimental* HKP interface! > gpgkeys: key D1DB3F812DD7B01A not found on keyserver > > Neal, > > Neal D. Becker wrote: > | Some time back I mentioned I was interested in iterator adaptors to > > convert > > | between vectors of complex and scalar. I have looked at using the > > iterator > > | adaptor framework in boost. It appears that it is easy enough to > > adapt from > > | a complex sequence to pick off either the real or imaginary part, but > > going > > | the other direction is not feasible? > | > | You would need to adapt from a pair of iterators over scalars to > > output an > > | iterator over complex. > > Thomas Becker is working on a combine iterator that will solve this > problem. IIUC he has a working draft. > Does this use the "old" iterator adaptor framework? Do you know where to find sample code? > | Will the "new" iterator adaptor framework help? > > If you need it badly iterator_facade will help with getting the iterator > interface right. > Don't know what that means. Is this part of the "new" iterator stuff? pgp0.pgp Description: signature
[boost] Iterator adaptor question
Some time back I mentioned I was interested in iterator adaptors to convert between vectors of complex and scalar. I have looked at using the iterator adaptor framework in boost. It appears that it is easy enough to adapt from a complex sequence to pick off either the real or imaginary part, but going the other direction is not feasible? You would need to adapt from a pair of iterators over scalars to output an iterator over complex. Will the "new" iterator adaptor framework help? pgp0.pgp Description: signature
Re: [boost] Patch to emacs cc-mode for template syntax andindentation
On Monday 04 August 2003 10:43 pm, David Abrahams wrote: > If anyone's interested, the enclosed patch against the current CC-mode Did you send this to cc-mode maintainer? Also, [EMAIL PROTECTED] pgp0.pgp Description: signature
Re: [boost] Iterator adaptor question
On Wednesday 06 August 2003 02:38 pm, Thomas Witt wrote:
> gpgkeys: WARNING: this is an *experimental* HKP interface!
> gpgkeys: key D1DB3F812DD7B01A not found on keyserver
>
> Rozental, Gennadiy wrote:
> | What is the problem adapting pair of iterators to scalar vectors to
>
> produce
>
> | an iterator with complex value type?
>
> The problem is you can hardly adapt a pair. So using iterator_adaptor
> (the new class template) does not provide any benefit.
>
> | I am sure both old and new iterator adaptor easily allows it.
>
> As I said before iterator_facade (new) would be the right tool AFAICS.
>
>
> Thomas
This seems to work, but it's klugey. I guess it is an existance proof that
it's possible to do with old iterator adaptors?
1) Since only 1 object can be passed to the iterator adaptor constructor, I
had to pass a pair.
2) Distance uses only one of the base iterators.
3) iterator_category uses only 1 of the iterators.
Can anyone suggest ways to improve this?
The first 2 policies pick off real or imag parts of complex. They are no
problem.
The last 1 combines real and imag into complex. That's where the problems
lie.
#include
#include
#include // pair
// #include
namespace boost {
namespace detail{
template
class complex_real_iterator_policy : public default_iterator_policies {
public:
// Constructors
complex_real_iterator_policy (BaseIterator const& _base) :
base (_base) {}
template
typename IteratorAdaptor::reference dereference (IteratorAdaptor& x)
const {
return real (*x.base());
}
private:
const BaseIterator& base;
};
template
class complex_imag_iterator_policy : public default_iterator_policies {
public:
// Constructors
complex_imag_iterator_policy (BaseIterator const& _base) :
base (_base) {}
template
typename IteratorAdaptor::reference dereference (IteratorAdaptor& x)
const {
return imag (*x.base());
}
private:
const BaseIterator& base;
};
template
class real_imag_complex_iterator_policy : public default_iterator_policies
{
public:
typedef typename std::pair base_type;
// Constructors
real_imag_complex_iterator_policy (base_type const& _base) :
base (_base) {}
template
typename IteratorAdaptor::reference dereference (IteratorAdaptor& x)
const {
return typename IteratorAdaptor::value_type (*x.base().first,
*x.base().second);
}
template
void increment(IteratorAdaptor& x)
{ ++x.base().first; ++x.base().second; }
template
void decrement(IteratorAdaptor& x)
{ --x.base().first; --x.base().second; }
template
typename IteratorAdaptor1::difference_type
distance(const IteratorAdaptor1& x, const IteratorAdaptor2& y) const
{ return y.base().first - x.base().first; }
private:
const base_type base;
};
} // namespace detail
template
struct complex_real_iterator_generator {
typedef typename boost::detail::iterator_traits::value_type
complex_value_type;
typedef typename complex_value_type::value_type scalar_value_type;
typedef
boost::iterator_adaptor,
reference_is > type;
};
template
typename complex_real_iterator_generator::type
make_complex_real_iterator(BaseIterator const& begin) {
typedef typename complex_real_iterator_generator::type
ret_type;
return ret_type (begin, detail::complex_real_iterator_policy
(begin));
}
template
struct complex_imag_iterator_generator {
typedef typename boost::detail::iterator_traits::value_type
complex_value_type;
typedef typename complex_value_type::value_type scalar_value_type;
typedef
boost::iterator_adaptor,
reference_is > type;
};
template
typename complex_imag_iterator_generator::type
make_complex_imag_iterator(BaseIterator const& begin) {
typedef typename complex_imag_iterator_generator::type
ret_type;
return ret_type (begin, detail::complex_imag_iterator_policy
(begin));
}
template
struct real_imag_complex_iterator_generator {
typedef typename boost::detail::iterator_traits::value_type
scalar_value_type;
typedef typename std::complex complex_value_type;
typedef typename std::pair pair_type;
typedef boost::iterator_adaptor,
complex_value_type, complex_value_type, complex_value_type*, typename
std::iterator_traits::iterator_category, typename
std::iterator_traits::difference_type > type;
};
template
typename real_imag_complex_iterator_generator::type
make_real_imag_complex_iterator(BaseIterator1 const& begin1, BaseIterator2
const& begin2) {
typedef typename real_imag_complex_iterator_generator::type ret_type;
typedef typename std::pair pair_type;
return ret_type (pair_type (begin1, begin2),
detail::real_imag_complex_iterator_policy
(pair_type (begin1, begin2)));
[boost] program_options defect
I just found that program_options (from yahoo "files") has a serious defect. The value of an option cannot start with the character '-', or it will be interpreted as an option. Obviously, this makes it difficult to enter a negative number as the option value. pgp0.pgp Description: signature
[boost] SRPM 1.30.1 available
I have modified the 1.30.0 SRPM for 1.30.1. Pretty simple, except you need a patch to fix the version number or the RPM build will fail. Should I upload the SRPM somewhere? pgp0.pgp Description: signature
[boost] searchable list archive + integer.hpp request
I know I (and others) have previously asked about extending integer.hpp to handle 64-bit types. I don't recall the conclusions of the discussion, though, and on visiting the boost archive, I don't see a search option. Perhaps someone can point me in the correct direction. (I would really like to see 64bit support in integer.hpp. Perhaps I should attempt a patch?) pgp0.pgp Description: signature
[boost] ublas compatibility question
Does ublas require matrix storage be managed by ublas? Is it possible to construct a ublas matrix that references a plain-old-C-style array? If not, what is a simple way construct a ublas matrix from a C-style array? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Updated Boost.Random to TR proposal
On Tuesday 08 July 2003 08:01 am, Neal D. Becker wrote:
> On Monday 07 July 2003 05:06 pm, Jens Maurer wrote:
> > I've updated the current Boost.Random CVS to the interface
> > contained in the C++ library TR proposal:
> >
> >http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1452.html
> >
> > The boost documentation has not yet been updated, I hope to be able
> > to do that later this week. Reading the TR proposal should give
> > you a sufficient idea.
> >
> > There have been various suggestions for changes from C++
> > committee members, so additional (but minor) interface changes
> > may happen after the October 2003 meeting.
>
> I would also like to suggest one addition that is very useful. It is very
> common in communications to need a generator that produces a 1-bit
> sequence.
After some reflection, I think a somewhat more generalized version might be
even better. This one can produce sequences of n-bit rather than only 1-bit.
I'm not sure what to do with max_value and min_value. It depends on
interpretation- whether you intend to sign extend the values and interpret
them as signed or zero extend and interpret as unsigned.
#ifndef pnseq_generator_H
#define pnseq_generator_H
#include
namespace boost
{
namespace random
{
template < class RandomNumberGenerator, int width=1 >
class pnseq_generator
{
public:
typedef pnseq_generator self_type;
typedef RandomNumberGenerator base_type;
typedef int result_type;
BOOST_STATIC_CONSTANT (bool, has_fixed_range = true);
BOOST_STATIC_CONSTANT (result_type, min_value = 0);
BOOST_STATIC_CONSTANT (unsigned int, max_value = ~(unsigned(-1) <<
width));
BOOST_STATIC_CONSTANT (int, mask = ~(unsigned(-1) << width));
result_type min() const
{ return min_value; }
result_type max() const
{ return max_value; }
explicit pnseq_generator (base_type & rng)
: rng_( rng ), count_()
{ init(); }
template < typename T >
void seed( T s )
{ rng_.seed( s ); init(); }
result_type operator()()
{
int const bits = cache_ & mask;
cache_ >>= width;
if ( --count_ <= width-1 )
init();
return bits;
}
bool validation( result_type x ) const
{ return valid == x; }
friend bool operator ==( self_type const &x, self_type const &y )
{
return x.rng_ == y.rng_ && x.cache_ == y.cache_
&& x.count_ == y.count_;
}
friend bool operator !=( self_type const &x, self_type const &y )
{ return !(x == y); }
private:
typedef typename base_type::result_type cache_type;
void init()
{
cache_ = rng_();
count_ = std::numeric_limits::digits;
}
base_type& rng_;
cache_type cache_;
int count_;
}; // boost::random::pnseq_generator
} // random
} // boost
#endif
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Updated Boost.Random to TR proposal
On Monday 07 July 2003 05:06 pm, Jens Maurer wrote:
> I've updated the current Boost.Random CVS to the interface
> contained in the C++ library TR proposal:
>
>http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1452.html
>
> The boost documentation has not yet been updated, I hope to be able
> to do that later this week. Reading the TR proposal should give
> you a sufficient idea.
>
> There have been various suggestions for changes from C++
> committee members, so additional (but minor) interface changes
> may happen after the October 2003 meeting.
>
I would also like to suggest one addition that is very useful. It is very
common in communications to need a generator that produces a 1-bit sequence.
#ifndef pnseq_generator_H
#define pnseq_generator_H
#include
namespace boost
{
namespace random
{
template < class RandomNumberGenerator >
class pnseq_generator
{
public:
typedef pnseq_generator self_type;
typedef RandomNumberGenerator base_type;
typedef bool result_type;
BOOST_STATIC_CONSTANT( bool, has_fixed_range = true );
BOOST_STATIC_CONSTANT( result_type, min_value = false );
BOOST_STATIC_CONSTANT( result_type, max_value = true );
result_type min() const
{ return min_value; }
result_type max() const
{ return max_value; }
explicit pnseq_generator (base_type & rng)
: rng_( rng ), count_()
{ init(); }
template < typename T >
void seed( T s )
{ rng_.seed( s ); init(); }
result_type operator()()
{
bool const bit = cache_ & 1;
cache_ >>= 1;
if ( --count_ <= 0 )
init();
return bit;
}
bool validation( result_type x ) const
{ return valid == x; }
friend bool operator ==( self_type const &x, self_type const &y )
{
return x.rng_ == y.rng_ && x.cache_ == y.cache_
&& x.count_ == y.count_;
}
friend bool operator !=( self_type const &x, self_type const &y )
{ return !(x == y); }
private:
typedef typename base_type::result_type cache_type;
void init()
{
cache_ = rng_();
count_ = std::numeric_limits::digits;
}
base_type& rng_;
cache_type cache_;
int count_;
}; // boost::random::pnseq_generator
} // random
} // boost
#endif
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Updated Boost.Random to TR proposal
On Monday 07 July 2003 05:06 pm, Jens Maurer wrote: > I've updated the current Boost.Random CVS to the interface > contained in the C++ library TR proposal: > >http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1452.html > > The boost documentation has not yet been updated, I hope to be able > to do that later this week. Reading the TR proposal should give > you a sufficient idea. > > There have been various suggestions for changes from C++ > committee members, so additional (but minor) interface changes > may happen after the October 2003 meeting. > Just one quick question: It is vital that "variate generators" can hold references to "engines" in order to share a single engine instance, and thus guarantee independence between variate generators. The proposal supports this? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Package for Cygwin distribution
On Thursday 19 June 2003 10:50 am, Reed Hedges wrote: > Hello. Has anyone made or thought about making packages for Cygwin? (i.e., > to include in the Cygwin distribution/automatic pakcage installer tool) I > have started, including some shell scripts to automate the process, and a > spec file. (Unfortunately, many of the libraries don't build, but I am > using GCC 2.95, maybe I should use 3.2 -- I plan on moving to 3.3 when it > is available for Cygwin). > If you are starting out, why not use current cygwin? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [program_option] post-review plan
On Tuesday 17 June 2003 10:49 am, Vladimir Prus wrote: > I've put together a plan of post-review developement of the program_options > library --- see attachemnt. I believe it includes all issues raised. If > anybody mage a suggestion which got lost, or has any opinion on the > document, I'd be interested to know. > Postional parameters looks like an interesting addition. I guess this is what is commonly called "non-option arguments"? Will non-option arguments be able to be placed anywhere on command line, like gnu getopt style? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [filesystem] "." directory-placeholder added
On Thursday 12 June 2003 01:31 pm, Daryle Walker wrote:
> On Thursday, June 12, 2003, at 11:23 AM, Beman Dawes wrote:
> > An updated version of Boost.Filesystem has been added to CVS. The
> > primary change is adding "." as a directory-placeholder to the generic
> > path grammar.
> >
> > This solves the problem of distinguishing between an empty path and
> > one that acts as a placeholder.
> >
> > This change does change some existing behavior: path("foo/..") used to
> > get converted to an empty path. Now it gets converted to a path of
> > ".", and thus the change will break any existing code which depended
> > on the prior behavior.
>
> Is it possible to override this and use "." or ".." as regular object
> names?
>
>
Do I understand correctly that you are proposing that "." or ".." are to be
used as the names of e.g., files? It's hard to see a need for it.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost python question
Is this the right place to ask boost python questions? I'm interested in getting started with boost python. I would need a way to comminicate containers of data between python and c++. My domain is signal processing. In c++, algorithms usually have an STLsyle iterator interface, and concrete containers are usually std::vector. In python numarray might be used. What options are available to interface between an (efficient) python-accessible container and c++ stl-style containers? I noticed the boost::python tutorial has a brief discussion of iterators. I guess this would suggest a strategy of using vector for containers with an iterator interface for python to access them. But this doesn't give any way for python to create or manage the containers. Is the reverse a feasible solution? Use python numarray containers and pass iterators to c++ algorithms for computation? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: program options change request
On Friday 06 June 2003 10:39 am, Vladimir Prus wrote:
> Neal,
>
[...]
> > I can appreciate the usefulness of the current behavior, and I also know
> > that there is a workaround (.default_value("true")), but this only works
> > if you notice the unexpected behaviour!
> >
> > The only good solution I can see is to either make the bool behaviour
> > configurable, or somehow force the user to choose so he will notice.
>
> I think the latter is possible. I can make behaviour of 'parameter'
> function the same for all types, and introduce another function, say
> 'switch' for current ('false' as default value) behaviour. You'd have to
> write
>
> desc.add_options()
> ("unified", switch("arg", &b), "unified format");
> ;
>
> does this make sense?
That sounds good.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: program options change request
On Friday 06 June 2003 10:10 am, Vladimir Prus wrote:
> Neal D. Becker wrote:
> > Currently (last I tested) program options when used with variable map
> > will set bool options to false even though they were not specified on the
> > command
> > line. What I'd prefer is that all options be left alone unless they are
> > set
> > on the command line. I've been bitten by this unexpected behaviour. (I
> > set bool option = true, then use
> >
> > parse_command_line(argc, argv, desc);
> > variables_map vm;
> > store(opts, vm, desc);
> >
> > And my bool option winds up set false even though nothing was specified
> > on the command line.
>
> Yes, that's true. All bool options implicitly have default value of
> "false". In fact, I think this is quite reasonable. Unless some switch is
> on, it's off. This saves the user the need to check if option is present.
>
> Could you describe how this behaviour has bitten you? There's probably a
> solution already.
>
I thought I did describe it. I converted some code which was using a
different library (getopt or popt). Before calling the option parser, I set
bool someopt = true;
After the parser the option is set false. I didn't expect this behavior.
This doesn't happen with other libraries, such as popt. Furthermore, and
perhaps more important, the treatment of bool is different than any other
options. This inconsistency is bound to trip up other users beside myself.
I can appreciate the usefulness of the current behavior, and I also know that
there is a workaround (.default_value("true")), but this only works if you
notice the unexpected behaviour!
The only good solution I can see is to either make the bool behaviour
configurable, or somehow force the user to choose so he will notice.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Math Constants Formal Review
Does anyone else think it's confusing that: const float e = 0.5772156649015328606065120900824024310422F; // Euler e I would have expected e to be 2.71828... ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] program options change request
Currently (last I tested) program options when used with variable map will set bool options to false even though they were not specified on the command line. What I'd prefer is that all options be left alone unless they are set on the command line. I've been bitten by this unexpected behaviour. (I set bool option = true, then use parse_command_line(argc, argv, desc); variables_map vm; store(opts, vm, desc); And my bool option winds up set false even though nothing was specified on the command line. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] program options question
Does/will program options support this style: -w1=10 -w2=20 w1 and w2 are options (with args) that act just the same as long options, but use a single '-' instead of the usual '--'. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] program options - generic validator
Why not a generic default validator?
BTW, I know "typeid (T).name()" doesn't really work, but I'm not sure what
would be better.
If not totally generic, then instead at least all fundamental types could be
handled by a single generic function, using maybe is_pod to dispatch.
namespace boost { namespace program_options {
template
void validator::operator()(any& v, const vector& xs)
{
check_first_occurence(v);
string s(get_single_string(xs));
try {
v = any(lexical_cast(s));
}
catch(bad_lexical_cast&) {
throw validation_error("'" + s + "' doesn't look like a " + typeid
(T).name());
}
}
} }
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] program options - how to extend
I'm trying to learn to use program options, posted here by Vladimir Prus.
I was trying to use the variables map, and I wanted a "double" variable. It
seems validator is specialized for float, but not double.
I tried following the example of the float type:
namespace boost { namespace program_options {
template<>
void validator::operator()(any& v, const vector& xs)
{
check_first_occurence(v);
string s(get_single_string(xs));
try {
v = any(lexical_cast(s));
}
catch(bad_lexical_cast&) {
throw validation_error("'" + s + "' doesn't look like a double value.");
}
}
}
But check_first_occurence and get_single_string are in an anonymous namespace,
and are not accessible.
Is there a workaround? Should these functions be moved to a different
namespace to make extension more convenient?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] signals - qt approach
There was some time back a discussion of various approaches to signals. I just ran across this, which explains the point of view of Trolltech (qt). Why doesn't Qt use templates for signals and slots? http://doc.trolltech.com/3.1/templates.html ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Statistics code example
On Thursday 03 April 2003 03:54 pm, Paul A. Bristow wrote: > I believe this conjecture is correct, but I am still eagerly awaiting 7.1 > :-) > > This is quite interesting (though it needs Industrial Strengthening of > course), and could usefully generate the higher moments and other > statistical thingys too. My purpose was only to demonstrate a generic class to do stats for both scalar and complex types. I don't know if I have time or will-power to turn it into a real boost submission. > > And it makes me wonder if one could use a container like a circular buffer. > I can think of applications where one would like new data to pour in > continuously and to look back for mean (weighted Kalmanesque?), perhaps > only a limited distance. Using a vector or valarray would imply it would > grow for ever and run out of space eventually. (I think someone else > suggested something of this sort?) > Is the STL queue suitable? > We have actually seen some nice code for circular buffer, about 6months to 1 year back. I have brought the subject up here a couple of times. The most promising IMHO is cycle_iterator, which is an adaptor submitted by Gennadiy Rozental. I believe this is almost ready for a real boost submission. Last we left it, there were some questions of the semantics of the "distance" between iterators. In any case, the "distance" between iterators in a cyclic buffer is fuzzy. I think the semantics in cyclic_buffer are the ones I prefer. That is, the distance from A -> B is always interpreted as positive. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Statistics code example
On Wednesday 02 April 2003 02:57 pm, Paul A. Bristow wrote: > Sadly (but perhaps not too surpringly) this does not seem to work for MSVC > 7.0 with complex. (OK without) > Could you elaborate? What didn't work? Any ideas how to fix? I don't use MSVC. > A full working example with at least a few comments might sell this better? > > Paul > > Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK > +44 1539 561830 Mobile +44 7714 33 02 04 > Mobile mailto:[EMAIL PROTECTED] > mailto:[EMAIL PROTECTED] > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Neal D. Becker > > Sent: Tuesday, April 01, 2003 2:26 PM > > To: [EMAIL PROTECTED] > > Subject: [boost] Statistics code example > > > > > > Here is an example of a class that can compute 2nd order stats that will > > work for either scalar or complex types. > > > > It could be made slightly more efficient. It uses abs(), relying on the > > "trick" that abs() is defined for both scalar float and complex. It > > could be improved by defining our own "norm" function for both scalar > > float and complex. (Unfortunately for efficiency, complex norm is > > defined in terms of abs, which uses sqrt, on at least some systems > > (libstdc++)). > > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Threading, boost_1_30_0, Linux, glibc-2.3.2
On Tuesday 01 April 2003 10:09 am, Peter Dimov wrote: > Neal D. Becker wrote: > > Here is some more on this problem. Perhaps someone on this list has > > some ideas where to look? Defining BOOST_NO_THREAD (or whatever it > > was) will "fix" the problem, but I suspect it's not the correct fix. > > The code will link OK dynamically, but not statically. That's > > strange. > > I'm not sure how you determine the correctness of the BOOST_DISABLE_THREADS > fix. > If dynamic link works, but static doesn't, something is broken. I haven't had time to investigate more, but I'll try. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Statistics code example
Here is an example of a class that can compute 2nd order stats that will work
for either scalar or complex types.
It could be made slightly more efficient. It uses abs(), relying on the
"trick" that abs() is defined for both scalar float and complex. It could be
improved by defining our own "norm" function for both scalar float and
complex. (Unfortunately for efficiency, complex norm is defined in terms of
abs, which uses sqrt, on at least some systems (libstdc++)).
#ifndef _Stat_H
#define _Stat_H
//! $Id: Stat.H,v 1.1 2003/03/17 13:51:03 nbecker Exp $
#include
template
struct Stat_t {
typedef T value_t;
};
template
struct Stat_t< std::complex > {
typedef typename std::complex::value_type value_t;
};
template
class Stat {
typedef typename Stat_t::value_t value_t;
T sumX;
value_t sumXsqr;
cnt_t count;
public:
Stat() :
sumX (0),
sumXsqr (0),
count (0)
{}
void Reset() {
sumX = 0;
sumXsqr = 0;
count = 0;
}
template
void Compute (in_t in, in_t inend) {
for (; in != inend; in++)
Compute (*in);
}
void Compute (T x) {
operator += (x);
}
void operator += (T x) {
count++;
sumX += x;
sumXsqr += (abs(x) * abs(x));
}
void operator() (T x) {
operator += (x);
}
value_t Mean() const {
if ( count > 0)
return (sumX / count);
else
return ( 0.0 );
}
value_t Var() const {
if (count > 1)
return (sumXsqr - ((abs(sumX) * abs (sumX)) / count)) / (count - 1);
else
return 0.0;
}
value_t StdDev() const {
if (count <= 0)
return 0;
else
return sqrt (Var());
}
value_t RMS() const {
return StdDev();
}
cnt_t Cnt() const {
return count;
}
value_t XsqrBar() const {
return (sumXsqr / count);
}
};
#endif
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Threading, boost_1_30_0, Linux, glibc-2.3.2
Here is some more on this problem. Perhaps someone on this list has some ideas where to look? Defining BOOST_NO_THREAD (or whatever it was) will "fix" the problem, but I suspect it's not the correct fix. The code will link OK dynamically, but not statically. That's strange. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87491 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2003-03-28 13:26 --- That looks like boost is broken (or whatever uses pthread_* functions without making them #pragma weak and using only conditionally (as does e.g. libstdc++). Can you find out what exactly uses them without making them weak? On Friday 28 March 2003 08:09 am, Neal D. Becker wrote: > I just installed boost_1_30_0 and updated to glibc-2.3.2 on my RH8.0 Linux > box. Now I have problems to create a static link of my executable. > > I'm wondering what is the correct link procedure. > > g++ -Wall -I ../../src/fixed -I ../../src/float -O3 -ffast-math > -fstrict-aliasing -m3dnow -ggdb -march=athlon-xp -mcpu=athlon-xp > -fprofile-arcs -D_GNU_SOURCE -Wp,-MMD,.d/Test34.d -o Test34 Test34.o -L. > -liTest -lpopt -lcephes -lfftw -static > Test34.o: In function > `boost::detail::shared_count::shared_count[in-charge]har, std::char_traits >*, > boost::checked_deleter > > > >(std::basic_ofstream > > >*, boost::checked_deleter > > > )': > > /usr/include/c++/3.2/iostream:62: undefined reference to > `pthread_mutex_init' Test34.o: In function > `boost::detail::sp_counted_base_impl std::char_traits >*, boost::checked_deleter std::char_traits > > >::~sp_counted_base_impl [in-charge]()': > /usr/include/c++/3.2/iostream:62: undefined reference to > `pthread_mutex_destroy' > Test34.o: In function > `boost::detail::sp_counted_base_impl std::char_traits >*, boost::checked_deleter std::char_traits > > >::~sp_counted_base_impl [in-charge > deleting]()': /usr/include/c++/3.2/iostream:62: undefined reference to > `pthread_mutex_destroy' > Test34.o: In function `boost::detail::sp_counted_base::~sp_counted_base > [in-charge]()': > /usr/include/c++/3.2/iostream:62: undefined reference to > `pthread_mutex_destroy' > Test34.o: In function `boost::detail::sp_counted_base::~sp_counted_base > [in-charge deleting]()': > /usr/include/c++/3.2/iostream:62: undefined reference to > `pthread_mutex_destroy' > collect2: ld returned 1 exit status > > It seems adding -lpthread fixes this, but 1) I don't use thread 2) it isn't > needed for normal (nonstatic) link, and wasn't needed before the updates. > > Now I see I have /usr/lib/libboost_thread.so.xxx > > What is it for? > > nm /usr/lib/libboost_thread.so.1.30.0 > nm: /usr/lib/libboost_thread.so.1.30.0: no symbols > > Is it just used to pull in -lpthread? > > Apparantly, the pthread is needed because I used a boost shared pointer. > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Threading, boost_1_30_0, Linux, glibc-2.3.2
I just installed boost_1_30_0 and updated to glibc-2.3.2 on my RH8.0 Linux box. Now I have problems to create a static link of my executable. I'm wondering what is the correct link procedure. g++ -Wall -I ../../src/fixed -I ../../src/float -O3 -ffast-math -fstrict-aliasing -m3dnow -ggdb -march=athlon-xp -mcpu=athlon-xp -fprofile-arcs -D_GNU_SOURCE -Wp,-MMD,.d/Test34.d -o Test34 Test34.o -L. -liTest -lpopt -lcephes -lfftw -static Test34.o: In function `boost::detail::shared_count::shared_count[in-charge] >*, boost::checked_deleter > > >(std::basic_ofstream >*, boost::checked_deleter > >)': /usr/include/c++/3.2/iostream:62: undefined reference to `pthread_mutex_init' Test34.o: In function `boost::detail::sp_counted_base_impl >*, boost::checked_deleter > > >::~sp_counted_base_impl [in-charge]()': /usr/include/c++/3.2/iostream:62: undefined reference to `pthread_mutex_destroy' Test34.o: In function `boost::detail::sp_counted_base_impl >*, boost::checked_deleter > > >::~sp_counted_base_impl [in-charge deleting]()': /usr/include/c++/3.2/iostream:62: undefined reference to `pthread_mutex_destroy' Test34.o: In function `boost::detail::sp_counted_base::~sp_counted_base [in-charge]()': /usr/include/c++/3.2/iostream:62: undefined reference to `pthread_mutex_destroy' Test34.o: In function `boost::detail::sp_counted_base::~sp_counted_base [in-charge deleting]()': /usr/include/c++/3.2/iostream:62: undefined reference to `pthread_mutex_destroy' collect2: ld returned 1 exit status It seems adding -lpthread fixes this, but 1) I don't use thread 2) it isn't needed for normal (nonstatic) link, and wasn't needed before the updates. Now I see I have /usr/lib/libboost_thread.so.xxx What is it for? nm /usr/lib/libboost_thread.so.1.30.0 nm: /usr/lib/libboost_thread.so.1.30.0: no symbols Is it just used to pull in -lpthread? Apparantly, the pthread is needed because I used a boost shared pointer. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
On Thursday 27 March 2003 12:41 pm, Douglas Paul Gregor wrote: > On Thu, 27 Mar 2003, William E. Kempf wrote: > > * On Cygwin, I get the result: > > > > xslt-xsltproc bin\gcc\debug\boost.docbook > > 'XML_CATALOG_FILES' is not recognized as an internal or external command, > > operable program or batch file. > > > > XML_CATALOG_FILES=catalog.xml xsltproc --xinclude -o > > bin\gcc\debug\boost.docbook > > C:\cygwin\home\wekempf\boost/tools/boostbook/xsl/docbook.xsl > > src\boost.xml > > > > failed xslt-xsltproc bin\gcc\debug\boost.docbook... > > Looks like I can't set an environment variable that way in Cygwin (or in > Windows without Cygwin, for that matter). > Looks to me that you're not using bash under cygwin. Make sure you're using bash for the shell that jam is using (I don't know anything about jam, how does it select the shell?) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request (novice alert)
OK, I can get boostbook running on RH8.0 using: using boostbook : /usr/share/sgml/docbook/xsl-stylesheets/ : /usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-14/ ; My interest was to try to learn about boostbook for my own purposes, which means running without bjam. Where would I find info on this, or can I ask bjam to show me the commands it is running? On Thursday 27 March 2003 10:17 am, Douglas Paul Gregor wrote: > On Thu, 27 Mar 2003, Neal D. Becker wrote: > > Now try with boostbook: > > db2pdf boostbook.xml > > jw: Please specify at least one catalog > > > > Any clue what's wrong? > > BoostBook isn't DocBook (although it can be transformed into DocBook), so > DocBook tools won't work directly on it. We have our own build tools > (Boost.Build v2) that are roughly equivalent to those scripts. See the > "Getting Started" section here for info on getting BoostBook up and > running with bjam: > http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ > > You probably have most/all of the prerequisites already, you'll just need > to tell BBv2 about them. > > Doug > > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request (novice alert)
I'm interested in learning about boostbook and would like to try it out. For some reason I can't seem to get my docbook tools to run. Perhaps someone can give me a hint what's wrong. I'm afraid I'm a docbook novice. I'm using Linux RH8.0 with all updates. I can run a simple test: db2pdf Test.xml Using catalogs: /etc/sgml/xml-docbook-4.2-1.0-14.cat Using stylesheet: /usr/share/sgml/docbook/utils-0.6.11/docbook-utils.dsl#print Working on: /home/nbecker/Test.xml Done. Here is the start of Test.xml: http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";> [...] Now try with boostbook: db2pdf boostbook.xml jw: Please specify at least one catalog Any clue what's wrong? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] info on boostbook
I'd like to learn about boostbook. Where can I find some info? Are there dtd's I can get? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RPMS?
I have built SRPMS for RH8 for boost1.30.0. They required just minor modifications to the spec files. Where should I upload them? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RPMS?
Is anyone working on RPMS for 1.30.0? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
On Thursday 13 March 2003 08:02 am, Joel Young wrote: > > "Neal D. Becker" <[EMAIL PROTECTED]> > > I reported this. A simple workaround, just remove the dependency from > > the .spec file. > > > > IIRC, it was libpython-devel. This is called python-devel on RH8. My > > suggestion, just remove it from Requires:. > > Just put a %if block in the .spec. I don't have time, but there should > be some rpm macro or other identifying condition on RH8 for the if check > below > > %if some condition identifying redhat > Requires: python-devel > %else > Requires: libpython-devel > %endif > I don't offhand know how to do this, and as far as I can tell, it isn't really necessary to have this line at all. So, unless I'm misunderstanding something (which is certainly possible) the simpler solution is just remove it. Otherwise a big segment of your user base (redhat) will be effectively lost. (I doubt many who would otherwise install an srpm would feel comfortable to fiddle with unpacking it and editing the spec file) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
On Wednesday 12 March 2003 11:50 am, David Abrahams wrote: > Beman Dawes <[EMAIL PROTECTED]> writes: > > * Boost.Python private email > >Final changes promised for Wednesday night. > > Those are done. I'd like to watch http://cci.lbl.gov/boost/ go > through one more successful test cycle. > > > * [Boost.Python] rpms and small fix for RedHat > >Awaiting reply. Dave? > > I'm not sure what this is about. Link? I reported this. A simple workaround, just remove the dependency from the .spec file. IIRC, it was libpython-devel. This is called python-devel on RH8. My suggestion, just remove it from Requires:. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] rpms and small fix for RedHat
I really appreciate the boost rpms that have been made available. I hope we can improve one thing in the upcoming release. rpm -q --requires boost-python-devel boost-devel libpython-devel Unfortuantely, on RedHat it's called python-devel I hope there is some way to fix this. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: Any interest in a stats class
Please remember that stats can be more general. I frequently use stats for
complex types. In that case, mean is also complex, but var is scalar. The
proposed implementation doesn't address this.
On Tuesday 25 February 2003 12:29 am, Jason D Schmidt wrote:
> I know this is well after the discussion on the stats class has ended,
> but I think I have a good idea here.
>
> Scott Kirkwood proposed a class that behaves something like this:
>
> stats myStats;
> for (int i = 0; i < 100; ++i) {
> myStats.add(i);
> }
> cout << "Average: " << myStats.getAverage() << "\n";
> cout << "Max: " << myStats.getMax() << "\n";
> cout << "Standard deviation: " << myStats.getStd() << "\n";
>
> In one of my classes in grad school, I found it quite useful and
> effecient to do statistics on the fly like this, so this stats class
> interests me. Anyway, Scott has already alluded to the point I'm about
> to make. I think it's important and useful for this stats class to
> integrate with the STL well. This example code was inspired by the
> PointAverage example from "Effective STL" p. 161:
>
> // this class reports statistics
> template
> class stats
> {
> public:
> stats(const size_t n, const value_type sum, const value_type
> sum_sqr):
> m_n(n), m_sum(sum), m_sum_sqr(sum_sqr)
> {}
> value_type sum() const
> { return m_sum; }
> value_type mean() const
> { return m_sum/m_n; }
> value_type var() const
> { return m_sum_sqr - m_sum*m_sum/m_n; }
> value_type delta() const // aka, standard dev
> { return sqrt(var() / (m_n-1)); }
> private:
> value_type m_n, m_sum, m_sum_sqr;
> };
>
> // this class accumulates results that can be used to
> // compute meaningful statistics
> template
> class stats_accum: public std::unary_function
> {
> public:
> stats_accum(): n(0), sum(0), sum_sqr(0)
> {}
> // use this to operate on each value in a range
> void operator()(argument_type x)
> {
> ++n;
> sum += x;
> sum_sqr += x*x;
> }
> stats result() const
> { return stats(n, sum, sum_sqr); }
> private:
> size_t n;
> value_type sum, sum_sqr;
> };
>
> int main(int argc, char *argv[])
> {
> typedef float value_type;
> const size_t n(10);
>
> float f[n] = {0, 2, 3, 4, 5, 6, 7, 8, 9, 8};
>
>// accumulate stats over a range of iterators
> my_stats = std::for_each(f, f+n,
> stats_accum()).result();
>
> m = my_stats.mean();
> m = my_stats.delta(); // aka, standard deviation
>
> return 0;
> }
>
> This seems to be pretty similar to what Scott has proposed, and it turns
> out that this method is very fast. In my tests it has been nearly as
> fast as if we got rid of the classes and used a hand-written loop. It's
> certainly much faster than storing the data in a std::valarray object,
> and using functions that calculate the mean & standard deviation
> separately. This is just a neat application of Scott's idea.
>
> I think this stats could be pretty useful for scientific computing, and
> in this example it works very well with the STL and has great
> performance. I'd like to see more code like this in Boost, but most of
> my work is numerical. Take my opinion or leave it.
>
> Jason Schmidt
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost SRPM, can't test new packages
On Friday 14 February 2003 10:25 am, Vladimir Prus wrote: [...] > > Oh, I see. But this doesn't get installed by any RPM. Should it? What > > is the minimum needed to install in order to be able to play with 3rd > > party boost packages? > > I'm afraid that full tree is needed now and I'm not sure what can be done > about it now. I think that for Boost.Build V2 will just have a separate rpm > which would allow building 3rd party packages. This might be possible > with V1, although I'm not sure I have the time (and access to Redhat box > ;-) ) > OK, I installed the whole boost src tree as /usr/local/src/boost_1_29_0 I installed my 3rd party package in my home directory, as ~/program_options. Now let's try: cd ~/program_options/libs/program_options/build BOOST_BUILD_PATH=/usr/local/src/boost_1_29_0 bjam ../../../Jamrules: No such file or directory ...found 69 targets... ...updating 11 targets... MkDir1 ../../../libs/program_options/build/bin MkDir1 ../../../libs/program_options/build/bin/libprogram_options.a MkDir1 ../../../libs/program_options/build/bin/libprogram_options.a/gcc MkDir1 ../../../libs/program_options/build/bin/libprogram_options.a/gcc/debug MkDir1 ../../../libs/program_options/build/bin/libprogram_options.a/gcc/debug/runtime-link-dynamic gcc-C++-action ../../../libs/program_options/build/bin/libprogram_options.a/gcc/debug/runtime-link-dynamic/cmdline.o ../src/cmdline.cpp:19:45: boost/program_options/cmdline.hpp: No such file or directory ../src/cmdline.cpp:20:44: boost/program_options/errors.hpp: No such file or directory [...] Well, that doesn't work. Is it possible to build 3rd party packages like this outside the boost tree? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost SRPM, can't test new packages
On Friday 14 February 2003 10:09 am, Vladimir Prus wrote: > Neal D. Becker wrote: > > > or from somewhere else? I've looked at those and source rpm does > > > include "boost-build.jam" > > > > Which rpm? > > > > rpm -q boost-jam > > boost-jam-3.1.3-1 > > > > rpm -q -l boost-jam | grep boost-build > > [silence] > > > > rpm -q -l boost | grep boost-build > > [nothing] > > > > rpm -q -l boost-devel | grep boost-build > > [nadda] > > > > BTW, I just rebuilt using boost-1.29.0-2.src.rpm > > And that package should include big tar file, with entire Boost source > tree. This is what is needed. Oh, I see. But this doesn't get installed by any RPM. Should it? What is the minimum needed to install in order to be able to play with 3rd party boost packages? Should boost-devel install the whole boost source tree somewhere? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost SRPM, can't test new packages
On Friday 14 February 2003 08:52 am, Vladimir Prus wrote: > Hi Neal, > > > I installed boost-1.29 from boost-1.29.0-1.src.rpm, > > boost-jam-3.1.3-1.src.rpm on RH8.0 Linux. Great stuff! > > Did you use those from > > http://www.starostik.de/malte/boost/ > yes > or from somewhere else? I've looked at those and source rpm does include > "boost-build.jam" Which rpm? rpm -q boost-jam boost-jam-3.1.3-1 rpm -q -l boost-jam | grep boost-build [silence] rpm -q -l boost | grep boost-build [nothing] rpm -q -l boost-devel | grep boost-build [nadda] BTW, I just rebuilt using boost-1.29.0-2.src.rpm BTW, there is one problem. I have to install with --nodeps because RH has python-devel while the SRPM requires libpython-devel. This should be fixed, but has nothing to do with my problem regarding boost-build.jam. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost SRPM, can't test new packages
I installed boost-1.29 from boost-1.29.0-1.src.rpm, boost-jam-3.1.3-1.src.rpm on RH8.0 Linux. Great stuff! One problem. I grabbed "program_options.tar.bz2" and want to play with it. It needs to build some lib. I can't run bjam on it AFAICT. Unable to load Boost.Build: could not find "boost-build.jam" locate boost-build.jam shows nothing. So, do we need to package boost jam files into boost-devel.rpm? Any ideas on how this could work? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any interest in a stats class
Yes, I use a simple 2nd order stats class all the time.
There is a scalar version:
template
class Stat {
And for complex:
template
class Stat< std::complex > {
On Tuesday 11 February 2003 11:19 am, Jeff Garland wrote:
> Scott K wrote:
> > Hi all,
> > I have a small family of statistics classes which I have used from time
> > to time. The one I use most often is simply called stats.
> > Here's an example of it's use:
> > ...details snipped...
>
> I'm sure there are folks interested in statistical (and other)
> functions. I've developed exactly this sort of class in the
> past so I understand the utility. However, I suspect some of
> us would hope statistical algorithms to be formulated as STL
> Algorithm extensions. Specifically concerning statistics see:
>
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?STLAlgorithm
>Extensions/StatisticsAlgorithms
>
> and more generally:
>
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?STLAlgorithm
>Extensions
>
> We definitely need volunteers to take these rough Wiki musings and
> convert them into actual documented libraries. I'm not sure this
> is what you had in mind, but I, for one, would welcome your effort
> either way!
>
> Jeff
>
>
> ___
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] binary (unformatted) I/O?
I wonder if anyone has code for implementing unformatted I/O? What I have in mind is for the simple case where the application that reads data knows the data types, so this is not as complicated as the general marshalling situation. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] status of 64bit support in integer.hpp?
What is the status of adding 64bit support to integer.hpp? I am looking for boost::int_t::least for n > 32. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] metaprogramming question
Thanks! ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] metaprogramming question
I hope it is permissible to ask a mp question. I'd like to have a template parameter is an int. If represents an arithmetic shift of an integral value. If the parameter is positive I'd like to shift left, and if negative shift right. Is it feasible to implement something like this? Any hints? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] lexical_cast and bool
> "Roland" == Roland Richter <[EMAIL PROTECTED]> writes: Roland> Dear all, Roland> just a minor issue for the upcoming(?) lexical_cast in 1.30.0: Roland> lexical_cast( "true" ) returns false, Roland> since std::ios::boolalpha is not set by default. Roland> How about changing this? I believe we need a mechanism to set all the flags, not just this one. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
