Gennaro Prota wrote:
On Wed, 19 Feb 2003 18:03:22 +0100, Markus Schöpflin
[EMAIL PROTECTED] wrote:
The main difference is that it casts the NULL to void * and VA6
can deal with that. I just tried. This means that the version on
the branch would work with this compiler.
Ah! Here's where the
"David B. Held" [EMAIL PROTECTED] wrote in messagenews:b2ug4i$a8q$[EMAIL PROTECTED]... "Eric Friedman" [EMAIL PROTECTED] wrote in message news:b2uflv$86s$[EMAIL PROTECTED]... [...] const T r = ...; r.~T(); Even if my understanding is correct though, it may be best for destroyer to take a
Reading various replies, we appear to have a couple of things that
aren't completely pinned down: the type of k and the implementation
of TLS.
1 If k is a regular pointer to integer and TLS is implemented by
tweaking page tables for each thread, then k has the same value
in each thread and
Is there something up with the boost list today? I haven't received anything
on the list since yesterday, though a quick check on gmane indicates that
there has been activity.
Anthony
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely
Itay Maman wrote:
David B. Held [EMAIL PROTECTED] wrote in message
b2ug4i$a8q$[EMAIL PROTECTED]">news:b2ug4i$a8q$[EMAIL PROTECTED]...
Eric Friedman [EMAIL PROTECTED] wrote in message
b2uflv$86s$[EMAIL PROTECTED]">news:b2uflv$86s$[EMAIL PROTECTED]...
[...]
const T r = ...;
r.~T();
Even
Kevin Atkinson wrote:
#ifdef FAST_MUTEX_INIT_DESTROY
Mutex() : l_(MUTEX_INIT) {}
#else
Mutex() {pthread_mutex_init(l_, 0);}
~Mutex() {pthread_mutex_destroy($l_);}
#endif
What makes you think that statically initializing a mutex is faster? It only
defers the initialization until
[Alisdair]
To use an old English idiom, I think you are putting the cart before
the horse [as did Modern C++ Design, IMNSHO]
Resource protection is a useful concept, and pointers are simply
another resource that needs protecting. It makes little sense to
dereference a mutex, for
Did you try to define BOOST_NO_INCLASS_MEMBER_INITIALIZATION for
borland? This will toggle BOOST_STATIC_CONSTANT to use the enum
workaround and might fix most of the problems you are having with BCC
not allowing static constant members as integral constant expressions
in template parameters.
David Abrahams [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] writes:
|
| Ken Hagan [EMAIL PROTECTED] writes:
|
| | Peter Dimov wrote:
| |
| | k does not exist yet at compile-time (in a pointer to int form), when
| | templates are instantiated.
| |
| | It doesn't have
Phil Nash [EMAIL PROTECTED] writes:
However, I still say that the overriding issue here is simply that of
*name*. Smart pointers and resource wrappers are, and still increasingly so,
important concepts. Having such a confusing name-intent relationship is, to
me, very counter-productive
At 05:27 AM 2/20/2003, Anthony Williams wrote:
Is there something up with the boost list today? I haven't received
anything
on the list since yesterday, though a quick check on gmane indicates that
there has been activity.
Early Tuesday (US Central time) an HP router got into a fight with a
Hi!
I'm under the process of getting rid of some of my old
smart pointers replacing them by shared_ptr.
There is however one idiomatic usage that it's pretty
hard to locate and edit, so I wondered if shared_ptr
could support it.
One is initialization from a null pointer value, as in:
struct C
{
Beman Dawes [EMAIL PROTECTED] writes:
At 05:27 AM 2/20/2003, Anthony Williams wrote:
Is there something up with the boost list today? I haven't received
anything
on the list since yesterday, though a quick check on gmane indicates that
there has been activity.
Early Tuesday (US
Fernando Cacciola (Home) wrote:
Hi!
I'm under the process of getting rid of some of my old
smart pointers replacing them by shared_ptr.
There is however one idiomatic usage that it's pretty
hard to locate and edit, so I wondered if shared_ptr
could support it.
I don't think it's a good
Peter Dimov wrote:
[...]
What makes you think that statically initializing a mutex is faster? It only
defers the initialization until the first lock call occurs.
That's the way how it works under win32. ;-)
Plus, pthread_mutex_init gives you the option to test for errors, should you
decide
Kevin Atkinson wrote:
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_
The problem I am encountering now with the current snapshot is a template relative
problem in type_traits/is_based_and_derived.hpp. The compiler asserts; probably
because of a template argument matching problem that the preprocessor has. I'm not
sure, but I would like to find out how to work
Hi all,
This is something I have brought up before and it has come up again on the
Lock Classes thread and I have made some new comments there, as well as
some others touching on the same area:
http://aspn.activestate.com/ASPN/Mail/Message/boost/1544269
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, looking at the
Gabriel Dos Reis [EMAIL PROTECTED] writes:
David Abrahams [EMAIL PROTECTED] writes:
| Let me reiterate, just in case somebody missed it: this is a similar
| problem to that of using a pointer/reference-to-data-member as a
| template paramter. You can think of each thread-local global
On Thu, 20 Feb 2003 09:17:17 +0100, Markus Schöpflin
[EMAIL PROTECTED] wrote:
PS: I'll write to Jeremy about the merge.
Great, thanks.
Thanks to *you*! I've informed him now.
Genny.
___
Unsubscribe other changes:
On Wed, 19 Feb 2003 18:51:42 -0500, Davlet Panech
[EMAIL PROTECTED] wrote:
Hello,
I'm getting the following warning in gcc 3.2/CYGWIN/boost 1.29:
% /cygdrive/c/boost/boost_1_29_0/boost/cast.hpp:178: warning: decimal
constant is so large that it is unsigned
173: static long long min()
174: {
David Abrahams [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] writes:
|
| David Abrahams [EMAIL PROTECTED] writes:
|
| | Let me reiterate, just in case somebody missed it: this is a similar
| | problem to that of using a pointer/reference-to-data-member as a
| | template
Phil Nash [EMAIL PROTECTED] writes:
Pointers are Resources
Resources are not (all) Pointers.
Actually,
Pointers *refer to* resources
Not all pointers refer to (are) resources
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
Gabriel Dos Reis [EMAIL PROTECTED] writes:
David Abrahams [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] writes:
|
| However, my point is that
|
|* a class is closed: that is, by the time you put the closing brace,
| the offset of the data member is a
Alexander Terekhov wrote:
Ken Hagan wrote:
[...]
3a If we allow Ck [...] It is then possible to initialise static
variables [...] and the results depend on the thread that ran
first. Again, we have the same problem passing a pointer to
a function, so I'm not bothered by this.
3b
David Abrahams [EMAIL PROTECTED] writes:
Phil Nash [EMAIL PROTECTED] writes:
Pointers are Resources
Resources are not (all) Pointers.
Actually,
Pointers *refer to* resources
Not all pointers refer to (are) resources
How about:
Pointers are a way of
Ken Hagan wrote:
Alexander Terekhov wrote:
Ken Hagan wrote:
[...]
3a If we allow Ck [...] It is then possible to initialise static
variables [...] and the results depend on the thread that ran
first. Again, we have the same problem passing a pointer to
a function, so I'm
Ken Hagan [EMAIL PROTECTED] writes:
Reading various replies, we appear to have a couple of things that
aren't completely pinned down: the type of k and the implementation
of TLS.
I think you may be missing the point that in some sense k doesn't
have to have a single type. At compile-time it
David Abrahams wrote:
Phil Nash [EMAIL PROTECTED] writes:
Pointers are Resources
Resources are not (all) Pointers.
Actually,
Pointers *refer to* resources
Not all pointers refer to (are) resources
I like word games:
Not all resources are referred to using pointers.
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
^^^
static const pthread_mutex_t MUTEX_INIT =
Pointers are Resources
Resources are not (all) Pointers.
Actually,
Pointers *refer to* resources
Not all pointers refer to (are) resources
How about:
Pointers are a way of referring to resources.
Not all ways of referring to resources
[Anthony Williams]
On Windows, for example, you can use GlobalAlloc to allocate some memory,
and
you get an HGLOBAL back --- a handle to the memory. You need to call
GlobalLock with that handle to get a pointer to the memory which you can
actually use. The resource manager therefore needs to
Phil Nash:
Not all pointers refer to resources.
Hmmm, unless you are thinking of null pointers I can't think of any pointers
that don't refer to resources. Perhaps we have a different definition of
resource?
Or of 'refer to resources'?
char * ptr = new char [12]; // points to
Well the problem I see is that we are using an entity with
pointer written
all over it (the name especially, but also the primary
semantics). Surely
managing general resources according to RAII principles is a
more general
concept than managing pointers to objects?
At the very least
-Original Message-
From: Phil Nash [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 20, 2003 1:13 PM
To: Boost mailing list
Subject: Re: [boost] Re: smart_ptr vs smart_resource
[Anthony Williams]
On Windows, for example, you can use GlobalAlloc to
allocate some memory,
Hmmm, unless you are thinking of null pointers I can't think of any
pointers
that don't refer to resources. Perhaps we have a different definition of
resource?
Or of 'refer to resources'?
char * ptr = new char [12]; // points to (ergo, refers to) resource
char * ptr2 = ptr+4 ; //
[Anthony Williams]
On Windows, for example, you can use GlobalAlloc to
allocate some memory,
and
you get an HGLOBAL back --- a handle to the memory.
[..]
This sounds like a perfect case where using a smart_PTR would be very
confusing, maybe dangerously so!
[Gennadiy]
The only
Hmmm, unless you are thinking of null pointers I can't think of any
pointers
that don't refer to resources. Perhaps we have a different definition of
resource?
Could you elaborate?
I think of resources as things which can be separately managed
independent of other objects. Here are
The only place where you will see usage of the name
smart_ptr is somewhere
deep in library code:
typedef smart_ptr ... GlobalMemoryHandler;
After that you will use non-confusing name GlobalMemoryHandler.
It may work out that way in this case - but why not make the name
Yet an other remark but this time about the answer of Graig Henderson to
Greg Dehass:
Greg,
From the Linker Error, it looks like you're using Microsoft Visual C++. I
discovered a bug recently with MSVC7.0 which may be the same as you're
seeing here, but it is reported to be fixed in Everett.
The
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... something very
non-pointer-like to me...
* The
Peter Dimov wrote:
[snip]
Destroying a const object is fine, but there is no reason to have a const
in
the argument.
templateclass T void call_destructor(T t) { t.~T(); }
X const x;
f(x); // OK, T = X const
f(5); // compile-time fail
Good point. Even though the class is in the detail
Ronald Garcia wrote:
I am attempting to use GCC 3.2 to review the variant library, but I am
getting compile-time errors:
boost/variant.hpp:569: no class template named `mpl' in
`boost::detail::variant
'
boost/variant.hpp:569: parse error before `,' token
boost/variant.hpp:569: template
All,
Using boost 1_29_0, Linux gcc3.2.1.
Just started using boost::bind, like it a lot.
I'm playing around with a little work crew,
which just queues up data, then calls the function
on them later.
bind does a great job of packaging up functions for later use.
is there an analogue for the
In article [EMAIL PROTECTED], Vladimir Prus wrote:
Vincent N. Virgilio wrote:
FYI, xParam (sourceforge) seems to fulfill similar requirements.
I had a brief look at the project before, and looked for another time now.
Are you sure that project called
XParam - General-Purpose Object
Trey Jackson wrote:
Just started using boost::bind, like it a lot.
I'm playing around with a little work crew,
which just queues up data, then calls the function
on them later.
[...]
I'd like to be able to do something like:
,
| work_crew??? mycrew(bind(X::f, x, _1, _2));
Jaakko wrote:
[snip]
Apologies, I cut/paste the wrong name.
Aleksey Gurtovoy wrote the text I quoted.
--
Trey Jackson
[EMAIL PROTECTED]
This man is depriving a village somewhere of an idiot.
-- filed in an officer fitness report in the British Royal Navy
Trey Jackson wrote:
template class DataType, class FunctionType =
boost::function1void,
DataType
class work_crew {
std::listDataType queue_;
FunctionType engine_;
public:
work_crew(FunctionType const tocall);
void add(DataType d) { queue_.push_front(d); };
49 matches
Mail list logo
