On Saturday, November 30, 2002, at 02:06 AM, David Abrahams wrote:
Matthias Troyer <[EMAIL PROTECTED]> writes:
In any case the library user should be reminded that short, int and
long are never portable
Of course they are perfectly portable!
I don't understand how you mean that. If sizeof(l
> For example boost_1_29_0.tar.gz has size 5 272 kB, tared and compressed by
> bzip2 size is 4 282 kB (down to 81%).
tar+ace -> 4 211 kB
tar+rar -> 4 138 kB
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boos
Matthias Troyer <[EMAIL PROTECTED]> writes:
>> So, while use of them may lead to a MORE portable C++ interface, they won't
>directly lead to a
>> portable binary serialization format (although you can clearly fix that problem in
>platform specific
>> byte reordering code).
>
> Agreed. It would j
Beman Dawes <[EMAIL PROTECTED]> writes:
> >I don't know if it was controversial, but I did bring this up during
> >the review and I do think its very important. The basic definition
> >of an absolute path should be a path that overrides the base path
> >during a resolve. To rephrase, 'foo' is
"John Maddock" <[EMAIL PROTECTED]> writes:
>> > I tried to compile Boost.Test using the Comeau C++ compiler version
>> > 4.3.0.1 under Linux, and I found several problems that I would like to
>> > report. For one, the build process needs the pre-processor define
>>
>> > _POSIX_SOURCE
>>
>> > d
"Paul Mensonides" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "David Abrahams" <[EMAIL PROTECTED]>
>
>> How is this different from
>>
>> implicit_cast(f)()
>>
>> ??
>
> It would be no different except that it would be obvious what you are doing
> and that you'd be able t
"David B. Held" <[EMAIL PROTECTED]> writes:
>> Also I have concerns about the name "assign()", since
>> that is used in the standard library to mean something
>> slightly different.
>
> I don't recall seeing this. Where is it used?
In the standard containers, for assignment from an iterator rang
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
> How is this different from
>
> implicit_cast(f)()
>
> ??
It would be no different except that it would be obvious what you are doing
and that you'd be able to enforce the function type.
Paul Mensonides
___
"Aleksey Gurtovoy" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> > > template
> > > struct get_category
> > > : mpl::if_<
> > > mpl::is_placeholder
> > > , mpl::identity
> > > , get_category_impl
>
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> When neccessary. It's not as though a "strong guarantee assignment"
> is a fundamental operation which people often need.
Which is why the swap idiom assign perhaps shouldn't be the default
Hi,
I'm wondering whether the get_pointer function used by mem_fn et
al. is really justified. Since you can't invoke a member function on a
null pointer anyway, why not simply use &*p for this purpose?
-Dave
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consu
"David B. Held" <[EMAIL PROTECTED]> writes:
> On c.l.c++.m, I argue that operator=() should not use the swap idiom
> (largely based on comments I've seen Dave Abrahams make), but that a
> named assignment function should instead provide assignment with the
> strong guarantee.
When neccessary. I
"John Maddock" <[EMAIL PROTECTED]> wrote in message
011f01c2979d$e3c6a020$cb5287d9@1016031671">news:011f01c2979d$e3c6a020$cb5287d9@1016031671...
> [...]
> Hard to make any patent guarentees I think, as I'm sure the inventors of
> the .gif format would attest to.
Maybe the Boost moderators could so
On Friday, November 29, 2002, at 06:32 PM, Robert Ramey wrote:
Two suggestions *I think* have been made.
1) that the serialisation library recommends to users who want
portable
archives, should use the boost::int*_t types instead of short, int,
etc.
This would only be applicable to binary a
Bandwith and time of those with dialup can be saved by compressing Boost
release by BZIP2 compressor (http://sources.redhat.com/bzip2/).
For example boost_1_29_0.tar.gz has size 5 272 kB, tared and compressed by
bzip2 size is 4 282 kB (down to 81%).
Boost size will grow (Spirit lib has over 600
From: "David Abrahams" <[EMAIL PROTECTED]>
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
> > From: "David Abrahams" <[EMAIL PROTECTED]>
> >>
> >> Here's what I think might be a correct implementation:
> >>
> >> template T implicit_cast(U const& x) { return
x; }
> >> template T implicit_
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Thu, 21 Nov 2002 19:15:21 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>>Thoughts?
>
>
> This is one... A nice thing about the problem you are talking about is
> that any function having a parameter of type T is in fact a general
> "detector"
Samuel Krempp wrote:
> Is it really enough to get boost.format to compile with BCB 5 ?
OK, finally got the latest version into our builds.
Looks good, but I found the following change significantly reduced our
number of warnings:
boost/format.hpp:
was
#if !defined(BOOST_MSVC) || BOOST_MSVC >
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Fri, 22 Nov 2002 13:48:01 +0200, "Peter Dimov" <[EMAIL PROTECTED]>
> wrote:
>
>>From: "David Abrahams" <[EMAIL PROTECTED]>
>>>
>>> Here's what I think might be a correct implementation:
>>>
>>> template T implicit_cast(U const& x) { return x; }
"Paul Mensonides" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "David Abrahams" <[EMAIL PROTECTED]>
>
>> Thoughts?
>
> We also need this:
>
> template inline func& ambiguity_cast(func& rf) {
> return rf;
> }
>
> ...which casts away ambiguity of a function call--even by re
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "David Abrahams" <[EMAIL PROTECTED]>
>>
>> Here's what I think might be a correct implementation:
>>
>> template T implicit_cast(U const& x) { return x; }
>> template T implicit_cast(U& x) { return x; }
>
> The correct implementation II
On Fri, 29 Nov 2002 19:20:35 +0200, "Peter Dimov" <[EMAIL PROTECTED]> wrote:
> From: "Hugo Duncan" <[EMAIL PROTECTED]>
> > I have started getting multiply defined symbols for throw_exception.
> >
> > Is the template missing an inline modifier ?
>
> Compiler/platform? Out of line function templates
Date: Thu, 28 Nov 2002 18:42:06 -
From: "Iain K.Hanson" <[EMAIL PROTECTED]>
>Understood.
>But C 99 standardised the int*_t types and in anticipation that C++ 0x
>might do the same, boost has them in the integer library ( cstdint.hpp ).
I'm am not aware of this. Will these be added to the la
From: "Hugo Duncan" <[EMAIL PROTECTED]>
> I have started getting multiply defined symbols for throw_exception.
>
> Is the template missing an inline modifier ?
Compiler/platform? Out of line function templates are supposed to generate a
single instantiation.
__
At 06:50 AM 11/29/2002, John Maddock wrote:
>> I'm willing to run the regression test regularly but I only have access
>to
>an
>> HPUX 10.20 with aCC version 1.21 installed. But since this compiler
>does'nt
>> even support the new-style headers I guess it's of little use.
>> Next I have trouble
I have started getting multiply defined symbols for throw_exception.
Is the template missing an inline modifier ?
Hugo
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"John Maddock" <[EMAIL PROTECTED]> writes:
>> I assume the current definition of ~d1() is because some compilers
>> generate an implicit destructor with a non-empty
>> exception-specification, which then causes an error? I'm wondering if
>> we wouldn't be better off just defining ~d1 for those com
> I'm willing to run the regression test regularly but I only have access to
an
> HPUX 10.20 with aCC version 1.21 installed. But since this compiler
does'nt
> even support the new-style headers I guess it's of little use.
> Next I have trouble finding info on the aCC compilers like the latest
> v
> > I think the problem is that the entire clause can be viewed as
disclaiming
> > warranties against patent infringement/copyright violation/etc. The
> > question is whether it is possible to protect both library authors and
> > potential users. I don't see where else the buck can get passed.
Pe
> I assume the current definition of ~d1() is because some compilers
> generate an implicit destructor with a non-empty
> exception-specification, which then causes an error? I'm wondering if
> we wouldn't be better off just defining ~d1 for those compilers, since
> many other compilers are likely
"Michel André" <[EMAIL PROTECTED]> wrote in message
0dde01c29700$f6cd7790$a400a8c0@orbit">news:0dde01c29700$f6cd7790$a400a8c0@orbit...
> > I have not used async io, so I am a little out of my depth here. If we
> > were to create an interface that could be implemented using select or
> > aio what
31 matches
Mail list logo
