[boost] ublas bug(?): sparse_matrix and matrix_row
Hi,
to me it looks like there may be a bug with sparse_matrix and
matrix_row.
I was building a large sparse matrix from some smaller ones. When I tried
to assign a matrix_row of a sparse_matrix to another matrix_row of
another sparse_matrix, nothing happened. When I mix sparse_matrix with
matrix, it works as I expected, but then the sparse matrix isn't sparse
anymore.
I tried this with the following code:
void SparseBug()
{
using
namespace boost::numeric;
typedef
ublas::sparse_matrix TSM;
typedef
ublas::matrix TM;
TSM
sm1(3,3);
TSM
sm2(3,3);
TM
m1(3,3);
TM
m2(3,3);
sm1(1,1) =
m1(1,1) = 2.;
ublas::matrix_row
(sm2,1) = ublas::matrix_row (sm1,1);
ublas::matrix_row
(m2,1) = ublas::matrix_row (m1,1);
std::cout
<< "matrix=matrix: m2(1,1) should be " << m1(1,1)
<< ", is "<< m2(1,1) << std::endl;
std::cout
<< "sparse_matrix=sparse_matrix: sm2(1,1) should be "
<< sm1(1,1) << ", is "<< sm2(1,1) <<
std::endl;
ublas::matrix_row
(sm2,1) = ublas::matrix_row (m1,1);
std::cout
<< "sparse_matrix=matrix: sm2(1,1) should be " <<
m1(1,1) << ", is "<< sm2(1,1) <<
std::endl;
ublas::matrix_row
(m2,1) = ublas::matrix_row (sm1,1);
std::cout
<< "matrix=sparse_matrix: m2(1,1) should be " <<
sm1(1,1) << ", is "<< m2(1,1) <<
std::endl;
};
and got
matrix=matrix: m2(1,1) should be 2, is 2
sparse_matrix=sparse_matrix: sm2(1,1) should be 2, is 0
sparse_matrix=matrix: sm2(1,1) should be 2, is 2
matrix=sparse_matrix: m2(1,1) should be 2, is 2
on my Win2000 SP3 machine with Microsoft VC++.net in debug mode.
Has anyone an idea?
Thanks, Julius
Julius Muschaweck
_
OEC AG
Paul-Gerhardt-Allee 42
81245 Muenchen, Germany
Phone: +49 89 820050-30
Fax: +49 89 820050-41
e-mail: <[EMAIL PROTECTED]>
Internet:
www.oec.net
__
Re: [boost] Re: Re: is_base_and_derived question
From: "Rani Sharoni" <[EMAIL PROTECTED]>
>
> I fogot to show little usability sample:
>
> struct B {};
> struct B1 : B {};
> struct B2 : B {};
> struct D : B1, private B2 {};
>
> typedef char Test[is_base_and_derived::result]; // improvement 1 -
> multiple base
> typedef char Test[is_base_and_derived::result];
> typedef char Test[is_base_and_derived::result]; // improvement 2 -
> private base
> typedef char Test[!is_base_and_derived::result];
Very clever. But I'm not sure whether this is what is_base_and_derived is
supposed to check. It seems that many are using it as
is_accessible_base_of_derived, is-a, or is_convertible.
Perhaps we need two separate metafunctions for that.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
From: "David Abrahams" <[EMAIL PROTECTED]> > > "Peter Dimov" <[EMAIL PROTECTED]> wrote in message > > 004501c2c6f8$970c7400$1d00a8c0@pdimov2">news:004501c2c6f8$970c7400$1d00a8c0@pdimov2... > >> From: "David B. Held" <[EMAIL PROTECTED]> > >> [...] > >> Nope, but I want my sink strongly exception safe; the pointer should > >> be deleted when a policy constructor throws. > > BTW, this is also not the "strong guarantee" (I dunno, maybe people > mean something else by "strongly exception safe" -- is there a > definition somewhere?) Can't get away with colloquialisms. Yep, I am very wrong if the sink is smart_ptr::smart_ptr. Strong guarantee here means do-nothing, which is exactly what the current smart_ptr does, leak and all. I am less wrong if the sink is the expression smart_ptr<> px(new X); although this can give the strong guarantee only if "delete new X" has no observable side effects; so "basic guarantee" is probably more precise. And I'm even less wrong if the sink is px.reset(new X); since "basic guarantee" here says nothing about px after the exception. The exception safety of this construct has no name, it's somewhere between basic and strong. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
From: "David B. Held" <[EMAIL PROTECTED]>
> "Peter Dimov" <[EMAIL PROTECTED]> wrote in message
> 004501c2c6f8$970c7400$1d00a8c0@pdimov2">news:004501c2c6f8$970c7400$1d00a8c0@pdimov2...
> > From: "David B. Held" <[EMAIL PROTECTED]>
> > [...]
> > Nope, but I want my sink strongly exception safe; the pointer should
> > be deleted when a policy constructor throws.
>
> Hmm...that's not a bad point. A function try block should make this
> possible, no?
To be honest, I don't know. The design is quite complicated, and I don't
have the time to study it in-depth. I'm not sure how this interacts with
stored_type being a smart pointer that owns the object.
See also:
friend inline void release(this_type& sp, stored_type& p)
{
checking_policy::on_release(storage_policy::storage());
p = get_impl_ref(sp);
get_impl_ref(sp) = storage_policy::default_value();
ownership_policy& op = sp;
op = ownership_policy();
}
I'm not sure whether this works as intended if ownership_policy() throws.
> > Yes, I understand that, but do you know of a user that needs an
> > almost_auto_ptr? ;-)
>
> Given how often people write auto_ptr<> without writing auto_ptr<>,
> I'd say yes. ;>
How often do people write pointers that use the auto_ptr_ref trick?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Deadline for the Standard Library TechnicalReport
From: "David B. Held" <[EMAIL PROTECTED]> > "Beman Dawes" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > [...] > > For a shared-ownership smart pointer with weak_ptr support, I expect > > some people will say that mandates a refcounted rather than reflinked > > implementation. I don't think that is true, but it may make a reflinked > > implementation less attractive. What's your opinion on that? > > I was looking through Peter's GC code, and I see that he builds a > map of pointers. I was wondering if a ref-linked implementation > would make the scan process faster. Some GCSP implementations do use linked pointers... although they typically keep one big list. This allows them to know precisely where all smart pointers are. The MT downside is that every smart pointer operation needs to grab a global lock. Counted pointers have a per-object mutex. (On a straightforward implementation; synchronization experts may be able to avoid the lock using atomic intructions in one or both cases.) > You could maintain a map of > pointers that would constitute your root set? Then instead of > scanning raw memory, just scan the ref-links? Maybe that's what > Andrei was referring to by the "shared global map approach". Andrei was probably referring to my "design notes" about raw to smart conversions; one solution is to keep a global object pointer to count pointer map. See for example http://web.onetel.net.uk/~anthony_w/cplusplus/genericptr.pdf http://web.onetel.net.uk/~anthony_w/cplusplus/genericptr.zip from http://cplusplus.anthonyw.cjb.net/articles.html ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
From: "David B. Held" <[EMAIL PROTECTED]> > "Greg Colvin" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > At 10:08 AM 1/28/2003, Andrei Alexandrescu wrote: > > >[...] > > >I think what Peter refers to is that C++ might change to make > > >move semantics easier to implement. That would render the effort > > >unnecessary. > > Only if we don't want smart_ptr for another year or two, or whenever > compiler vendors start shipping compilers that implement the new move > syntax, and people start using them in force. I don't see why. You'll have a C++98 smart_ptr. It won't be able to emulate auto_ptr<>, that's all. If your user community tells you that auto_ptr emulation is important for them, you'll try to add it. If other features are more important to your users, you'll work on those instead. Like extend the COM policy to use QueryInterface on conversions, for example. Or adding deep const. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] BGL: checking for internal properties
Jeremy, suppose I got lazy and don't want my graph algorithm to be passed a graph which does not have internal edge_weight property. What's the best way to check? I can do get(edge_weight, g); but that causes compile error in instantination deeps. What I'd like is something like: BOOST_STATIC_ASSERT(has_property::value); Is it possible now? If not, is this a reasonable feature? - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] BGL: graph direction
Jeremy, When declaring adjacency_list, one can specify whether graph is directed or not, using selectors directedS undirectedS and bidirectionalS No wonder I always try to type "bidirectedS" and get a compile error. Is there any reason for different naming? No sure which is correct grammatically, but "bidirected" certainly used. For example, in LEDA docs: http://www.algorithmic-solutions.info/leda_manual/graph.html (in the second section). What do you think? - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Formal Review Request, Fixed-Point Decimal Library
Now that I once again have the time to pay attention to what's going on in Boost, I'd like to request a formal review of the fixed-point decimal library in fixdecv2.zip in the Yahoo files section. I haven't made any changes since I uploaded that file last October. Thanks, --Bill Seymour ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
> I've always felt that is_base_and_derived is a funny name. is_base_of > and is_derived_from both look pronounceable(sp?) to me: "is B a base > of D? is D derived from B?" > > While we're at it, is the final verdict that is_base_and_derived > should be false? What about is_base_and_derived? The LWG suggested (and I agreed with) a change to "is_base". And yes, if one or the other template arguments are non-class types, then the answer is false (I may need to double check the current implementation on this). John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Building boost ignores GCC_ROOT_DIRECTORY etc.
> The documentation on the site indicates I can use GXX or > GCC_ROOT_DIRECTORY to specify which g++ binary to run. However, these > settings are ignored, and the g++ in my path is used instead. > > GCC_ROOT_DIRECTORY=/usr/local/gcc-cvs/ TOOLS=gcc ~/bin/bjam > > and other variants show this behaviour. Probably a dumb question, but I assume that you exported those variables? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
> Before changing the documentation please consider the following improved > implemetation that overcomes ambiguity and access control issues of the > current is_base_and_derived implemetation (I lately posted it to c.l.c++.m) That's really interesting, but I can't get to work with the compilers I have access to (Borland/gcc), I've attached a modified version that at least compiles with these compilers, but it doesn't produce the correct results: Running 1 test case... Platform: Cygwin Compiler: GNU C++ version 3.2 20020927 (prerelease) STL : GNU libstdc++ version 20020927 Boost : 1.30.0 is_base_and_derived_test.cpp(109): error in "is_base_and_derived": The expression: "(::boost::is_base_and_derived::value)" had an invalid value (found 0, expected 1) is_base_and_derived_test.cpp(110): error in "is_base_and_derived": The expression: "(::boost::is_base_and_derived::value)" had an invalid value (found 0, expected 1) is_base_and_derived_test.cpp(111): error in "is_base_and_derived": The expression: "(::boost::is_base_and_derived::value)" had an invalid value (found 0, expected 1) is_base_and_derived_test.cpp(119): error in "is_base_and_derived": The expression: "(::boost::is_base_and_derived::value)" had an invalid value (found 0, expected 1) is_base_and_derived_test.cpp(121): error in "is_base_and_derived": The expression: "(::boost::is_base_and_derived::value)" had an invalid value (found 0, expected 1) Test suite "Type Traits" failed with: 15 assertions out of 20 passed 5 assertions out of 20 failed Test case "is_base_and_derived" failed with: 15 assertions out of 20 passed 5 assertions out of 20 failed Any ideas, or results from other compilers? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm is_base_and_derived_test.cpp Description: Binary data ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Deadline for the Standard Library TechnicalReport
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > "David B. Held" <[EMAIL PROTECTED]> writes: > > | "Beman Dawes" <[EMAIL PROTECTED]> wrote in message > | [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > | > [...] > | > Anyone interested might want to read the actual proposal. See > | > http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1406.pdf > | > | Yes, I found that on my own, and noticed that of the two "mutually > | exclusive designs", the one with one feature was chosen over the > | one with three features. > > In fact, these notions are not mutually exclusive. There was a debate > to that effect on the committee reflectors, recently. Was it on "-core" or did I miss it somehow? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Deadline for the Standard LibraryTechnicalReport
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > David Abrahams <[EMAIL PROTECTED]> writes: > > | "David B. Held" <[EMAIL PROTECTED]> writes: > | > | > "Peter Dimov" <[EMAIL PROTECTED]> wrote in message > | > 000d01c2c6f3$85038c30$1d00a8c0@pdimov2">news:000d01c2c6f3$85038c30$1d00a8c0@pdimov2... > | >> [...] > | >> By the way, the current typedef template proposal prohibits deduction; > | >> this makes it less attractive for creating subpointers. > | > > | > Ouch! Is this due to complexity issues, or was it just not deemed useful?? > | > | It's hard to say why, exactly, but my sense of it was that it was done > | because it was easy to specify semantics that were identical to those > | of the existing metafunction-form workaround. > > My recollection is a little different :-) Are you planning to grace us with the contents of your memory, Gaby, or are you gonna hold us in suspense forever? :-) come-up-to-the-lab-and-see-what's-on-the-slab-ly y'rs, -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"Peter Dimov" <[EMAIL PROTECTED]> writes: > From: "David Abrahams" <[EMAIL PROTECTED]> >> > "Peter Dimov" <[EMAIL PROTECTED]> wrote in message >> > 004501c2c6f8$970c7400$1d00a8c0@pdimov2">news:004501c2c6f8$970c7400$1d00a8c0@pdimov2... >> >> From: "David B. Held" <[EMAIL PROTECTED]> >> >> [...] >> >> Nope, but I want my sink strongly exception safe; the pointer should >> >> be deleted when a policy constructor throws. >> >> BTW, this is also not the "strong guarantee" (I dunno, maybe people >> mean something else by "strongly exception safe" -- is there a >> definition somewhere?) > > Can't get away with colloquialisms. Not in this area, sorry. Too many colloquiallisms, for too long, are in large part what had poisoned people's ability to think effectively about it. > Yep, I am very wrong if the sink is smart_ptr::smart_ptr. Strong guarantee > here means do-nothing, which is exactly what the current smart_ptr does, > leak and all. > > I am less wrong if the sink is the expression > > smart_ptr<> px(new X); > > although this can give the strong guarantee only if "delete new X" has no > observable side effects ; so "basic guarantee" is probably more precise. That is a general assumption that underlies all of the guarantees. It's a difficult corner to speak more-precisely about: to do so you need to say something about which operations undo which other operations. Anyway, we'd normally call that "strong" as well. > And I'm even less wrong if the sink is > > px.reset(new X); > > since "basic guarantee" here says nothing about px after the exception. The > exception safety of this construct has no name, it's somewhere between basic > and strong. Not sure what you expect the behavior to be in the face of an exception, but I can't see why you say that neither named guarantee applies here. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
"John Maddock" <[EMAIL PROTECTED]> writes: >> I've always felt that is_base_and_derived is a funny name. is_base_of D> >> and is_derived_from both look pronounceable(sp?) to me: "is B a base >> of D? is D derived from B?" >> > The LWG suggested (and I agreed with) a change to "is_base". Wow, how did I miss that? I find is_base_and_derived to be much clearer. With "is_base", how will I know which of the two arguments is the supposed base class? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
John Maddock wrote:
>
> > I've always felt that is_base_and_derived is a funny name. is_base_of D>
> > and is_derived_from both look pronounceable(sp?) to me: "is B a base
> > of D? is D derived from B?"
> >
> > While we're at it, is the final verdict that is_base_and_derived
> > should be false? What about is_base_and_derived?
>
> The LWG suggested (and I agreed with) a change to "is_base".
I don't like this - I gave the rationale in another posting already.
Here's yet another idea which might keep the syntax readable for the
user:
// given some is_base_and_derived< B, D >::value
template< typename T > struct is
{
template< typename U > struct derived_from
{ enum { value = is_base_and_derived< U, T >::value };
template< typename U > struct base_of
{ enum { value = is_base_and_derived< T, U >::value };
};
// usage:
is< D >::derived_from< B >::value
is< B >::base_of< D >::value
Thoughts?
Regards, Daniel
--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
On Wednesday 29 January 2003 09:42 am, Daniel Frey wrote:
> // given some is_base_and_derived< B, D >::value
>
> template< typename T > struct is
> {
>template< typename U > struct derived_from
>{ enum { value = is_base_and_derived< U, T >::value };
>template< typename U > struct base_of
>{ enum { value = is_base_and_derived< T, U >::value };
> };
>
> // usage:
>
> is< D >::derived_from< B >::value
> is< B >::base_of< D >::value
>
> Thoughts?
>
> Regards, Daniel
It gets ugly in the common case (where D is a template parameter):
is::template derived_from::value
Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Building boost ignores GCC_ROOT_DIRECTORY etc.
"John Maddock" <[EMAIL PROTECTED]> writes: >> The documentation on the site indicates I can use GXX or >> GCC_ROOT_DIRECTORY to specify which g++ binary to run. However, these >> settings are ignored, and the g++ in my path is used instead. >> >> GCC_ROOT_DIRECTORY=/usr/local/gcc-cvs/ TOOLS=gcc ~/bin/bjam >> >> and other variants show this behaviour. > > Probably a dumb question, but I assume that you exported those variables? I've verified that it's a bug. It appears to have been caused by these changes of Rene's from December: 1.57 (grafik 23-Dec-02): flags gcc GCC_ROOT_DIRECTORY : $(GCC_ROOT_DIRECTORY) ; 1.57 (grafik 23-Dec-02): flags gcc GCC_BIN_DIRECTORY : $(GCC_BIN_DIRECTORY) ; 1.57 (grafik 23-Dec-02): flags gcc GCC_INCLUDE_DIRECTORY : $(GCC_INCLUDE_DIRECTORY) ; 1.57 (grafik 23-Dec-02): flags gcc GCC_STDLIB_DIRECTORY : $(GCC_STDLIB_DIRECTORY) ; Rene, can you comment please? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
From: "David Abrahams" <[EMAIL PROTECTED]> > "Peter Dimov" <[EMAIL PROTECTED]> writes: > > > And I'm even less wrong if the sink is > > > > px.reset(new X); > > > > since "basic guarantee" here says nothing about px after the exception. The > > exception safety of this construct has no name, it's somewhere between basic > > and strong. > > Not sure what you expect the behavior to be in the face of an > exception, but I can't see why you say that neither named guarantee > applies here. The behavior, at least in shared_ptr's case, is that the pointer is deleted, but there are no other effects, i.e. px is left unchanged. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] MutablePropertyGraph questions
Jeremy Siek wrote: Hi Volodya, On Tue, 10 Dec 2002, Vladimir Prus wrote: ghost> Looking at BGL's MutablePropertyGraph docs I can't understand ghost> two things: ghost> ghost> ep is an object of type G::edge_property_type ghost> ghost> Is that really so? Why not graph_traits::edge_property_type? Actually, I think it really should be edge_property::type and vertex_property::type. OK. Also MutablePropertyGraph should be split into VertexMutablePropertyGraph and EdgeMutablePropertyGraph. Oh.. I only now realized how to use ReabablePropertyGraph concept: function_requires< ReadablePropertyGraphConcept >(); Are you suggesting that this become function_requires< EdgePropertyGraphConcept >(); and the same split done to PropertyGraphConcept and LvaluePropertyGraphConcept? The BGL book is more up-to-date than the online-docs, so I'd look there for the final story. If you see discrepencies between the online-docs and the book, feel free to update the html to match the book. Alas, I don't have the book, so can't compare the two. ghost> Unfortunately, this description says nothing about that concept ghost> these types model. As the result, I don't know how can I ghost> use 'add_edge' and 'add_vertex' as defined in MutablePropertyGraph. ghost> ghost> Can it be clarified? Yes, that is a problem. We need some more concepts for this. If you're dealing with an adjacency_list you know that they are nested instances of the property class, but this doesn't help generic code. I'm not sure how this could be made generic... maybe if we hade a concept that covered what the property class does (BTW, a better name for the property class would be static_alist). Also, it would be good to have a notion of what copying these objects does. I agree. The type basically is a structure, which fields are not named in a regular C++ way, but are identified by type. A subscript operator can take the "tag" type and return the value (or reference to it). Lookings at the code, it seems like this is actually implemented. BTW the following code does not compile for me at the moment. Is it correct? typedef adjacency_list property > > G; vertex_property::type p; // p[vertex_edge_t()] = 10; I think the best approach would be to make this concept explicit, and independent from BGL. Something like type_indexed_container< mpl::list< pair, pair > > c; c[vertex_name_t()] = 10; I wonder if something like this already exists... I vaguely recall someone was doing that. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Errors in Boost.Graph's topological_sort
Hi Christoph,
The problem with your example is that you forgot to initialize the
vertex_index property for each vertex. Perhaps you thought that the
adjacency_list would do this for you. However, this is not the case when
using VertexList=listS. I know this is confusing, but it is stated in the
docs that there is a builtin vertex_index property when VertexList=vecS,
whereas you were using listS.
So you need to add a couple calls to "put" to fix the situation.
u = boost::add_vertex( g );
put(boost::vertex_index, g, u, 0);
v = boost::add_vertex( g );
put(boost::vertex_index, g, v, 1);
Regards,
Jeremy
P.S. You know, it isn't polite to be accusatory before you really know
what the problem is.
On Wed, 19 Dec 2002, Christoph [ISO-8859-1] Kögl wrote:
christ> Hi there,
christ>
christ> I am using 1.29.0 on a Linux PC running Mandrake 8.1, and I am using
christ> gcc-2.96 (GNU CPP version 2.96 2731 (Mandrake Linux 8.1
christ> 2.96-0.62mdk).
christ>
christ> See the following code. Topological sort has all sorts of problems with
christ> directed graphs (using adjacency lists) having two vertices and a single
christ> edge connecting them:
christ>
christ> #include
christ> #include
christ> #include
christ> #include
christ> #include
christ> #include
christ>
christ> typedef
christ> boost::adjacency_list<
christ> boost::listS
christ> , boost::listS
christ> , boost::directedS
christ> , boost::property<
christ> boost::vertex_index_t
christ> , int
christ> >
christ> >
christ> Graph;
christ>
christ> void testing( bool flip )
christ> {
christ> Graph g;
christ> Graph::vertex_descriptor u, v;
christ> u = boost::add_vertex( g );
christ> v = boost::add_vertex( g );
christ> if( flip )
christ> {
christ> boost::add_edge( v, u, g );
christ> }
christ> else
christ> {
christ> boost::add_edge( u, v, g );
christ> }
christ> std::list< Graph::vertex_descriptor > seq;
christ> try
christ> {
christ> boost::topological_sort( g, std::front_inserter( seq ) );
christ> }
christ> catch( const boost::not_a_dag & )
christ> {
christ> std::cout << "G(" << (flip ? "v, u" : "u, v") << ") not a DAG\n";
christ> }
christ> }
christ>
christ> int main( )
christ> {
christ> testing( false );
christ> testing( true );
christ> return 0;
christ> }
christ>
christ> Running this program results in the following output (slightly edited):
christ> > G(u, v) not a DAG
christ> > Speicherzugriffsfehler (German for SIGSEV)
christ> Hence u->v is not a DAG, the top. sorting routine detects a back edge.
christ> BYP?
christ> And the second call get stuck consistently at this point:
christ> template
christ> inline void put(const put_get_helper& pa, K k,
christ> const V& v)
christ> {
christ> static_cast(pa)[k] = v; // Crash occurs here.
christ> }
christ>
christ> Inverting the above function invocation sequence results in the
christ> following
christ> output:
christ> > G(u, v) not a DAG
christ> Same wrong answer, but no crash this time in testing( false ).
christ>
christ> Running only the testing( false ) call results in the same output.
christ>
christ> Boost.Graph's interfaces really appeal to me, they are very cleverly
christ> designed, but I am
christ> unable to use the current implementation in any serious project, since
christ> the above seems to
christ> point to nasty little QOI problems ... It's back to LEDA again, I
christ> suppose ...
christ>
christ> Cheers
christ>
christ> Christoph
christ>
christ> ___
christ> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
christ>
--
Jeremy Siek http://php.indiana.edu/~jsiek/
Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED]
C++ Booster (http://www.boost.org) office phone: (812) 855-3608
--
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BGL: concept docs buglets
On Wed, 29 Jan 2003, Vladimir Prus wrote: ghost> ghost> Does it mean that all MutablePropertyGraphConcept instances of docs should ghost> be renamed to LvaluePropertyGraphConcept? ghost> Yes, I think that is correct. Also, I just checked in a fix to LvaluePropertyGraphConcept in graph_concepts.hpp. Cheers, Jeremy -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"Greg Colvin" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > At 08:25 PM 1/28/2003, Edward Diener wrote: > >"Beman Dawes" <[EMAIL PROTECTED]> wrote in message > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> At 01:42 PM 1/28/2003, David B. Held wrote: > >> > >> >"Greg Colvin" <[EMAIL PROTECTED]> wrote in message > >> >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> > >> >> Also, auto_ptr is an ugly hack that needn't be replicated. > >> > > >> >Disavowing your child? ;) > >> > >> Historical note: auto_ptr<> was one of the few (maybe only) times when the > >> C++ committee as a whole overrode the recommendation of the Library > >Working > >> Group. > >> > >> Greg and other people in the LWG didn't like auto_ptr<>, preferring what is > >> now called shared_ptr<>. But we were good soldiers, and accepted the > >> committee's decision. That meant we had to develop auto_ptr<>, even though > >> we didn't like it. A lot of us still think it is a minor smart pointer, and > >> has no place in the standard, except perhaps as an adjunct to more > >> important smart pointers such as shared_ptr<> and eventually smart_ptr<>. > > > >Many people have used std::auto_ptr<> successfully to do what it does best. > >As languages and understanding evolve other, better solutions have evolved > >also, but that doesn't mean std::auto_ptr<> has not served its purpose or > >will continue to do so. > > My problem with auto_ptr isn't so much the semantics, which > have proved useful and are probably the minimum needed to > solve the problem that the committee wanted solved. And it > isn't so much the "move as copy" syntax that Howard dislikes. > And except on a personal level it isn't the politics that led > to it being the way it is. My problem is the extremely fragile > language tricks needed to implement auto_ptr, exploiting a > loophole on a loophole, which I don't think should be imitated > unless really, really necessary. I hope that in the next > standard the language can be changed in a way that makes > auto_ptr straightforward to implement. OK, but the language tricks, which I am guessing centers on auto_ptr_ref, are very well hidden from the user who understands exactly how and why a std::auto_ptr<> should be used. In that sense it is successful rather than in the sense of the difficulty of implementation itself. In other words, the basic interface to using it is clear and fairly simple unless the programmer decides not to learn it and just makes unwarranted assumptions. I have no doubt a smarter pointer, such as Boost's shared_ptr<> and/or Loki's SmartPtr<>, will be part of the next standard, for the simply reason that a smart pointer which can be used in containers is an important programming idiom. Over and above that I am sure there are other commendable goals for a smarter pointer standard library class, but whichever smarter pointers are chosen, the implementors should not take their eye off of the result that makes that smart pointer clear and fairly simple for an end-user programmer to use in its normal configuration. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [build] intel-linux problems...
Rene Rivera <[EMAIL PROTECTED]> writes: > [2003-01-27] Ronald Garcia wrote: > >> >> >>Howdy, >> >>I'm trying to use boost build with the intel c++ compiler under linux. >>My compiler is installed in /usr/local/intel, but boost build appears to >>be looking for it in /opt/intel. Is there a way to specify the compiler >>location as an option to boost build? According to the docs, the only >>parameter for intel is the compiler version, which defaults to 60. >> >>Thanks, > > Run the setup script "iccvars.sh" before running bjam. I think this one is my fault. It looks like the same problem that was recently reported for gcc-tools.jam. Rene, could you look into this? "Someone" should write down and test some rules for dealing with (and overriding) configuration variables. "Attempted fix for people who want to work with 2 versions" 1.14 (david_ab 17-Dec-02): flags intel-linux INTEL_LINUX_VERSION : $(INTEL_LINUX_VERSION) ; 1.14 (david_ab 17-Dec-02): 1.3 (david_ab 02-Jan-02): # Root directory 1.14 (david_ab 17-Dec-02): flags intel-linux INTEL_LINUX_ROOT : "/opt/intel/compiler"$(INTEL_LINUX_VERSION) ; 1.1 (david_ab 29-Nov-01): # Setup script 1.14 (david_ab 17-Dec-02): flags intel-linux INTEL_LINUX_SETUP : ". "$(INTEL_LINUX_ROOT)"/ia32/bin/iccvars.sh" ; 1.3 (david_ab 02-Jan-02): # Additional DLL directory 1.14 (david_ab 17-Dec-02): flags intel-linux INTEL_LINUX_RUN_LD_LIBRARY_PATH : $(INTEL_LINUX_ROOT)"/ia32/lib" ; -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"Peter Dimov" <[EMAIL PROTECTED]> writes: > From: "David Abrahams" <[EMAIL PROTECTED]> >> "Peter Dimov" <[EMAIL PROTECTED]> writes: >> >> > And I'm even less wrong if the sink is >> > >> > px.reset(new X); >> > >> > since "basic guarantee" here says nothing about px after the exception. > The >> > exception safety of this construct has no name, it's somewhere between > basic >> > and strong. >> >> Not sure what you expect the behavior to be in the face of an >> exception, but I can't see why you say that neither named guarantee >> applies here. > > The behavior, at least in shared_ptr's case, is that the pointer is deleted, > but there are no other effects, i.e. px is left unchanged. Then for the whole expression, "px.reset(new X)", it's the strong guarantee. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BGL: graph direction
Hi Volodya, No reason in particular for the spelling. I'm sorry it is confusing, but it is a bit late to change this now. Cheers, Jeremy P.S. In LEDA "bidirected" means something different than what "bidirectional" means in the BGL. On Wed, 29 Jan 2003, Vladimir Prus wrote: ghost> ghost> Jeremy, ghost> ghost> When declaring adjacency_list, one can specify whether graph is directed or ghost> not, using selectors ghost> ghost> directedS ghost> undirectedS ghost> ghost> and ghost> ghost> bidirectionalS ghost> ghost> No wonder I always try to type "bidirectedS" and get a compile error. ghost> Is there any reason for different naming? No sure which is correct ghost> grammatically, but "bidirected" certainly used. For example, in LEDA ghost> docs: ghost> ghost> http://www.algorithmic-solutions.info/leda_manual/graph.html ghost> ghost> (in the second section). ghost> ghost> What do you think? ghost> ghost> - Volodya -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BGL: checking for internal properties
Hi Volodya, I do this kind of checking in the BGL algorithms. Look at the function choose_param in boost/graph/named_function_params.hpp Warning: the code is pretty ugly :( Regards, Jeremy On Wed, 29 Jan 2003, Vladimir Prus wrote: ghost> ghost> Jeremy, ghost> ghost> suppose I got lazy and don't want my graph algorithm to be passed a ghost> graph which does not have internal edge_weight property. What's the ghost> best way to check? I can do ghost> ghost> get(edge_weight, g); ghost> ghost> but that causes compile error in instantination deeps. What I'd like is ghost> something like: ghost> ghost> BOOST_STATIC_ASSERT(has_property::value); ghost> ghost> Is it possible now? If not, is this a reasonable feature? ghost> ghost> - Volodya ghost> ghost> ___ ghost> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ghost> -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] MutablePropertyGraph questions
Hi Volodya, On Wed, 29 Jan 2003, Vladimir Prus wrote: ghost> ghost> Oh.. I only now realized how to use ReabablePropertyGraph concept: ghost> ghost>function_requires< ReadablePropertyGraphConcept >(); ghost> ghost> Are you suggesting that this become ghost> ghost>function_requires< EdgePropertyGraphConcept >(); ghost> ghost> and the same split done to PropertyGraphConcept and LvaluePropertyGraphConcept? I'm not so sure that change is worth it because the Edge/Vertex versions would look exactly the same except for name unless I am mistaken. ghost> I agree. The type basically is a structure, which fields are not named in a ghost> regular C++ way, but are identified by type. A subscript operator can take the ghost> "tag" type and return the value (or reference to it). Lookings at the code, ghost> it seems like this is actually implemented. ghost> BTW the following code does not compile for me at the moment. Is it correct? ghost> ghost> typedef adjacency_list property > > G; ghost> ghost> vertex_property::type p; ghost> // p[vertex_edge_t()] = 10; No, operator[] is not supported for the property class, though it is supported for property maps (I know, the naming here is a bit confusing). ghost> I think the best approach would be to make this concept explicit, and ghost> independent from BGL. Something like ghost> ghost>type_indexed_container< ghost> mpl::list< ghost> pair, ghost> pair > > c; ghost>c[vertex_name_t()] = 10; ghost> I wonder if something like this already exists... I vaguely recall ghost> someone was doing that. 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 Cheers, Jeremy -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BGL: graph direction
I'm not familiar with the details, but could there be a typedef or something like that in order to accept bidirectedS? Or maybe replacing the bidirectionalS with bidirectedS and making bidirectionalS typedef'd to bidirectedS? Jeremy Siek wrote: > > Hi Volodya, > > No reason in particular for the spelling. I'm sorry it is confusing, but > it is a bit late to change this now. > > Cheers, > Jeremy > > P.S. In LEDA "bidirected" means something different than what > "bidirectional" means in the BGL. > > On Wed, 29 Jan 2003, Vladimir Prus wrote: > ghost> > ghost> Jeremy, > ghost> > ghost> When declaring adjacency_list, one can specify whether graph is directed or > ghost> not, using selectors > ghost> > ghost> directedS > ghost> undirectedS > ghost> > ghost> and > ghost> > ghost> bidirectionalS ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] BGL: external properties
Well, external properties still confuse me. Assume I want to attach some data to vertices in adjacency_list. No problem: vector< vertex > alternative_s ; iterator_property_map< vector::iterator, property_map > alternative = ... The problem is that I have to pass alternative_s.begin() when constructig alternative, but I might want to add new vertices. In that case the iterator can be invalidated. Is there a solution to this problem, except for resorting to internal properties? - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BGL: graph direction
Jeremy Siek wrote: Hi Volodya, No reason in particular for the spelling. I'm sorry it is confusing, but it is a bit late to change this now. Jason House wrote: > I'm not familiar with the details, but could there be a typedef or > something like that in order to accept bidirectedS? > Or maybe replacing the bidirectionalS with bidirectedS and making > bidirectionalS typedef'd to bidirectedS? Hmm.. had the same thought. It might not worth the trouble to go though all documentation changing names, but OTOH hand it's not that hard with emacs :-/ P.S. In LEDA "bidirected" means something different than what "bidirectional" means in the BGL. Yea, you're right. What did you expect from a person who never used LEDA in practice? ;-) - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] How to make Boost.Test work with function objects?
Somewhere in the E.U., le 29/01/2003
Bonjour
I guess I am being denser than usual, but I just can't seem to
find the solution to the following problem:
given
boost::unit_test_framework::test_suite * test = BOOST_TEST_SUITE("");
if I have the following
template void atanh_test(){}
then I can use the following invocation
test->add(BOOST_TEST_CASE(&atanh_test));
however, if I have
template
class atanh_tester
{
public:
atanh_tester(char *)
{
}
void operator () ()
{
// whatever
}
};
how can I add a test case to "test" buit from an instance of
atanh_tester ?
Merci
Hubert Holin
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
"John Maddock" <[EMAIL PROTECTED]> wrote in message
014601c2c79c$f53f7f00$8e3687d9@1016031671">news:014601c2c79c$f53f7f00$8e3687d9@1016031671...
> > Before changing the documentation please consider the following improved
> > implemetation that overcomes ambiguity and access control issues of the
> > current is_base_and_derived implemetation (I lately posted it to
> c.l.c++.m)
>
> That's really interesting, but I can't get to work with the compilers I
have
> access to (Borland/gcc), I've attached a modified version that at least
> compiles with these compilers, but it doesn't produce the correct results:
>
> Running 1 test case...
> Platform: Cygwin
> Compiler: GNU C++ version 3.2 20020927 (prerelease)
> STL : GNU libstdc++ version 20020927
> Boost : 1.30.0
> is_base_and_derived_test.cpp(109): error in "is_base_and_derived": The
> [...]
> Test suite "Type Traits" failed with:
> 15 assertions out of 20 passed
> 5 assertions out of 20 failed
>
> Test case "is_base_and_derived" failed with:
> 15 assertions out of 20 passed
>5 assertions out of 20 failed
>
>
> Any ideas, or results from other compilers?
I tried to complie the code you attached (with boost 1.29.0) but some files
were missing (test.hpp, check_integral_constant.hpp,
TYPE_TRAITS(is_base_and_derived)).
As mentioned in the c.l.c++.m posting (http://tinyurl.com/51a5) I complied
the original code with Comeau C/C++ 4.3.0.1 and VC7.1 beta.
I was able to complie the attached code (with minor improvment) using strict
Comeau and VC7.1 and boost 1.29.0.
Rani
begin 666 is_base_and_derived2.hpp
M#0HO+R H0RD@0V]P>7)I9VAT(%-T979E($-L96%R>2P@0F5M86X@1&%W97,L
M($AO=V%R9"!(:6YN86YT("8@2F]H;B!-861D;V-K(#(P,# N#0HO+R!097)M
M:7-S:6]N('1O(&-O<'DL('5S92P@;6]D:69Y+"!S96QL(&%N9"!D:7-T7)I9VAT(&YO=&EC92!A<'!E87)S(&EN(&%L;"!C;W!I97,N(%1H
M:7,@2!F;W(@86YY('!U7!E7W1R86ETPT*#0IT96UP
M;&%T92 \='EP96YA;64@0F%S92P@='EP96YA;64@1&5R:79E9#X-"G-T7!E('EE7!E9&5F(#HZ8F]O7!E("!N
M;SL-"@T*(" @('1E;7!L871E/'1Y<&5N86UE(%0^#0H@(" @65S*0T*(" @("D[#0I].PT*#0IT96UP;&%T92 \='EP96YA;64@0F%S
M92P@='EP96YA;64@1&5R:79E9#X-"G-T7!E;F%M92!"87-E+'1Y<&5N86UE($1E7!E;F%M92!$97)I=F5D
M+&ES7V)AWT[#0IS=')U8W0@0C(@.B!"('M].PT*7!E9&5F(&-H87(@5&5S=%LA:7-?8F%S95]A;F1?9&5R:79E9#Q$
6+$0^.CIV86QU95T[#0H-"BHO#0H-"@``
`
end
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] MutablePropertyGraph questions
Jeremy, On Wed, 29 Jan 2003, Vladimir Prus wrote: ghost> ghost> Oh.. I only now realized how to use ReabablePropertyGraph concept: ghost> ghost>function_requires< ReadablePropertyGraphConcept >(); ghost> ghost> Are you suggesting that this become ghost> ghost>function_requires< EdgePropertyGraphConcept >(); ghost> ghost> and the same split done to PropertyGraphConcept and LvaluePropertyGraphConcept? I'm not so sure that change is worth it because the Edge/Vertex versions would look exactly the same except for name unless I am mistaken. 1. I think one of them will look for a property in edge_property and another in vertex_property 2. Why do you think that MutablePropertyGraph *should* be split? ghost> I agree. The type basically is a structure, which fields are not named in a ghost> regular C++ way, but are identified by type. A subscript operator can take the ghost> "tag" type and return the value (or reference to it). Lookings at the code, ghost> it seems like this is actually implemented. ghost> BTW the following code does not compile for me at the moment. Is it correct? ghost> ghost> typedef adjacency_list property > > G; ghost> ghost> vertex_property::type p; ghost> // p[vertex_edge_t()] = 10; No, operator[] is not supported for the property class, though it is supported for property maps (I know, the naming here is a bit confusing). 1. In fact, it fails to compile with the last line *commented*. There's something wrong with the second one. 2. The question is whether operator[] should be supported. So far, the only way edge_property::type can be used is by passing it to new_edge function -- i.e. to duplicate properties of an existing edge. ghost> I think the best approach would be to make this concept explicit, and ghost> independent from BGL. Something like ghost> ghost>type_indexed_container< ghost> mpl::list< ghost> pair, ghost> pair > > c; ghost>c[vertex_name_t()] = 10; ghost> I wonder if something like this already exists... I vaguely recall ghost> someone was doing that. 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 Thanks for the link. That's what I meant, indeed. Do you think that such container can be used in BGL properties implementation, when available? BTW, I think I like mpl::list-based syntax better than chaining of types... - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost.threads: Thread pool
"William E. Kempf" wrote: > > [Michel André] > > Another question i noted that in the current boost CVS the boost.thread > > only builds a dll version of the library and no static ones, in earlier > > release you only needed the dll when using tss? Is it supposed to be > > that way? > > Yes. It vastly simplifies the build process (now that we have a working > DLL implementation), and is the version most users have been asking for > any way. I did expect to get some static about this, so let the debate > begin. ;) Note, however, that it will be a little problematic to continue > with a build process that provides both a forms, and that the > threadmon.dll has been the source of a lot of confusion for users, so > there will have to be very compelling reasons to bring this build type > back. OK, here's some static!! As you know from an earlier thread I aim to finally investigate boost::thread this week (as a largely drop-in replacement for our compiler vendor-supplied thread library) A static build is important to us, as we have found many support/development issues simply vanish with a static build. We would be very reluctant to move to a system requiring such a .dll, especially if it means using the dynamic RTL with our compiler (as that is where we generally hit the problems above) I am also unsure how a standard proposal might look if we can only say 'the dynamic library version works well, but we have problems with the static' although I have no experience of the committee to be sure. I would give me pause for thought. What problems does the static build bring? Would it be useful for someone who does care about static builds ( thinking of no-one in particular ) to look after the issue? -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Deadline for the Standard Library TechnicalReport
"Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > More accurately, there are *two* notions being considered: > >1) typedef template; >2) template aliasing -- the thingy Andrei is missing. Could you clue us in on the current consensus? You would still express 2) using template typedefs, right? Is it possible or likely that the proposal will be altered to be more inclusive? Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Deadline for the Standard Library TechnicalReport
David Abrahams <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | > David Abrahams <[EMAIL PROTECTED]> writes: | > | > | "David B. Held" <[EMAIL PROTECTED]> writes: | > | | > | > "Peter Dimov" <[EMAIL PROTECTED]> wrote in message | > | > 000d01c2c6f3$85038c30$1d00a8c0@pdimov2">news:000d01c2c6f3$85038c30$1d00a8c0@pdimov2... | > | >> [...] | > | >> By the way, the current typedef template proposal prohibits deduction; | > | >> this makes it less attractive for creating subpointers. | > | > | > | > Ouch! Is this due to complexity issues, or was it just not deemed useful?? | > | | > | It's hard to say why, exactly, but my sense of it was that it was done | > | because it was easy to specify semantics that were identical to those | > | of the existing metafunction-form workaround. | > | > My recollection is a little different :-) | | Are you planning to grace us with the contents of your memory, Gaby, | or are you gonna hold us in suspense forever? :-) Well, my impression wans't that it was done that "way because it was easy to specify semantics that were identical to those of the existing metafunction-form workaround". We started with looking at both possibilities (I believe you'll agree), and I can't recall why, it was suddenly assumed that both forms are exclusive and we started looking at things we could do with the non-deduction possibility. Someone (I think Herb) asked some questions to make sure that we understodd what we were chosing not to have. Francis distinguishly and continuously raised several arguments against the trend. But at no time, it was question to see whether the other way was difficult. I even seem to recall that John Spicer attempted to make cases for the "template aliasing" form. -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [build] intel-linux problems...
[2003-01-29] David Abrahams wrote: >Rene Rivera <[EMAIL PROTECTED]> writes: > >> [2003-01-27] Ronald Garcia wrote: >> >>> >>> >>>Howdy, >>> >>>I'm trying to use boost build with the intel c++ compiler under linux. >>>My compiler is installed in /usr/local/intel, but boost build appears to >>>be looking for it in /opt/intel. Is there a way to specify the compiler >>>location as an option to boost build? According to the docs, the only >>>parameter for intel is the compiler version, which defaults to 60. >>> >>>Thanks, >> >> Run the setup script "iccvars.sh" before running bjam. > >I think this one is my fault. It looks like the same problem that was >recently reported for gcc-tools.jam. Rene, could you look into this? >"Someone" should write down and test some rules for dealing with (and >overriding) configuration variables. > >"Attempted fix for people who want to work with 2 versions" > >1.14 (david_ab 17-Dec-02): flags intel-linux INTEL_LINUX_VERSION : >$(INTEL_LINUX_VERSION) ; >1.14 (david_ab 17-Dec-02): >1.3 (david_ab 02-Jan-02): # Root directory >1.14 (david_ab 17-Dec-02): flags intel-linux INTEL_LINUX_ROOT : >"/opt/intel/compiler"$(INTEL_LINUX_VERSION) ; >1.1 (david_ab 29-Nov-01): # Setup script >1.14 (david_ab 17-Dec-02): flags intel-linux INTEL_LINUX_SETUP : ". >"$(INTEL_LINUX_ROOT)"/ia32/bin/iccvars.sh" ; >1.3 (david_ab 02-Jan-02): # Additional DLL directory >1.14 (david_ab 17-Dec-02): flags intel-linux INTEL_LINUX_RUN_LD_LIBRARY_PATH : >$(INTEL_LINUX_ROOT)"/ia32/lib" ; Nope, not your fault, nor mine ;-) I happen to have recently installed the intel 7 compiler and here's the problem. The iccvars.sh script in it no longer sets "IA32ROOT" which is how we are detecting if the script was used already. It seems the only "solution" now is to support a way of setting the root, as in document INTEL_LINUX_ROOT and make it work. Any other ideas? -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Maddock wrote: | | The LWG suggested (and I agreed with) a change to "is_base". To me this is a bad idea, from a usability point of view. I strongly object against making this change. The argument ordering is perfectly obvious in is_base_and_derived, there is no such hint in is_base. Just my 2c Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+N+dk0ds/gS3XsBoRAtD6AJwIvNqyKNwqGPMp0yKnm+AtG/dTDwCfRMjx PvxWiOpHeLVmyCCXu2No6uQ= =x9Oo -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost.threads: Thread pool
Alisdair Meredith said: > "William E. Kempf" wrote: > >> > [Michel André] >> > Another question i noted that in the current boost CVS the >> boost.thread only builds a dll version of the library and no static >> ones, in earlier release you only needed the dll when using tss? Is >> it supposed to be that way? >> >> Yes. It vastly simplifies the build process (now that we have a >> working DLL implementation), and is the version most users have been >> asking for any way. I did expect to get some static about this, so >> let the debate begin. ;) Note, however, that it will be a little >> problematic to continue with a build process that provides both a >> forms, and that the >> threadmon.dll has been the source of a lot of confusion for users, so >> there will have to be very compelling reasons to bring this build type >> back. > > OK, here's some static!! > > As you know from an earlier thread I aim to finally investigate > boost::thread this week (as a largely drop-in replacement for our > compiler vendor-supplied thread library) A static build is important to > us, as we have found many support/development issues simply vanish with > a static build. We would be very reluctant to move to a system > requiring such a .dll, especially if it means using the dynamic RTL with > our compiler (as that is where we generally hit the problems above) OK, but remember that this has always been a requirement on Windows platforms any way (well, technically you could get by with out the threadmon.dll if you used no thread_specific_ptr<> instances, but this ability may disappear shortly any way, as the implementation will have to use TSS data, and the only way to clean up such data on Win32 platforms is by hooking into DllMain). Knowing this, do you still feel as strongly? If so, I'll listen, but I'm not sure I'll have much choice here in the long run. > I am also unsure how a standard proposal might look if we can only say > 'the dynamic library version works well, but we have problems with the > static' although I have no experience of the committee to be sure. I > would give me pause for thought. Well, if the library becomes part of the standard, I would expect that MS would have to do something about this glaring hole in the Win32 API (and fixing this would be trivial for MS). (And yes, I realize that a C++ standard technically has no bearing on MS C API, but I also believe that they'd respond to public pressure on this one.) On the Win32 platform today you have three choices (one of which isn't always an option): explicitly delete the TSS data before a thread ends (which is only an option when you control the creation of all threads that access the TSS slot), hook into DllMain, or leak memory. > What problems does the static build bring? Would it be useful for > someone who does care about static builds ( thinking of no-one in > particular ) to look after the issue? I think I outlined the problem above well enough for you to understand the issue, but if I need to give more detail, just ask. Other than the DllMain hook, the only solution I've been able to come up with is to stub the call to CreateThread, but this has many complications of its own, and may still leak memory if any threads were created before the stub was put in place. An unlikely corner case, maybe, but still certainly possible (especially for library developers), so I rejected this alternate solution. I've asked some contacts at MS for alternative solutions, but none have been provided to me. If you, or anyone else, can find a better solution I'd be greatly appreciative, but I fear that there is no other solution available. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: SmartPtr (Loki) - auto_ptr/move c'torissue
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > I was half-joking. Imagine you used an auto_ptr in the > implementation of SmartPtr<>. > [...] Well, help me reason this out anyway, because this is a gray area for me. We would have to put the auto_ptr<> in a StoragePolicy (otherwise, you defeat the point of PBD), and then we would have to make sure that the StoragePolicy was the first member to get initialized, right? Then we would have to guarantee that StoragePolicy is no-throw, or we defeat the whole purpose of this little game, right? That means that StoragePolicy() will always succeed, and thus, the StoragePolicy sub-object will be fully constructed before any of the other policy constructors are called? Then, if one of the other c'tors does throw, the StoragePolicy d'tor will get called, even though the SmartPtr is not fully constructed, and that will clean up the resource? Or am I missing something? It seems that the function try block is slightly more powerful, because it does not require StoragePolicy() to be no-throw. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Deadline for the Standard Library TechnicalReport
David Abrahams <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | > "David B. Held" <[EMAIL PROTECTED]> writes: | > | > | "Beman Dawes" <[EMAIL PROTECTED]> wrote in message | > | [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... | > | > [...] | > | > Anyone interested might want to read the actual proposal. See | > | > http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1406.pdf | > | | > | Yes, I found that on my own, and noticed that of the two "mutually | > | exclusive designs", the one with one feature was chosen over the | > | one with three features. | > | > In fact, these notions are not mutually exclusive. There was a debate | > to that effect on the committee reflectors, recently. | | Was it on "-core" or did I miss it somehow? See c++std-ext-5658 and the whole thread that followed. In fact, you didn't miss it: You were the first person to reply... with the usual reaction ;-] -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
>From: "John Maddock" <[EMAIL PROTECTED]>
> > Before changing the documentation please consider the following improved
> > implemetation that overcomes ambiguity and access control issues of the
> > current is_base_and_derived implemetation (I lately posted it to
> c.l.c++.m)
>
> That's really interesting, but I can't get to work with the compilers I
have
> access to (Borland/gcc), I've attached a modified version that at least
> compiles with these compilers, but it doesn't produce the correct results:
The following version works on g++ for the same cases that the current
is_base_and_derived works (i.e. excluding multiple bases, and
private/protected inheritance), and gives an error in the cases it doesn't
work, while it works completely on the compilers that supports this (such as
Comeau C++ and Intel C++ 6/7). In other words, it "degrades gracefully", and
breaks noisily, if the compiler doesn't support the extra cases. This is
tested on Comeau 4.3, Intel C++ 6/7 and g++ 3.2.
You could get the same effect with #ifdef between Rani's original version,
and the current Boost version, but the following version makes the #ifdef
unnecessary.
template
struct helper
{
template
static char check(D const volatile &, T);
static char (& check(B const volatile &, int))[2];
struct C
{
operator B const volatile &() const;
operator D const volatile &();
};
static C getC();
};
template
struct is_base_and_derived
{
static const bool result =
sizeof(helper::check(helper::getC(), 0)) == 1;
};
// If strict interpretation, i.e. not its own base class
template
struct is_base_and_derived
{
static const bool result = false;
};
struct B {};
struct B1 : B {};
struct B2 : B {};
struct D : B1, private B2 {};
struct BV1 : virtual B {};
struct BV2 : virtual B {};
struct DV : BV1, BV2 {};
// g++ doesn't like multiple definitions of the same typedef, therefore they
have different names
typedef char TestA[is_base_and_derived::result]; // Multiple bases
(error on g++)
typedef char TestB[is_base_and_derived::result];
typedef char TestC[is_base_and_derived::result]; // Private base
(error on g++)
typedef char TestD[!is_base_and_derived::result];
typedef char TestE[!is_base_and_derived::result];
typedef char TestF[is_base_and_derived::result]; // Virtual base
int main()
{
}
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
00aa01c2c791$7df10cd0$1d00a8c0@pdimov2">news:00aa01c2c791$7df10cd0$1d00a8c0@pdimov2...
> [...]
> To be honest, I don't know. The design is quite complicated, and I
> don't have the time to study it in-depth. I'm not sure how this interacts
> with stored_type being a smart pointer that owns the object.
Hmm...that's also an interesting point, since one of design rationales was
to make it possible to implement a SmartPtr in terms of a SmartPtr.
> See also:
>
> friend inline void release(this_type& sp, stored_type& p)
> {
> checking_policy::on_release(storage_policy::storage());
> p = get_impl_ref(sp);
> get_impl_ref(sp) = storage_policy::default_value();
> ownership_policy& op = sp;
> op = ownership_policy();
> }
>
> I'm not sure whether this works as intended if ownership_policy()
> throws.
Also a good point. I should document that
storage_policy::default_value() must be no-throw to get the basic
guarantee from release(). That is probably more advisable than trying
to make it safe for default_value() to throw. In fact, this code is not
correct at all, given the current definition of ref_counted. In particular,
ref_counted does not define an operator=, which means that the old
count is leaked. Since the default c'tor allocates a new count, it
could most certainly throw. It seems wasteful to delete then new
the count. Perhaps ref_counted should have a reset() function for
this case. Then we could mandate that it be no-throw (which seems
reasonable).
> [...]
> How often do people write pointers that use the auto_ptr_ref trick?
Ok, not very often.
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Usability of http://boost.sourceforge.net/regression-logs
Hi, This is a minor complaint about the wonderful automatically generated page at http://boost.sourceforge.net/regression-logs/, and perhaps also which tables we're generating and how we're generating them. When I'm interested in finding out how a library is performing on a given platform, I tend to go to the compilers column and click a link, expecting to see a table of results for that compiler. Of course, it takes me to the vendor's page instead. I can't tell you how many times I've made this mistake. It seems to me that while lib developers may be interested in the "big table", most users, unless they care extraordinarily about portability, will want to know about individual compiler results. I wonder if we shouldn't be assembling the HTML on-the-fly for all tables, and just having testers upload jam logs? I know this goes against the grain of Beman's desire to produce the HTML with C++ code because of CGI portability issue, but I have the sense that until we have a true portable C++ virtual machine this might be the wrong kind of job for our favorite language. -Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Re: SmartPtr (Loki) - auto_ptr/movec'tor issue
"David B. Held" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> [...] >> I was half-joking. Imagine you used an auto_ptr in the >> implementation of SmartPtr<>. >> [...] > > Well, help me reason this out anyway, because this is a gray area for me. > We would have to put the auto_ptr<> in a StoragePolicy (otherwise, > you defeat the point of PBD), I'll take your word for that. > and then we would have to make sure that the StoragePolicy was the > first member to get initialized, right? Yeah, sounds right. > Then we would have to guarantee that StoragePolicy is no-throw, or > we defeat the whole purpose of this little game, right? Hmm, no. The contract would have to be that if StoragePolicy throws an exception, it frees the resource passed as its constructor argument. There's nothing wrong with a requirement like that in principle. > That means that StoragePolicy() will always succeed, and thus, the > StoragePolicy sub-object will be fully constructed before any of the > other policy constructors are called? "Mu" (ask Terje to explain) > Then, if one of the other c'tors does throw, the StoragePolicy d'tor > will get called, even though the SmartPtr is not fully constructed, > and that will clean up the resource? Or am I missing something? A little, but you mostly got the picture right. > It seems that the function try block is slightly more powerful, > because it does not require StoragePolicy() to be no-throw. Yes and no. 1. Aren't function try blocks somewhat non-portable in practice? 2. Isn't it onky the StoragePolicy that knows how to free the resource? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Deadline for the Standard Library TechnicalReport
"David B. Held" <[EMAIL PROTECTED]> writes: | "Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message | [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... | > [...] | > More accurately, there are *two* notions being considered: | > | >1) typedef template; | >2) template aliasing -- the thingy Andrei is missing. | | Could you clue us in on the current consensus? There is no formal vote about these thingies yet. | You would still express 2) using template typedefs, right? Not really. A (very convincing) argument made by Daveed Vandevoorde is to get rid of the keyword "typedef" when one talks about "template aliasing" because that does not introduce any type-name: Rather it introduces a template-name, synonymous for a family of type-names. You may say template Vec = std::vector >; | Is it possible or likely that the | proposal | will be altered to be more inclusive? Oh well, I believe we're very far from any actual definitive form of "template typedef" or "template aliasing". -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > Hmm, no. The contract would have to be that if StoragePolicy > throws an exception, it frees the resource passed as its constructor > argument. There's nothing wrong with a requirement like that in > principle. I see. We don't need StoragePolicy to be constructed. We just need it to be constructed before everything else. Makes sense. > [...] > > It seems that the function try block is slightly more powerful, > > because it does not require StoragePolicy() to be no-throw. > > Yes and no. > > 1. Aren't function try blocks somewhat non-portable in practice? Are they? You mean because they aren't implemented well? > 2. Isn't it only the StoragePolicy that knows how to free the > resource? Hmm...technically yes. If the StoragePolicy were fully constructed, you could ask it to free the resource. But then you're requiring it to be no-throw to begin with. So it seems that they give you nothing, as usual. ;) Unfortunately, neither does a managed pointer in the StoragePolicy. Sure, it frees the resource in the presence of exceptions, but it also frees it in the absence of exceptions, which is quite too often. Namely, it doesn't know when it *shouldn't* free the resource, because it doesn't know about Ownership. So now it looks like we're back to that pesky function try-block, and requiring StoragePolicy to be no-throw. :( Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] How to make Boost.Test work with function objects?
>template
>class atanh_tester
>{
>public:
> atanh_tester(char *)
> {
> }
>
> void operator () ()
> {
> // whatever
> }
>};
>
> how can I add a test case to "test" buit from an instance of
> atanh_tester ?
Use unit_test_suite_ex.hpp. It allows to supply boost::function0 as a
test case.
See unit_test_suite_ex_test.cpp for example.
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Deadline for the Standard Library TechnicalReport
"Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > There is no formal vote about these thingies yet. Well, I just wanted to know what the most popular opinion was, and you give some interesting info here. > [...] > template >Vec = std::vector >; This looks cool! Is someone going to write a proposal for this before April? Or does this type of change not get considered at that time? > [...] > Oh well, I believe we're very far from any actual definitive form of > "template typedef" or "template aliasing". Well, I thought Herb's proposal was more or less "definitive". Is that not what's likely to be presented to the committee? If we got template aliasing as you describe above, then Herb's proposal is just fine with me. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David B. Held" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> [...] >> Hmm, no. The contract would have to be that if StoragePolicy >> throws an exception, it frees the resource passed as its constructor >> argument. There's nothing wrong with a requirement like that in >> principle. > > I see. We don't need StoragePolicy to be constructed. We just need > it to be constructed before everything else. Makes sense. > >> [...] >> > It seems that the function try block is slightly more powerful, >> > because it does not require StoragePolicy() to be no-throw. >> >> Yes and no. >> >> 1. Aren't function try blocks somewhat non-portable in practice? > > Are they? You mean because they aren't implemented well? s/well/at all/ in some cases IIRC. >> 2. Isn't it only the StoragePolicy that knows how to free the >> resource? > > Hmm...technically yes. If the StoragePolicy were fully constructed, > you could ask it to free the resource. But then you're requiring it > to be no-throw to begin with. So it seems that they give you > nothing, as usual. ;) "They" meaning function-try-blocks? The rule I have stuck in my head from the last time I considered this was: all they give you is the ability to translate the exception into some other exception. I never thought that was a particularly valuable thing to do in most cases. > Unfortunately, neither does a managed pointer in the StoragePolicy. > Sure, it frees the resource in the presence of exceptions, but it > also frees it in the absence of exceptions, Huh? No way. If it were a member of the StoragePolicy, it wouldn't be a problem. But I'm not seriously suggesting that you do this, because it still wouldn't be freed according to the StoragePolicy if you used, e.g. auto_ptr. > which is quite too often. Namely, it doesn't know when it > *shouldn't* free the resource, because it doesn't know about > Ownership. So now it looks like we're back to that pesky function > try-block, and requiring StoragePolicy to be no-throw. :( I can't agree with your conclusion. IMO the right answer is that StoragePolicy promises to free the resource it's initialized with when construction fails. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Deadline for the Standard Library TechnicalReport
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > See c++std-ext-5658 and the whole thread that followed. In fact, you > didn't miss it: You were the first person to reply... with the usual > reaction ;-] OK, I remember now. It's probably time to bring the issue up again, since the conversation seems to have dissolved quickly. I'd especially like to see more discussion of the template alias idea, since I have a very clear idea of the implications of the other one and tend to agree with Peter that it doesn't add much that we don't already have. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > "They" meaning function-try-blocks? Yes. > The rule I have stuck in my head from the last time I considered this > was: all they give you is the ability to translate the exception into > some other exception. I never thought that was a particularly > valuable thing to do in most cases. So I've heard. > [...] > > which is quite too often. Namely, it doesn't know when it > > *shouldn't* free the resource, because it doesn't know about > > Ownership. So now it looks like we're back to that pesky function > > try-block, and requiring StoragePolicy to be no-throw. :( > > I can't agree with your conclusion. IMO the right answer is that > StoragePolicy promises to free the resource it's initialized with when > construction fails. Unfortunately, StoragePolicy doesn't know when other c'tors have failed. The only one who does is smart_ptr, which is why it seems I have to either A) use a function try block to inform StoragePolicy that someone else has failed, and clean up appropriately, or B) not use initializer lists, and do all the work in the c'tor body of smart_ptr. It seems to me that neither is a particularly attractive alternative, although, I see that shared_count goes by way of B). Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Deadline for the Standard Library TechnicalReport
>From: "David B. Held" <[EMAIL PROTECTED]> > "Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > [...] > > There is no formal vote about these thingies yet. > > Well, I just wanted to know what the most popular opinion was, > and you give some interesting info here. > > > [...] > > template > >Vec = std::vector >; > > This looks cool! Is someone going to write a proposal for this before > April? Or does this type of change not get considered at that time? > > > [...] > > Oh well, I believe we're very far from any actual definitive form of > > "template typedef" or "template aliasing". > > Well, I thought Herb's proposal was more or less "definitive". Is that > not what's likely to be presented to the committee? If we got template > aliasing as you describe above, then Herb's proposal is just fine with > me. Yeah. It's probably hard to perform deduction in the presence of specialisations. If that turns out very hard or impossible, then having a specialisable (non-deducible) template typedef, and deducible template aliasing, might mean that we could have our cake and eat it, too. :) Thus, we could have the benefits of specialisation, for example (from the proposal): template typedef int int_exact; template<> typedef char int_exact<8>; template<> typedef short int_exact<16>; // ... template typedef T remove_const; template typedef T remove_const; As well as deducability (using the example above): template Vec = std::vector >; template void f(std::vector); f(Vec); // Deduces T=int and A=MyAlloc As well as, of course: template some_pointer = smart_ptr Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David B. Held" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> [...] >> "They" meaning function-try-blocks? > > Yes. > >> The rule I have stuck in my head from the last time I considered this >> was: all they give you is the ability to translate the exception into >> some other exception. I never thought that was a particularly >> valuable thing to do in most cases. > > So I've heard. > >> [...] >> > which is quite too often. Namely, it doesn't know when it >> > *shouldn't* free the resource, because it doesn't know about >> > Ownership. So now it looks like we're back to that pesky function >> > try-block, and requiring StoragePolicy to be no-throw. :( >> >> I can't agree with your conclusion. IMO the right answer is that >> StoragePolicy promises to free the resource it's initialized with when >> construction fails. > > Unfortunately, StoragePolicy doesn't know when other c'tors have > failed. The only one who does is smart_ptr, which is why it seems > I have to either A) use a function try block to inform StoragePolicy > that someone else has failed, and clean up appropriately, Why not just arrange for StoragePolicy to be the first constructed? > or B) not use initializer lists, and do all the work in the c'tor > body of smart_ptr. I don't see how B can work; the resource will be unmanaged at least until the body is entered, while all the bases and members are constructed. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] shifted_ptr<> optimized
Pointers to polymorphic objects was optimized a little: http://groups.yahoo.com/group/boost/files/shifted_ptr.zip Philippe A. Bouchard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shifted_ptr<> w/ lock mechanism
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > Lock mechanism was added to shifted_ptr<>: > http://groups.yahoo.com/group/boost/files/shifted_ptr.zip > > Benchmarks are also updated. Still shifted_ptr<> is using less memory and > twice faster for reconstruction time. Almost. > Notes: > - The first memory map report is not precise (shifted_ptr). > - The reports were reordered (shifted_ptr, shifted_ptr & > shared_ptr). > > I believe there is not that much left to do besides optimizations. Have you tried a comparison against a shared_ptr using an optimized count allocator? Nobody has invested as much effort in optimizing shared_ptr as you are pouring into shifted_ptr, but an experiment I did years ago made a huge difference in the efficiency of shared_ptr just by implementing a crude allocator for count objects (took me about 10 minutes to code up). For me to find shifted_ptr convincing I'd have to see a noticeable performance improvement over using an optimized count allocator with shared_ptr. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] libs/config/configure as shipped in CVS is broken
John Levon <[EMAIL PROTECTED]> writes: > The generated script contains the lines : > > # add the -AA conformance option to CXXFLAGS for HP aCC only > if test $CXX = 'aCC' >CXXFLAGS="-AA $CXXFLAGS" > fi > > This fails under "sh configure". Changing to : > > if test $CXX = 'aCC'; then >CXXFLAGS="-AA $CXXFLAGS" > fi > > fixes it Patched, thanks! > -- > "What *is* your fascination with my forbidden closet of mystery ?" > - Chief Wiggum "That's some nice flutin' ralphie"-ly y'rs, Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] BOOST_PP_XX_INCCLUDE
On Mon, 27 Jan 2003 12:42:14 -0800, "Paul Mensonides" <[EMAIL PROTECTED]> wrote: > #define BOOST_PP_HEADERS \ > (...), /* i.e. "no path" */ \ > (iostream)(fstream)(vector)(string) \ > (map)(cstdlib)(sstream) \ > /**/ > > ??=include BOOST_PP_ANGLED_INCLUDE() > > effectively does this: > > #include > #include > #include > #include > #include > #include > #include Looks good to me. > > The other problem that I have when using this is that it removes > > dependencies for the build process. To solve this, the files can > > be preprocess. Is there a standard toolset/method for preprocessing > > header files ? > > I'm not sure what you mean here. I would like to take a file that uses BOOST_PP_HEADERS, say > #define BOOST_PP_HEADERS \ > (...), /* i.e. "no path" */ \ > (iostream)(fstream)(vector)(string) \ > (map)(cstdlib)(sstream) \ > /**/ > > ??=include BOOST_PP_ANGLED_INCLUDE() and preprocess it to generate the file that says > #include > #include > #include > #include > #include > #include > #include > You can simply make a source file that includes all the files that you want > to pre-preprocess (if that is what your getting at), run it through your > compiler's preprocessor, and then include the result file. I don't think bjam supports just running the preprocessor, but as you say the poblem is more tricky; I would like to stop preprocessing at a certain include depth. > but this is outside the scope of the pp-lib can automate because it > requires a separate build step to produce the preprocessor equivalent of a > "pre-compiled header." I didn't mean to imply it was within scope. I know MPL does preprocessing using python, but I don't know how reuseable that code is, so I was just hunting for tips, suggestions and pointers. Thanks for your help. Look forward to seeing BOOST_PP_INCLUDE when you have time. Hugo ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Review Request: shifted_ptr<>
Greeting, I would like to request a formal review for my library: shifted_ptr. It consists of a smart pointer optimizing dynamic memory allocations and deallocations on the heap, thus lower requirement on the memory map and faster execution. It is accessible at: http://groups.yahoo.com/group/boost/files/shifted_ptr.zip. The main documentation & rationale is found in /shifted_ptr/doc/structboost_1_1shifted__ptr.html. Regards, Philippe A. Bouchard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > [...]
> > Unfortunately, StoragePolicy doesn't know when other c'tors have
> > failed. The only one who does is smart_ptr, which is why it seems
> > I have to either A) use a function try block to inform StoragePolicy
> > that someone else has failed, and clean up appropriately,
>
> Why not just arrange for StoragePolicy to be the first constructed?
smart_ptr(T* p)
: storage(p), ownership(p), conversion(), checking()
{ ... }
Suppose storage(p) succeeds, but ownership(p) throws (such as while
allocating a count). You can't rely on ~storage() to do cleanup, because
storage doesn't know what the ownership strategy is. It only knows
about storage. Here's what ~smart_ptr() looks like:
~smart_ptr()
{
if (ownership_policy::release(get_impl(*this)))
{
storage_policy::destroy();
}
}
So you see, storage_policy must be told when to do cleanup by
smart_ptr (that's the principle of orthogonal policies). It's easy
enough to write storage_policy::storage_policy(T* p) to clean up
after itself if *it* throws. But getting it to clean up after *another*
policy is the trick. Obviously, if one of the other c'tors throws,
~smart_ptr() never gets called, so how do we tell storage_policy
that a failure occurred, and it needs to clean up? The only way I
can see is to use a function try block:
smart_ptr(T* p)
try
: storage_policy(p), ownership(p), conversion(), checking()
{ ... }
catch
{
storage_policy::destroy();
}
Unfortunately, that's totally Greek to bcc 5.5 (and probably vc++,
though I don't have access to it right now), not to mention that it
requires storage_policy(p) to be no-throw.
> > or B) not use initializer lists, and do all the work in the c'tor
> > body of smart_ptr.
>
> I don't see how B can work; the resource will be unmanaged at
> least until the body is entered, while all the bases and members
> are constructed.
That can only work if the default c'tors are no-throw, which would
mean special-casing ref_counted to not allocate a count until it
actually receives a pointer. But it would also make the rest of the
functions in ref_counted bulkier because now you have to detect a
null count pointer. Otherwise, you would have to set the count
pointer to null, and have the body of smart_ptr ask ref_counted if
he was built properly. Quite messy. I don't see any nice solutions
to this problem.
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_PP_XX_INCCLUDE
Hugo Duncan <[EMAIL PROTECTED]> writes: >> #include >> #include >> #include >> #include >> #include >> #include >> #include > >> You can simply make a source file that includes all the files that you want >> to pre-preprocess (if that is what your getting at), run it through your >> compiler's preprocessor, and then include the result file. > > I don't think bjam supports just running the preprocessor, but as you say > the poblem is more tricky; I would like to stop preprocessing at a certain > include depth. bjam doesn't support running the PP as part of the build process. However, it is possible to build in "arbitrary" parsing rules for processing includes. You could train it to recognize these BOOST_PP_ constructs. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] ublas bug(?): sparse_matrix and matrix_row
Hi Julius,
you wrote:
> to me it looks like there may be a bug with sparse_matrix and matrix_row.
> I was building a large sparse matrix from some smaller ones. When I tried
to assign a
> matrix_row of a sparse_matrix to another matrix_row of another
sparse_matrix, nothing > happened. When I mix sparse_matrix with matrix, it
works as I expected, but then the
> sparse matrix isn't sparse anymore.
>
> I tried this with the following code:
>
> void SparseBug()
>{
>using namespace boost::numeric;
>typedef ublas::sparse_matrix TSM;
>typedef ublas::matrix TM;
>TSM sm1(3,3);
>TSM sm2(3,3);
>TM m1(3,3);
>TM m2(3,3);
>sm1(1,1) = m1(1,1) = 2.;
>ublas::matrix_row (sm2,1) = ublas::matrix_row (sm1,1);
>ublas::matrix_row (m2,1) = ublas::matrix_row (m1,1);
>std::cout << "matrix=matrix: m2(1,1) should be " << m1(1,1) << ",
is "<< m2(1,1) > << std::endl;
> std::cout << "sparse_matrix=sparse_matrix: sm2(1,1) should be " <<
sm1(1,1) << > ", is "<< sm2(1,1) << std::endl;
> ublas::matrix_row (sm2,1) = ublas::matrix_row (m1,1);
> std::cout << "sparse_matrix=matrix: sm2(1,1) should be " <<
m1(1,1) << ", is "<< > sm2(1,1) << std::endl;
> ublas::matrix_row (m2,1) = ublas::matrix_row (sm1,1);
> std::cout << "matrix=sparse_matrix: m2(1,1) should be " <<
sm1(1,1) << ", is "<< > m2(1,1) << std::endl;
> };
>
> and got
>
> matrix=matrix: m2(1,1) should be 2, is 2
> sparse_matrix=sparse_matrix: sm2(1,1) should be 2, is 0
> sparse_matrix=matrix: sm2(1,1) should be 2, is 2
> matrix=sparse_matrix: m2(1,1) should be 2, is 2
>
> on my Win2000 SP3 machine with Microsoft VC++.net in debug mode.
>
> Has anyone an idea?
I just fed this into GCC 3.2.1 and got the following results with my current
version (in debug & release mode):
matrix=matrix: m2(1,1) should be 2,is 2
sparse_matrix=sparse_matrix: sm2(1,1) should be 2, is 2
sparse_matrix=matrix: sm2(1,1) should be 2, is 2
matrix=sparse_matrix: m2(1,1) should be 2, is 2
So I'm assuming you're using the boost_1_29_0 distribution. ublas had an
undocumented restriction regarding sparse proxy assignment at that time,
which was later resolved thanks to Michael Stevens.
I'm a bit surprised that ublas's debug mode didn't alert you, though.
Sorry for the inconvenience,
Joerg
P.S.: Please see Boost CVS for a more current version of ublas.
P.P.S.: Did you already consider to use compressed_matrix<>?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_PP_XX_INCCLUDE
- Original Message - From: "Hugo Duncan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 29, 2003 12:23 PM Subject: [boost] BOOST_PP_XX_INCCLUDE > On Mon, 27 Jan 2003 12:42:14 -0800, "Paul Mensonides" <[EMAIL PROTECTED]> wrote: > > > #define BOOST_PP_HEADERS \ > > (...), /* i.e. "no path" */ \ > > (iostream)(fstream)(vector)(string) \ > > (map)(cstdlib)(sstream) \ > > /**/ > > > > ??=include BOOST_PP_ANGLED_INCLUDE() > > > > effectively does this: > > > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > Looks good to me. Does anyone else have any comments about what they'd like out of such a mechanism? > I would like to take a file that uses BOOST_PP_HEADERS, say > > > #define BOOST_PP_HEADERS \ > > (...), /* i.e. "no path" */ \ > > (iostream)(fstream)(vector)(string) \ > > (map)(cstdlib)(sstream) \ > > /**/ > > > > ??=include BOOST_PP_ANGLED_INCLUDE() > > and preprocess it to generate the file that says > > > #include > > #include > > #include > > #include > > #include > > #include > > #include Ah, you mean _without_ actually including the files? Well, for obvious reasons, this can't be done without a double preprocessor pass, but it is possible. To make such a file, you'd have to write the #include directive manually, something like: #include #include #include #define HASH # #define HEADERS \ (iostream)(fstream)(vector)(string) \ (map)(cstdlib)(sstream) \ /**/ #define BOOST_PP_LOCAL_LIMITS \ (0, BOOST_PP_SEQ_SIZE(HEADERS) - 1) \ /**/ #define BOOST_PP_LOCAL_MACRO(n) \ HASH include \ /**/ #include BOOST_PP_LOCAL_ITERATE() #undef HASH #undef HEADERS Preprocessing this will output a set of include directives: # include # include # include # include # include # include # include However, you may have problems with the pound-sign (#), so you may have to do something more ridiculous like defining HASH like this: #define HASH % ## : %: is the digraph for '#' and prevents it from being a macro expansion operator--i.e. stringizing. Of course, whatever uses the resulting file must be able to handle digraphs. I'm not sure if this is a good solution or not, it is dangerously close to being undefined behavior--if it isn't already. It seems to me that it would be easier to just write it by hand, or use a small program to write it out for you. I don't know, just some thoughts. > > You can simply make a source file that includes all the files that you want > > to pre-preprocess (if that is what your getting at), run it through your > > compiler's preprocessor, and then include the result file. > > I don't think bjam supports just running the preprocessor, but as you say > the poblem is more tricky; I would like to stop preprocessing at a certain > include depth. This I can't do without compiler support. > > but this is outside the scope of the pp-lib can automate because it > > requires a separate build step to produce the preprocessor equivalent of a > > "pre-compiled header." > > I didn't mean to imply it was within scope. I know MPL does preprocessing > using python, but I don't know how reuseable that code is, so I was > just hunting for tips, suggestions and pointers. > > Thanks for your help. Look forward to seeing BOOST_PP_INCLUDE when you have time. I'll write up a copy and send it to you directly to try out. Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shifted_ptr<> w/ lock mechanism
From: "David Abrahams" <[EMAIL PROTECTED]> > "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > > > Lock mechanism was added to shifted_ptr<>: > > http://groups.yahoo.com/group/boost/files/shifted_ptr.zip > > > > Benchmarks are also updated. Still shifted_ptr<> is using less memory and > > twice faster for reconstruction time. > > Almost. > > > Notes: > > - The first memory map report is not precise (shifted_ptr). > > - The reports were reordered (shifted_ptr, shifted_ptr & > > shared_ptr). > > > > I believe there is not that much left to do besides optimizations. > > Have you tried a comparison against a shared_ptr using an optimized > count allocator? One easy way to estimate the impact of an optimized allocator is to #define BOOST_SP_USE_STD_ALLOCATOR, to make shared_ptr use std::allocator. On SGI derived STLs, std::allocator is usually faster than plain new. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David B. Held" <[EMAIL PROTECTED]> writes:
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> > [...]
>> > Unfortunately, StoragePolicy doesn't know when other c'tors have
>> > failed. The only one who does is smart_ptr, which is why it seems
>> > I have to either A) use a function try block to inform StoragePolicy
>> > that someone else has failed, and clean up appropriately,
>>
>> Why not just arrange for StoragePolicy to be the first constructed?
>
> smart_ptr(T* p)
> : storage(p), ownership(p), conversion(), checking()
> { ... }
>
> Suppose storage(p) succeeds, but ownership(p) throws (such as while
> allocating a count).
Ah, I had forgotten the details of the policy decomposition.
> You can't rely on ~storage() to do cleanup, because
> storage doesn't know what the ownership strategy is. It only knows
> about storage. Here's what ~smart_ptr() looks like:
>
> ~smart_ptr()
> {
> if (ownership_policy::release(get_impl(*this)))
> {
> storage_policy::destroy();
> }
> }
>
> So you see, storage_policy must be told when to do cleanup by
> smart_ptr (that's the principle of orthogonal policies).
Then you've indeed got a problem. There were indications in some of
Beman's earlier explorations that the orthogonal policy decomposition
wasn't always a natural one. This might be another clue.
> It's easy enough to write storage_policy::storage_policy(T* p) to
> clean up after itself if *it* throws. But getting it to clean up
> after *another* policy is the trick. Obviously, if one of the other
> c'tors throws, ~smart_ptr() never gets called, so how do we tell
> storage_policy that a failure occurred, and it needs to clean up?
> The only way I can see is to use a function try block:
>
> smart_ptr(T* p)
> try
> : storage_policy(p), ownership(p), conversion(), checking()
> { ... }
> catch
> {
> storage_policy::destroy();
This looks like a static member function call. How does it get ahold
of p?
IIRC one of the reasons function-try-blocks are often useless is that
the data members are already gone, so you can't touch them.
> }
>
> Unfortunately, that's totally Greek to bcc 5.5 (and probably vc++,
> though I don't have access to it right now), not to mention that it
> requires storage_policy(p) to be no-throw.
And conversion and checking, no? If one of those fails, don't you
want the regular release sequence you cite above to take effect?
This appears to be the lesson that Cargill failed to learn from his
own article all over again: some designs are incompatible with certain
EH properties (just like some are incompatible with certain efficiency
properties, etc.).
>> > or B) not use initializer lists, and do all the work in the c'tor
>> > body of smart_ptr.
>>
>> I don't see how B can work; the resource will be unmanaged at
>> least until the body is entered, while all the bases and members
>> are constructed.
>
> That can only work if the default c'tors are no-throw, which would
> mean special-casing ref_counted to not allocate a count until it
> actually receives a pointer. But it would also make the rest of the
> functions in ref_counted bulkier because now you have to detect a
> null count pointer. Otherwise, you would have to set the count
> pointer to null, and have the body of smart_ptr ask ref_counted if
> he was built properly. Quite messy. I don't see any nice solutions
> to this problem.
Me neither, other than changing the design.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shifted_ptr<> w/ lock mechanism
From: "Peter Dimov" <[EMAIL PROTECTED]> > > One easy way to estimate the impact of an optimized allocator is to #define > BOOST_SP_USE_STD_ALLOCATOR, to make shared_ptr use std::allocator. On SGI > derived STLs, std::allocator is usually faster than plain new. I tried to do that myself but benchmark.cpp doesn't compile for me, there's probably no timespec on Windows. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shifted_ptr<> w/ lock mechanism
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > > > Lock mechanism was added to shifted_ptr<>: > > http://groups.yahoo.com/group/boost/files/shifted_ptr.zip > > > > Benchmarks are also updated. Still shifted_ptr<> is using less memory and > > twice faster for reconstruction time. > > Almost. benchmark-nothreads.txt is more precise than benchmark-yesthreads.txt because there is no switching between threads. But yes it is almost doubled (90%). > > Notes: > > - The first memory map report is not precise (shifted_ptr). > > - The reports were reordered (shifted_ptr, shifted_ptr & > > shared_ptr). > > > > I believe there is not that much left to do besides optimizations. > > Have you tried a comparison against a shared_ptr using an optimized > count allocator? Nobody has invested as much effort in optimizing > shared_ptr as you are pouring into shifted_ptr, but an experiment I > did years ago made a huge difference in the efficiency of shared_ptr > just by implementing a crude allocator for count objects (took me > about 10 minutes to code up). For me to find shifted_ptr convincing > I'd have to see a noticeable performance improvement over using an > optimized count allocator with shared_ptr. I think the best way to optimize counts using shared_ptr<> is to derive the subject class from counted_base. This way shared_ptr<> should logically be exactly like shifted_ptr<> in terms of CPU cycles and memory usages. But you won't be able to use typenames easily and complex hierarchies will highly likely confront ambiguity for multiple ownership if virtual inheritance is not used. It is just another solution involving different costs / benefits. Regards, Philippe A. Bouchard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shifted_ptr<> w/ lock mechanism
"Peter Dimov" <[EMAIL PROTECTED]> writes: > From: "David Abrahams" <[EMAIL PROTECTED]> >> "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: >> >> > Lock mechanism was added to shifted_ptr<>: >> > http://groups.yahoo.com/group/boost/files/shifted_ptr.zip >> > >> > Benchmarks are also updated. Still shifted_ptr<> is using less memory > and >> > twice faster for reconstruction time. >> >> Almost. >> >> > Notes: >> > - The first memory map report is not precise (shifted_ptr). >> > - The reports were reordered (shifted_ptr, shifted_ptr & >> > shared_ptr). >> > >> > I believe there is not that much left to do besides optimizations. >> >> Have you tried a comparison against a shared_ptr using an optimized >> count allocator? > > One easy way to estimate the impact of an optimized allocator is to #define > BOOST_SP_USE_STD_ALLOCATOR, to make shared_ptr use std::allocator. On SGI > derived STLs, std::allocator is usually faster than plain new. Yeah; I'm pretty sure that my specialized allocator was faster still, since it just allocated fixed-sized blocks and linked them back into a free-list. It was pretty trivial to implement on top of a std::deque of POD unions. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shifted_ptr<> w/ lock mechanism
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message 000901c2c7dc$e76195e0$1d00a8c0@pdimov2">news:000901c2c7dc$e76195e0$1d00a8c0@pdimov2... > From: "Peter Dimov" <[EMAIL PROTECTED]> > > > > One easy way to estimate the impact of an optimized allocator is to > #define > > BOOST_SP_USE_STD_ALLOCATOR, to make shared_ptr use std::allocator. On SGI > > derived STLs, std::allocator is usually faster than plain new. > > I tried to do that myself but benchmark.cpp doesn't compile for me, there's > probably no timespec on Windows. I have defined BOOST_SP_USE_STD_ALLOCATOR in benchmark.cpp (gcc 2.95): Resources required by list< shifted_ptr >(4000): Arena 0: system bytes = 226820 in use bytes = 226052 Total (incl. mmap): system bytes = 226820 in use bytes = 226052 max mmap regions = 0 max mmap bytes = 0 list shifted_ptr took0.0002951000 seconds to construct. list shifted_ptr took7.1966276647 seconds to reconstruct 2000 times. list shifted_ptr took5.0495961000 seconds to copy 2000 times. list shifted_ptr took4.0016951000 seconds to sort 4000 times. list shifted_ptr took0.1382300647 seconds to swap 500 times. list shifted_ptr took0.0003241000 seconds to destroy. Resources required by list< shared_ptr >(4000): Arena 0: system bytes = 325124 in use bytes = 321988 Total (incl. mmap): system bytes = 325124 in use bytes = 321988 max mmap regions = 0 max mmap bytes = 0 list shared_ptr took 0.0004259000 seconds to construct. list shared_ptr took 14.0157271000 seconds to reconstruct 2000 times. list shared_ptr took 5.0331178000 seconds to copy 2000 times. list shared_ptr took 4.0376376000 seconds to sort 4000 times. list shared_ptr took 0.1449102647 seconds to swap 500 times. list shared_ptr took 0.0004831000 seconds to destroy. Philippe A. Bouchard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Review Request: shifted_ptr<>
"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message b19e0t$v9l$[EMAIL PROTECTED]">news:b19e0t$v9l$[EMAIL PROTECTED]... > [...] > The main documentation & rationale is found in > /shifted_ptr/doc/structboost_1_1shifted__ptr.html. While the generated documention is ok, it is a bit hard to read, because so much of it appears superfluous. Also, you should consider looking at other Boost documentation, and making yours conform more to the style of the typical library. In particular, you are missing a Rationale section, which, for your library, is probably the most important part. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: shifted_ptr<> w/ lock mechanism
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: >> Have you tried a comparison against a shared_ptr using an optimized >> count allocator? Nobody has invested as much effort in optimizing >> shared_ptr as you are pouring into shifted_ptr, but an experiment I >> did years ago made a huge difference in the efficiency of shared_ptr >> just by implementing a crude allocator for count objects (took me >> about 10 minutes to code up). For me to find shifted_ptr convincing >> I'd have to see a noticeable performance improvement over using an >> optimized count allocator with shared_ptr. > > I think the best way to optimize counts using shared_ptr<> is to > derive the subject class from counted_base. This way shared_ptr<> > should logically be exactly like shifted_ptr<> in terms of CPU > cycles and memory usages. But you won't be able to use typenames > easily and complex hierarchies will highly likely confront ambiguity > for multiple ownership if virtual inheritance is not used. > > It is just another solution involving different costs / benefits. That may be the best way to optimize counts using shared_ptr<> if you don't care about complex hierarchies and "using typenames easily" (not that I understand what it means). The things you have to give up by using an intrusive count with shared_ptr are things I care about, though. AFAICT, the fact that shifted_ptr<> is testing faster than shared_ptr<> when those features are available is the argument for shifted_ptr<>'s existence in the first place. What I'd like to know is whether shifted_ptr still provides any significant benefits over shared_ptr if you apply a simple optimization tweak to shared_ptr and use it in its most-flexible configuration. I don't think it's an unreasonable question, and I'll need the answer in order to decide whether something like shifted_ptr is worth accepting into Boost. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> Then you've indeed got a problem. There were indications in
> some of Beman's earlier explorations that the orthogonal policy
> decomposition wasn't always a natural one. This might be another
> clue.
Indeed. My new suggested change involves breaking orthogonality
in a way that I think even Beman suggested, if memory serves me
correctly.
> > [...]
> > smart_ptr(T* p)
> > try
> > : storage_policy(p), ownership(p), conversion(), checking()
> > { ... }
> > catch
> > {
> > storage_policy::destroy();
>
> This looks like a static member function call. How does it get ahold
> of p?
Yes, it *looks* like a static member. ;) But remember that
storage_policy is a base, so this is also a valid member function call,
and destroy() is a non-static member of storage_policy. Of course, the
call to destroy() only succeeds if storage_policy(p) has succeeded.
> IIRC one of the reasons function-try-blocks are often useless is that
> the data members are already gone, so you can't touch them.
Yup. 15.3.11. That does make them incredibly useless.
> [...]
> And conversion and checking, no? If one of those fails, don't you
> want the regular release sequence you cite above to take effect?
Yes, but who in their right minds is going to write a custom conversion
policy? ;) The ones provided are explicitly no-throw. However,
checking will probably throw exceptions in some configurations, and
requiring them to be no-throw would defeat the point of having the
checking to begin with.
> [...]
> Me neither, other than changing the design.
I think by parameterizing the policies on storage_policy, rather
than storage_policy::pointer_type is the solution. It breaks
orthogonality, but in the most minimal way I can imagine. It gives
the other policies the ability to tell storage_policy to clean up, but
introduces no other dependencies. If I recall correctly, this is
exactly the design Beman settled on (or something close, where
storage_policy was a central point).
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shifted_ptr<> w/ lock mechanism
"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message b19hhg$i2m$[EMAIL PROTECTED]">news:b19hhg$i2m$[EMAIL PROTECTED]... > [...] > list shifted_ptr took0.0002951000 seconds to construct. > list shifted_ptr took7.1966276647 seconds to reconstruct 2000 > times. > list shifted_ptr took5.0495961000 seconds to copy 2000 times. > list shifted_ptr took4.0016951000 seconds to sort 4000 times. > list shifted_ptr took0.1382300647 seconds to swap 500 times. > list shifted_ptr took0.0003241000 seconds to destroy. > [...] > list shared_ptr took 0.0004259000 seconds to construct. > list shared_ptr took 14.0157271000 seconds to reconstruct 2000 times. > list shared_ptr took 5.0331178000 seconds to copy 2000 times. > list shared_ptr took 4.0376376000 seconds to sort 4000 times. > list shared_ptr took 0.1449102647 seconds to swap 500 times. > list shared_ptr took 0.0004831000 seconds to destroy. Looks like your lead is getting eroded by the day. ;) And that's just with a quick hack. You better be worried about a serious small object allocator. Not only that, but the items that seem most important to me are copy, sort, and swap, since those are the most frequent or computationally intensive. And in those three categories, you have virtually no advantage. In fact, shared_ptr beats shifted_ptr in copy??? What happened? The sort speed amounts to < 1% difference. Even swap amounts to about a 5% diff. This is very telling. The biggest speed difference is during construction, and that is where shared_ptr is least optimized. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: shifted_ptr<> w/ lock mechanism
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> "Peter Dimov" <[EMAIL PROTECTED]> wrote in message
> 000901c2c7dc$e76195e0$1d00a8c0@pdimov2">news:000901c2c7dc$e76195e0$1d00a8c0@pdimov2...
>> From: "Peter Dimov" <[EMAIL PROTECTED]>
>> >
>> > One easy way to estimate the impact of an optimized allocator is to
>> #define
>> > BOOST_SP_USE_STD_ALLOCATOR, to make shared_ptr use std::allocator. On
> SGI
>> > derived STLs, std::allocator is usually faster than plain new.
>>
>> I tried to do that myself but benchmark.cpp doesn't compile for me,
> there's
>> probably no timespec on Windows.
>
> I have defined BOOST_SP_USE_STD_ALLOCATOR in benchmark.cpp (gcc 2.95):
>
> Resources required by list< shifted_ptr >(4000):
> Arena 0:
> system bytes = 226820
> in use bytes = 226052
> Total (incl. mmap):
> system bytes = 226820
> in use bytes = 226052
> max mmap regions = 0
> max mmap bytes = 0
> list shifted_ptr took0.0002951000 seconds to construct.
> list shifted_ptr took7.1966276647 seconds to reconstruct 2000
> times.
> list shifted_ptr took5.0495961000 seconds to copy 2000 times.
> list shifted_ptr took4.0016951000 seconds to sort 4000 times.
> list shifted_ptr took0.1382300647 seconds to swap 500 times.
> list shifted_ptr took0.0003241000 seconds to destroy.
>
> Resources required by list< shared_ptr >(4000):
> Arena 0:
> system bytes = 325124
> in use bytes = 321988
> Total (incl. mmap):
> system bytes = 325124
> in use bytes = 321988
> max mmap regions = 0
> max mmap bytes = 0
> list shared_ptr took 0.0004259000 seconds to construct.
> list shared_ptr took 14.0157271000 seconds to reconstruct 2000 times.
> list shared_ptr took 5.0331178000 seconds to copy 2000 times.
> list shared_ptr took 4.0376376000 seconds to sort 4000 times.
> list shared_ptr took 0.1449102647 seconds to swap 500 times.
> list shared_ptr took 0.0004831000 seconds to destroy.
Would you indulge me and try the benchmark again with the enclosed
shared_count patch applied and #undef BOOST_SP_USE_STD_ALLOCATOR? I
don't really know what's going on under the covers in the SGI
allocator; this is basically just the same hack I threw at the problem
years ago.
My patch doesn't pretend to work for a threaded implementation, so
only the no-threads test applies.
*** shared_count.hpp.~1.31.~ Sun Jan 19 10:14:15 2003
--- shared_count.hpp Wed Jan 29 17:28:11 2003
***
*** 37,45
--- 37,104
# pragma warn -8027 // Functions containing try are not expanded inline
#endif
+ # include
+ # include
+ # include
+
namespace boost
{
+ namespace aux_
+ {
+ // # include
+
+ template
+ union freeblock
+ {
+ typename boost::type_with_alignment::type aligner;
+ char bytes[sz];
+ freeblock *next;
+ };
+
+ template
+ struct allocator_impl
+ {
+ typedef freeblock block;
+
+ static std::deque store;
+ static block* free;
+
+ static inline void* alloc()
+ {
+ block* x = free;
+ if (x)
+ {
+ free = x->next;
+ return x;
+ }
+ else
+ {
+ store.resize(store.size() + 1);
+ return &store.back();
+ }
+ }
+
+ static inline void dealloc(void* p_)
+ {
+ block* p = static_cast(p_);
+ p->next = free;
+ free = p;
+ }
+ };
+
+
+ template
+ std::deque > allocator_impl::store;
+
+ template
+ freeblock* allocator_impl::free = 0;
+
+ template
+ struct quick_allocator : allocator_impl::value>
+ {
+ };
+ }
// Debug hooks
#if defined(BOOST_ENABLE_SP_DEBUG_HOOKS)
***
*** 272,277
--- 331,346
void operator delete(void * p)
{
std::allocator().deallocate(static_cast(p), 1);
+ }
+ #else
+ void * operator new(std::size_t)
+ {
+ return aux_::quick_allocator::alloc();
+ }
+
+ void operator delete(void * p)
+ {
+ aux_::quick_allocator::dealloc(p);
}
#endif
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shifted_ptr<> w/ lock mechanism
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Peter Dimov" <[EMAIL PROTECTED]> writes: > > > From: "David Abrahams" <[EMAIL PROTECTED]> > >> "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > >> > >> > Lock mechanism was added to shifted_ptr<>: > >> > http://groups.yahoo.com/group/boost/files/shifted_ptr.zip > >> > > >> > Benchmarks are also updated. Still shifted_ptr<> is using less memory > > and > >> > twice faster for reconstruction time. > >> [snip] > > One easy way to estimate the impact of an optimized allocator is to #define > > BOOST_SP_USE_STD_ALLOCATOR, to make shared_ptr use std::allocator. On SGI > > derived STLs, std::allocator is usually faster than plain new. > > Yeah; I'm pretty sure that my specialized allocator was faster still, > since it just allocated fixed-sized blocks and linked them back into a > free-list. It was pretty trivial to implement on top of a std::deque > of POD unions. > Latest C++ compilers come with fairly good allocator for small object . I played with Loki's SmallObjAllocator and even heavily sped up version didn't match the native allocators used in BCB or Intel C++ (being still 30% slower and no MT safety). I guess small object optimisation was already provided, maybe mixed together with tricks as assembler optimisation or cache wizardry. OTOH GCC 2.95.* was significantly slower than Loki. $0.02 /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Gmane thread view fixed
In one of his usual shows of responsiveness, Lars has fixed a bug in Gmane that would prevent the "thread view" link at the bottom of a message from working because our message archive is too big. See http://news.gmane.org/thread.php?group=gmane.comp.lib.boost.devel -Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Review Request: shifted_ptr<>
I notice that a special operator new must be used to create objects pointed to by shifted_ptr. Is this really necessaty? It prevents shifted_ptr from just being an alternative implementation of shared_ptr. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David B. Held" <[EMAIL PROTECTED]> wrote in message b19ic3$m48$[EMAIL PROTECTED]">news:b19ic3$m48$[EMAIL PROTECTED]... > Indeed. My new suggested change involves breaking orthogonality > in a way that I think even Beman suggested, if memory serves me > correctly. Ideally, SmartPtr should orchestrate the workings of the policies together while they are aloof of each other. In this particular case, if we are to apply this approach, it seems like SmartPtr should detect that the appropriate ownership policy fails to construct, and should say "never mind" to the storage policy by triggering its destruction. This sounds like a reasonable approach to me. It looks like SmartPtr cannot apply this simple algorithm due to syntactic and semantic issues of the language, which some (including me) deem as problems with the language. So my suggestion is to work around the language instead of breaking orthogonality gratuitously. I believe this is NOT an example when orthogonality plays against you. Andrei ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
Terje Slettebø <[EMAIL PROTECTED]> writes: >>From: "Terje Slettebø" <[EMAIL PROTECTED]> > > As Daveed notes in the posting Rani gives a link to in the clc++m posting, > if D is not derived from B, it has to choose between C -> C const -> B for > the first function, and C -> D for the second function, which are just as > good, _had it not been for the fact that "static no check(B const volatile > &, int)" is not templated (as Rani points out in the posting)_, which makes > C -> C const B the best choice, resulting in "no". Seems to me that an ellipsis might be a slightly more-efficient means to the same end here. > Also, if C::operator B hadn't been const, the two conversion sequences for > "static no check(B const volatile &, int)" would have been ambiguous. Yup. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"Andrei Alexandrescu" <[EMAIL PROTECTED]> writes: > "David B. Held" <[EMAIL PROTECTED]> wrote in message > b19ic3$m48$[EMAIL PROTECTED]">news:b19ic3$m48$[EMAIL PROTECTED]... >> Indeed. My new suggested change involves breaking orthogonality >> in a way that I think even Beman suggested, if memory serves me >> correctly. > > Ideally, SmartPtr should orchestrate the workings of the policies together > while they are aloof of each other. > > In this particular case, if we are to apply this approach, it seems like > SmartPtr should detect that the appropriate ownership policy fails to > construct, and should say "never mind" to the storage policy by triggering > its destruction. This sounds like a reasonable approach to me. > > It looks like SmartPtr cannot apply this simple algorithm due to syntactic > and semantic issues of the language, which some (including me) deem as > problems with the language. It could do that; You'd just need to make room to handle in-place construction and destruction itself (a technique I know you're familiar with). I'm not sure that's a language problem since after all situations like this don't arise often and the workaround is correspondingly difficult. Hmm, you want these policies to be bases, though, so they can inject interface, right? Should a class really be allowed to control the construction and destruction of its bases? That sounds frought with peril to me. If you have a picture of how this would work, can you describe it? > So my suggestion is to work around the language instead of breaking > orthogonality gratuitously. I'd have suggested the same thing if I thought that breaking orthogonality was gratuitous in this case, i.e. if there was a workaround within the current language that didn't compromise efficiency in a serious way. Do you see a way to handle it? > I believe this is NOT an example when orthogonality plays against > you. Orthogonality itself never plays agin' ya. It's when you try to force orthogonality on things which actually have to cooperate closely that you get problems. I'm not sure we have that case here, but it looks like a possibility. One way out, as Dave H. has suggested, might be to impose nothrow requirements to get back some independence. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"Andrei Alexandrescu" <[EMAIL PROTECTED]> wrote in message
b19mhu$9sm$[EMAIL PROTECTED]">news:b19mhu$9sm$[EMAIL PROTECTED]...
> [...]
> Ideally, SmartPtr should orchestrate the workings of the policies
> together while they are aloof of each other.
That's the gold standard, of course.
> [...]
> So my suggestion is to work around the language instead of
> breaking orthogonality gratuitously. I believe this is NOT an example
> when orthogonality plays against you.
Unfortunately, I'm not sure what you suggest as an exception-safe
implementation now. The function try block solution is right out, both
in practice (because most compilers fail to support it, and frankly, I
don't blame them), and in theory (destructors have been called on
fully constructed members/bases already anyway). It seems the only
"safe" solution is default construction with ownership transfer in the
body of the c'tor. Is this what you recommend? It requires expanding
the policy interface by adding new functions to storage_policy and
ownership_policy. I suppose we could do something like this:
void scalar_storage::acquire(stored_type const& p)
{
pointee_ = p;
}
template
void ref_counted::acquire(U const& p)
{
}
template
smart_ptr(U const& p)
{
try
{
storage_policy::acquire(p);
ownership_policy::aquire(p);
checking_policy::on_init(get_impl(*this));
}
catch (...)
{
storage_policy::destroy();
throw;
}
}
Ultimately, it's only slightly less efficient than the initializer list
form, and
now doesn't leak p when someone passes 'new X'. Orthogonality is
preserved, and angels from on high sing Hallelujah (ok, maybe the last
part is stretching it). Taking ownership probably should be a separate
step from construction anyway.
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > Orthogonality itself never plays agin' ya. It's when you try to force > orthogonality on things which actually have to cooperate closely that > you get problems. I'm not sure we have that case here, but it looks > like a possibility. One way out, as Dave H. has suggested, might be > to impose nothrow requirements to get back some independence. Hopefully, it won't come to that, if my latest implementation is non- stupid. However, there's no guarantee of that (it fails to provide the non-stupid guarantee), since the previous suggestion of calling storage_policy::destroy() from ownership_policy was blatantly wrong. I fell into the same trap you did thinking that it was a static function that could be called from anywhere. Unfortunately (or fortunately, depending on how you look at it), storage_policy is not a base class of ownership_policy, so that call would have been illegal. Thus, the policy interaction as I suggested it buys you nothing. However, I do seem to recall that Beman's plan did involve some inheritance between policies, and that design probably does offer the non-stupid guarantee. I think the two-step ownership acquisition is the better way to go, here. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Previously GPL'd Code
A licensing question for everyone: Is there any problem with submitting, for possible inclusion in Boost, a library that was previously released under the GNU GPL? The submission would, in its new incarnation, be covered by a license that meets the Boost criteria. It would be submitted by the original copyright holders and would include no modifications made by others who received the library under the GPL. I understand that there are no *legal* problems with this (right??), but legal problems are not the only problems there are = Glenn G. Chappell<><[EMAIL PROTECTED] Dept. of Mathematical Sciences * Ofc: (907) 474-5736 University of Alaska Fairbanks * Fax: (907) 474-5394 __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David B. Held" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> [...] >> Orthogonality itself never plays agin' ya. It's when you try to force >> orthogonality on things which actually have to cooperate closely that >> you get problems. I'm not sure we have that case here, but it looks >> like a possibility. One way out, as Dave H. has suggested, might be >> to impose nothrow requirements to get back some independence. > > Hopefully, it won't come to that, if my latest implementation is non- > stupid. However, there's no guarantee of that (it fails to provide the > non-stupid guarantee), since the previous suggestion of calling > storage_policy::destroy() from ownership_policy was blatantly wrong. > I fell into the same trap you did thinking that it was a static function > that could be called from anywhere. I don't think I fell into that trap FWIW. I was pointing out that in a function-catch-clause it had better be a static function, and then it can't touch data members. > Unfortunately (or fortunately, depending on how you look at it), > storage_policy is not a base class of ownership_policy, so that call > would have been illegal. Thus, the policy interaction as I > suggested it buys you nothing. However, I do seem to recall that > Beman's plan did involve some inheritance between policies, and that > design probably does offer the non-stupid guarantee. I think the > two-step ownership acquisition is the better way to go, here. So you are willing to require nothrow policy construction? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David B. Held" <[EMAIL PROTECTED]> writes:
> I suppose we could do something like this:
>
> void scalar_storage::acquire(stored_type const& p)
> {
> pointee_ = p;
> }
>
> template
> void ref_counted::acquire(U const& p)
> {
> }
>
> template
> smart_ptr(U const& p)
> {
> try
> {
> storage_policy::acquire(p);
> ownership_policy::aquire(p);
> checking_policy::on_init(get_impl(*this));
> }
> catch (...)
> {
> storage_policy::destroy();
> throw;
> }
> }
>
> Ultimately, it's only slightly less efficient than the initializer list
> form, and
> now doesn't leak p when someone passes 'new X'.
It sure does if any of the bases or members of smart_ptr throws from
its constructor.
> Orthogonality is preserved, and angels from on high sing Hallelujah
> (ok, maybe the last part is stretching it). Taking ownership
> probably should be a separate step from construction anyway.
I dunno. Acquiring ownership at construction time is a key part of
the "one true meaning" of RAII (not the accepted meaning, which has
come to be "deallocating resources in destructors" -- a concept having
nothing to do with acquisition _or_ initialization). There's a good
reason for this, since it avoids the problem of leaking when a
constructor throws.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shifted_ptr<> w/ lock mechanism
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > > I believe there is not that much left to do besides optimizations. > > Have you tried a comparison against a shared_ptr using an optimized > count allocator? Nobody has invested as much effort in optimizing > shared_ptr as you are pouring into shifted_ptr, but an experiment I > did years ago made a huge difference in the efficiency of shared_ptr > just by implementing a crude allocator for count objects (took me > about 10 minutes to code up). For me to find shifted_ptr convincing > I'd have to see a noticeable performance improvement over using an > optimized count allocator with shared_ptr. My understanding is that shifted_ptr mandates allocating *your* objects inside *its* "doped memory" area by using placement new. (Phillippe, please correct me if I'm wrong.) This slashes many good uses of smart pointers, which include, but are not limited to (damn, I feel I talk like a lawyer :o)): object factories (unless they use shfted_ptr from the get-go), the Template Method pattern (ditto), cross-DLL communication, object brokers (COM/CORBA), working nicely with other allocators. All these idioms require you to grab a pointer to an object that was constructed elsewhere. If my understanding is correct, shifted_ptr is not able to do that, while shared_ptr is. These are use cases that I personally find important, so, although there existed some precedent back in 1999, I did not consider using a custom allocator (that would allocate the object plus extra memory for bookkeeping) in mc++d. At any rate, anyone comparing shifted_ptr with shared_ptr should keep in mind that one has an apple flavor and the other an orange flavor. It would be interesting to see how much the implementation of shifted_ptr is simplified if it's put into an Ownership policy of the Borg, er, loki::smart_ptr. I guess a lot. That would nicely let the users decide whether they can do with allocating objects with placement new and enjoy the additional performance. Of course, all that *after* fixing smart_ptr's buggy constructor :o). Andrei ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> It sure does if any of the bases or members of smart_ptr throws
> from its constructor.
Just when I thought the problem was solved...
> [...]
> I dunno. Acquiring ownership at construction time is a key part
> of the "one true meaning" of RAII (not the accepted meaning,
> which has come to be "deallocating resources in destructors" -- a
> concept having nothing to do with acquisition _or_ initialization).
> There's a good reason for this, since it avoids the problem of
> leaking when a constructor throws.
On the other hand, acquiring multiple resources is going to present
exactly the same problem. Or acquiring a resource in any other
context when members can throw will have the same problem. You
could say that no class should acquire a resource and have other
members/bases that could throw, but that seems draconian. So
what is the real solution? I'm beginning to agree with Andrei that
there appears to be a fundamental language problem here, but I
don't pretend to have a change that would fix it. Modifying function
try blocks to be more useful might seem like the answer, but any
change would make them different from normal try blocks, right?
Look at shared_count. It does not acquire the count in the initializer
list. It default-constructs and then acquires the count inside a try
block in the body of the c'tor. Does that mean it does not perform
"True RAII"? I would like to use the initializer list as much as the
next guy, but multiple initializers seem to be a real problem. It works
great for the trivial case. Does this mean "True RAII" doesn't scale?
And this is an RAII problem, not a PBD or orthogonality problem.
That's because as much as we would like to say that every class
should only perform one function, it happens that some functions
cannot be performed with a single resource. For ref-counted smart
pointers (shared_ptr or smart_ptr), those resources are the managed
resource and the count.
A kludge, but perhaps a start in the right direction, would be to have
a special function analogous to the destructor that gets called when
a member is destroyed as the result of a failed construction. It would
be analogous to placement delete. It would only get called on fully
constructed objects. This way, objects would be able to tell when
they are being destroyed as part of their normal life cycle, and when
they are being destroyed due to a problem. One syntax would be to
pass a dummy int parameter to a normal destructor, like so:
scalar_storage::scalar_storage()
{
// normal destruction, do nothing
}
scalar_storage::~scalar_storage(int)
{
// something bad happened, clean up with extreme prejudice
destroy();
}
Another syntax might be to pass the exception type to the destructor.
Then, a given destructor would only get called if its argument were
convertible to the thrown exception type, like so:
scalar_storage::~scalar_storage(std::bad_alloc const&)
{
// failed allocation somewhere else, clean up
destroy();
}
scalar_storage::~scalar_storage(std::exception const&)
{
// some other problem, clean up anyway ;)
destroy();
}
In the event that no specialized d'tor were defined, the normal
destructor would get called.
So, in this case:
int main()
{
ref_counted r;
}
At the end of scope, ref_counted::~ref_counted() is called. Whereas,
in this case:
struct X
{
struct Y { Y() { throw 0; } };
X() : r(), y(){ }
ref_counted r;
Y y;
};
ref_counted::~ref_counted(int) would get called.
Unfortunately, shared_count shows that this scheme is not sufficient,
because you lose the context of the throwing c'tor. In particular,
the shared_count(P, D) c'tor is most problematic. On the other
hand, shared_count could technically be written using a function
try block. Who knows. Maybe someone can come up with a
better idea.
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David B. Held" <[EMAIL PROTECTED]> writes:
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> [...]
>> It sure does if any of the bases or members of smart_ptr throws
>> from its constructor.
>
> Just when I thought the problem was solved...
>
>> [...]
>> I dunno. Acquiring ownership at construction time is a key part
>> of the "one true meaning" of RAII (not the accepted meaning,
>> which has come to be "deallocating resources in destructors" -- a
>> concept having nothing to do with acquisition _or_ initialization).
>> There's a good reason for this, since it avoids the problem of
>> leaking when a constructor throws.
>
> On the other hand, acquiring multiple resources is going to present
> exactly the same problem.
Which is why the first "I" in RAII stands for "is". Each acquired
resource should initialize exactly one (sub)object.
> Or acquiring a resource in any other context when members can throw
> will have the same problem.
I can't picture what you mean.
> You could say that no class should acquire a resource and have other
> members/bases that could throw
I don't think I'd say that.
> but that seems draconian. So what is the real solution?
To this particular problem? I'd say "redesign or respecify". That
is, move the design or move the goalposts.
> I'm beginning to agree with Andrei that there appears to be a
> fundamental language problem here, but I don't pretend to have a
> change that would fix it.
It's very easy to blame the language for not allowing us to easily
implement DWIM semantics, especially when we're not sure exactly what
those semantics should be. Have you got a clear idea of what should
happen during construction if an exception is thrown? Can you write
it as pseudocode?
The language gives us a very coherent mechanism for dividing up the
units of work that must get done when a constructor throws an
exception. See page 53 of "more effective C++"
(http://www.awprofessional.com/meyerscddemo/DEMO/MEC/MI10_FR.HTM) and
my 5/5/99 notes at
http://www.aristeia.com/BookErrata/mec++-errata_frames.html for
reference. Any "fix" to the language will only be an improvement if
it doesn't undermine that coherence.
> Modifying function try blocks to be more useful might seem like the
> answer, but any change would make them different from normal try
> blocks, right?
They're already different. But anyway, I think you're putting the
cart before the horse. First describe exactly what you think ought to
happen; then we can see how close or far the language is from allowing
it.
> Look at shared_count. It does not acquire the count in the initializer
> list. It default-constructs and then acquires the count inside a try
> block in the body of the c'tor. Does that mean it does not perform
> "True RAII"?
It's certainly walking the line. Internally it has to do something
other than pure RAII: all these smart pointer classes are complicated
by the fact that we expect them to take posession of an
already-allocated yet unmanaged resource in their constructors. If
they have to allocate any other resources before managing the one
they're passed, they have to take extraordinary measures.
One language change I could imagine which would help would be the
ability to declare an auto variable in the class' initializer list:
template shared_count(P p, D d)
: auto deleter del(d, p)
, pi_(new sp_counted_base_impl(p, d))
{
del.release();
}
...and I suppose you could simulate this by adding an extra default
parameter:
template shared_count(
P p, D d, deleter del = deleter(p,d))
: pi_(new sp_counted_base_impl(p, d))
{
del.release();
}
So, does that help with your problem?
> I would like to use the initializer list as much as the next guy,
> but multiple initializers seem to be a real problem. It works great
> for the trivial case. Does this mean "True RAII" doesn't scale?
It scales fine; it's unmanaged resources which don't scale ;-)
> And this is an RAII problem, not a PBD or orthogonality problem.
That's still not totally clear to me. shared_count works fine from
the POV of its caller; you could make your policies do the same if
they were organized appropriately for that job (which may destroy
other nice properties like orthogonality).
> That's because as much as we would like to say that every class
> should only perform one function, it happens that some functions
> cannot be performed with a single resource.
That's no problem:
struct totally_safe
{
totally_safe() : pa(new A), pb(new B), pc(new C) {}
...
std::auto_ptr pa;
std::auto_ptr pb;
std::auto_ptr pc;
};
> For ref-counted smart pointers (shared_ptr or smart_ptr), those
> resources are the managed resource and the count.
Uh-huh.
> A kludge, but perhaps a start in the right direction, would be to have
> a special function anal
Re: [boost] Re: BGL: graph direction
Adding typedef bidirectionalS bidirectedS; would be fine by me. I just don't want to break current code or docs by removing bidirectionalS. Cheers, Jeremy On Wed, 29 Jan 2003, Jason House wrote: jhouse> I'm not familiar with the details, but could there be a typedef or jhouse> something like that in order to accept bidirectedS? jhouse> Or maybe replacing the bidirectionalS with bidirectedS and making jhouse> bidirectionalS typedef'd to bidirectedS? -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BGL: external properties
We currenly do not have a solution for this in the BGL (other than internal properties). I seem to remember LEDA having a solution for this, so you might want to look there for ideas. Cheers, Jeremy On Wed, 29 Jan 2003, Vladimir Prus wrote: ghost> ghost> Well, external properties still confuse me. Assume I want to attach ghost> some data to vertices in adjacency_list. No problem: ghost> ghost> vector< vertex > alternative_s ; ghost> iterator_property_map< vector::iterator, ghost> property_map > alternative = ... ghost> ghost> The problem is that I have to pass alternative_s.begin() when ghost> constructig alternative, but I might want to add new vertices. ghost> In that case the iterator can be invalidated. ghost> ghost> Is there a solution to this problem, except for resorting to internal ghost> properties? ghost> ghost> - Volodya ghost> -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shifted_ptr<> w/ lock mechanism
"Andrei Alexandrescu" <[EMAIL PROTECTED]> wrote in message b1a0uv$lju$[EMAIL PROTECTED]">news:b1a0uv$lju$[EMAIL PROTECTED]... [...] > My understanding is that shifted_ptr mandates allocating *your* objects > inside *its* "doped memory" area by using placement new. (Phillippe, please > correct me if I'm wrong.) No, it works exactly this way. The reference count is allocated at the same time the object is. The returned pointer is shifted to the starting address of the object in question. > This slashes many good uses of smart pointers, > which include, but are not limited to (damn, I feel I talk like a lawyer > :o)): object factories (unless they use shfted_ptr from the get-go), the > Template Method pattern (ditto), cross-DLL communication, object brokers > (COM/CORBA), working nicely with other allocators. All these idioms require > you to grab a pointer to an object that was constructed elsewhere. If my > understanding is correct, shifted_ptr is not able to do that, while > shared_ptr is. shifted_ptr only works with "shifted objects" allocated with placement operator new (size_t, shifted_type const &). In theory it would be possible to displace operator delete (void *) to handle properly addresses not pointing to the beginning of a block (hack); to implement this directly in a compiler; etc. > These are use cases that I personally find important, so, although there > existed some precedent back in 1999, I did not consider using a custom > allocator (that would allocate the object plus extra memory for > bookkeeping) in mc++d. At any rate, anyone comparing shifted_ptr with > shared_ptr should keep in mind that one has an apple flavor and the other > an orange flavor. Yes, exactly. shared_ptr has its advantages and so is shifted_ptr. I am not a judge either. I like shifted_ptr because the only cost involves the placement operator new usage. > It would be interesting to see how much the implementation of shifted_ptr > is simplified if it's put into an Ownership policy of the Borg, er, > loki::smart_ptr. I guess a lot. That would nicely let the users decide > whether they can do with allocating objects with placement new and enjoy > the additional performance. Of course, all that *after* fixing smart_ptr's > buggy constructor :o). That would be great, agreed. But I thinly think it would require additional policies... @:) Regards, Philippe A. Bouchard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shifted_ptr<> w/ lock mechanism
"David B. Held" <[EMAIL PROTECTED]> wrote in message b19io8$o05$[EMAIL PROTECTED]">news:b19io8$o05$[EMAIL PROTECTED]... [...] > Looks like your lead is getting eroded by the day. ;) And that's just > with a quick hack. You better be worried about a serious small > object allocator. Not only that, but the items that seem most important > to me are copy, sort, and swap, since those are the most frequent or > computationally intensive. And in those three categories, you have > virtually no advantage. In fact, shared_ptr beats shifted_ptr in copy??? > What happened? The sort speed amounts to < 1% difference. Even > swap amounts to about a 5% diff. This is very telling. The biggest > speed difference is during construction, and that is where shared_ptr > is least optimized. Let's not forget constructions and destructions are optimized by the compiler when used consecutively. Reconstruction is a more concrete example. Thus I can play with construction and destruction as well. Swaps and copies should logically be similar since only the count is incremented, the memory blocks are not affected. Don't we forget also that every time I run the benchmark, the results are always different (I should use nice --20 as root) and there is some margin of error +/-1 second. Philippe A. Bouchard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[snip]
One problem I see is that the constructor uses a different syntax than any
other function. Imho syntax uniformity is good, and lack thereof is not
good.
Other languages get away from this problem by considering the first
assignment to an base or member, the constructor call for that base or
member. If no first assignment is statically decided, there is a
compile-time error.
If that were the case, Loki::SmartPtr's constructor could be written like
this:
SmartPtr::SmartPtr(T* p)
{
*this = storage(p);
ScopeGuard g = MakeGuard(storage::destroy, p);
*this = ownership(p);
g.Dismiss();
*this = conversion();
*this = checking();
}
Well, dream mode off. If that's not to work, using Dave Abrahams' idea of
passing a default argument might apply, however the problem is that you
can't pass previous arguments to the default argument :o/.
I suggest we just make an explicit function acquire() for the ownership
policy and have all of its other member functions assume acquire() was
called.
Imho this is an issue of language peculiarity, and not a matter of
principle.
Andrei
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"Andrei Alexandrescu" <[EMAIL PROTECTED]> writes:
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [snip]
Might help to know what you're responding to here, though I can try to
guess...
> One problem I see is that the constructor uses a different syntax
> than any other function. Imho syntax uniformity is good, and lack
> thereof is not good.
In general I agree, though it's not clear how that relates to our
problem.
> Other languages get away from this problem by considering the first
> assignment to an base or member, the constructor call for that base or
> member. If no first assignment is statically decided, there is a
> compile-time error.
>
> If that were the case, Loki::SmartPtr's constructor could be written like
> this:
>
> SmartPtr::SmartPtr(T* p)
> {
> *this = storage(p);
> ScopeGuard g = MakeGuard(storage::destroy, p);
> *this = ownership(p);
> g.Dismiss();
> *this = conversion();
> *this = checking();
> }
Conceivably workable for C++, though very expensive in copies using
that precise form. It would require different unwind sequences for
each differently-ordered constructor. I'm not sure whether it's worth
breaking the invariant about members being destroyed in the reverse
order they constructed in, though I suppose it's possible to eliminate
all of that by restricting the initialization order to match the order
of bases and members.
> Well, dream mode off. If that's not to work, using Dave Abrahams' idea of
> passing a default argument might apply, however the problem is that you
> can't pass previous arguments to the default argument :o/.
Sure, you can just use a base implementation layer. Then you don't even
need a default:
template
struct pb_impl : P1, P2, P3
{
pb_impl(T* x, deleter del)
: P1(x), P2(x), P3(x)
{
del.release();
}
};
template
struct policy_based
: pb_impl
{
policy_based(T* x)
: pb_impl(x, deleter(x))
{}
};
Note how this very quickly turns back towards a kind of "pure RAII."
> I suggest we just make an explicit function acquire() for the ownership
> policy and have all of its other member functions assume acquire() was
> called.
It's not obvious to me what that looks like, but if you think you've
got an acceptable answer maybe that doesn't matter.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"Andrei Alexandrescu" <[EMAIL PROTECTED]> wrote in message
b1aact$imm$[EMAIL PROTECTED]">news:b1aact$imm$[EMAIL PROTECTED]...
> [...]
> I suggest we just make an explicit function acquire() for the ownership
> policy and have all of its other member functions assume acquire() was
> called.
Unfortunately, this requires no-throw default construction of all policies.
Since ref_counted allocates the count even in the default case, we have
to silence any std::bad_alloc's that get thrown. That leaves us with
checking if we actually have a count or not. We either have to validate
the count pointer in every member function, or call a special function that
does nothing but check to see if ownership_policy() was successful or
not. Can we say 'ugly'?? Let me state the problem in C++:
smart_ptr(P p)
: storage(), ownership(), conversion(), checking()
{
try
{
storage::acquire(p);
ownership::acquire(p);
checking::on_init(p);
}
catch (...)
{
storage::destroy();
}
}
If ownership() throws, p is leaked. So we have to make ownership() no-
throw:
ref_counted()
: pCount(0)
{ }
ref_counted(P p)
: pCount(new int(1))
{ }
void acquire(P p)
{
if (pCount) throw 0;
pCount = new int(1);
}
P clone(P p)
{
if (!pCount) throw 0;
++*pCount;
return p;
}
bool release(P p)
{
if (!pCount) throw 0;
if (!--*pCount)
{
delete pCount;
return true;
}
return false;
}
friend inline unsigned use_count(ref_counted const& p)
{ if (!p.pCount) throw 0; return *(p.pCount); }
Or, we could do it this way:
ref_counted()
: pCount(new (std::no_throw) int(1))
{ }
void acquire(P p)
{
if (!pCount) throw 0;
}
And then mandate that ownership_policy is not usable until acquire()
has been called, avoiding further checks for pCount == 0. Hopefully,
requiring all no-throw default c'tors will not impose an undue penalty
on policies.
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
