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
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
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
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
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:
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
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
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.
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
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
|
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
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
John Maddock [EMAIL PROTECTED] writes:
I've always felt that is_base_and_derived is a funny name. is_base_ofB,
D
and is_derived_fromD, B 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
John Maddock wrote:
I've always felt that is_base_and_derived is a funny name. is_base_ofB,
D
and is_derived_fromD, B 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_derivedvoid, X
should be false?
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 {
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
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
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_traitsG::edge_property_type?
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
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.
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
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
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
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,
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
Hi Volodya,
On Wed, 29 Jan 2003, Vladimir Prus wrote:
ghost
ghost Oh.. I only now realized how to use ReabablePropertyGraph concept:
ghost
ghostfunction_requires ReadablePropertyGraphConceptG, edge, edge_weight_t ();
ghost
ghost Are you suggesting that this become
ghost
ghost
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
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 vectorvertex::iterator,
property_mapG, vertex_index_t alternative = ...
The problem is that I have to pass
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
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
templatetypename T void
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
Jeremy,
On Wed, 29 Jan 2003, Vladimir Prus wrote:
ghost
ghost Oh.. I only now realized how to use ReabablePropertyGraph concept:
ghost
ghostfunction_requires ReadablePropertyGraphConceptG, edge, edge_weight_t ();
ghost
ghost Are you suggesting that this become
ghost
ghost
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
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?
-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
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
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
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
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
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
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
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
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
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
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:
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:
- 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 \
(...), /*
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
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
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
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
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
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
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
Philippe A. Bouchard [EMAIL PROTECTED] wrote in message
b19hhg$i2m$[EMAIL PROTECTED]">news:b19hhg$i2m$[EMAIL PROTECTED]...
[...]
list shifted_ptrT took0.0002951000 seconds to construct.
list shifted_ptrT took7.1966276647 seconds to reconstruct 2000
times.
list shifted_ptrT
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
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:
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:
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
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
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
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
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
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
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
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 typename U
void ref_counted::acquire(U const p)
{
}
template typename U
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
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
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.
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
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
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
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,
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
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
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,
76 matches
Mail list logo
