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-q
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, LA
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 convert
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
_
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
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 re
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
Andrei Alexandrescu wrote:
>> I agree that vector (or vector-like substitutes) are preferred over
>> smart_ptr 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_ptr > is a
>> possib
[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
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 in
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
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 B
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 specializ
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-con
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:
h
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
a
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 deb
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 const member function. As far as I understand it, th
Dear Boosters,
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
I have not looked at all the problems yet and will do so when I find
time. For now I have posted it just in case that some
Joel de Guzman wrote:
> I'm not sure if you are aware of this but g++ 2.95.3 cannot
> handle the casts:
[snip errors]
> and I must revert to:
>
> #elif defined(__GNUC__) && (__GNUC__ < 3)
> // g++ 2.95.3 cannot take the casts,
> typedef integral_c next;
> typedef integral_c prior;
>
"Howard Hinnant" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > 1. Arrays of polymorphic objects don't work.
>
> Right. But to me that just means you don't want to have the member
> template converting constructors/assignment in your array version of
> the sm
>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_format("\n|","|\n","|")
> > << io_format("---","---","-
>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
> test_
"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 poin
Terje Slettebø wrote:
From: "Vladimir Prus" <[EMAIL PROTECTED]>
Terje Slettebø wrote:
[snip]
std::cout << io_format("\n|","|\n","|")
<< io_format("---","---","---")
<< board << '\n';
}
we get:
---
|O|X|O|
---
|X|X|O|
---
|O|O|X|
---
I've
Terje Slettebø wrote:
> and given this:
>
> int main()
> {
> char board[3][3]=
> {
> {'O','X','O'},
> {'X','X','O'},
> {'O','O','X'}
> };
>
> std::cout << io_format("\n|","|\n","|")
> << io_format("---","---","---")
> << board << '\n';
> }
>
> we get:
>
> -
Joel de Guzman wrote:
> Hi,
>
> Borland cannot handle this code:
>
> #include
> #include
>
> using namespace boost;
> using namespace boost::mpl;
>
> struct A {};
> struct B {};
>
> template
> struct C : if_, A, B>::type {};
>
> struct D { int i; };
> struct E {};
>
> struct F : C {};
> s
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 opera
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 t
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_c next;
>> typedef integr
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_c
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_c next;
> typedef integral_c prior;
Hey, does that one wo
>>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 fo
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*
>
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
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
>From: "Vladimir Prus" <[EMAIL PROTECTED]>
> Terje Slettebø wrote:
>
> > There are also some other issues: The current version assumes
basic_string
> > for the delimiters. I've found it hard to let it take an arbitrary
string
> > type, as the format-object (which the manipulator,
basic_composite_f
"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, and it "just works!"
I must admit that I do not understand why anyone would switch away
fr
Beman Dawes wrote:
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".
B
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
>`boost::filesystem::dire
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
>
Terje Slettebø wrote:
I've some concerns, though:
1. Are "default" breaces/separators possible? I'd rather not use
io_format every time I had to output a vector.
Good point. As it is now, it just defaults to empty strings for the
separators. Any idea how to specify such a default? If it's
Hi there
I tried to use mpl::is_sequence<> on an incomplete type and ran into errors
suggesting that the argument must not be incomplete (I'm using MSVC 7.0). I
assume this cannot be fixed, right?
Thanks,
Andreas
P.S. I'm compiling code similar to the following:
template< class InnerInitial >
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
>From: "Vladimir Prus" <[EMAIL PROTECTED]>
> Terje Slettebø wrote:
>
> > Incidentally, I've just made a version that does exactly this. :) I've
> > attached it, including a test, with this posting.
>
> I've take a look and I like it -- quite lean and does the work.
Thanks. :)
> I've some concern
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 is my current un
Joel de Guzman wrote:
- Original Message -
From: "Vladimir Prus" <[EMAIL PROTECTED]>
Joel de Guzman wrote:
Hi,
Borland cannot handle this code:
#include
#include
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
template
struct C : if_, A, B>::type {
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
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
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 li
- Original Message -
From: "Vladimir Prus" <[EMAIL PROTECTED]>
> Joel de Guzman wrote:
> > Hi,
> >
> > Borland cannot handle this code:
> >
> > #include
> > #include
> >
> > using namespace boost;
> > using namespace boost::mpl;
> >
> > struct A {};
> > struct B {};
> >
> > templa
- Original Message -
From: "Vladimir Prus" <[EMAIL PROTECTED]>
> Joel de Guzman wrote:
> > Hi,
> >
> > Borland cannot handle this code:
> >
> > #include
> > #include
> >
> > using namespace boost;
> > using namespace boost::mpl;
> >
> > struct A {};
> > struct B {};
> >
> > templa
- 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:
> | >
> | > >
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! A
> 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 chang
From: "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]>
>
> I did not use boost::shared_array to implement the shared_plain 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.
"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
Joel de Guzman wrote:
Hi,
Borland cannot handle this code:
#include
#include
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
template
struct C : if_, A, B>::type {};
struct D { int i; };
struct E {};
struct F : C {};
struct G : C {};
Just tried. Works prett
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_funct
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/m
Hi,
Borland cannot handle this code:
#include
#include
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
template
struct C : if_, A, B>::type {};
struct D { int i; };
struct E {};
struct F : C {};
struct G : C {};
Is there a known workaround? Can this be fixed?
>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 inc
Terje Slettebø wrote:
This example should one case where manipulators are desirable:
vector< vector > 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
con
Vladimir Prus <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis 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:
"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 tha
Alisdair Meredith writes:
> Beman Dawes wrote:
>
> > See http://www.boost.org/more/cpp_committee_meetings.html. While the
> > general public isn't invited to committee meetings, Boost "technical
> > experts" are welcome.
>
> So how would I qualify myself as a "Boost technical expert"?
IIR
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
boost::fi
[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 I
Gabriel Dos Reis 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: sorry, not implemented: `static_cast_expr' not supported
| by du
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 vectors, sets, etc?
[...]
and so on.
"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
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: `static_cast
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 the
73 matches
Mail list logo
