Rozental, Gennadiy wrote:
I've a similiar problem with BOOST_CHECK family, but I think
the solution
can be different: provide a means to convert failed test into
assertion
failure. This way I can conveniently debug. Currently, I have to
replace BOOST_CHECK with assert manually, to find where
Hi,
I'm not sure if you are aware of this but g++ 2.95.3 cannot
handle the casts:
g++ 2.95.3 [no STLport]
C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented: `static_cast_expr'
not supported
by dump_expr
C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented:
Beman Dawes [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
* Should a PBSP supply policies that are prone to be used unsafely?
I'd say no is an acceptable answer, at least for something like the T*
conversion in widely used libraries like the Standard Library
[bringing to list again]
Hi David,
David A. Greene wrote:
Vladimir Prus wrote:
-fcopyPropagation={--maxTransforms=32 --keepStats}
Hmm... that's pretty interesting example. While I'm not sure how
Gennadiy's
code can handle such things, I have some ideas w.r.t my library.
Good! Glad
Beman, I've just got the following:
gcc.compile
../../../libs/filesystem/build/bin/gcc-3.2/release/link-static/operations_posix_windows.o
../../../libs/filesystem/src/operations_posix_windows.cpp: In member function
`boost::filesystem::directory_iterator::directory_iterator(const
Joel de Guzman [EMAIL PROTECTED] writes:
| Hi,
|
| I'm not sure if you are aware of this but g++ 2.95.3 cannot
| handle the casts:
|
| g++ 2.95.3 [no STLport]
| C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented: `static_cast_expr'
|not supported
| by dump_expr
This means that
Terje Slettebø wrote:
This example should one case where manipulators are desirable:
vector vectorint v;
cout v ;
Here, each nested vector better go on a separate line. I suggest:
cout multiline v;
where multiline manipulator causes each element of the next output
container
From: Vladimir Prus [EMAIL PROTECTED]
Terje Slettebø wrote:
From: Vladimir Prus [EMAIL PROTECTED]
after having to output std::vector to stream again and again using
custom
solution, I started to wonder why we don't have a solution in boost.
Does it makes sense to include operators for
Hi,
Borland cannot handle this code:
#include boost/type_traits.hpp
#include boost/mpl/if.hpp
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
template typename T
struct C : if_is_emptyT, A, B::type {};
struct D { int i; };
struct E {};
struct F : CD {};
struct G
On Tuesday, February 04, 2003 4:05 AM [GMT+1=CET],
Gabriel Dos Reis [EMAIL PROTECTED] wrote:
Joel de Guzman [EMAIL PROTECTED] writes:
Hi,
I'm not sure if you are aware of this but g++ 2.95.3 cannot
handle the casts:
g++ 2.95.3 [no STLport]
C:/dev/boost/boost/mpl/integral_c.hpp:67:
From: Daniel Frey [EMAIL PROTECTED]
On Tue, 04 Feb 2003 00:23:26 +0100, Paul Mensonides wrote:
- Original Message -
From: Daniel Frey [EMAIL PROTECTED]
template class C, typename T struct is_member_function_pointer T
C::*
{ enum { value = is_function T ::value }; };
Dave Abrahams [EMAIL PROTECTED] writes:
| On Tuesday, February 04, 2003 4:05 AM [GMT+1=CET],
| Gabriel Dos Reis [EMAIL PROTECTED] wrote:
|
| Joel de Guzman [EMAIL PROTECTED] writes:
|
| Hi,
|
| I'm not sure if you are aware of this but g++ 2.95.3 cannot
| handle the casts:
|
| g++
From: Ralf W. Grosse-Kunstleve [EMAIL PROTECTED]
I did not use boost::shared_array to implement the shared_plainT type
because
one of our requirements is that one reference count can be used to manage
multiple types. This is required in the context of in-place fast Fourier
transforms. I.e. an
I was just about to build the filesystem library for the first time on my
Win98+BCC 5.5.1 environment, but I got lots of errors from
type_traits/is_convertible.hpp
Since the regression_test shows that this library passed bcc5.6.1
yesterday,
I thought that is_convertible might have changed
Hey all you Outlook Express users - if you're tired of sending mangled
emails, like this:
Dominik Jain wrote in message
news:aip4cd$15eofi$[EMAIL PROTECTED]...
This is a simple sample text, and as you will see, Outlook Express is
going
to wrap this line. I've always hated that! And one
- Original Message -
From: Gabriel Dos Reis [EMAIL PROTECTED]
Dave Abrahams [EMAIL PROTECTED] writes:
| On Tuesday, February 04, 2003 4:05 AM [GMT+1=CET],
| Gabriel Dos Reis [EMAIL PROTECTED] wrote:
|
| Joel de Guzman [EMAIL PROTECTED] writes:
|
| Hi,
|
| I'm not
- Original Message -
From: Vladimir Prus [EMAIL PROTECTED]
Joel de Guzman wrote:
Hi,
Borland cannot handle this code:
#include boost/type_traits.hpp
#include boost/mpl/if.hpp
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
- Original Message -
From: Vladimir Prus [EMAIL PROTECTED]
Joel de Guzman wrote:
Hi,
Borland cannot handle this code:
#include boost/type_traits.hpp
#include boost/mpl/if.hpp
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
Dave Abrahams wrote:
Hey all you Outlook Express users - if you're tired of sending mangled
emails, like this:
Dominik Jain wrote in message
news:aip4cd$15eofi$[EMAIL PROTECTED]...
This is a simple sample text, and as you will see, Outlook Express
is going to wrap this line. I've always
At 03:22 AM 2/4/2003, Vladimir Prus wrote:
Terje Slettebø wrote:
...
Have you looked at Jen Maurer's persistence library? It was an elegant
design and quite good at handling the issues you are discussing, IIRC.
It is still in CVS under the branch persistence-initial.
I've always been sorry
Peter Dimov wrote:
Are you sure that T C::* const is a type?
Isn't it? It's a constant pointer to a member of class C. T may be the
type of a member variable or (although GCC don't detect it) a function
type. At least this is my current understanding. Do you have a reason to
ask about it? I
Joel de Guzman wrote:
- Original Message -
From: Vladimir Prus [EMAIL PROTECTED]
Joel de Guzman wrote:
Hi,
Borland cannot handle this code:
#include boost/type_traits.hpp
#include boost/mpl/if.hpp
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
Vladimir Prus wrote:
I just updated from CVS before posting this to be sure.
Borland 5.5.1,
bcc32 -O1 -w-inl -w-aus -q -P
Yes, this fails for me too, *after update*. I meant to say that ~
week's
old CVS was ok. Guess you'll have to do binary search in time to
find out who and when
Peter Dimov wrote:
From: Daniel Frey [EMAIL PROTECTED]
Peter Dimov wrote:
Are you sure that T C::* const is a type?
Isn't it? It's a constant pointer to a member of class C. T may be the
type of a member variable or (although GCC don't detect it) a function
type. At least this
At 04:47 AM 2/4/2003, Vladimir Prus wrote:
Beman, I've just got the following:
gcc.compile
../../../libs/filesystem/build/bin/gcc-3.2/release/link-static/operations_po
six_windows.o
../../../libs/filesystem/src/operations_posix_windows.cpp: In member
function
On Tue, 4 Feb 2003 02:20:14 -0500, Daryle Walker [EMAIL PROTECTED]
wrote:
I haven't been following Boost that much lately. Spent the past few
days catching up.
Some people have been discussing changes to the algorithm used by
static_log2 lately.
Yes. Thanks for intervening. To be more
On Tuesday, February 04, 2003 9:53 AM [GMT+1=CET],
Lars Gullik Bjønnes [EMAIL PROTECTED] wrote:
Joel de Guzman [EMAIL PROTECTED] writes:
I'm pretty sure I'm going to be switching back to Outlook Express from
emacs/GNUs because of this (and the many joys of OE). I'm using it
right now,
At 03:35 AM 2/4/2003, Andrei Alexandrescu wrote:
Beman Dawes [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
* Should a PBSP supply policies that are prone to be used unsafely?
I'd say no is an acceptable answer, at least for something like the
T*
conversion in
I would like to offer for discussion one more implementation of reference
counting smart pointer.
[snip]
Howgh!
Andrei
:-) In general, I agree with you. 1024-th smart pointer is 1023-rd
wheel reinvented. But The Best Wheel is still to be found.
Nevertheless, thanks for reply, even for the
On Tuesday, February 04, 2003 8:05 AM [GMT+1=CET],
Joel de Guzman [EMAIL PROTECTED] wrote:
Yup, this works:
#elif defined(__GNUC__) (__GNUC__ 3)
// g++ 2.95.3 cannot take static_cast the casts,
typedef integral_cT, T(value + 1) next;
typedef integral_cT, T(value - 1) prior;
John Maddock wrote:
I was just about to build the filesystem library for the first time
on my Win98+BCC 5.5.1 environment, but I got lots of errors from
type_traits/is_convertible.hpp
Since the regression_test shows that this library passed bcc5.6.1
yesterday,
I thought that is_convertible
Dave Abrahams wrote:
On Tuesday, February 04, 2003 8:05 AM [GMT+1=CET],
Joel de Guzman [EMAIL PROTECTED] wrote:
Yup, this works:
#elif defined(__GNUC__) (__GNUC__ 3)
// g++ 2.95.3 cannot take static_cast the casts,
typedef integral_cT, T(value + 1) next;
typedef
On Thu, Jan 30, 2003 at 03:10:10PM -0500, David Abrahams wrote:
If it was ever accepted by GNU, I think the authors had to sign it
over to the FSF. Did they? Does that matter? I don't know the
answers.
It does but I believe the usual agreement used by the FSF gives the
original authors the
This looks most useful - potentionally :-(
Alas the two files, test and composite_stream_operators.hpp
http://groups.yahoo.com/group/boost/files/composite_stream_operators/).
won't compile on MSVC 7.0.
test_composite_format.cpp
test_composite_format.cpp(43) : error C2679: binary '' : no
Joel de Guzman wrote:
Hi,
Borland cannot handle this code:
#include boost/type_traits.hpp
#include boost/mpl/if.hpp
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
template typename T
struct C : if_is_emptyT, A, B::type {};
struct D { int i; };
Terje Slettebø wrote:
and given this:
int main()
{
char board[3][3]=
{
{'O','X','O'},
{'X','X','O'},
{'O','O','X'}
};
std::cout io_formatchar ()[3](\n|,|\n,|)
io_formatchar ()[3][3](---,---,---)
board '\n';
}
we get:
---
|O|X|O|
Terje Slettebø wrote:
From: Vladimir Prus [EMAIL PROTECTED]
Terje Slettebø wrote:
[snip]
std::cout io_formatchar ()[3](\n|,|\n,|)
io_formatchar ()[3][3](---,---,---)
board '\n';
}
we get:
---
|O|X|O|
---
|X|X|O|
---
|O|O|X|
---
I've
Pavel Vasiliev [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
I would like to offer for discussion one more implementation of
reference
counting smart pointer.
[snip]
Howgh!
Andrei
:-) In general, I agree with you. 1024-th smart pointer is 1023-rd
From: Paul A. Bristow [EMAIL PROTECTED]
This looks most useful - potentionally :-(
Alas the two files, test and composite_stream_operators.hpp
http://groups.yahoo.com/group/boost/files/composite_stream_operators/).
won't compile on MSVC 7.0.
test_composite_format.cpp
From: Jason House [EMAIL PROTECTED]
Terje Slettebø wrote:
and given this:
int main()
{
char board[3][3]=
{
{'O','X','O'},
{'X','X','O'},
{'O','O','X'}
};
std::cout io_formatchar ()[3](\n|,|\n,|)
io_formatchar ()[3][3](---,---,---)
Jaap Suter wrote:
Try turning off debug symbols; GCC spends a long time and a lot of
disk generating them.
Thanks, works excellent! In fact, my GCC object files and executables are
the smallest now.
Yep, I came to the same conclusion. Unfortunately, it does not help
much when you need to
On Tuesday, February 04, 2003 5:27 PM [GMT+1=CET],
David A. Greene [EMAIL PROTECTED] wrote:
Jaap Suter wrote:
Try turning off debug symbols; GCC spends a long time and a lot of
disk generating them.
Thanks, works excellent! In fact, my GCC object files and executables
are
the
In a bout of cleaning, and wanting to learn about SourceForge file
distribution... I put all the historical releases of Boost, and the current
also, in the SourceForge files distribution system. Also available now are
bzip2 versions for those interested in smaller downloads. For details see:
On Tue, 04 Feb 2003 23:10:39 +0100, Paul Mensonides wrote:
Daniel Frey wrote:
Yes, I worded that incorrectly. I should have said: are you thinking
that the above will match
int (X::*pf)(long, double) const;
I'm not absolutely sure, but I think that this creates a non-const
pointer to a
Daniel Frey wrote:
[...]
I might be misunderstanding you, but the above does not match the
type int (X::*)(long, double) const. E.g. if I have this template:
I think you misunderstood me. I should have made it clearer what I was
refering to when I wrote matches the above specialization. By
At 05:06 PM 2/4/2003, Matthias Troyer wrote:
I have run the regression tests on a Cray SV1 system using the Cray C++
3.6 compiler and posted the results on
http://www.comp-phys.org/boost/cs-sn9626.html
Thanks, Matthias, those are really interesting. I'm always curious how C++
in general and
At 05:52 PM 2/4/2003, Rene Rivera wrote:
In a bout of cleaning, and wanting to learn about SourceForge file
distribution... I put all the historical releases of Boost, and the
current
also, in the SourceForge files distribution system.
Thanks! Looks great! I was wondering who added the other
The following request came from Reg Charney, from the ACCU Silicon Valley
chapter:
I was wondering if there are active Boost contributors in the Silicon
Valley area. I was hoping to invite one or two of them to come talk to
the ACCU here on Boost and what they are doing. Thanks.
If you are
[2003-02-04] Beman Dawes wrote:
At 05:52 PM 2/4/2003, Rene Rivera wrote:
In a bout of cleaning, and wanting to learn about SourceForge file
distribution... I put all the historical releases of Boost, and the
current
also, in the SourceForge files distribution system.
Thanks! Looks great! I
Andrei Alexandrescu wrote:
I agree that vector (or vector-like substitutes) are preferred over
smart_ptrT[] in most circumstances. But there are times when
ownership of the array needs to be transferred or shared. In those
instances, vector is not a good fit. smart_ptrvectorT is a
At 07:25 PM 2/4/2003, Paul Mensonides wrote:
...
If an implicit conversion to the pointed-to type is provided, there is no need to
overload the subscript operator:
...
The same applies to the standing problem of operator-*().
2c.
Yep. More reasons why I prefer that smart pointers have an
Greg Colvin wrote:
At 07:25 PM 2/4/2003, Paul Mensonides wrote:
...
If an implicit conversion to the pointed-to type is provided, there
is no need to overload the subscript operator:
...
The same applies to the standing problem of operator-*().
2c.
Yep. More reasons why I prefer that
Custom deleter policy + implicit conversion policy - converting
constructors - converting assignment operators == smart pointer that
handles arrays.
-Howard
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Howard Hinnant wrote:
Custom deleter policy + implicit conversion policy - converting
constructors - converting assignment operators == smart pointer that
handles arrays.
A custom deleter policy could prevent the use of converting ctors and
assignment.
Paul Mensonides
On Tuesday, February 4, 2003, at 10:56 PM, Paul Mensonides wrote:
Howard Hinnant wrote:
Custom deleter policy + implicit conversion policy - converting
constructors - converting assignment operators == smart pointer that
handles arrays.
A custom deleter policy could prevent the use of
This looks really neat - and potentially very useful.
Sadly, array is one of the most interesting cases - so I'm sure I won't be the
only one 'watching this space'.
Thanks
Paul
PS composite_format is a bit long, but I can't suggest better.
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria,
On Wed, 05 Feb 2003 01:11:23 +0100, Paul Mensonides wrote:
Daniel Frey wrote:
Yes. My problem is that I still don't understand what Peter is trying
to
show and that makes me kind of nervous :)
[deep breath]
I think that he thought that you might have thought that the
cv-qualified
57 matches
Mail list logo
