[boost] About the static_log2 discussions

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. Actually, I've forgotten why I used the implementation I did. I sometimes tend to be verbose in my code; hopefully comp

Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]

--- David Abrahams <[EMAIL PROTECTED]> wrote: > > 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. > > Sounds like a job for a policy-based smart pointer to array to me ;-)

Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]

--- Larry Evans <[EMAIL PROTECTED]> wrote: > > The type implemented in shared_plain.h (in the directory above) is a > reference > All I see there doesn't include shared_plain.h unless it's in a subdirectory. > > Is it some other place? Sorry, this is the correct link: http://cvs.sourceforge.net/

Re: [boost] io operations for stl containers?

>From: "Glenn G. Chappell" <[EMAIL PROTECTED]> > Vladimir Prus wrote: > > 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? >

Re: [boost] MPL::void_t

- Original Message - From: "Aleksey Gurtovoy" <[EMAIL PROTECTED]> > Joel de Guzman wrote: > > Hi, > > Hi Joel, > > > Question why is mpl::void_t an incomplete type? > > I suppose we are talking about 'mpl::void_'. Since we have a use case for it > now, just go ahead and make it compl

Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]

Ralf W. Grosse-Kunstleve wrote: --- David Abrahams <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] (Joerg Walter) writes: I needed something with exactly boost::shared_array's interface to add reference counting to ublas. With shared_array I'm able to run the CLAPACK test suite on ublas containe

Re: [boost] io operations for stl containers?

Vladimir Prus wrote: > 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? ... > std::cout << "new path is " << v << "\n"; The

[boost] Borland specific defects : new config defines?

Most my porting to borland recently has involved a couple of new bugs introduced in BCB6. Rather than testing compiler and version everywhere, should I instead create some BOOST_SOME_DEFECT macros in the borland config file and test for those instead? If so, any suggestions for the macro names wo

Re: [boost] Rewritten "Rationale" for shifted_ptr<>

Philippe A. Bouchard wrote: 1) I have rewritten the "Rationale" section of shifted_ptr<> in file /shifted_ptr/doc/structboost_1_1shifted__ptr.html: http://groups.yahoo.com/group/boost/files/shifted_ptr.zip In my mozilla browser, I opened this html file and did search for "ration" but got nothing

Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]

"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes: > --- David Abrahams <[EMAIL PROTECTED]> wrote: >> [EMAIL PROTECTED] (Joerg Walter) writes: >> >> > I needed something with exactly boost::shared_array's interface to add >> > reference counting to ublas. With shared_array I'm able to run the

[boost] Re: Rewritten "Rationale" for shifted_ptr<>

"David B. Held" <[EMAIL PROTECTED]> wrote in message b1mruf$o2u$[EMAIL PROTECTED]">news:b1mruf$o2u$[EMAIL PROTECTED]... [...] > It took me a while to find the Rationale section. If you look at most > other Boost libraries, you'll see that the documentation has a very > specific layout. The fir

Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]

--- David Abrahams <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Joerg Walter) writes: > > > I needed something with exactly boost::shared_array's interface to add > > reference counting to ublas. With shared_array I'm able to run the CLAPACK > > test suite on ublas containers. > > I think Ralf

[boost] Re: is_class

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 }; }; >> template< class C, typename T

Re: [boost] is_class

- Original Message - From: "Daniel Frey" <[EMAIL PROTECTED]> > This not only leads to safer class detection, it also allows us to > implement is_member_function without providing versions for every number > of parameters. This is already possible. The specialization... R C::* ...matche

Re: [boost] is_class

- 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 }; }; > template< class C, typename T > struct is_member_function_pointer< T C::* const > { enum { value = is_

[boost] Re: Rewritten "Rationale" for shifted_ptr<>

"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message b1mh0i$2js$[EMAIL PROTECTED]">news:b1mh0i$2js$[EMAIL PROTECTED]... > 1) > I have rewritten the "Rationale" section of shifted_ptr<> in file > /shifted_ptr/doc/structboost_1_1shifted__ptr.html: > http://groups.yahoo.com/group/boost/files/sh

[boost] is_class

I noticed that is_class actually detects classes only for the Metrowerks and the VC++, other compilers use a fall-back implementation which works by detecting everything but classes and thus everything which remains has to be a class. This is IMHO broken as i.e. member functions are detected as cla

[boost] Re: Re: boost/mpl/integral_c.hpp and Borland

"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Fernando Cacciola" <[EMAIL PROTECTED]> writes: > > >> [snip ] > > I see that integral_c<> has been fixed now. > > I'm puzzled though about why the apparently simple fix didn't worked on > > Borlan

Re: [boost] Re: Smart pointers: One more implementation + question

"Andrei Alexandrescu" <[EMAIL PROTECTED]> writes: > "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 How do you

[boost] Re: Smart pointers: One more implementation + question

"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 ___ Unsubscribe & other change

[boost] Current is_convertible borken for bcc5.5.1

Hi, 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 to

Re: [boost] Re: boost/mpl/integral_c.hpp and Borland

"Fernando Cacciola" <[EMAIL PROTECTED]> writes: > - Original Message - > From: "David Abrahams" <[EMAIL PROTECTED]> > To: "Beman Dawes" <[EMAIL PROTECTED]> > Cc: "boost" <[EMAIL PROTECTED]>; "Aleksey Gurtovoy" > <[EMAIL PROTECTED]>; "Fernando Cacciola" <[EMAIL PROTECTED]> > Sent: Friday, J

[boost] Re: Array support [was SmartPtr (Loki) - auto_ptr/move c'tor issue]

"Rozental, Gennadiy" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > I would like to second this opinion. I do not see a big of a deal in > enforcing get() for direct access. It may make transition to SP > slightly more difficult. But the advantages IMO p

Re: [boost] Array support [was SmartPtr (Loki) - auto_ptr/move c'tor issue]

At 02:57 PM 2/3/2003, David Abrahams wrote: >Beman Dawes <[EMAIL PROTECTED]> writes: > >> At 09:46 PM 2/2/2003, Howard Hinnant wrote: >> >> To me, a major benefit of a policy based design is to >> be able to accommodate a wide range of features, >> including those which find only limited use. >> >

Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]

[EMAIL PROTECTED] (Joerg Walter) writes: > I needed something with exactly boost::shared_array's interface to add > reference counting to ublas. With shared_array I'm able to run the CLAPACK > test suite on ublas containers. I think Ralf Grosse-Kunstleve did something similar in scitbx (http://cv

Re: [boost] Array support [was SmartPtr (Loki) - auto_ptr/move c'tor issue]

At 02:32 PM 2/3/2003, Howard Hinnant wrote: >On Monday, February 3, 2003, at 12:50 PM, Beman Dawes wrote: >> To me, a major benefit of a policy based design is to be able to >> accommodate a wide range of features, including those which find only >> limited use. >> >> If a policy based smart poi

Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]

- Original Message - From: "Andrei Alexandrescu" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 03, 2003 8:44 PM Subject: [boost] Re: Array support [was SmartPtr (Loki) -auto_ptr/movec'torissue] > "Howard Hinnant" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTE

[boost] Re: Array support [was SmartPtr (Loki) -auto_ptr/movec'torissue]

On Monday, February 3, 2003, at 02:44 PM, Andrei Alexandrescu wrote: "Howard Hinnant" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Sunday, February 2, 2003, at 11:40 PM, Andrei Alexandrescu wrote: By and large, I believe "smart pointers to arrays" are

RE: [boost] Array support [was SmartPtr (Loki) - auto_ptr/move c'tor issue]

> I find this remarkably analogous to the operator const charT* issue > with early basic_string. We needed that operator for better > compatibility with legacy code using null-terminated char arrays, and > writing s.c_str() all over the place doesn't read as nice. > But in the > end, the imp

[boost] Re: Re: Minor problem with random::lognormal_distribution

"Beman Dawes" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >At 02:26 PM 2/3/2003, Thorsten Ottosen wrote: ... >Only in the global namespace. 17.4.3.1.2 says: > >- Each name that begins with an underscore is reserved to the >implementation for use as a name in

RE: [boost] Test Tool Proposal (test_tools.hpp)

> Gennadiy, > > I had to set the log level from the command line recently, > and had a hard time finding out how. > > I did eventually find an explanation in the docs, but it is > buried so deep that it took me quite a while to find it. The was a request couple month ago (by David Held if I am

Re: [boost] Re: Minor problem with random::lognormal_distribution

At 02:26 PM 2/3/2003, Thorsten Ottosen wrote: > >"Michael Stevens" <[EMAIL PROTECTED]> wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> There is a small correction required for lognormal_distribution. >> The problem is flagged under GCC3.2 >> >> explicit lognormal_distribution(ba

Re: [boost] Array support [was SmartPtr (Loki) - auto_ptr/movec'tor issue]

Beman Dawes <[EMAIL PROTECTED]> writes: > At 09:46 PM 2/2/2003, Howard Hinnant wrote: > > To me, a major benefit of a policy based design is to > be able to accommodate a wide range of features, > including those which find only limited use. > > If a policy based smart pointer can't accommodate a

[boost] Rewritten "Rationale" for shifted_ptr<>

1) I have rewritten the "Rationale" section of shifted_ptr<> in file /shifted_ptr/doc/structboost_1_1shifted__ptr.html: http://groups.yahoo.com/group/boost/files/shifted_ptr.zip 2) I have taken a look at some garbage collector routines and they all use placement operator new (). The best way to s

[boost] Re: Array support [was SmartPtr (Loki) -auto_ptr/movec'torissue]

"Howard Hinnant" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > On Sunday, February 2, 2003, at 11:40 PM, Andrei Alexandrescu wrote: > > > By and large, I believe "smart pointers to arrays" are an oxymoron and > > should not be supported. > > Why? The reasons

[boost] Re: [ublas-dev] Re: abs doesn't work with VC .NET

Hi Michael (hi Kresimir, hi Julius, hi all ;-), you wrote: > I have come across this problem before. The same problem occured when I > was working on .NET patches for boost::quaternion. So there's at least another boost library affected. > The following is from memory of VC7, so actual names m

[boost] Re: SmartPtr - Exception safety reprise

"David B. Held" <[EMAIL PROTECTED]> wrote in message news:... > > What can you say about empty member optimization in VC6.5 and later? > Also, do you have any idea why an empty class that inherits from > non-empty bases would be bigger than the sum of the size of t

Re: [boost] Array support [was SmartPtr (Loki) - auto_ptr/move c'torissue]

Thanks Beman. On Monday, February 3, 2003, at 12:50 PM, Beman Dawes wrote: At 09:46 PM 2/2/2003, Howard Hinnant wrote: >Could someone review the motivations for wanting an implicit conversion >to T* ? I'm failing to come up with any myself. It is useful when it is desirable for the smart po

[boost] Re: Re: auto_ptr/move issue

"Howard Hinnant" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > On Monday, February 3, 2003, at 12:53 PM, David B. Held wrote: > > > So, apologies to Howard if it > > looked like I was calling him a copycat. That was not my intent in the > > least. > > No, I d

[boost] Re: Minor problem with random::lognormal_distribution

"Michael Stevens" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > There is a small correction required for lognormal_distribution. > The problem is flagged under GCC3.2 > > explicit lognormal_distribution(base_type & rng, > re

Re: [boost] io operations for stl containers?

>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? > > I was thinking about > > >

[boost] Minor problem with random::lognormal_distribution

There is a small correction required for lognormal_distribution. The problem is flagged under GCC3.2 explicit lognormal_distribution(base_type & rng, result_type mean = result_type(1), result_type sigma = result_type(1)) ... RealT

Re: [boost] Re: auto_ptr/move issue

On Monday, February 3, 2003, at 12:53 PM, David B. Held wrote: So, apologies to Howard if it looked like I was calling him a copycat. That was not my intent in the least. No, I did not read your question that way. No apologies necessary at all. "I plan to implement Mojo in SmartPtr. Does

Re: [boost] Re: io operations for stl containers?

>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

Re: [boost] io operations for stl containers?

From: "Terje Slettebø" <[EMAIL PROTECTED]> > >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

RE: [boost] Test Tool Proposal (test_tools.hpp)

At 12:54 PM 2/3/2003, Rozental, Gennadiy wrote: >P.S. Don't forget to set log level to "messages" would you decide to choose >the second solution. Gennadiy, I had to set the log level from the command line recently, and had a hard time finding out how. I did eventually find an explanation in

Re: [boost] Re: MetaMap (was: [BGL] MutablePropertyGraph questions)

On Mon, 2003-02-03 at 07:18, David B. Held wrote: > Where can we see the actual library? here: http://groups.yahoo.com/group/boost/files/associative_list/ Emily ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: io operations for stl containers?

Al Stevens who writes the C++ column for "Doctor Dobbs Journal" put out a persistent template library for C++ containers some time back. It is probably on the DDJ web site, although I haven't looked there recently. You might want to check that out and see what he did. I will readily admit I have no

RE: [boost] io operations for stl containers?

> Hi, > > 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? > > I was thinking about > > > > > and so on. There are bas

[boost] Re: io operations for stl containers?

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? I was thinking abou

RE: [boost] Test Tool Proposal (test_tools.hpp)

> 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 > failure hap

Re: [boost] Array support [was SmartPtr (Loki) - auto_ptr/move c'tor issue]

At 09:46 PM 2/2/2003, Howard Hinnant wrote: >Could someone review the motivations for wanting an implicit conversion >to T* ? I'm failing to come up with any myself. It is useful when it is desirable for the smart pointer to mimic a built-in pointer as closely as possible. One case where that

RE: [boost] Test Tool Proposal (test_tools.hpp)

> void checkMyObject(MyObject* my, int context, int a, int b, int c) > { > BOOST_CHECK_EQUAL_MESSAGE(my->getA(), a, context); > BOOST_CHECK_EQUAL_MESSAGE(my->getB(), b, context); > BOOST_CHECK_EQUAL_MESSAGE(my->getC(), c, context); > } > > MyObject* my1 = new MyObject(1, 2

[boost] Re: auto_ptr/move issue

"David B. Held" <[EMAIL PROTECTED]> wrote in message b1e68m$mqs$[EMAIL PROTECTED]">news:b1e68m$mqs$[EMAIL PROTECTED]... > [...] > This looks suspiciously like Mojo. > [...] Ok, this was perhaps one of the most poorly worded things I've said in a long time (toothpaste discussions nothwithstanding).

Re: [boost] Regression tests on Cray

On Monday, February 3, 2003, at 04:37 PM, Beman Dawes wrote: At 03:10 AM 2/3/2003, Matthias Troyer wrote: >prompt$ >../tools/regression/build/bin/process_jam_log/cray/release/ >process_jam_log >Usage: bjam [bjam-args] | process_jam_log [locate-root] > locate-root is the same as the bjam ALL_L

Re: associate_list( Was: [boost] [BGL] MutablePropertyGraphquestions)

On Monday, February 3, 2003, at 06:20 PM, Emily Winch wrote: On Mon, 2003-02-03 at 08:02, Matthias Troyer wrote: Yes, Emily Winch was working on this, and I thought she was going to submit to boost. The following URL has a paper she wrote about this. http://www.oonumerics.org/tmpw01/schedu

[boost] Re: Re: [BGL] MutablePropertyGraph questions

Thank you for taking the time to dissect my e-mail Emily: > ... I assume, are built up at runtime. True. > In fact, my class _is_ a BGL property > map (I mean that it does the same thing, not that it necessarily > conforms to the required interface), and you are deliberately subverting > the

Re: [boost] io operations for stl containers?

>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? > > I was thinking about > > >

Re: [boost] Re: boost/mpl/integral_c.hpp and Borland

- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> To: "Beman Dawes" <[EMAIL PROTECTED]> Cc: "boost" <[EMAIL PROTECTED]>; "Aleksey Gurtovoy" <[EMAIL PROTECTED]>; "Fernando Cacciola" <[EMAIL PROTECTED]> Sent: Friday, January 31, 2003 9:58 PM Subject: [boost] Re: boost/mpl/integ

Re: [boost] Re: Thread library with BOOST_HAS_PTHREAD

>> Alexander Terekhov writes: > >> Shimshon Duvdevan wrote: > >>> [ ... Solaris -> PTHREAD_SCOPE_SYSTEM ... ] > >>> Can anyone verify the supposed boost threads library behavior on a >>> multi-processor Solaris machine? Is this behavior the intended one? >>> Perhaps a bug fix is necessary. > >> Th

[boost] Re: associate_list( Was: [BGL] MutablePropertyGraphquestions)

Vladimir Prus wrote: i needed that (or maybe something similar) for the filesystem attributes in the sandbox. i tried to make it compatible to the property map concept. the output can be used as follows (taken from boost-sandbox/libs/filesystem/test/type_pm_test.cpp) AFAIKT, this is quite clos

Re: [boost] Regression tests on Cray

At 03:10 AM 2/3/2003, Matthias Troyer wrote: >> Maybe. First tell me what the output is from the messages that >> process_jam_log outputs soon after it starts. The lines that create >> the messages begin about line 366 in the source file: >> >> std::cout << "boost_root: " << boost_root.string()

Re: associate_list( Was: [boost] [BGL] MutablePropertyGraphquestions)

On Mon, 2003-02-03 at 08:02, Matthias Troyer wrote: > > > > >>Yes, Emily Winch was working on this, and I thought she was going to > > >>submit to boost. The following URL has a paper she wrote about this. > > >> > > >>http://www.oonumerics.org/tmpw01/schedule.html > > I can't access that file. Is

Re: [boost] Re: [BGL] MutablePropertyGraph questions

On Sun, 2003-02-02 at 22:37, Chris Russell wrote: > Hi Emily, I just read your paper and think it's excellent. A while ago (some > months past), I think I hacked together a solution to a similar problem and > made a mental note to post it into the Wiki for analysis by folks who really > know what

[boost] io operations for stl containers?

Hi, 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? I was thinking about and so on. There are basically two approaches: 1. O

RE: [boost] boost::format problems

I use MSVC6.5 and STLPort. Well, now it seems to work, except: 1) I don't have wformat defined, and I need to define it myself. I can see the bunch of defines that go into deciding this in the config, and I'm not sure why in the end boost::format concludes that because there's a using ::x compile

[boost] Re: auto_ptr/move issue

"Peter Dimov" <[EMAIL PROTECTED]> wrote in message 001b01c2cb95$de5e8fe0$1d00a8c0@pdimov2">news:001b01c2cb95$de5e8fe0$1d00a8c0@pdimov2... > [...] > And finally Mojo approximates: > > public: > mojoized(mojoized const & rhs); // can copy > mojoized(mojoized && rhs); // but can also move for effi

[boost] Re: SmartPtr - Exception safety reprise

"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > That's called boost::compressed_pair. Right. The generality of compressed_pair kept me from seeing that rather obvious fact. > [...] > There is no such thing as empty member optimization.

Re[2]: [boost] Smart pointers: One more implementation + question

>> The advantage is that with void*-based implementation... > There are no significant drawbacks that I can see. > The only drawback is that with a void * px it's easier to create a broken > implementation that will almost work. For example > template shared_ptr::shared_ptr(shared_ptr const & rh

Re: [boost] Smart pointers: One more implementation + question

From: "Pavel Vasiliev" <[EMAIL PROTECTED]> [...] > Also there is a question related to boost::shared_ptr: what the > drawbacks would be in implementing it via void*? I mean > > template class shared_ptr > { > void * px; > detail::shared_count pn; > ... > public: > T * get() const > { >

Re: [boost] Re: auto_ptr/move issue

From: "David B. Held" <[EMAIL PROTECTED]> > "Howard Hinnant" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > [...] > > I presented code under the thread "SmartPtr (Loki) - auto_ptr/move > > c'tor issue" on Jan. 28 which does this. For easy reference, here is

Re: [boost] auto_ptr/move issue

From: "Howard Hinnant" <[EMAIL PROTECTED]> > move_ptr source(); > ... > move_ptr i(source()); // move with copy syntax from rvalue, ok. > move_ptr j(i); // error, move with copy syntax from lvalue, bad! > move_ptr k(move(i)); // move with move syntax from lvalue, ok. [...] > I presented code

[boost] Smart pointers: One more implementation + question

I would like to offer for discussion one more implementation of reference counting smart pointer. It has taken much of the design from boost::shared_ptr/weak_ptr and is quite similar to it, but supports different types of reference counting (intrusive, semi- intrusive, non-intrusive + weak referen

[boost] Re: Thread library with BOOST_HAS_PTHREAD

Shimshon Duvdevan wrote: [...] > So, if upgrading Solaris is not an option, I should patch boost.threads each > time a new version is out? Isn't it easier to add a couple of #ifdefs? :) I'd suggest that you should just wait for "a new version" that would hopefully allow you to have something alo

[boost] MSVC .NET + BOOST_NO_STDC_NAMESPACE (formerublas::type_traits::abs doesn't work with VC .NET)

Hi Kresimir, hi Joerg, At 11:41 03.02.2003, you wrote: Hi Joerg, hi Julius, I am not sure whether the message http://groups.google.com/groups?selm=3E23CE08.893428D0%40bdal.de from comp.lang.c++.moderated is on topic ;o), but maybe it is worth a look. Thanks. The message is exactly on topic.

[boost] Re: Array support [was SmartPtr (Loki) - auto_ptr/movec'torissue]

On Sunday, February 2, 2003, at 11:40 PM, Andrei Alexandrescu wrote: By and large, I believe "smart pointers to arrays" are an oxymoron and should not be supported. Why? -Howard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listin

[boost] Re: A functional "bind"-ing exercice...

Somewhere in the E.U., le 03/02/2003 Bonjour In article <001b01c2c942$cd3f08c0$1d00a8c0@pdimov2>, "Peter Dimov" <[EMAIL PROTECTED]> wrote: > From: "Hubert Holin" <[EMAIL PROTECTED]> > > Somewhere in the E.U., le 31/01/2003 > > > > In article <00d801c2c927$8d06dd20$1d00a8c0@pdimov2>, > > "Pe

Re: [boost] [BGL] MutablePropertyGraph questions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Emily, Emily Winch wrote: | On Wed, 2003-01-29 at 15:30, Jeremy Siek wrote:> | I would be very happy to submit it to boost, and several people have | suggested this. I think it would be a mistake to submit it for a formal | review without any prio

Re: [boost] Re: Array support [was SmartPtr (Loki) -auto_ptr/movec'torissue]

From: "Andrei Alexandrescu" <[EMAIL PROTECTED]> > > That very nicely clarifies the requirements. I don't have time to munch on > a detailed solution, but let me add this: operator[] doesn't have to be a > member, which might simplify things considerably. Nope, it "shall be a non-static member func

Re: [boost] Re: is_base_and_derived question

From: "Gennaro Prota" <[EMAIL PROTECTED]> > On Sat, 1 Feb 2003 20:01:15 -0800, "Eric Niebler" <[EMAIL PROTECTED]> > wrote: > > >"Gennaro Prota" <[EMAIL PROTECTED]> wrote > >> > >> Well, then I imagine you would prefer the old semantics. Was there > >> anybody complaining that being not enough? > >>

Re: [boost] boost::format problems

Le jeu 16/01/2003 à 15:13, Yitzhak Sapir a écrit : > I tried to use boost::format in a simple manner. The line in question is: > std::cout << boost::format("%0d") % some_function(); > > Unfortunately, in order for this to compile I have to: > 1) #include > 2) add a line "using namespace std;

Re: [boost] Test Tool Proposal (test_tools.hpp)

[EMAIL PROTECTED] wrote: --- SNIP Example --- MyObject* my1 = new MyObject(1, 2, 3); BOOST_CHECK_EQUAL(my1->getA(), 1); BOOST_CHECK_EQUAL(my1->getB(), 2); BOOST_CHECK_EQUAL(my1->getC(), 3); MyObject* my2 = new MyObject(4, 5, 6); BOOST_CHECK_EQUAL(my2->getA(), 4); BOOST_CHECK_EQUAL(my2->getB(), 5

Re: [boost] Re: ublas::type_traits::abs doesn't work with VC .NET

Hi Joerg, (snip) OK, I'll add #include to ublas/traits.hpp. Does this solve the original problem with .NET? No it doesn't, for the same reasons as with cmath. Julius Muschaweck _ OEC AG Paul-Gerhardt-Allee 42 81245 Muenchen, Germany P

[boost] Re: borland patch for random/graph tests

Beman Dawes wrote: > * Patches really are best to be supplied as diff output; that cuts errors > applying them. The -c switch helps make them more readable. It may be > better to attach the diff output as a file, if long lines would be wrapped > by pasting it inline. Is this form better? [diff

Re: [boost] Re: ublas::type_traits::abs doesn't work with VC.NET

Hi Julius, you wrote: [snip] > > IIRC the signatures 'float abs(float)' and 'double abs(double)' should be > > part of , which is included in . > I think they should, too, but they aren't. I don't know why, but the Standard (Table 81, > Section, 26.5, p596) puts abs, div, rand and srand into cs

[boost] Test Tool Proposal (test_tools.hpp)

I suggest adding the following (or a similar) macro to test_tools.hpp: #define BOOST_CHECK_EQUAL_MESSAGE(left_, right_, message_) \ boost::test_toolbox::detail::equal_and_continue_impl((left_), (right_), \ boost::test_toolbox::detail::wrapstrstream() << #left_ " == " #right_ << " ("

[boost] Re: ublas::type_traits::abs doesn't work with VC .NET

Hi Joerg, At 09:27 03.02.2003, you wrote: Hi Julius, it looks as if your mail didn't find it's way to the boost ml. You wrote: Sorry, I had a typo in the boost ml address. You included my message in your reply, so I don't send it again. > (snipped) IIRC the signatures 'float abs(float)' and '

[boost] Re: Re: [BGL] MutablePropertyGraph questions

Indeed. boost::any does look very similar. Some differences: - Invoking CMoniker's operator= or copy constructor doesn't duplicate the shrouded object, it duplicates a void * and increments a refcount on the contained CMonikerBase object the idea being that CMoniker's typically contain heavy objec

[boost] Re: ublas::type_traits::abs doesn't work with VC .NET

Hi Julius, it looks as if your mail didn't find it's way to the boost ml. You wrote: > Hello Joerg, > and hello to whoever deals with MSVC .NET Standard conformance at boost: > > I found a small but nasty bug between MSVC .NET and ublas which I believe is > Microsoft's fault. > > #include > #inc

Re: [boost] Re: associate_list( Was: [BGL] MutablePropertyGraphquestions)

Jan Langer wrote: Personally, I did not really notice your announcements. Some time ago I wanted a dynamic type-indexed container, in which you specify the required type, and it's either returned, or created. After quite look on some email of yours I decided it's something different and stopped

Re: [boost] Re: SmartPtr - Exception safety reprise

"David B. Held" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> [...] >> The problem arises if the user passes an empty policy class with >> non-trivial ctor or dtor: then the fact that it's being >> constructed/

Re: [boost] Regression tests on Cray

On Sunday, February 2, 2003, at 05:36 PM, Beman Dawes wrote: At 05:37 PM 2/1/2003, Matthias Troyer wrote: > >On Saturday, February 1, 2003, at 10:49 PM, Beman Dawes wrote: > >> At 12:39 PM 2/1/2003, Matthias Troyer wrote: >> >> >< cat regress.log | $process_jam_log >> >--- >> > > cat regress.log

[boost] Re: SmartPtr - Exception safety reprise

"David B. Held" <[EMAIL PROTECTED]> wrote in message b1l1s5$7fm$[EMAIL PROTECTED]">news:b1l1s5$7fm$[EMAIL PROTECTED]... > [...] > I mean, the optimally_inherit eliminates the empty bases, and yet > there is size bloat. So VC++ makes the class bigger for some other > reason than that it has empty b

Re: associate_list( Was: [boost] [BGL] MutablePropertyGraphquestions)

>>Yes, Emily Winch was working on this, and I thought she was going to >>submit to boost. The following URL has a paper she wrote about this. >> >>http://www.oonumerics.org/tmpw01/schedule.html I can't access that file. Is there a server problem or has it moved?