definition of allocator::difference_type?

Thread View: comp.std.c++

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Eric Biederman Tue, 31 Oct 1995 08:30

#2359

Author: Eric Biederman
Date: Tue, 31 Oct 1995 08:30

39 lines
1572 bytes

In reading through 20.1 Allocator requirements [lib.allocator.requirements]

I have come across some wording which I find inconsistent with what is
in the rest of the standard as I understand it.

X::difference_type 
the type that can represent the difference between any two pointers in
the memory model.

Which seems to say that the operation 
X::pointer a,b;
  // initialize a & b to point into different objects
X::difference t = a - b; // seems to be well defined.

later in 
20.4.1 The default allocator [lib.default.allocator]
in the definition of the default allocator,

class allocator {
public:
  typedef size_t size_type
  typedef ptrdiff_t difference_type

If I understand the definition of ptrdiff_t from C the result is
undefined if you take the difference of two pointers which do not
point into the same object.

So is it undefined or not, if you are using the types supplied with
the allocators?  What is the intent here?

Eric



---
[ 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. ]

Re: definition of allocator::difference_type?

#2447

Author: David Byrden
Date: Tue, 07 Nov 1995 05:48

14 lines
1273 bytes

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.
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.

            David
---
[ 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. ]

Re: definition of allocator: :difference_type?

#2451

Author: Fergus Henderson
Date: Tue, 07 Nov 1995 13:54

35 lines
2253 bytes

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. ]

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads