Daniel Frey wrote:
On Tue, 25 Feb 2003 08:34:43 +0100, Nicola Musatti wrote:
[...]
I don't have a strong opinion in either direction, but I do feel that it
is important that this is thought over. Overloading checked_delete() on
purpose in a user defined namespace might be considered a way to provi
David B. Held wrote:
[...]
> and then just store Base*, but this requires explicit run-time
> checking of types which would otherwise be automatic with pointers to
> T instead of optional. If this is the only solution, so be it;
> but any clever alternatives are welcome.
This example is not obj
Fernando Cacciola wrote:
[...]
> That would have to be _measured_; my guess is that it could be twice
> slower, specially considering that I don't think boost sources will
> ever include assembly
> code; it's a portability nightmere.
I've just generated some code, and the compiler can even optim
"David B. Held" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> I think optional might be perfect for an issue I have, but there is one
> catch.
> I have a polymorphic hierarchy that I would like to use with optional, but
> optional is not a base of optional. Of course, this is
"Philippe A. Bouchard" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> Fernando Cacciola wrote:
>
> [...]
>
> > It seems there is something one of us don't understand...
> > optional::m_storage has nothing to do with alignment to 'int'
> > unless T happens to be aligned just lik
Jason Shirk <[EMAIL PROTECTED]> writes:
> From: David Abrahams
>>> Hum, it looks like Microsoft took you up on it.
>>
>>Well, it was MS I was haranguing most-loudly about it.
>
> I don't recall a discussion on warnings about ADL, I'll need a
> refresher.
I remember mentioning it to you in Herb'
> I would be searching namely for smart_ptr. I know that smart pointer is
> the name for the resource management idiom.
But those that don't would look for "resource_manager" or "resource_mgr"
(and might even find "res_mgr"). The smart_ prefix is quite useless in
this context, there isn't an o
>From: "Jason House" <[EMAIL PROTECTED]>
> >
> > std::vector > test;
> >
> > std::cout << test: // Using defaults
> >
> > (('A',1),('B',2),('C',3))
>
> I would suspect that chars don't get output with '' around them...
Right. I was just thinking C++ code, here. :)
> Is there even a way to specify
From: David Abrahams Hum, it looks like Microsoft took you up on it. >>Well, it was MS I was haranguing most-loudly about it.
I don't recall a discussion on warnings about ADL, I'll need a refresher. I do recall a discussion we had on non-dependent names.
>> See the shared_ptr_test warning
William E. Kempf wrote:
> Edward Diener said:
>> William E. Kempf wrote:
>> I still don't think it is a TLS issue but rather a thread cleanup
>> issue and the restrictions imposed by MS's design of that situation.
>> So I can well understand your chagrin at the tricks you must do in
>> order to cle
When Mark Terribile proposed a class like this way back in
the last century I think he called it "releaser".
At 04:00 PM 2/25/2003, Rozental, Gennadiy wrote:
>> This is an excellent point. One doesn't go looking for a class
>> named "smart_ptr" or a library named "Boost.SmartPointer" when
>> look
> This is an excellent point. One doesn't go looking for a class
> named "smart_ptr" or a library named "Boost.SmartPointer" when
> looking to manage the lifetime of some arbitrary resource. When
> one uses pointers, it makes sense.
I would be searching namely for smart_ptr. I know that smart po
Edward Diener said:
> William E. Kempf wrote:
>> Edward Diener said:
>>> William E. Kempf wrote:
And it's full of issues.
You are quite limited in what you can safely do within DllMain. Any
calls to synchronization routines is likely to deadlock the entire
process.
>>>
>>> I
I think optional might be perfect for an issue I have, but there is one
catch.
I have a polymorphic hierarchy that I would like to use with optional, but
optional is not a base of optional. Of course, this isn't
really a problem with optional, par se, but any suggestions on how to store
pointers t
William E. Kempf wrote:
> Edward Diener said:
>> William E. Kempf wrote:
>>> And it's full of issues.
>>> You are quite limited in what you can safely do within DllMain. Any
>>> calls to synchronization routines is likely to deadlock the entire
>>> process.
>>
>> I agree that this is so. You can'
On Tue, 25 Feb 2003 21:14:14 +0100, David Abrahams wrote:
> Daniel Frey <[EMAIL PROTECTED]> writes:
>
>> David Abrahams wrote:
>>>
>>> Daniel Frey <[EMAIL PROTECTED]> writes:
>>>
>>> > That won't work as you made it a nested struct so it is still
>>> > different for all instantiations. I think
On Tue, 25 Feb 2003, David Abrahams wrote:
> namespace boost
> {
>struct safe_bool
>{
>int value;
>typedef int safe_bool::*type;
>};
> }
>
> struct myclass
> {
>operator boost::safe_bool::type() const
>{
> return expression ? &boost::safe_bool::value : 0;
Daniel Frey <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>>
>> Daniel Frey <[EMAIL PROTECTED]> writes:
>>
>> > That won't work as you made it a nested struct so it is still different
>> > for all instantiations. I think Dave meant to go for this one:
>>
>> Yup, that's what I meant. BTW,
Hi all,
On Tue, 25 Feb 2003, Fernando Cacciola wrote:
>
> "Peter Dimov" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > template void * operator new(size_t n, optional & t);
> >
>
> Anyway, there are still problems with this: operator new is called _before_
> the T is cons
David Abrahams wrote:
>
> Daniel Frey <[EMAIL PROTECTED]> writes:
>
> > That won't work as you made it a nested struct so it is still different
> > for all instantiations. I think Dave meant to go for this one:
>
> Yup, that's what I meant. BTW, so this safe_bool thing can get
> further re-used
Daniel Frey <[EMAIL PROTECTED]> writes:
> That won't work as you made it a nested struct so it is still different
> for all instantiations. I think Dave meant to go for this one:
Yup, that's what I meant. BTW, so this safe_bool thing can get
further re-used it might make sense to make a special
From: Jason House <[EMAIL PROTECTED]>
>
> Well, being relatively a newbie at all this stuff, I have to admit
> that the initial discussion of performing a lock using a (smart)
> pointer, seemed odd to me. Someone later "clarified" that a smart
> pointer doesn't need to use * and -> operators...
Terje Slettebø wrote:
>
> >From: "Jason House" <[EMAIL PROTECTED]>
>
> > Terje Slettebø wrote:
> > > In a way, something good came from it, as well: I've recently looked at
> > > Boost.Tuple, and I see that they have I/O operators defined (in
> > > tuple_io.hpp).
> >
> > Well, it definitely see
"Sam Partington" <[EMAIL PROTECTED]> writes:
> I think I agree, we want to provide as little restrictions as possible.
>
> Also seems to me that anyone who declares a global template operator!
> deserves some problems!
I don't know why you think so.
> So, now with David's suggestion, I've attach
"William E. Kempf" wrote:
[...]
> > explicit scoped_lock(lightweight_mutex & m): m_(m)
> > {
> > while( InterlockedExchange(&m_.l_, 1) )
> > {
> > // Note: changed to Sleep(1) from Sleep(0).
> > // According to MSDN, Sle
Sam Partington wrote:
>
> I think I agree, we want to provide as little restrictions as possible.
Dave's argument is a good one. I agree, too.
> So, now with David's suggestion, I've attached what I propose.
That won't work as you made it a nested struct so it is still different
for all instant
Daniel Frey <[EMAIL PROTECTED]> writes:
> Sam Partington wrote:
>>
>> I thought of this too, but this limits the user to using a member based
>> operator!. So I couldn't do this :
>>
>> class A : public boost::bool_testable
>> {
>> public:
>> int get();
>> };
>>
>> bool operator!(const A&
Please remember that stats can be more general. I frequently use stats for
complex types. In that case, mean is also complex, but var is scalar. The
proposed implementation doesn't address this.
On Tuesday 25 February 2003 12:29 am, Jason D Schmidt wrote:
> I know this is well after the discu
Peter Dimov wrote:
>
> Your example works for me. Qualified identifiers such as
> boost::checked_delete disable ADL, and foo::boost::checked_delete isn't
> found.
I wasn't aware of this, so I assume that this is the standard's way of
handling it and not just some compilers. Thanks.
Regards, Dani
I think I agree, we want to provide as little restrictions as possible.
Also seems to me that anyone who declares a global template operator!
deserves some problems!
So, now with David's suggestion, I've attached what I propose.
I've tested to a small extent on MSVC6 and gcc 2.95, which are all
Russell Hind said:
> Is yield intended to always yield to another thread if one can run?
> Because the code for yield is
>
> void thread::yield()
> {
> #if defined(BOOST_HAS_WINTHREADS)
> Sleep(0);
> #elif defined(BOOST_HAS_PTHREADS)
> # if defined(BOOST_HAS_SCHED_YIELD)
> int res = 0
Sam Partington wrote:
>
> I thought of this too, but this limits the user to using a member based
> operator!. So I couldn't do this :
>
> class A : public boost::bool_testable
> {
> public:
> int get();
> };
>
> bool operator!(const A& a)
> {
> return a.get() == 0;
> }
>
> Of course I
Daniel Frey wrote:
> I wasn't thinking of the user to drop things into boost, this is
> obvbiously not supported. I was thinking of this:
>
> namespace foo {
> namespace boost { // <-- Is this "allowed" by boost?
> template< typename T >
> void checked_delete( T* );
> }
>
> class A {}
Edward Diener said:
> William E. Kempf wrote:
>>> You can clean up your own TLS index ( or indices ) in your DllMain
>>> routine when the seond parameter is DLL_PROCESS_DETACH, meaning that
>>> your process is being exited. AFAIK this is the standard way to do
>>> this.
>>
>> (Note: The issue is m
Peter Dimov wrote:
>
> Daniel Frey wrote:
> >
> > Any reason why you went for 'boost::' instead of '::boost::' for the
> > prefix? IMO only the latter expresses exactly what we want or do we
> > rely on user to never create sub-namespaces called 'boost'? Although
> > this is not very likely, we sh
Fernando Cacciola wrote:
[...]
> Yes, that's why I was thinking of something that were overloaded for T
> rather than for optional.
>
> Anyway, there are still problems with this: operator new is called
> _before_ the T is constructed, so there won't be a way, AFAICT, to
> properly set the initia
"Peter Dimov" <[EMAIL PROTECTED]> writes:
>> Hum, it looks like Microsoft took you up on it. See the
>> shared_ptr_test warning on the VC++ 7.1 beta regression test.
>
> No, C4675 is the opposite of what Dave wants. Earlier MSVC didn't support
> ADL at all, and MSVC 7.1 is now issuing the warning
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 08:34 AM 2/25/2003, David Abrahams wrote:
>
> >Beman Dawes <[EMAIL PROTECTED]> writes:
> >
> >> Go ahead and make the change, unless someone voices an objection.
> >>
> >> I'm wondering how may other places we have similar problems?
> >
> >Now yo
"Sam Partington" <[EMAIL PROTECTED]> writes:
> I thought of this too, but this limits the user to using a member based
> operator!. So I couldn't do this :
>
> class A : public boost::bool_testable
> {
> public:
> int get();
> };
>
> bool operator!(const A& a)
> {
> return a.get() == 0;
>
Daniel Frey wrote:
>
> Any reason why you went for 'boost::' instead of '::boost::' for the
> prefix? IMO only the latter expresses exactly what we want or do we
> rely on user to never create sub-namespaces called 'boost'? Although
> this is not very likely, we shouldn't place any restrictions on
Beman Dawes wrote:
> At 08:34 AM 2/25/2003, David Abrahams wrote:
>
> >Beman Dawes <[EMAIL PROTECTED]> writes:
> >
> >> Go ahead and make the change, unless someone voices an objection.
> >>
> >> I'm wondering how may other places we have similar problems?
> >
> >Now you know why I've been m
Daniel Frey wrote:
> Nice idea! I already had something similar in mind, but you managed to
> make it really generic.
Not really, all I've done is to borrow the code from shared_ptr, and to put
into a shape like one of the existing unary operator helpers in
operator.hpp. Thanks anyway though :-)
Daniel Frey wrote:
>
> The only problem I see is that an instance of safe_bool_conversion is
> created which is not really needed. I suggest to rely on the operator!
> provided by T:
>
> template< class T, class B = ::boost::detail::empty_base >
> struct bool_testable : B
> {
> private:
>type
> In case any of you don't have enough to do (!) I've placed the next draft of
> my regular expression standardisation proposal at
> http://www.regex.fsnet.co.uk/n1429dft.htm, as ever comments, nit picks etc
> are very welcome (the deadline for this revision is Monday the 3rd March).
A minor nit:
David Abrahams wrote:
[...]
> Once again, the case was:
>
> {
> aligned_storage::type storage;
>
> new ((void*)&storage) T(x, y, z); // throws
>
> // ~aligned_storage() destroys non-existent T
> }
>
> The question is not what happens if aligned_storage::type throws
A Nit Pick :
The column headings in the first table are displaced to the left
( see ECMAScript - comparing ECMA and POSIX regular expressions )
Keith Burton
[EMAIL PROTECTED] wrote:
> Guys,
>
> In case any of you don't have enough to do (!) I've placed the next
> draft of my regular expression
Peter Dimov wrote:
>
> Daniel Frey wrote:
> > Hi,
> >
> > I came across the following problem:
> >
> > When I have a class X which lives in a namespace where there's a
> > function 'checked_delete' declared that can take a X*, smart_ptr (and
> > probably others) that use checked_deleter (note the
At 08:34 AM 2/25/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> Go ahead and make the change, unless someone voices an objection.
>>
>> I'm wondering how may other places we have similar problems?
>
>Now you know why I've been making such a stink about insidious ADL!
>
>
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>
> [...]
>
>>> What will happen to a normal type then?
>>
>> What is a "normal type"?
>
> Any type besides optional.
>
>>> {
>>> T storage = T(x, y, z); // throws
>>>
>>> // storage.~T() destroys non-existent T
>>
Philippe A. Bouchard wrote:
[...]
> It's true. Imagine we have some partial specialization of array size_t>:
>
> template
> struct array
> {
> char value_[I >> 3];
>
> // Read-only version:
> bool operator [] (unsigned int a_index) const
> {
>
Beman Dawes <[EMAIL PROTECTED]> writes:
> Go ahead and make the change, unless someone voices an objection.
>
> I'm wondering how may other places we have similar problems?
Now you know why I've been making such a stink about insidious ADL!
> Is there any programatic way to detect them?
I've be
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> David Abrahams wrote:
> > "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> >
> >> No, right're right :-)
> >> Is perfectly possible to simply discard it, though to me it looks
> >> kind of akward in anything but deeply lo
> Essentially you supply a operator! and it supplies an unspecified-bool-type
> conversion operator.
Nice idea! I already had something similar in mind, but you managed to
make it really generic.
> //Key
> //T: primary operand type
> //t: values of type T
>
> // TemplateSupplied Operatio
David Abrahams wrote:
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
>> No, right're right :-)
>> Is perfectly possible to simply discard it, though to me it looks
>> kind of akward in anything but deeply low-level code.
>>
>> Anyway, doesn't this require a definition of placement operator new
Is yield intended to always yield to another thread if one can run?
Because the code for yield is
void thread::yield()
{
#if defined(BOOST_HAS_WINTHREADS)
Sleep(0);
#elif defined(BOOST_HAS_PTHREADS)
# if defined(BOOST_HAS_SCHED_YIELD)
int res = 0;
res = sched_yield();
assert(re
Nicola Musatti wrote:
> I don't have a strong opinion in either direction, but I do feel that
> it
> is important that this is thought over. Overloading checked_delete()
> on purpose in a user defined namespace might be considered a way to
> provide
> a smart pointer with a custom deleter. Is this
Beman Dawes wrote: [about inintended ADL]
> I'm wondering how may other places we have similar problems?
Many. ;-)
> Is there any programatic way to detect them?
I don't think there is, but even if there was, I'd suggest leaving things as
they currently are, and waiting for the actual problem r
Thomas Witt <[EMAIL PROTECTED]> writes:
> Hi,
>
> There is a reference to the 1.29.0 distribution in
>
> boost/libs/mpl/doc/index.html#source
>
> Shouldn't this be removed before 1.30 is branched?
I think Aleksey is planning to check in completely new docs before
1.30 goes out.
--
Dave Abraham
Daniel Frey wrote:
> Hi,
>
> I came across the following problem:
>
> When I have a class X which lives in a namespace where there's a
> function 'checked_delete' declared that can take a X*, smart_ptr (and
> probably others) that use checked_deleter (note the 'r'!) cannot call
> checked_delete.
"Sam Partington" <[EMAIL PROTECTED]> writes:
> Hi,
>
> While making myself an interim shared_resource class, I found myself reusing
> the shared_ptr safe-bool conversion, and thought that really the idiom ought
> to go into the operators library.
>
> I am unsure about the name, but for now bool_te
Alexander Terekhov <[EMAIL PROTECTED]> writes:
> I have yet to see a compelling reason to embrace the MS
> ``TLS-template'' innovation.
Ah. Well, that's an entirely different matter ;-). I was going on
the assumption that there was a reasonable argument for the existence
of the feature, and jus
Michael Stevens <[EMAIL PROTECTED]> writes:
> Dear Boosters,
>
> This is just a quick reminder of regression before boost_1_30_0 gets
> released. Without CVS access I can fix it myself and Jens seems to be
> offline at the moment. It would be great if someone could step in and
> make a simple corr
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> "Ken Hagan" <[EMAIL PROTECTED]> writes:
>
> | Gabriel Dos Reis wrote:
> | >
> | > This analgoy does not cut it: You don't have a function "fk" by
> | > thread. You have a -single- function designator. And the return
> | > value depends on the calling
Sorry for confusion, the reply below obviously belongs to a different
thread.
Aleksey Gurtovoy wrote:
> Andreas Huber wrote:
> > P.S. Is it a good idea to use mpl::aux::msvc_eti_base on all platforms
(on
> > conforming compilers I'd expect it to "call" mpl::identity) or should I
> > #ifdef my way
Andreas Huber wrote:
> P.S. Is it a good idea to use mpl::aux::msvc_eti_base on all platforms (on
> conforming compilers I'd expect it to "call" mpl::identity) or should I
> #ifdef my way around it?
Yep, it's intentionally written in the way so that you don't have to #ifdef
in your code.
Aleksey
Hi,
There is a reference to the 1.29.0 distribution in
boost/libs/mpl/doc/index.html#source
Shouldn't this be removed before 1.30 is branched?
Thomas
--
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +4
Andreas Huber wrote:
> P.S. Is it a good idea to use mpl::aux::msvc_eti_base on all platforms (on
> conforming compilers I'd expect it to "call" mpl::identity) or should I
> #ifdef my way around it?
Yep, it's intentionally written in the way so that you don't have to #ifdef
in your code.
Aleksey
Guys,
In case any of you don't have enough to do (!) I've placed the next draft of
my regular expression standardisation proposal at
http://www.regex.fsnet.co.uk/n1429dft.htm, as ever comments, nit picks etc
are very welcome (the deadline for this revision is Monday the 3rd March).
For those of y
Hi,
While making myself an interim shared_resource class, I found myself reusing
the shared_ptr safe-bool conversion, and thought that really the idiom ought
to go into the operators library.
I am unsure about the name, but for now bool_testable seems to match the
naming style used by the rest of
"Ken Hagan" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| >
| > This analgoy does not cut it: You don't have a function "fk" by
| > thread. You have a -single- function designator. And the return
| > value depends on the calling thread.
|
| Whereas with a TLS variable you have a single
"Ken Hagan" <[EMAIL PROTECTED]> writes:
| Alexander Terekhov wrote:
| >
| > Uhmm. In return, I venture to suggest that MS-TLS can and shall be
| > characterized as ``utterly busted.''
|
| Fine, but the OP asked about existing practice and the bugs
| don't change the fact that "&k" can be a templa
Ken Hagan wrote:
>
> Alexander Terekhov wrote:
> >
> > Uhmm. In return, I venture to suggest that MS-TLS can and shall be
> > characterized as ``utterly busted.''
>
> Fine, but the OP asked about existing practice and the bugs
> don't change the fact that "&k" can be a template parameter
> if th
> From: Michael Stevens [mailto:[EMAIL PROTECTED]
>
> Correction required for boost/random/lognormal_distribution.
Fixed, thanks!
Bjorn Karlsson
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Somewhere in the E.U., le 25/02/2003
Bonjour
In article <[EMAIL PROTECTED]>,
Jason D Schmidt <[EMAIL PROTECTED]> wrote:
> I know this is well after the discussion on the stats class has ended,
> but I think I have a good idea here.
>
> Scott Kirkwood proposed a class that behaves somethin
Alexander Terekhov wrote:
>
> Uhmm. In return, I venture to suggest that MS-TLS can and shall be
> characterized as ``utterly busted.''
Fine, but the OP asked about existing practice and the bugs
don't change the fact that "&k" can be a template parameter
if the compiler is willing to thunk its wa
Dear Boosters,
This is just a quick reminder of regression before boost_1_30_0 gets
released. Without CVS access I can fix it myself and Jens seems to be
offline at the moment. It would be great if someone could step in and
make a simple correction.
The regression is the the return values of t
Gabriel Dos Reis wrote:
>
> This analgoy does not cut it: You don't have a function "fk" by
> thread. You have a -single- function designator. And the return
> value depends on the calling thread.
Whereas with a TLS variable you have a single variable name and
the value of that variable when refe
On Tue, 25 Feb 2003 08:34:43 +0100, Nicola Musatti wrote:
> Beman Dawes wrote:> At 07:32 PM 2/24/2003, Daniel Frey wrote:
>> >Hi,
>> >
>> >I came across the following problem:
>> >
>> >When I have a class X which lives in a namespace where there's a
>> >function 'checked_delete' declared tha
78 matches
Mail list logo
