Robert Ramey wrote:
How does this strike you?
text_iarchive(Stream &_is) :
is(_is)
{
// archives always use classic locale
#ifndef BOOST_NO_STD_LOCALE
plocale = is.imbue(std::locale::classic());
#endif
init();
}
~text_iarchive(){
#ifndef BOOST_NO_STD_LOCALE
is.imbue(plocale
> Something odd is going on... My code does include
> (on line 16 for both quaternion_test.cpp and octonion_test.cpp, on line
> 13 for quaternion_mi_test.cpp, though admitedly not yet for
> quaternion_mi1.cpp, quaternion_mi2.cpp and HSO3SO4.cpp... I'll fix that
> right now). I checked both my loca
> Hugh!
> Is this fixed by "boost/limits.hpp"?
No there's no way it can be. BTW I think that recent STLport releases may
have fixed this, I'm not sure though...
Oh, and just to make things worse... Borlands compiler has problems with all
of STLports numeric_limits<> members when used as template
> Well, it was intentional, if not very smart.
>
> The idea was that the config files essentially allowed workarounds for
> platform deficiencies, so if your platform was conformant, you did not
> need them. Including the config from the headers hides from the user his
> platform's deficiencies, wh
>From: "John Maddock" <[EMAIL PROTECTED]>
> > Well, it was intentional, if not very smart.
> >
> > The idea was that the config files essentially allowed workarounds for
> > platform deficiencies, so if your platform was conformant, you did not
> > need them. Including the config from the headers
Hi,
In Boost.Python, I am going to start using custom deleters to enable
me to produce shared_ptr from any Python object which contains a T,
while keeping the Python object alive. I can't believe I didn't think
of this earlier, and I want to thank Peter Dimov for putting me onto
the idea.
Each
On Fri, Nov 15, 2002 at 06:47:35PM +0100, Thorsten Ottosen wrote:
> >Seq rtrim( const Seq& Input, const std::locale& Loc=std::locale() )
> >Seq& rtrim_in( Seq& Input, const std::locale& Loc=std::locale() )
> >Seq trim( const Seq& Input, const std::locale& Loc=std::locale() )
> >Seq&
On Fri, Nov 15, 2002 at 06:57:47PM +0100, Thorsten Ottosen wrote:
> - Original Message -
> From: "Pavol Droba" <[EMAIL PROTECTED]>
>
> > bool contains( const Seq1& Input, const Seq2& Prefix, BinaryPredicate
> Comp )
>
> BTW, contains is one of the new proposed algorithms. It would be doub
On Fri, Nov 15, 2002 at 01:12:59PM -0500, Rozental, Gennadiy wrote:
> > Trimming:
> >
> >Iterator trim_begin( Iterator InBegin, Iterator InEnd,
> > const std::locale& Loc=std::locale() )
> >Seq ltrim( const Seq& Input, const std::locale& Loc=std::locale() )
> >Seq& ltrim_in( Seq& Inpu
> > 1. I would prefer explisit names: trim_left, trim_right,...
> I'm open for discussion about this. You are probably right. More peaole
> were asking for more readable names. I will probably rename them soon.
I think these names are better as well. The clearer the name the better.
Jeff
_
Pavol Droba wrote:
To pick on a function at random...
>Seq ltrim( const Seq& Input, const std::locale& Loc=std::locale() )
Why the default to std::locale?
In typical use, I expect Seq to be an instantiation of
std::basic_string. Given this is a string library, what motivation is
there to s
Before coming to my detailed review I would like to thank Robert for
all his work and for contributing it to Boost.
I want to start with a general comment about text vs. binary archives.
While a text archive is nice to look at, and can also be compressed
after writing to save disk space there
Sorry for the late reply (it's just my timezone).
You wrote:
>I don't see the contradiction here. 5.2.10/7 says that you can cast from a T
>pointer to a U pointer and back to a T pointer and get the original pointer
>back.
Unfortunately the standard is a great piece of work but fails
miserably
On Sat, Nov 16, 2002 at 03:46:07PM +, Alisdair Meredith wrote:
> Pavol Droba wrote:
>
> To pick on a function at random...
>
> >Seq ltrim( const Seq& Input, const std::locale& Loc=std::locale() )
>
> Why the default to std::locale?
>
> In typical use, I expect Seq to be an instantiation
On Sat, 16 Nov 2002 00:07:11 +0100, "Terje Slettebø"
<[EMAIL PROTECTED]> wrote:
>>From: "Gennaro Prota" <[EMAIL PROTECTED]>
>> Who knows? When I encounter these sorts of situations I dream a
>> standard where propositions can be demonstrated like in mathematics or
>> counter-examples provided. Don
Gennaro Prota <[EMAIL PROTECTED]> writes:
[...]
| I really miss formality in the standard. Even answering a simple
| question like: "is static_cast(-1) guaranteed to give
| UINT_MAX on all conforming implementations?" is quite a project.
How so?
-- Gaby
>From: "Gennaro Prota" <[EMAIL PROTECTED]>
> On Sat, 16 Nov 2002 00:07:11 +0100, "Terje Slettebø"
> <[EMAIL PROTECTED]> wrote:
>
> >>From: "Gennaro Prota" <[EMAIL PROTECTED]>
> >> Who knows? When I encounter these sorts of situations I dream a
> >> standard where propositions can be demonstrated l
- Original Message -
From: "Pavol Droba" <[EMAIL PROTECTED]>
> On Fri, Nov 15, 2002 at 06:47:35PM +0100, Thorsten Ottosen wrote:
> > I would find it more naturally to say
> >
> > string s = ...;
> > trim( s );
> >
> > than to use 'trim_in()'.
[snip]
> Well I have reasons to put it in the
I've been using scoped_ptr and scoped_array in several large
projects, and I'm very happy with them.
One feature that they lack that would be useful for me is a set
member function. It would be similar to reset, except that it
would require the stored pointer to be 0. This would allow user
code to
> Perhaps one could use these names then:
>
> Seq trimmed(...);
> void trim(...);
> >Seq trim( const Seq& Input, const std::locale& Loc=std::locale() )
> >Seq& trim_in( Seq& Input, const std::locale& Loc=std::locale() )
>
> and
>
> Seq lower_cased(...);
> void to_lower_case(...);
>
>
Hi Boosters,
During the implementation of the new container algorithms a little trait is
needed to
distinguish between arrays, STL containers and pairs. So far I have tested
it with
comeau 4.3, gcc 3.2 and VC7, but it would be great with some more feedback
from all kinds of compilers.
I'm very i
I have spent several hours looking at the library. In that time I read the docs,
skimmed the implementation, tried compiling the
tests, and wrote a simple sample program. I have written more than one serialization
library, so I am pretty familiar with the
domain. Unfortunately, I didn't have m
At 11:58 AM 11/15/2002, Pavol Droba wrote:
>Hi Boosters,
>
>I have developed a set of various string manipulating functions into a
>string_algo lib.
Pavol,
Have you taken a look at Darin Adler's string algorithms? See
http://groups.yahoo.com/group/boost/files/string_algorithm/
Do any of these
> Requiring a default constructor is a mistake. For one thing there are
often reasons not to provide a default constructor. For
> another, when serializing we might want different behavior. Provide a
factory method instead.
>
> Question, do classes without default constructors must be serializab
"Jeff Garland" <[EMAIL PROTECTED]> writes:
...
> And, also a request that we try to schedule more time for library
> reviews -- 9 days just isn't enough given that this has to be fit in
> with everything else.
>
> I'm going to abstain on voting for or against inclusion because I'm
> impossibly c
>From: Alberto Barbati <[EMAIL PROTECTED]>
>This solution does not address the objections in my last post in the
>original thread. You seem really concerned about this. We could meet in
>the middle with this solution, instead:
There are a couple of issues here
1) changing the state of the strea
I am having hard time finding free time lately. So I wouls also ask for
couple more days.
Gennadiy.
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Jeff Garland" <[EMAIL PROTECTED]> writes:
>
> ...
>
> > And, also a request that we try to sch
>From: Matthias Troyer <[EMAIL PROTECTED]>
>1.) The first problem are the basic data types used in the archive:
>short, int and long have no defined bit size, and can thus never be used
>for portable serialization.
>Imagine I use a platform where long is
>64-bit, write it to the archive and th
From: "Jeff Garland" <[EMAIL PROTECTED]>
>From my perspective the following changes must are must-haves:
>1) The library must have a 'real' test suite that checks. We will never get this
> ported without some automated tests. Further, it is simply too much to ask users
> to use this library w
29 matches
Mail list logo
