Hi All,
I'm probably being stoopid, but if someone could point me in the right
direction, thanks :)
I've got this:
boost::any test = "Test Me";
int nTest=0;
try
{
nTest = boost::any_cast(test);
}
catch(const boost::bad_
Greg Dehaas wrote:
Hi All,
boost::any test = "Test Me";
[...]
And the error message is:
c:\dev\boost\boost\any.hpp(105) : error C2536: 'boost::any::holder::held' : cannot specify explicit initializer for arrays
c:\dev\boost\boost\any.hpp(122) : see declaration of 'held'
c:\d
On Fri, 31 Jan 2003 10:12:42 +0200, Greg Dehaas <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I'm probably being stoopid, but if someone could point me in the right
> direction, thanks :)
>
> I've got this:
>
> boost::any test = "Test Me";
boost::any test = std::string("Test Me");
On Thu, 30 Jan 2003 20:29:18 +0100, Terje Slettebø
<[EMAIL PROTECTED]> wrote:
>You don't need expressions (if by that you mean an object of the type to
>test, or pointer/reference to it) to check for convertibility, as it may be
>done with sizeof, so no object of any kind need to be created. Howev
- Original Message -
From: "Vladimir Prus" <[EMAIL PROTECTED]>
> Greg Dehaas wrote:
> > Hi All,
>
> > boost::any test = "Test Me";
> [...]
> > And the error message is:
> > c:\dev\boost\boost\any.hpp(105) : error C2536: 'boost::any::holder > [8]>::held' : cannot specify explicit initia
Thanks guys :)
-Original Message-
From: Vladimir Prus [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 31, 2003 11:02 AM
To: Boost mailing list
Subject: Re: [boost] any_cast issues
Greg Dehaas wrote:
> Hi All,
> boost::any test = "Test Me";
[...]
> And the error message is:
>
Hi,
I compiled boost_1_29_0 libraries with gcc-3.2.1 ,
copied the libboost_thread.a library to HOME and tried to compile
a small thread test program:
with:
g++ -I/opt/boost_1_29_0 -L/home/pberg -lboost_thread -lpthread tt.cc
I get:
/tmp/ccjTcBBI.o: In function `main':
/tmp/ccjTcBBI.o(.text+0x
Shimshon Duvdevan wrote:
[ ... Solaris -> PTHREAD_SCOPE_SYSTEM ... ]
> Can anyone verify the supposed boost threads library behavior on a
> multi-processor Solaris machine? Is this behavior the intended one?
> Perhaps a bug fix is necessary.
That's Solaris' bug and actually, they've already ki
From: "David B. Held" <[EMAIL PROTECTED]>
>
> smart_ptr(P p)
> : storage(p), ownership(p), checking(), conversion()
> { checking::on_init(p) }
smart_ptr(P p)
: storage(p), ownership(p), checking(p), conversion()
{}
is nicer. Maybe even conversion(p), for consistency. :-)
But that's not w
On Thu, 30 Jan 2003 18:43:19 +0100, Daniel Frey
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota wrote:
>>
>> to avoid changes not forced by compiler bugs. Incidentally, I noticed
>> that if you add a default argument
>>
>> template
>> static yes check(D const volatile *, T = 0);
>> static no ch
From: "Joel de Guzman" <[EMAIL PROTECTED]>
> From: "Vladimir Prus" <[EMAIL PROTECTED]>
>
> > Hmm... the same problem can be seen if you try
> >
> > std::make_pair("1", "2");
[...]
> Yes, but a library can make it work. For instance, make_tuple("hello, ",
"world")
> works as expected. QOI matt
From: "David B. Held" <[EMAIL PROTECTED]>
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > That is a very clean approach, and assuming it's OK to keep the
> > the sole copy of p in storage_policy, even efficient.
>
> I'm not sure anyone woul
From: "Howard Hinnant" <[EMAIL PROTECTED]>
>
> Imho, standardized move syntax/semantics is very close to the top of
> important issues for C++. I guess that's why I'm pushing for current
> smart pointers to get "the right syntax" for move semantics.
But can they get the right syntax without &&
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> In short, trying to support auto_ptr, shared_ptr, and weak_ptr will either
> destroy the design, or make it stronger. :-)
Didn't we decide weak_ptr isn't a _ptr after all? If so, doesn't that
get Dave off the hook for trying to support it using the sma
> The technique I know relies on detecting whether the template argument
> is *derived* from some policy, and that's doable with expressions.
> That's why I asked you what was the exact technique you were using.
> Also, if you have any (other) example where "convertibility of a type"
> is needed I
> Maybe you had the following variation on Terje's code in mind.
>
> The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1:
Hey, now that one really does work well, I'm still testing here (doesn't
work with Borland, but I have a fallback position for that), but if there
are no objection
--- John Maddock <[EMAIL PROTECTED]> wrote:
> One question though - a lot of people seem to have worked on this: which
> people deserve the copyright/credit listing?
Rani only, IMO.
Genny.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable
Somewhere in the E.U., le 31/01/2003
Bonjour
Given my recent (and now solved, thanks!) problems with the
Boost.Test framework and bind, I felt I needed some exercice. As I
believe this may be of interest to others, and do not know where to put
it where it can be found (perhaps include
The issue is not about creating objects or not but about what does it
mean for "a type" to be convertible to another. Personally I have no
idea what the meaning can be. Instead, the standard specifies what it
means for an "expression" to be implicitly convertible to another:
4/3: An expression e
Joel de Guzman wrote:
Hmm... the same problem can be seen if you try
std::make_pair("1", "2");
the template parameters are deduces as char[1] and char[1], and there's no
much you can do with that type, not even copy it. That's the way template
argument deduction works, IIRC. I suggest that
--- John Maddock <[EMAIL PROTECTED]> wrote:
>
> > The technique I know relies on detecting whether the template argument
> > is *derived* from some policy, and that's doable with expressions.
> > That's why I asked you what was the exact technique you were using.
> > Also, if you have any (other)
From: "Hubert Holin" <[EMAIL PROTECTED]>
>eater(::boost::bind(std::mem_fun_ref(&(A::operator ())), a));
eater(a) is much simpler, I think.
>eater(::boost::bind(std::mem_fun_ref(&(AN::operator ())), an, 1));
eater(bind(an, 1));
___
Unsubscribe
"John Maddock" <[EMAIL PROTECTED]> writes:
>> Maybe you had the following variation on Terje's code in mind.
>>
>> The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1:
>
> Hey, now that one really does work well, I'm still testing here (doesn't
> work with Borland, but I have a fallba
"John Maddock" <[EMAIL PROTECTED]> writes:
>> Maybe you had the following variation on Terje's code in mind.
>>
>> The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1:
>
> Hey, now that one really does work well, I'm still testing here (doesn't
> work with Borland, but I have a fallba
Rani Sharoni wrote:
>
> Here is a weird (but working !) version:
>
> template
> struct helper
> {
> template
> static yes check(int B::*, T);
> static no check(int D::*, int);
> };
>
> // TODO: add cv-qualifiers to B and D
>
> template
> struct is_base_and_derived
> {
> struc
Daniel Frey wrote:
>
> Cool. I modified it a bit, my version works for the GCC 3.2.1 and the
> Intel 7 - with no namespace polution from 'helper':
(And I just noticed it even seems to work for the GCC 2.95.x!)
Regards, Daniel
--
Daniel Frey
aixigo AG - financial training, research and technol
Somewhere in the E.U., le 31/01/2003
In article <00d801c2c927$8d06dd20$1d00a8c0@pdimov2>,
"Peter Dimov" <[EMAIL PROTECTED]> wrote:
> From: "Hubert Holin" <[EMAIL PROTECTED]>
>
> >eater(::boost::bind(std::mem_fun_ref(&(A::operator ())), a));
>
> eater(a) is much simpler, I think.
Hi, I'm having the following problem (?) with mpl::integral_c.
Since it is intended to encapsulate an "Integral Constant",
I thought that it somewhat superseded BOOST_STATIC_CONSTANT.
IOWs, I figured that if I have something of the form:
struct X
{
BOOST_STATIC_CONSTANT( Type, ID = Val ) ;
} ;
>From: "Gennaro Prota" <[EMAIL PROTECTED]>
> --- John Maddock <[EMAIL PROTECTED]> wrote:
> > One question though - a lot of people seem to have worked on this: which
> > people deserve the copyright/credit listing?
>
> Rani only, IMO.
I think so, too.
Regards,
Terje
__
>From: "Gennaro Prota" <[EMAIL PROTECTED]>
> On Thu, 30 Jan 2003 15:13:19 +0100, Terje Slettebø
> <[EMAIL PROTECTED]> wrote:
>
> [...]
> >> Roughly speaking B is a base of D if and only if
> >> the base-specifier-list of D contains a class name for B or for a
> >> class of which B is a base. Of co
On Friday, January 31, 2003, at 07:26 AM, Peter Dimov wrote:
From: "Howard Hinnant" <[EMAIL PROTECTED]>
Imho, standardized move syntax/semantics is very close to the top of
important issues for C++. I guess that's why I'm pushing for current
smart pointers to get "the right syntax" for move s
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> Didn't we decide weak_ptr isn't a _ptr after all? If so, doesn't that
> get Dave off the hook for trying to support it using the smart_ptr
> facade?
That will be my excuse, anyway. I'll j
>From: "David Abrahams" <[EMAIL PROTECTED]>
> "John Maddock" <[EMAIL PROTECTED]> writes:
>
> >> Maybe you had the following variation on Terje's code in mind.
> >>
> >> The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1:
> >
> > Hey, now that one really does work well, I'm still test
>From: "Terje Slettebø" <[EMAIL PROTECTED]>
> >From: "David Abrahams" <[EMAIL PROTECTED]>
>
> > S... Somewhere back in this thread Peter Dimov raised a serious
> > question about whether this implements the semantics we want. Was
> > there ever agreement on that?
>
> As I mentioned in an earl
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
009501c2c923$b4de48a0$1d00a8c0@pdimov2">news:009501c2c923$b4de48a0$1d00a8c0@pdimov2...
> [...]
> shared_ptr keeps a copy of p in the "ownership policy" (the count
> structure.) Its "storage policy" (px) doesn't own the pointer. But I may
> be misun
Terje Slettebø wrote:
>
> You can't prove a negative, an impossibility.
Can you prove that? ;)
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
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
004f01c2c921$aae010b0$1d00a8c0@pdimov2">news:004f01c2c921$aae010b0$1d00a8c0@pdimov2...
> From: "David B. Held" <[EMAIL PROTECTED]>
> >
> > smart_ptr(P p)
> > : storage(p), ownership(p), checking(), conversion()
> > { checking::on_init(p) }
>
>
"Howard Hinnant" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> I presented code under the thread "SmartPtr (Loki) - auto_ptr/move
> c'tor issue" on Jan. 28 which does this. For easy reference, here is
> the code again, slightly improved:
>
> http://hom
From: "Hubert Holin" <[EMAIL PROTECTED]>
> Somewhere in the E.U., le 31/01/2003
>
> In article <00d801c2c927$8d06dd20$1d00a8c0@pdimov2>,
> "Peter Dimov" <[EMAIL PROTECTED]> wrote:
>
> > From: "Hubert Holin" <[EMAIL PROTECTED]>
> >
> > >eater(::boost::bind(std::mem_fun_ref(&(A::operator ())), a
On Fri, 31 Jan 2003 08:27:25 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>S... Somewhere back in this thread Peter Dimov raised a serious
>question about whether this implements the semantics we want. Was
>there ever agreement on that?
Who cares? The new toy is so cool! :-) Seriously, P
Terje Slettebø <[EMAIL PROTECTED]> writes:
> No. You can't prove a negative, an impossibility.
I think that's wrong, and here's my one white crow to prove it ;-)
I can prove that there can never exist a positive integral multiple of 2 which
is both greater than 2 and prime.
It's the same as
"David B. Held" <[EMAIL PROTECTED]> writes:
> "Howard Hinnant" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> [...]
>> I presented code under the thread "SmartPtr (Loki) - auto_ptr/move
>> c'tor issue" on Jan. 28 which does this. For easy reference, here is
"David B. Held" <[EMAIL PROTECTED]> writes:
> "Peter Dimov" <[EMAIL PROTECTED]> wrote in message
> 009501c2c923$b4de48a0$1d00a8c0@pdimov2">news:009501c2c923$b4de48a0$1d00a8c0@pdimov2...
>> [...]
>> shared_ptr keeps a copy of p in the "ownership policy" (the count
>> structure.) Its "storage policy
"David B. Held" <[EMAIL PROTECTED]> writes:
>> smart_ptr(smart_ptr & rhs)
>> : storage(rhs), ownership(rhs), checking(rhs), conversion(rhs)
>> {}
>>
>> Its purpose is to take ownership away from the auto_ptr-like rhs
>> (you wanted to support that) and construct a counted_ptr.
>
> Hmm...I'm no
On Friday, January 31, 2003, at 10:59 AM, David B. Held wrote:
"Howard Hinnant" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[...]
I presented code under the thread "SmartPtr (Loki) - auto_ptr/move
c'tor issue" on Jan. 28 which does this. For easy reference
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Fri, 31 Jan 2003 08:27:25 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>>S... Somewhere back in this thread Peter Dimov raised a serious
>>question about whether this implements the semantics we want. Was
>>there ever agreement on that?
>
At 09:53 AM 1/31/2003, David Abrahams wrote:
>...
>In fact, I have been arguing for years that our smart pointers should
>never have had a public interface which adopts unmanaged resources on
>construction. Instead, we should write:
>
>std::auto_ptr = std::auto_ptr_new(arg1, arg2, arg3);
>
>Vo
>From: "David Abrahams" <[EMAIL PROTECTED]>
> Terje Slettebø <[EMAIL PROTECTED]> writes:
>
> > No. You can't prove a negative, an impossibility.
>
> I think that's wrong, and here's my one white crow to prove it ;-)
>
> I can prove that there can never exist a positive integral multiple of 2
which
David Abrahams wrote:
>
> > Who cares? The new toy is so cool! :-) Seriously, Peter is a wise man.
> > Personally I would go with his suggestion about having two (or more)
> > separate metafunctions, at least for the sake of generality
>
> I'd rather settle on one for the sake of simplicity and s
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> Why "suspiciously?" Both Mojo and Howard's move_ptr followed
> the design of std::auto_ptr.
Oh, I understand they are all using the by_ref trick. I just wanted to
know if there were any s
Greg Colvin <[EMAIL PROTECTED]> writes:
> At 09:53 AM 1/31/2003, David Abrahams wrote:
>>...
>>In fact, I have been arguing for years that our smart pointers should
>>never have had a public interface which adopts unmanaged resources on
>>construction. Instead, we should write:
>>
>>std::auto
"Howard Hinnant" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> ***
> * *
> * Do not move from an lvalue with copy syntax
Hi,
There's an nice implementation of the NTP in boost-sandbox, which follows the idea in
the book "C++ Templates". But we have to repeat the definitions the "feature_is"
classes with virtual inheritance and some typedefs all the time. I wonder if we can
make it eaiser.
Taking the test "car"
"Greg Colvin" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> And I proposed something like this years before that, but
> foundered on not being able to declare a type-safe variadic
> function in C++.
Do you suppose that with the PP lib, we should try so
On Fri, 31 Jan 2003 16:15:49 +0100, Terje Slettebø
<[EMAIL PROTECTED]> wrote:
>>From: "Gennaro Prota" <[EMAIL PROTECTED]>
>> On Thu, 30 Jan 2003 15:13:19 +0100, Terje Slettebø
>> <[EMAIL PROTECTED]> wrote:
>>
>> [...]
>> >> Roughly speaking B is a base of D if and only if
>> >> the base-specifier-
>From: "Daniel Frey" <[EMAIL PROTECTED]>
> David Abrahams wrote:
> >
> > > Who cares? The new toy is so cool! :-) Seriously, Peter is a wise man.
> > > Personally I would go with his suggestion about having two (or more)
> > > separate metafunctions, at least for the sake of generality
> >
> > I'd
On Fri, 31 Jan 2003 12:14:09 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>I'd rather settle on one for the sake of simplicity and see if it's
>enough for people. Once you provide two interfaces, you're sort of
>stuck supporting them both.
Well, then I imagine you would prefer the old semant
"Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> Hi, I'm having the following problem (?) with mpl::integral_c.
>
> Since it is intended to encapsulate an "Integral Constant",
> I thought that it somewhat superseded BOOST_STATIC_CONSTANT.
> IOWs, I figured that if I have something of the form:
>
[Please allow me to suggest that you turn on line wrapping in your
mailer. Most of your paragraphs were just one line]
"Jonathan Wang" <[EMAIL PROTECTED]> writes:
> Hi,
>
> There's an nice implementation of the NTP in boost-sandbox, which
> follows the idea in the book "C++ Templates". But we h
On Fri, 31 Jan 2003 19:30:09 +0100, Gennaro Prota
<[EMAIL PROTECTED]> wrote:
> This wouldn't certainly be
>a new experience for C++, since it has happened with templates or e.g.
>with function call expressions as operand of sizeof.
Well, I meant that 'additional' usages for templates were found,
David Abrahams <[EMAIL PROTECTED]> writes:
> I think the fix is much easier than either of those:
>
> typedef integral_c(value + 1)> next;
> typedef integral_c(value - 1)> prior;
Could you try that and see if it works?
Thanks,
Dave
--
David Abrahams
[EMAIL PRO
On Tue, 28 Jan 2003 19:41:09 +0200, "Peter Dimov" <[EMAIL PROTECTED]>
wrote:
>I've always felt that is_base_and_derived is a funny name.
Just to have a moment of recreation before resuming work... it looks
funny to me too, but for another reason. To an Italian it creates a
strange effect to have
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> > Hi, I'm having the following problem (?) with mpl::integral_c.
> >
> > Since it is intended to encapsulate an "Integral Constant",
> > I though
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> If you want to subsume the current shared_ptr and auto_ptr you'd
> better handle it.
Ok, point taken.
> There are other ways to prevent indiscriminate mixing (an orthogonal
> "interoperabi
"Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>> > So, first of all, do you agree that the mpl form is better?
>>
>> It's "better", but maybe not for the reasons you think ;-). [It has
>> to do with metafunction/metadata polymorphism]
>>
> Also... It is a burden to deal with X::value in bcc5.5
"David B. Held" <[EMAIL PROTECTED]> wrote in message
b1ehpj$j1n$[EMAIL PROTECTED]">news:b1ehpj$j1n$[EMAIL PROTECTED]...
> [...]
> ~InitializerScopeGuard()
> { if (execute_) storage::release(); }
Oops!
~InitializerScopeGuard()
{ if (execute_) storage_.release(); }
Also, I
The first part of this is probably a stupid question
Terje Slettebø wrote:
>
> What makes the template typedef proposal different from the template alias
> proposal, is that the former may be specialised, and the latter may be
> deduced.
What do you mean by deduced? I saw it in the proposal to
On Friday, January 31, 2003, at 12:54 PM, Jonathan Wang wrote:
The default features(types) are stored in a type-vector, and we can
use boost.mpl to update the default features into use-defined ones,
and to extract the updated paramters from type-vector. Then we can use
NTPs later. And even ca
I was seeing something which looked like the regex_timer test ran
forever on my system. Then I looked at the output file, which said
(in Emacs):
Enter expression (or "quit" to exit):
abc^M
Enter string to search (or "quit" to exit):
aaab^M
regex time: 5.7051us
regex
At 10:48 AM 1/31/2003, David Abrahams wrote:
>Greg Colvin <[EMAIL PROTECTED]> writes:
>
>> At 09:53 AM 1/31/2003, David Abrahams wrote:
>>>...
>>>In fact, I have been arguing for years that our smart pointers should
>>>never have had a public interface which adopts unmanaged resources on
>>>constru
Greg Colvin <[EMAIL PROTECTED]> writes:
> At 10:48 AM 1/31/2003, David Abrahams wrote:
>>Greg Colvin <[EMAIL PROTECTED]> writes:
>>
>>> At 09:53 AM 1/31/2003, David Abrahams wrote:
...
In fact, I have been arguing for years that our smart pointers should
never have had a public interfa
Howard Hinnant <[EMAIL PROTECTED]> writes:
> On Friday, January 31, 2003, at 12:54 PM, Jonathan Wang wrote:
>
>> The default features(types) are stored in a
>> type-vector, and we can use boost.mpl to update the
>> default features into use-defined ones, and to
>> extract the updated paramters fr
[Note to moderators: This is just to reply, including giving possible
alternative places to discuss this]
>From: "Jason House" <[EMAIL PROTECTED]>
> The first part of this is probably a stupid question
Not at all. :)
> Terje Slettebø wrote:
> >
> > What makes the template typedef proposal diffe
At 01:44 PM 1/31/2003, David Abrahams wrote:
>>>The move/forwarding proposals will fix that. In the meantime we have
>>>boost::ref(x)... ugly but effective.
>>
>> Can you give us link to that proposal?
>
>You can find it in
>http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/mailings/papers/2002/pre_sant
Hi all,
I've just committed my current ublas version to Boost CVS. It contains
support for the newly added interval library and corresponding tests.
Best,
Joerg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I've seen some talk of fully in-memory databases, and have a few
questions:
1) Does anyone have any experience with them?
2) Would people use them if there were a nice library available?
It seems that such a library could benefit from the serialization/
persistence library. A reference for a Ja
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
007001c2c78e$ca921550$1d00a8c0@pdimov2">news:007001c2c78e$ca921550$1d00a8c0@pdimov2...
> From: "Rani Sharoni" <[EMAIL PROTECTED]>
> >
> > I fogot to show little usability sample:
> >
> > struct B {};
> > struct B1 : B {};
> > struct B2 : B {};
> >
The "People" section of the web site currently has capsule biographies and
pictures for 30 people.
There should probably be two or three times that many people represented;
there are 54 developers with write access to CVS, and beyond those there
are lots of people who make important contributio
Beman Dawes <[EMAIL PROTECTED]> writes:
> Dave,
>
> Your change to boost/mpl/integral_c.hpp broke a lot of
> Borland 5.61 compiles.
I thought something like that might happen on the broken compilers. I
don't really know what the best approach here might be, other than to
take out casts for those
"Larry Evans" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Philippe A. Bouchard wrote:
>
> [snip]
> >
> > I guess it would also be possible to allocate a "shifted object" into
some
> > specific memory page, so operator delete will be able to quickly detect
>
At 04:10 PM 1/31/2003, David B. Held wrote:
>I've seen some talk of fully in-memory databases, and have a few
>questions:
>
>1) Does anyone have any experience with them?
Yes.
>2) Would people use them if there were a nice library available?
Yes.
>It seems that such a library could benefit from
"David B. Held" <[EMAIL PROTECTED]> wrote in message
b1ehpj$j1n$[EMAIL PROTECTED]">news:b1ehpj$j1n$[EMAIL PROTECTED]...
> Actually, you can control mixing by determining which policies can be
> constructed from which other policies. I just didn't know if it was a
> good idea to let users freely mi
"Andrei Alexandrescu" <[EMAIL PROTECTED]> writes:
> "David B. Held" <[EMAIL PROTECTED]> wrote in message
> b1ehpj$j1n$[EMAIL PROTECTED]">news:b1ehpj$j1n$[EMAIL PROTECTED]...
>> Actually, you can control mixing by determining which policies can be
>> constructed from which other policies. I just d
83 matches
Mail list logo
