On Saturday, August 16, 2003, at 8:06 AM, David Abrahams wrote:
Thanks. I'll keep my fingers crossed...
Still no joy :(
Could you elaborate? Perhaps I could help.
-Howard
___
Unsubscribe other changes:
On Monday, July 14, 2003, at 05:18 AM, John wrote:
class nat {nat();};
How about not_a_type?
It's a little more to type, but looks much better (IMHO).
And shouldn't it be :
struct not_a_type {};
As Peter pointed out, such a class can have several uses. In some of
the contexts I've used it,
On Sunday, July 13, 2003, at 07:04 PM, Howard Hinnant wrote:
class rw_mutex
{
public:
typedef detail::read_lockrw_mutex read_lock;
typedef detail::write_lockrw_mutex write_lock;
...
};
I'm not picky about the names read_lock and write_lock. Then these
locks could have
On Sunday, July 13, 2003, at 08:49 AM, Peter Dimov wrote:
Maybe the problems are caused by overloading void_. I haven't looked
at MPL
recently, but as a general observation I have identified at least
three uses
of a void_-like entity.
1. A type parameter used to emulate a variable argument
On Sunday, July 13, 2003, at 12:17 PM, Gabriel Dos Reis wrote:
Howard Hinnant [EMAIL PROTECTED] writes:
| Another possible spelling for this animal is:
|
| class nat {nat();};
|
| Inspired from nan. In this case means Not A Type.
Ahem, a class is a type, no matter how you name it.
Really, I
On Wednesday, July 2, 2003, at 06:06 PM, Jaakko Jarvi wrote:
libs/utility/test/enable_if*
Would it be possible to augment the enable_if_constructors.cpp test
with a templated container? Maybe something like:
template class charT
struct string
{
template class It
string(It begin, It end,
On Wednesday, July 9, 2003, at 04:31 PM, Jaakko Jarvi wrote:
Yes it would be possible. Just committed in.
Thanks!
Breaks in g++ 3.2.
ICC 7 accepts.
Metrowerks? Must works, you wouldn't have asked otherwise, right :)
chuckle Yes, it works, and yes I do have ulterior motives, though
they are
On Thursday, July 3, 2003, at 11:05 AM, Schoenborn, Oliver wrote:
I could sure use some feedback about how the technique stands to
generic
algorithms.
I'm not sure how this will work with your library, but the below
example is meant to illustrate the kind of accidental ownership
transfer I am
On Tuesday, July 1, 2003, at 11:45 PM, Larry Evans wrote:
There's also:
http://pcroot.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/
Docs/books/FS/FS_59.html
whose TInstanceOf or TOnlyPointerTo may be what your wanting.
Interesting, thanks for the link.
TInstanceOf appears to have copy
On Wednesday, July 2, 2003, at 12:06 AM, Schoenborn, Oliver wrote:
I have experimented (actual working code) with what you're
looking for. But the tools are *experimental* and not ready for prime
time public use.
So have I.
Just to be clear, what I was working with required both an experimental
On Monday, June 30, 2003, at 06:04 PM, Philippe A. Bouchard wrote:
Suppose you have:
struct functor1
{
listvoid * m_list;
void operator () ()
{
...
}
};
struct functor2
{
listvoid * m_list;
void operator () ()
{
On Tuesday, July 1, 2003, at 08:21 PM, Schoenborn, Oliver wrote:
On Tuesday, Jul 1, 2003, at 17:36 America/Denver, Schoenborn, Oliver
wrote:
On Tuesday, Jul 1, 2003, at 14:38 America/Denver, Boost wrote:
Why is there no strict-ownership smart-pointer in boost?
Just curious to know what the
On Sunday, June 29, 2003, at 07:17 AM, Philippe A. Bouchard wrote:
What I was looking for was to gather information for each specific
thread
about their heap usages. A thread oriented implementation would allow
synchronized information without using mutexes.
Hmm... would
On Saturday, June 28, 2003, at 02:43 PM, Philippe A. Bouchard wrote:
Hi there,
I was wondering if you were planning to implement some static
thread
thread::current() that returns the current thread id ( thread). That
would
be really useful.
The thread default constructor serves this
On Saturday, June 28, 2003, at 06:32 PM, Philippe A. Bouchard wrote:
Thanks... but is it possible to obtain the initial address of the
functor
object portably, given the current thread object?
To the best of my knowledge, no. As currently designed the thread
constructor is not required to
On Thursday, June 26, 2003, at 01:24 PM, Alexander Terekhov wrote:
Howard Hinnant wrote:
Since boost is a spring board for standardization of a library, I'm
wondering if the boost license requires the copyright notice to follow
for other implementations which follow the interface of the boost
On Thursday, June 26, 2003, at 07:51 PM, Beman Dawes wrote:
A copyright, unlike a patent, just applies to the actual
representation. So unless another implementation actually made a
literal copy of the Boost code, the other implementation would not be
a derived work of the Boost code and so
On Tuesday, June 17, 2003, at 10:53 AM, David Abrahams wrote:
You might also infer how good a compiler's language support is in
some cases, but that takes a much more sophisticated view.
Most pointy-haired managers and newbies are convinced they are
sophisticated enough to use the results in
On Thursday, June 12, 2003, at 12:43 PM, Nigel Stewart wrote:
I can see the appeal here in using a circular buffer in
this manner, while at the same time I'm cooling against
the compromise of insert auto-resizes, while push doesn't
which seems inconsistant. Given
On Wednesday, June 11, 2003, at 05:55 PM, Dave Gomboc wrote:
Why is
a deque inadequate?
deque is more expensive than a resizing circular buffer in both
performance and code size. One also can not control *when* deque will
allocate as one can with a resizing circular buffer. In a nutshell, a
On Tuesday, June 10, 2003, at 05:20 AM, Jan Gaspar wrote:
Hi Howard!
I like your idea. But (referring to the Nigel Stewart's posting) what
would you
propose for the insert? Should I not provide it?
Jan
Howard Hinnant wrote:
In article [EMAIL PROTECTED], Alisdair Meredith
[EMAIL PROTECTED] wrote
On Tuesday, June 10, 2003, at 10:48 AM, Jan Gaspar wrote:
insert in general should have the basic exception safety guarantee.
But when inserting only one element at either end, the strong
guarantee
is in place.
I think the strong guarantee can reached only in case the
cyclic_buffer is not
full
On Tuesday, June 10, 2003, at 11:33 AM, Nigel Stewart wrote:
Constant time push/pop_front, constant time push/pop_back. When begin
and end collide, reallocation automatically happens vector-like.
Another point to consider:
Constant time push/pop can not be combined with std::vector
);
Container tmp(c); // assumes tmp.capacity() == c.size()
c.swap(tmp);
}
}
// etc.
private:
Container c;
};
--
Howard Hinnant
Metrowerks
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thursday, May 29, 2003, at 12:29 AM, Daryle Walker wrote:
I'm trying to fix up the I/O library submission I gave a few months
ago, and came up with an issue with a copy constructor and GCC. I
explicitly wrote a copy constructor for a new stream-buffer class
template. I just added test
On Thursday, April 3, 2003, at 05:04 AM, Peter Dimov wrote:
So if someone has an opinion about this potential change to
scoped_ptr, now
is probably the right time to express it.
I've been experimenting with:
templateclass T, class D = detail::apply_delete
class move_ptr;
So far I like it. It
On Thursday, March 20, 2003, at 05:17 PM, Eric Niebler wrote:
It's not a compiler thing. Look at the implementation:
http://www.boost.org/boost/detail/call_traits.hpp
template typename T
struct call_traitsT
{
typedef T value_type; // -- problem here
typedef T reference;
typedef const
On Thursday, March 13, 2003, at 02:24 AM, Daryle Walker wrote:
3. To the Metrowerks guys on this list, what is the difference between
regular CodeWarrior Pro and the Dev Studio I got? The web site is
somewhat vague, but I think the only difference is that the number of
tools in Dev Studio is
On Thursday, March 13, 2003, at 10:34 AM, David Abrahams wrote:
Howard Hinnant [EMAIL PROTECTED] writes:
Developers Studio is a stripped down version of CodeWarrior Pro. It
only has CodeWarrior for Mach-O compilers and linkers for
C/C++/Objective C/Objective C++.
There is no Java support
On Saturday, March 8, 2003, at 07:28 AM, Beman Dawes wrote:
So Howard was right - BOOST_NO_STDC_NAMESPACE is defined but shouldn't
be.
Look at boost/config/posix_features.hpp, around line 38:
# ifndef __APPLE_CC__
// GCC strange ignore std mode works better if you pretend everything
// is
Custom deleter policy + implicit conversion policy - converting
constructors - converting assignment operators == smart pointer that
handles arrays.
-Howard
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tuesday, February 4, 2003, at 10:56 PM, Paul Mensonides wrote:
Howard Hinnant wrote:
Custom deleter policy + implicit conversion policy - converting
constructors - converting assignment operators == smart pointer that
handles arrays.
A custom deleter policy could prevent the use
On Sunday, February 2, 2003, at 11:40 PM, Andrei Alexandrescu wrote:
By and large, I believe smart pointers to arrays are an oxymoron and
should not be supported.
Why?
-Howard
___
Unsubscribe other changes:
On Monday, February 3, 2003, at 12:53 PM, David B. Held wrote:
So, apologies to Howard if it
looked like I was calling him a copycat. That was not my intent in the
least.
No, I did not read your question that way. No apologies necessary at
all.
I plan to implement Mojo in SmartPtr. Does
Thanks Beman.
On Monday, February 3, 2003, at 12:50 PM, Beman Dawes wrote:
At 09:46 PM 2/2/2003, Howard Hinnant wrote:
Could someone review the motivations for wanting an implicit
conversion
to T* ? I'm failing to come up with any myself.
It is useful when it is desirable for the smart
On Monday, February 3, 2003, at 02:44 PM, Andrei Alexandrescu wrote:
Howard Hinnant [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
On Sunday, February 2, 2003, at 11:40 PM, Andrei Alexandrescu wrote:
By and large, I believe smart pointers t
On Saturday, February 1, 2003, at 04:54 AM, Jonathan Wang wrote:
Howard Hinnant [EMAIL PROTECTED] writes:
I've also looked at ntp implementation similar to this (but used Loki
type lists), and agree that this is a neat way to go. Essentially you
just stick the defaults onto the end
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
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
On Tuesday, January 28, 2003, at 11:19 PM, Greg Colvin wrote:
My problem with auto_ptr isn't so much the semantics, which
have proved useful and are probably the minimum needed to
solve the problem that the committee wanted solved. And it
isn't so much the move as copy syntax that Howard
On Thursday, January 30, 2003, at 08:53 PM, Greg Colvin wrote:
Sigh...
To be clear, I'll be happy to see a better syntax
in the next standard -- auto_ptr was the best we
could do with the syntax we had, but ...
Agreed on all points. And glad to have your continued support for a
better
On Tuesday, January 28, 2003, at 01:42 PM, David B. Held wrote:
Also, auto_ptr is an ugly hack that needn't be replicated.
Disavowing your child? ;) Not everyone agrees with you. After all,
we still have scoped_ptr and a move proposal. auto_ptr was just
too far ahead of its time. ;)
On Saturday, January 25, 2003, at 08:39 AM, Peter Dimov wrote:
Furthermore, it is undefined to pass a non-pod to an ellipse
(5.2.2/7):
int foo(...);
class B
{
public:
B();
private:
B(const B);
};
int main()
{
foo(B()); // undefined behavior
}
If you stick that in a sizeof, it is still
On Friday, January 24, 2003, at 08:32 PM, David Abrahams wrote:
Actually, not that it matters, but I think I'm misquoting the original
request, which was, IIRC, tell us whether evaluating this expression
should produce a compilation error. Howard knows for sure...
Yes, that was my proposal,
On Friday, January 24, 2003, at 09:37 PM, Paul Mensonides wrote:
Fortunately circumstances such as the one illustrated above seem to be
rare (at least in my experience). But it is amusing (amazing?) how
many traits like tests are today passing non-POD classes to an
ellipsis, and invoking
On Friday, January 24, 2003, at 09:36 PM, David Abrahams wrote:
Howard Hinnant [EMAIL PROTECTED] writes:
Fortunately circumstances such as the one illustrated
above seem to be rare (at least in my experience). But
it is amusing (amazing?) how many traits like tests are
today passing non-POD
On Friday, January 24, 2003, at 09:12 PM, Howard Hinnant wrote:
struct A
{
private:
A(const A);
};
struct B
: A
{
};
char test[is_convertibleB, A::value];
On Metrowerks this gives:
Error : illegal access from 'A' to protected/private member
'A::A(const A )'
(instantiating
On Saturday, January 11, 2003, at 09:42 AM, Beman Dawes wrote:
Or maybe even just:
template class T
struct my_container
: if_is_PODT::value, impl1, impl2::type
{
...
};
These are the examples that resonate with me, particularly Howard's
version. It looks so easy, and
On Saturday, January 11, 2003, at 01:17 PM, David B. Held wrote:
Howard Hinnant [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[...]
Despite the fact that I suggested it, I don't find it a killer
example.
;-)
I already code stuff like this, with th
On Monday, January 6, 2003, at 01:14 PM, David B. Held wrote:
While this is a cute idea, my first impression would be: Uh...is this
really something I could use in my own code? On the other hand,
I seem to use compile-time if more than anything else, even in user
code. I suspect that most
On Monday, January 6, 2003, at 06:50 PM, David Abrahams wrote:
OK, I see your point. How about:
template class T
struct my_container
: if_
and_
is_pointerT
, is_PODremove_pointerT
, impl1
, impl2
::type
{
...
};
On Friday, December 20, 2002, at 03:21 PM, Samuel Krempp wrote:
Checking today's boost.format regression results, there was new
failures
for the metrowerks compiler.
Was it recently updated ? (now 8.3)
I see boost.format is not the only lib for which the codewarrior
regression status changed.
isn't the current implementation of is_compound overly complex? Can't
we
just change it to basically match:
is_compound = !is_fundamental
given a working version of is_fundamental of course, but this seems
easier than providing an always safe and portable is_class or other
stuff required
On Tuesday, December 17, 2002, at 11:54 AM, Daniel Frey wrote:
It might be useful to distinguish classes into unions and non-unions,
but the standard clearly says that a union *is* a class (9/1).
The standard also clearly says that unions and classes are different
categories of types
On Sunday, November 17, 2002, at 10:01 AM, Peter Dimov wrote:
From: David Abrahams [EMAIL PROTECTED]
I haven't encountered a need to inspect the deleter yet... what
interface
are you suggesting?
How about:
// attempt to extract a deleter of type D
D* d = boost::get_deleterD(p);
55 matches
Mail list logo
