*laugh* I was thinking exactly the opposite. To me, the resource
itself
is clear from the template parameter -- it's the management that
needs to
be indicated.
+1 for managed.
What template parameter? That's not a part of the name.
Template parameters, just like function
First I want to say that I'm not experienced with multitherading, but I
would like to see a standard lib
to solve these situations.
A small question about enforcing correct parameter passing: you have these
typedefs :
// These locks should never be passed by value to functions.
// Instead
Dirk Gerrits [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
[snip]
At what cost? The strings you generate are indeed very readable, but
specializing spelling for every type that might be a template parameter
someday seems like too much of a burden to me.
Others might disagree
- Original Message -
From: Kevin Atkinson [EMAIL PROTECTED]
To: Boost mailing list [EMAIL PROTECTED]
Sent: Saturday, March 01, 2003 12:03 AM
Subject: Re: [boost] Is there any Interest in a Fixed Point Library?
On Fri, 28 Feb 2003, Stephen Nutt wrote:
Kevin,
I started on this
OK, I've finally shipped my ACCU talk slides and can concentrate on 1.30.0.
Sorry for the delays.
One issue surfaced mid-week; some Win32 compilers (VC++, possibly others)
are silently failing to compile certain source lines terminated with a CR
only. (The traditional Apple Mac line
I believe a standardized (within Boost), portable, and *readable* text
representation of T makes my proposal better than typeid().
I think if readability is the main criterion we'd do much better to
invest in decoding the typeids generated by GCC. I believe there's
even a library that
I think that is a problem too. Maybe a macro could make things easier:
#define DECLARE_SPELLABLE( a_type ) \
template class spellinga_type { public: static const std::string
result; }; \
const std::string spellingmy_enum::result = #a_type
but this should be preferrable be put in headers,
On Sat, 1 Mar 2003, Thorsten Ottosen wrote:
First I want to say that I'm not experienced with multitherading, but I
would like to see a standard lib
to solve these situations.
A small question about enforcing correct parameter passing: you have these
typedefs :
// These locks should
Kevin Atkinson wrote:
This is a repost of my Lock Classes. Hopefully this time I will get some
constructive feedback. These classes have the following features.
1) The ability to acquire a lock and release it when the object
goes out of scope effectively implemented the Monitor
Greg Colvin wrote:
Which is why the original releaser proposal is not in the standard.
There are just too many different kinds of resource, with too many
different ways of acquiring and releasing them. So it wasn't clear
that any general facility could improve on just wrapping each resource
At 10:16 AM 3/1/2003, Alisdair Meredith wrote:
Greg Colvin wrote:
Which is why the original releaser proposal is not in the standard.
There are just too many different kinds of resource, with too many
different ways of acquiring and releasing them. So it wasn't clear
that any general
Beman Dawes [EMAIL PROTECTED] writes:
OK, I've finally shipped my ACCU talk slides and can concentrate on
1.30.0. Sorry for the delays.
Beman, it appears that you didn't tag the trunk at the branch point,
which will make multiple merges to the branch more difficult. Do you
want me to do it?
David Abrahams [EMAIL PROTECTED] writes:
Beman Dawes [EMAIL PROTECTED] writes:
OK, I've finally shipped my ACCU talk slides and can concentrate on
1.30.0. Sorry for the delays.
Beman, it appears that you didn't tag the trunk at the branch point,
which will make multiple merges to the
Robert Allan Schwartz [EMAIL PROTECTED] writes:
I believe a standardized (within Boost), portable, and *readable* text
representation of T makes my proposal better than typeid().
I think if readability is the main criterion we'd do much better to
invest in decoding the typeids generated
At 01:01 PM 3/1/2003, David Abrahams wrote:
David Abrahams [EMAIL PROTECTED] writes:
Beman Dawes [EMAIL PROTECTED] writes:
OK, I've finally shipped my ACCU talk slides and can concentrate on
1.30.0. Sorry for the delays.
Beman, it appears that you didn't tag the trunk at the branch point,
Kevin,
The classes still need much work (read as not fully implemented and full of
bugs etc). They compiler under MSVC++ 6.0 but you may find that you need to
add the following typedefs to get it to compile.
typedef unsigned __int64uintmax_t;
typedef __int64 intmax_t;
What is there to fix? Of course yield only yields to equal priority
threads (one hopes that higher priority threads have already pre-empted).
At Tuesday 2003/02/25 08:26, you wrote:
Russell Hind said:
Is yield intended to always yield to another thread if one can run?
Because the code for
At Tuesday 2003/02/25 09:10, you wrote:
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.
You sure lost me. Would you care to point out _where_ the
The tag is RC_1_30_0
I'm going to take a break for the rest of the weekend, and then we should
get together a list of what needs to be done before the actual release.
Thanks,
--Beman
___
Unsubscribe other changes:
Kevin Atkinson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Sat, 1 Mar 2003, Thorsten Ottosen wrote:
First I want to say that I'm not experienced with multitherading, but I
would like to see a standard lib
to solve these situations.
A small question about enforcing
On Sat, 1 Mar 2003, Thorsten Ottosen wrote:
Is this the best way to enforce this? Why not just make lock objects
noncopyable?
Um, they are. This typedef are strictly for convenience and readability.
what convenience and what readability? C++ programmers are use to const
XX
Beman Dawes [EMAIL PROTECTED] writes:
The tag is RC_1_30_0
Didn't we agree that we were going to tag the trunk and generally do
any merges from the trunk to the branch? This tag appears to be on
the branch AFAICT.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
Hi Boosters,
The container algorithms are almost finished (at least for complient
compilers). This means we can do the following for all standard algorithms:
int array[] = { };
std::pairiterator,iterator = ...;
vector v = ;
std::copy( one_of_the_three_containers, one_of_the_containers
23 matches
Mail list logo
