David Byrden <100101.2547@CompuServe.COM> writes:

>The basic intent here is that difference_type  will have enough
>bits, segments, and sundry machine-specific doodads to represent
>the difference between two addresses, even if they are the two
>ends of an array as large as all of memory.

Are you sure?  Why?
I'm not at all convinced that that was the intent,
and I'm not convinced that mandating this would
be possible, meaningful, or useful.

>The difference between addresses in separate object is undefined
>in the sense that it is a meaningless number. None the less, this
>meaningless number should FIT in a difference_type without
>overflowing it.

Are you suggesting that if you subtract pointers to objects from
different arrays you should merely get an unspecified result
rather than undefined behaviour?  If so, why?
This is clearly different from the status quo for tbe builtin pointer
types - the definition of subtraction in 5.7 [expr.add] clearly states
that the behaviour is undefined.  Why should implementations be
prohibited from say aborting the program with a diagnostic in this case?

I basically agree with John Skaller's comment - the current definition
of `difference_type' is a bug in the draft standard.

--
Fergus Henderson              WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au               PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]