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 that can take a X*, smart_ptr (and probably
>others)
>that use checked_deleter (
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 something like this:
stats myStats; for (int i = 0; i < 100;
++i) {
myStats.add(i); } cout <<
"Average: " << myStats.
William E. Kempf wrote:
> Edward Diener said:
>> "William E. Kempf" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>>
>>> Edward Diener said:
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Ken Hagan wrote:
>>
>> Alexan
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
>
> Storage never gets constructed if T(x,y,z) throws, so it is also
> n
Fernando Cacciola wrote:
[...]
> Anyway, doesn't this require a definition of placement operator new
> for each T?
Maybe for each optional if I am on the same wave length.
Philippe A. Bouchard
___
Unsubscribe & other changes: http://lists.boost.
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 like 'int', which won't always be
> the case, so I don't
> see the relation between optional's storage a
>From: "Jason House" <[EMAIL PROTECTED]>
> Terje Slettebø wrote:
> >
> > >From: "Vladimir Prus" <[EMAIL PROTECTED]>
> >
> > Sorry for having taken so long to respond to these messages. I felt a
need
> > for a break, to consider how it might be done.
>
> I was wondering about this line of discussio
"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 for each
> T?
I don't know,
Edward Diener said:
> "William E. Kempf" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>
>> Edward Diener said:
>> > "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
>> > news:[EMAIL PROTECTED]
>> >>
>> >> Ken Hagan wrote:
>> >> >
>> >> > Alexander Terekhov wrote:
>> >> >
"Stephen Lamb" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> I'm not absolutely sure I have the latest class optional but here goes.
>
> Why does optional not have an assignment operator which takes a value?
>
Experience shown that this question is hard to answer convincely..
At 03:41 PM 2/24/2003, Thomas Witt wrote:
>I am looking for volunteers who are willing to act as review manager. Due
>to the increasing number of review requests the current pool of review
>managers just isn't enough. As of now we do have a backlog of five
>outstanding reviews. For those intereste
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 that can take a X*, smart_ptr (and probably
>others)
>that use checked_deleter (note the 'r'!) cannot call c
"Philippe A. Bouchard" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> Fernando Cacciola (Home) wrote:
>
> [...]
>
> >> Well it depends on the platform but if sizeof(bool) == sizeof(int) on
> > Intel,
> >
> > ^^^
> > Were does this 'int' comes from?
>
> sizeof(bool) may vary
"David Abrahams" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> > I thougth about placement new as a way to achieve
> > in-place optional construction, precisely because of the forwarding
> > problem, but I couldn't get it to
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>
> [...]
>
>> look:
>>
>> {
>> aligned_storage::type storage;
>>
>> new ((void*)&storage) T(x, y, z); // throws
>>
>> // ~aligned_storage() destroys non-existent T
>> }
>
Daniel Frey <[EMAIL PROTECTED]> writes:
> 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. It's
> ambiguous due to argumen
David Abrahams wrote:
[...]
> look:
>
> {
> aligned_storage::type storage;
>
> new ((void*)&storage) T(x, y, z); // throws
>
> // ~aligned_storage() destroys non-existent T
> }
What will happen to a normal type then?
{
T storage = T(x, y, z
I'm going to check in the following patch to ref.hpp, which makes the
traits into valid MPL metafunctions. It introduces a dependency on
one new file (boost/mpl/bool_c.hpp), but that's truly the cleanest
way to get there. If there are any objections, I'm willing to employ
less-clean methods, but
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
>> And if the object's constructor throws an exception, what then?
>
> I am not familiar with exceptions that much, but calling implicitly
> the object's destructor will not affect its construction if the user
> does not forget to call its constru
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. It's
ambiguous due to argument depe
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Edward Diener said:
> > "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> >>
> >> Ken Hagan wrote:
> >> >
> >> > Alexander Terekhov wrote:
> >> > >
> >> > > I, for one, believe st
David Abrahams wrote:
[...]
>> Everything seems already defined ;)
>
> ???
Every time I'm thinking about something, I find that it was already defined
somewhere else.
>> Given the fact optional<>::m_storage is aligned like a bool...:
>>
>> - Maybe aligned_storage<> should always destruct its ob
Fernando Cacciola (Home) wrote:
[...]
>> Well it depends on the platform but if sizeof(bool) == sizeof(int) on
> Intel,
>
> ^^^
> Were does this 'int' comes from?
sizeof(bool) may vary, you just don't know (1, 4, 8, ...). On Intel, if
sizeof(bool) == 4 == sizeof(int) optional<>::m_storage w
Fernando Cacciola wrote:
[...]
>> Yes, something like that. I am curious to know how in_place<> works.
>>
> Look at the thread "'optional' - request for extension"
> Essentilly,
>
> in_place(a0,a1,a2...)
>
> just creates a function object which holds onto the argument list:
>
> template
> struct
"Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> I thougth about placement new as a way to achieve
> in-place optional construction, precisely because of the forwarding
> problem, but I couldn't get it to really work.
> What would it be like, exactly?
>
> I considered:
>
> (a)
>
> optional opt (
Terje Slettebø wrote:
>
> >From: "Vladimir Prus" <[EMAIL PROTECTED]>
>
> Sorry for having taken so long to respond to these messages. I felt a need
> for a break, to consider how it might be done.
I was wondering about this line of discussion earlier today... wondering
if it died on the vine o
The attached document was submitted for publication to C/C++ Users Journal
today, but I thought it might be worth submitting to Boost as well.
Perhaps my spelling class template could be folded into type_traits?
Robert Allan Schwartz
Have you ever wished you could convert a template parameter to
Edward Diener said:
> "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>
>> Ken Hagan wrote:
>> >
>> > Alexander Terekhov wrote:
>> > >
>> > > I, for one, believe strongly that "&k" is nothing but
>> > >
>> > > "static_cast(pthread_getspecific(__k_key));"
>>
"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Fernando Cacciola (Home) wrote:
>
> [...]
>
> > I'm still not sure I understand what are you trying to do, but it
> > looks
> > like you want optional with in-place construction (which bypasses the
> > copy). In t
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Fernando Cacciola \(Home\)" <[EMAIL PROTECTED]> writes:
>
> > optional opt( in_place(point(0,0),point(10,10)));
> >
> > here, in_place() is used to forward T's ctor argument to optional<> so
that
> > T is effectively co
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Ken Hagan wrote:
> >
> > Alexander Terekhov wrote:
> > >
> > > I, for one, believe strongly that "&k" is nothing but
> > >
> > > "static_cast(pthread_getspecific(__k_key));"
> > >
> > > It *isn't* a compile-tim
- Original Message -
From: "Philippe A. Bouchard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 24, 2003 6:31 PM
Subject: [boost] Re: Re: Re: Re: partial<> proposal
> Fernando Cacciola wrote:
>
> [...]
>
> >> Given the fact optional<>::m_storage is aligned like a boo
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
>> Can you really do anything to make this cleaner? I guess:
>>
>> aligned_storage storage;
>> new (storage.bytes) T(x, y, z);
>>
>> might be a help. What else are you gaining? And how do you destroy
>> the T? If not explicitly and you
Fernando Cacciola wrote:
[...]
>> Given the fact optional<>::m_storage is aligned like a bool...:
>>
> It is not aligned like a bool...
Well it depends on the platform but if sizeof(bool) == sizeof(int) on Intel,
m_storage will be aligned to the next word boundary i.e. aligned like an
integer.
"Fernando Cacciola \(Home\)" <[EMAIL PROTECTED]> writes:
> optional opt( in_place(point(0,0),point(10,10)));
>
> here, in_place() is used to forward T's ctor argument to optional<> so that
> T is effectively constructed in-place right within the aligned storage.
>
> Is this what you want?
I have
Fernando Cacciola (Home) wrote:
[...]
> I'm still not sure I understand what are you trying to do, but it
> looks
> like you want optional with in-place construction (which bypasses the
> copy). In this case, I recently explored something which would look
> like:
>
> optional opt( in_place(point(
"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> David Abrahams wrote:
> > "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> >
> >> Yes, exactly. Sorry if I wasn't precise enough.
> >>
> >> The bool type will cancel type_with_alignment<> effects (at least on
[ ... ]
> > Has anyone else ever encountered similar problems with either 7.0 or
6.5?
>
>
> Yep, it's a known bug called "early template instantiation" (ETI). It's
> briefly described here -
> http://lists.boost.org/MailArchives/boost/msg39915.php.
>
> > Are there any workarounds?
>
>
> Sure. In yo
David Abrahams wrote:
> "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
>
>> Yes, exactly. Sorry if I wasn't precise enough.
>>
>> The bool type will cancel type_with_alignment<> effects (at least on
>> Intel compatible platforms); i.e. unique alignment of each
>> optional type.
>
> Sounds like
Hi,
I am looking for volunteers who are willing to act as review manager. Due to
the increasing number of review requests the current pool of review managers
just isn't enough. As of now we do have a backlog of five outstanding
reviews. For those interested in the details I have updated the re
- Original Message -
From: "Philippe A. Bouchard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 24, 2003 4:29 PM
Subject: [boost] Re: Re: Re: partial<> proposal
> David Abrahams wrote:
>
> [...]
>
> >> Example:
> >> optional i;
> >>
> >> new (i) int(17);
> >
> > Whic
>From: "Vladimir Prus" <[EMAIL PROTECTED]>
Sorry for having taken so long to respond to these messages. I felt a need
for a break, to consider how it might be done.
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
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>
> [...]
>
>>> Example:
>>> optional i;
>>>
>>> new (i) int(17);
>>
>> Which copy ctor are you referring to?
>> And why do we want to prevent copy ctor usages?
>
> Because optional<> will be able to handle types without co
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> Yes, exactly. Sorry if I wasn't precise enough.
>
> The bool type will cancel type_with_alignment<> effects (at least on Intel
> compatible platforms); i.e. unique alignment of each optional type.
Sounds like you want
type_with_alignment:
David Abrahams wrote:
[...]
>> Example:
>> optional i;
>>
>> new (i) int(17);
>
> Which copy ctor are you referring to?
> And why do we want to prevent copy ctor usages?
Because optional<> will be able to handle types without copy constructors
(this was the main purpose of partial<> in fact). I
David Abrahams wrote:
[...]
>>> Example:
>>> optional i;
>>>
>>> new (i) int(17);
>>
>>
>> Ex. 1:
>> // Class Widget has a heavy copy constructor
>> optional i;
>>
>> new (i) Widget(this, ...);
>
>
> Soo... what are you demonstrating here? Please spell it out. Normal
> construction of a widget i
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> Maybe the following placement operator new can help prevent copy constructor
> usages:
> #include
>
> template
> class optional
> {
> friend void * operator new (size_t, optional &);
>
> ...
> };
>
> template
>
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> Philippe A. Bouchard wrote:
>
> [...]
>
>> Example:
>> optional i;
>>
>> new (i) int(17);
>
>
> Ex. 1:
> // Class Widget has a heavy copy constructor
> optional i;
>
> new (i) Widget(this, ...);
Soo... what are you demonstrating here? Please
David Abrahams wrote:
> I'd like to be able to stick all the generated code for using
> get_deleter(sp), for a given X, on one side of a shared library
> boundary. The closest thing I've been able to find in the public
> interface is:
>
> my_get_deleter(shared_ptr(sp))
>
> but that incurs refe
Philippe A. Bouchard wrote:
[...]
> Example:
> optional i;
>
> new (i) int(17);
Ex. 1:
// Class Widget has a heavy copy constructor
optional i;
new (i) Widget(this, ...);
Ex. 2:
// The object A is aligned like a char
struct A
{
char c_;
A() : c_('\0') {}
A(char a_c) : c_(a_c) {}
David Abrahams wrote:
[...]
>> 2) Placement operator new (size_t, boost::optional &) definition
>> which I highly suggest.
>
> Your response is a bit too terse for me to understand. Care to
> clarify a bit?
Maybe the following placement operator new can help prevent copy constructor
usages:
#in
I'd like to be able to stick all the generated code for using
get_deleter(sp), for a given X, on one side of a shared library
boundary. The closest thing I've been able to find in the public
interface is:
my_get_deleter(shared_ptr(sp))
but that incurs reference-counting, at the very least.
David Abrahams wrote:
> "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
>
>> I would like to propose partial<> when you wish to postpone an
>> object's construction:
>> http://groups.yahoo.com/group/boost/files/shifted_ptr/partial.hpp
>
> How is this different from the recently-accepted opti
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
>>
>>> I would like to propose partial<> when you wish to postpone an
>>> object's construction:
>>> http://groups.yahoo.com/group/boost/files/shifted_ptr/partial.hp
David Abrahams wrote:
> "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
>
>> I would like to propose partial<> when you wish to postpone an
>> object's construction:
>> http://groups.yahoo.com/group/boost/files/shifted_ptr/partial.hpp
>
> How is this different from the recently-accepted opti
"Ken Hagan" <[EMAIL PROTECTED]> writes:
| I could write...
|
| int fk() { return k; }
|
| and re-cast my template to expect a pointer to function and then
| write C<&fk>. This is perfectly legal under the current language
| rules, and gives a type whose behaviour depends on the thread that
|
David Abrahams <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > | OK, whatever. I guess I should've said that you can instantiate a
| > | template on &k with sensible results. Whether or not you want to call
| > | it a constant is another semantic matter. I'd ca
Ken Hagan wrote:
>
> Alexander Terekhov wrote:
> >
> > I, for one, believe strongly that "&k" is nothing but
> >
> > "static_cast(pthread_getspecific(__k_key));"
> >
> > It *isn't* a compile-time constant (just like &errno isn't a compile
> > time constant).
>
> MSVC has no pthread_getspecif
All -
This is a reminder about the variant formal review. The
review period was scheduled to end on Tuesday Feb 25th,
but since we got a late start I have asked and received
additional time from the review wizard. The review is now
scheduled to end Sunday March 2nd.
The variant library offers a
PS: I guess your time is limited - as it seems to be for most people :)
- but I just want to make sure you haven't missed it: Somewhere at the
end of the ( heated :-9 ) discussion of is_class I proposed a small
patch which removes the warnings from the regression tests for the GCC -
at least it wor
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> | OK, whatever. I guess I should've said that you can instantiate a
> | template on &k with sensible results. Whether or not you want to call
> | it a constant is another semantic matter. I'd call it a constant
> | which evaluates differently in di
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> I would like to propose partial<> when you wish to postpone an object's
> construction:
> http://groups.yahoo.com/group/boost/files/shifted_ptr/partial.hpp
How is this different from the recently-accepted optional class
template?
--
Dave
Thomas Witt <[EMAIL PROTECTED]> writes:
> Greg
>
> On Sunday 23 February 2003 20:03, Greg Colvin wrote:
> > At 03:34 AM 2/23/2003, Thomas Witt wrote:
> > >Greg,
> > >
> > >I can not figure out how you make sure to satisfy the alignment
> > > constraints of T and counted_base_header_impl. Any hint
Alexander Terekhov wrote:
>
> I, for one, believe strongly that "&k" is nothing but
>
> "static_cast(pthread_getspecific(__k_key));"
>
> It *isn't* a compile-time constant (just like &errno isn't a compile
> time constant).
MSVC has no pthread_getspecific(), so I venture to suggest that
your b
Greeting,
I would like to propose partial<> when you wish to postpone an object's
construction:
http://groups.yahoo.com/group/boost/files/shifted_ptr/partial.hpp
The partial object is aligned like an object of type T and reserves
enough memory space to hold it, of course. partial<> uses
65 matches
Mail list logo
