"Johan Nilsson" <[EMAIL PROTECTED]> wrote in message
at76e1$2ro$[EMAIL PROTECTED]">news:at76e1$2ro$[EMAIL PROTECTED]...
>
> "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message
> at542o$2hq$[EMAIL PROTECTED]">news:at542o$2hq$[EMAIL PROTEC
Oh. Yes, on that particular machine I was using 1.27.
Thanks.
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
00c301c2a07d$d1d09860$1d00a8c0@pdimov2">news:00c301c2a07d$d1d09860$1d00a8c0@pdimov2...
> From: "Eric Woodruff" <[EMAIL PROTECTED]>
>
PROTECTED]> wrote in message
005d01c2a073$546e1960$1d00a8c0@pdimov2">news:005d01c2a073$546e1960$1d00a8c0@pdimov2...
> From: "Eric Woodruff" <[EMAIL PROTECTED]>
> >
> > Doesn't make any difference with the outcome in theory or in my test as
I
&
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
003f01c2a06f$2c4f6550$1d00a8c0@pdimov2">news:003f01c2a06f$2c4f6550$1d00a8c0@pdimov2...
> From: "Eric Woodruff" <[EMAIL PROTECTED]>
> > Using g++ 2.95.4,
> >
> > #include
> > #in
; "done." << std::endl;
}
I didn't find any special documentation explaining special use of
boost::shared_ptr.
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
002b01c2a06b$2388ade0$1d00a8c0@pdimov2">news:002b01c2a06b$2388ade0$1d00a8c0@pdimov2...
> F
I tested a shared_ptr and while it seems to be invalidating the memory
of the pointer (implying that it is deleted), the proper destructor is never
called.
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
000701c2a066$b1a8e720$1d00a8c0@pdimov2">news:000701c2a066$b1a8e720$1d00a8c0@pdimov2...
> F
"Johan Nilsson" <[EMAIL PROTECTED]> wrote in message
at52vi$si6$[EMAIL PROTECTED]">news:at52vi$si6$[EMAIL PROTECTED]...
[snip]
> I'd like to be able to store references to objects of arbitrary types in a
> homogenous collection, not requiring them to be derived from a common base
> class. For COM
I don't think that anyone is going to find a new quote from the standard
that will end the discussion on reinterpret_cast. Even and email from Bjarne
okayed by three major platform compiler developers probably wouldn't suffice
anymore.
I had pointed out that instead of using any cast, one can just
"Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Eric Woodruff" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | > Thus, given that h.storage is properly aligned, (which is the purpose
as well
"Eric Woodruff" <[EMAIL PROTECTED]> wrote in message
aso09f$akc$[EMAIL PROTECTED]">news:aso09f$akc$[EMAIL PROTECTED]...
>
> "Anthony Williams" <[EMAIL PROTECTED]> wrote in
> message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
"Anthony Williams" <[EMAIL PROTECTED]> wrote in
message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Eric Woodruff writes:
> > "Anthony Williams" <[EMAIL PROTECTED]> wrote in
> > message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]..
(inline)
"Anthony Williams" <[EMAIL PROTECTED]> wrote in
message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[snip]
> Gabriel Dos Reis writes:
> unsigned char* has _additional_ properties to void* --- you can access the
> object representation of _any_ object through an unsigned char* (and for
P
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
>
> > Thanks for your patience.
> >
> > Now, imagine an implementation where the original type is remembered,
> > then dereferencing the pointer obtaine
"David B. Held" <[EMAIL PROTECTED]> wrote in message
aslftb$cr2$[EMAIL PROTECTED]">news:aslftb$cr2$[EMAIL PROTECTED]...
> "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message
> aslbsn$nt3$[EMAIL PROTECTED]">news:aslbsn$nt3$[EMAIL PROTECTED].
"Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "David B. Held" <[EMAIL PROTECTED]> writes:
>
> | Does this have any merit whatsoever?
> |
> | template
> | T* dangerous_cast(U* p)
> | {
> | return static_cast(static_cast(p));
> | }
>
> Is
[snip]
> holder h;
> new (h.storage) Foo;
What is the meaning of that syntax?
>...
> T* u = dangerous_cast(h.storage); // can't do this with
reinterpret_cast
Why would you want to do that in the first place.
>
> HTH,
> --
>David Abrahams
>[EMAIL PROTECTED] * htt
In my experience in attempting to develop an over-general sockets
abstraction, it is next to impossible to contrive a perfect generalization
of the many different socket types.
A good sockets implementation will at a minimum:
* Use polymorphism on a well-defined socket interface.
This will allow
According to g++ and comeau, the following is illegal: (The commented line
allows the code to compile.)
class A {
public:
A () {}
~A () {}
private:
class Nested;
//friend class B;
};
class B {
public:
B () {}
~B () {}
private:
friend class A::N
"Rob Stewart" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> From: "Eric Woodruff" <[EMAIL PROTECTED]>
> >
> > Every reference I can find excludes pointer conversions from being
> > implementa
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
> > From: "Eric Woodruff" <[EMAIL PROTECTED]>
> >>
> >> &qu
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
> > * shared_*_cast will be renamed to sp_*_cast.
>
> Why? Without rationale, this seems like a gratuitous change,
> especailly since "sp" doesn't mean m
In my opinion, assertions indicate enfrorcement of pre/post conditions, that
are separate from the algorithmic logic of a function. What happens from the
result of the assertion, an exception or an abort is a separate issue.
Consider (if assert takes a boost::function0):
assert (!harddrive.isFrag
type_info is not portable in the slightest.
"Vahan Margaryan" <[EMAIL PROTECTED]> wrote in message
news:003401c28bee$7fbc4f40$4f09a8c0@;lan.mosaic.am...
- Original Message -
From: "Robert Ramey" <[EMAIL PROTECTED]>
Sent: Thursday, November 14, 2002 5:45 PM
Subject: Re: [boost] Serializatio
wrote in message
news:3599.167.16.75.51.1037037372.squirrel@;frodo.kempf-ville.com...
>
> Eric Woodruff said:
> > William,
> >
> > I'm not sure. I haven't been following the development branch, and don't
> > know exactly how to access it.
>
> $> cvs co
I've always used the examples out of TC++PL of some assertions:
template
assertion (bool const condition) {
if (!condition) {
throw Exception ();
}
}
template
assertion (bool const condition, Exception const& exception) {
if (!condition) {
throw exception;
}
}
vided a grouped join. I
needed to be abstracted from the thread itself. Thus, thread was not a good
choice in the class's name.
eric
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message
news:3666.167.16.75.51.1037032721.squirrel@;frodo.kempf-ville.com...
>
> Eric Woo
Is there any interest in a threaded function queue? I ran into a problem
where I needed to asynchronously run methods but I didn't want to (or
actually couldn't easlily) maintain threads to run them in. So I created a
function queue where I could control the number of threads that were used to
exec
27 matches
Mail list logo
