File: lock.hpp
//
// Copyright (c) 2002,2003
// Kevin Atkinson
//
// Permission to use, copy, modify, distribute and sell this software
// and its documentation for any purpose is hereby granted without
// fee, provided that the above copyright notice appear in all copies
// and that both that copyright
worthy addition
to boost I will be willing to being it up to boost standards. But for
right now please refrain from making comments on coding style or the
like.
---
http://kevin.atkinson.dhs.org
// File: example.cpp
//
// Copyright (c) 2003
// Kevin Atkinson
//
// Permission to us
s.
That may work if it can be determined at compile time when a fixed amount
of memory is acceptable. Sometimes this can not be determined at compile
time however.
Generic algorithms will work just fine as look as the available memory
isn't being exceeded. When it doesn't, my B
Is there any interest in a vector like container which is designed to make
working with raw memory easy. It is different from a vector (with
the additional assumption that the objects are stored in memory
sequentially) is the following ways:
The integrator is defined to be a pointer to make
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
>
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 s
On Fri, 28 Feb 2003, Stephen Nutt wrote:
> Kevin,
>
> I started on this must be close to a year ago, and I got wrapped up with
> other stuff and never got back to it.
Well I don't have a large interest in it beyond simple arithmetic. The
main reason that I wrote is to avoid having to deal with
er learning the hard way that "Lock l0(l)" is a bad idea.
See code for details
--
http://kevin.atkinson.dhs.org
// File: example.cpp
//
// Copyright (c) 2003
// Kevin Atkinson
//
// Permission to use, copy, modify, distribute and sell this software
// and its documentation for any
On Thu, 27 Feb 2003, Jason House wrote:
> Kevin Atkinson wrote:
> >
> > On Thu, 27 Feb 2003, Jason House wrote:
> > > One thought... It looks like the template parameter should be an integer
> > > type (of course, right?)... I think that there is some way to
On Thu, 27 Feb 2003, Paul A. Bristow wrote:
> Yes - this looks potentially rather useful for some tasks, especially embedded
> systems.
> Why on earth didn't the language include fixed point and/or fractional types?
Well in order for fractions to be really useful, that is to support exact
values
On Thu, 27 Feb 2003, Jason House wrote:
> Kevin Atkinson wrote:
> >
> > Is there any interest in a fixed point math library.
>
> Well, I'm interested in a fixed point library :)
> Especially if it can be used as a template argument in place of a
> floating
brary for anything beyond simple
arithmetic.
--
http://kevin.atkinson.dhs.org
// Copyright (c) 2003
// Kevin Atkinson
//
// Permission to use, copy, modify, distribute and sell this software
// and its documentation for any purpose is hereby granted without
// fee, provided that the above copy
On Thu, 20 Feb 2003, Alexander Terekhov wrote:
> Kevin Atkinson wrote:
> >
> > On Thu, 20 Feb 2003, Alexander Terekhov wrote:
> >
> > > > I have changed the definition to:
> > > >
> > > > #ifdef FAST_MUTEX_INIT_DESTROY
> >
On Thu, 20 Feb 2003, Alexander Terekhov wrote:
> > I have changed the definition to:
> >
> > #ifdef FAST_MUTEX_INIT_DESTROY
> ^^^
>
> > static const pthread_mutex_t MUTEX_INIT = PTHREAD_MUTEX_INITIALIZER;
>
> Uhmm. What does your "fast destruction" do? Well, looki
On Thu, 20 Feb 2003, Peter Dimov wrote:
> Kevin Atkinson wrote:
> > #ifdef FAST_MUTEX_INIT_DESTROY
> > Mutex() : l_(MUTEX_INIT) {}
> > #else
> > Mutex() {pthread_mutex_init(&l_, 0);}
> > ~Mutex() {pthread_mutex_destroy($l_);}
> > #endi
On Wed, 19 Feb 2003, Kevin Atkinson wrote:
> On Wed, 19 Feb 2003, Alexander Terekhov wrote:
>
> > struct pthread_mutex_t_ {
> >
> > /* ... */
> >
> > #ifdef __cplusplus
> >
> > __copy_ctor(const pthread_mutex_t_&) {
> &g
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
> struct pthread_mutex_t_ {
>
> /* ... */
>
> #ifdef __cplusplus
>
> __copy_ctor(const pthread_mutex_t_&) {
> throw "Don't do this!";
> }
>
> #endif
>
> };
> typedef struct pthread_mutex_t_ pthread_mutex_t;
I do not know
On Wed, 19 Feb 2003, Kevin Atkinson wrote:
> On Wed, 19 Feb 2003, Alexander Terekhov wrote:
>
> > Kevin Atkinson wrote:
>
> > > > static const pthread_mutex_t MUTEX_INIT = PTHREAD_MUTEX_INITIALIZER;
> > > >
> > > > class Mutex {
> > >
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
> Kevin Atkinson wrote:
> > > static const pthread_mutex_t MUTEX_INIT = PTHREAD_MUTEX_INITIALIZER;
> > >
> > > class Mutex {
> > >pthread_mutex_t l_;
> >
On Wed, 19 Feb 2003, William E. Kempf wrote:
First off, just in case you didn't realize it, this message was directed at
one person not the group in general. I cced it to the list. I *hate*
forced reply-to.
> > Are you, or are you not interested in my Lock Classes. The messages I
> > got fr
On Wed, 19 Feb 2003, Edward Diener wrote:
> I think the question that needs to be answered is if locking mechanisms have
> any use outside of threading models.
Yes they do. For example when accessing memory shared between separate
process. Also, locks can also be used when accessing files. In
te forced reply-to. The message was directed at
Gennadiy Rozental but I CCed it to the boost mailing list.
> Kevin Atkinson wrote:
> >
> > > your Mutex class offers undefined behavior;
> > > you really can NOT "replicate" a {pthread_mutex_t} mutex.
> >
On Wed, 19 Feb 2003, Kevin Atkinson wrote:
> On Wed, 19 Feb 2003, Alexander Terekhov wrote:
>
> > Kevin Atkinson wrote:
> >
> > > I have got very little indication that you actually looked at what my
> > > classes are offering.
> >
> > Uhm
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
> Kevin Atkinson wrote:
>
> > I have got very little indication that you actually looked at what my
> > classes are offering.
>
> Uhmm. "Original-To" aside,
What does that mean?
> your Mutex class offers unde
Are you, or are you not interested in my Lock Classes. The messages I got
from you is that you are only interested in my lock classes if
1) It is reproposed as an extension to the locking mechanism in Boost
thread.
and/or
2) It is reworked to somehow be an extension of the smart pointer
On Tue, 18 Feb 2003, Gennadiy Rozental wrote:
> > > 1. Does not Boost.Thread already have locking mechanisms
> >
> > The only thing boost threads offer is #1 on my list, that is "The ability
> > to acquire a lock and release it when the object goes out of scope
> > effectively implemented the "Mon
On Tue, 18 Feb 2003, Gennadiy Rozental wrote:
> Two comments:
>
> 1. Does not Boost.Thread already have locking mechanisms
The only thing boost threads offer is #1 on my list, that is "The ability
to acquire a lock and release it when the object goes out of scope
effectively implemented the "Mon
On Tue, 18 Feb 2003, Fernando Cacciola (Home) wrote:
> Kevin, we're currently in the middle of a release and a formal review...
> If you wait a week or so.. and recall our attention, you're likely to get a
> response.
> Just hold on.
No problem. I'm in no rush. If I don't get any response expre
I posted this a couple days ago and have yet to seen any sort of reply or
any sign that anyone is interested. If people are having trouble
understanding the concept please let me know and I will try harder to
explain it. If you meant to reply but haven't yet, sorry for being
impatient.
If no
it up to boost standards. But for
right now please refrain from making comments on coding style or the
like.
--
http://kevin.atkinson.dhs.org
// File: example.cpp
//
// Copyright (c) 2003
// Kevin Atkinson
//
// Permission to use, copy, modify, distribute and sell this software
// and its docume
If people are interested I would like to present several possible
additions to the Boost library. I will be willing to answer questions
about my code but won't be willing to modify my code to boost standards as
I simply don't have the time.
They are:
A generic hash table based on the SGI ha
31 matches
Mail list logo
