From: Daryle Walker (darylew_at_[hidden])
Date: 2000-07-09 23:28:33
on 7/8/00 9:25 PM, David Abrahams at abrahams_at_[hidden] wrote:
> ----- Original Message -----
> From: "Daryle Walker" <darylew_at_[hidden]>
>> on 7/8/00 1:04 AM, David Abrahams at abrahams_at_[hidden] wrote:
>>> It's easy to write a class whose default construction or copy-assignment
>>> semantics don't work right, but operator, and operator& pretty much always
>>> do the right thing. Do you have a motivating example for these?
>> No. But remember, I'm not changing their semantics; I'm blocking them
> My point is that we might reasonably choose to block copy semantics with
> noncopyable when the default semantics are inappropriate. What reason might
> there be to block the comma and/or address semantics?
I can't think of any. Maybe someone else can?
I've thought of one. When you want objects of a class to act like literal
constants. You shouldn't be able to take an address of a literal.
I have an idea for a class that would meet this requirement, but my compiler
doesn't support it (for a different reason, no class member template partial
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk