Boost logo

Boost :

From: Fred Bertsch (fred.bertsch_at_[hidden])
Date: 2006-02-07 15:22:47


On 2/7/06, Peter Dimov <pdimov_at_[hidden]> wrote:
> Fred Bertsch wrote:
>
> > Second, there isn't as much type safety as there could be in a lot of
> > these classes. For example, shared_message_queue does not have a
> > template parameter to determine what is stored in the queue. Instead,
> > its send and receive member functions take void*'s. Is there a good
> > reason for this? I suppose another process could use the same
> > shared_message_queue with another type, but I'd really like to see
> > some type safety within the same process.
>
> Moving a reinterpret_cast from user code, where it's visible, to the queue
> implementation, where it's hidden, decreases type safety instead of
> increasing it. A typed interface is only meaningful if the queue enforces
> type safety, perhaps by encoding the type (and ideally the compiler version)
> somehow.

I will admit that the queue will have trouble enforcing type safety
across process boundaries. However, the queue can certainly enforce
type safety *within* one process. It can make sure, for example, that
exactly one type is written to a particular queue and exactly one type
is read from the queue.

Guaranteeing that the same type is written and read is more of a
problem. I'll admit that it would certainly be better if it could
write out a type_info::name or something when the queue is created or
opened, but it's hard to imagine how that could work without putting
in workarounds for each supported compiler. Actually, you'd have to
write out compiler switches as well as the compiler version if you
wanted it to be even slightly safe. I don't think that's worth doing.

-Fred


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk