"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.
Unfortu
"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 dif
"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 pro
"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 t
"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
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 m
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
"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...
"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 constructio
"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
> co
"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_pt
"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
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 orig
"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
"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.
> [...]
> S
"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
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 functi
"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 orchest
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.
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]> 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_pt
"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
"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_pt
"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 ano
"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 differ
"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 t
"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,
"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. Sti
"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
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 benchma
"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 seem
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
- 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 \
> >
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
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
>> compile
"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 t
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/g
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 do
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
>CXXFL
"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:
> -
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
"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 gi
>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
"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
> s
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 s
"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
>> ar
"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
>
>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_suit
"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 lik
"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 An
"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,
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 ten
"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 s
>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 int
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
"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 pu
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
-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_deri
[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 lo
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
"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 conse
"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
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< EdgePrope
"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
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_tes
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
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
c
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
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< EdgePro
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,
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
"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
>> >
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
"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:
> >>
>
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
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
do
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_ty
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 s
"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
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_o
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?
"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
"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]>
>> >> [...]
>>
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...
> |
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.dkuu
> 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
> 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 beha
> 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 L
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
___
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 cor
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
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 easie
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
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 p
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 saf
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_deriv
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,
97 matches
Mail list logo
