In article <4pkb24$l38@silver.jba.co.uk>, JdeBP@jba.co.uk says...
[ ... ]

> If so, then, by [expr.add], which states that pointer subtraction is
> only defined for the case that the two pointers point to objects in
> the same array (or one past the end thereof), the only constraint
> upon such a system so that it be conforming is that arrays cannot
> exceed 4Tb in size.
>
>  [Moderator's note: I think you mean 2**32 bytes, i.e. 4Gb,
>  not 4Tb.  -fjh.]

While 4 Gig is closer, since the result it signed, its range is only 2
Gig.  E.g. with a 3 Gig array, subtracting the end element from the
start element overflows 2 Gig.

However, differences are returned as a number of elements, not a
number of bytes (unless it happens to be an array of char) so with,
say, 8 byte doubles, a 32 bit ptrdiff_t can be used with arrays up to
16 Gb in actual size...
--
    Later,
    Jerry.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze US/ESC 60/3/141 #40763 wrote:
> In article <ww7mtmbznh.fsf@nellie.bby.com.au> Gregory Bond
> <gnb@bby.com.au> writes:
[... cast pointers to integrals and compare? ...]
> > The above discussions imply no.  Why not?
>
> What is the appropriate integral type.  Consider that there are, for
> example, implementations in which a pointer is larger than any
> integral type.  (I've worked on a system where pointers were 48 bits,
> but long's only 32.  Obviously, on such a system, there is no way to
> cast a pointer to an integer without some loss of information.)
> --
> James Kanze         email: kanze@gabi-soft.fr

Unless I have failed to remember correctly, such a system would be
incapable of supporting the type ptrdiff_t.  This type is (still) standard
C, and I recall it being transplanted into standard C++ (still).  ptrdiff_t
would also seem to address the original question.
                -- Eric Gindrup ! gindrup@okway.okstate.edu
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Eric Gindrup (gindrup@Okway.okstate.edu) wrote:
| James Kanze US/ESC 60/3/141 #40763 wrote:
| > I've worked on a system where pointers were 48 bits,
| > but long's only 32.  Obviously, on such a system, there is no way to
| > cast a pointer to an integer without some loss of information.)
|
| Unless I have failed to remember correctly, such a system would be
| incapable of supporting the type ptrdiff_t.

I don't have a copy of the C Standard, but isn't it true that ptrdiff_t is
defined to be an alias for the (implementation defined) signed integral
type that is returned from the subtraction of two pointers ?

 [Moderator's note: yes, that's correct. -fjh.]

If so, then, by [expr.add], which states that pointer subtraction is only
defined for the case that the two pointers point to objects in the same
array (or one past the end thereof), the only constraint upon such a system
so that it be conforming is that arrays cannot exceed 4Tb in size.

 [Moderator's note: I think you mean 2**32 bytes, i.e. 4Gb,
 not 4Tb.  -fjh.]

---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 1bda3410@Okway.okstate.edu, gindrup@Okway.okstate.edu (Eric Gindrup) writes:
>James Kanze US/ESC 60/3/141 #40763 wrote:
>> In article <ww7mtmbznh.fsf@nellie.bby.com.au> Gregory Bond
>> <gnb@bby.com.au> writes:
>[... cast pointers to integrals and compare? ...]
>> > The above discussions imply no.  Why not?
>>
>> What is the appropriate integral type.  Consider that there are, for
>> example, implementations in which a pointer is larger than any
>> integral type.  (I've worked on a system where pointers were 48 bits,
>> but long's only 32.  Obviously, on such a system, there is no way to
>> cast a pointer to an integer without some loss of information.)
>
>Unless I have failed to remember correctly, such a system would be
>incapable of supporting the type ptrdiff_t.

Not necessarily. Some systems have extra bits in pointers which are
descriptive rather than being a proper part of the "address". I once
worked on a word-addressed machine where half-words or quarter-words
(bytes) were expressed by extra bits in the pointer. In either case,
the distance between two addresses might still be representable as
a long (for example) even if a pointer contained more bits than a long.

Finally, you may take the difference between pointers only if they point
into the same object. An ordinary system with 48-bit or 64-bit pointers
might not allow objects bigger than 4Gb. Any legitimate pointer difference
would then fit in a 32-bit integral type.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Eric Gindrup (gindrup@Okway.okstate.edu) wrote:
: James Kanze US/ESC 60/3/141 #40763 wrote:
: > In article <ww7mtmbznh.fsf@nellie.bby.com.au> Gregory Bond
: > <gnb@bby.com.au> writes:
: [... cast pointers to integrals and compare? ...]
: > > The above discussions imply no.  Why not?
: >
: > What is the appropriate integral type.  Consider that there are, for
: > example, implementations in which a pointer is larger than any
: > integral type.  (I've worked on a system where pointers were 48 bits,
: > but long's only 32.  Obviously, on such a system, there is no way to
: > cast a pointer to an integer without some loss of information.)
: > --
: > James Kanze         email: kanze@gabi-soft.fr

: Unless I have failed to remember correctly, such a system would be
: incapable of supporting the type ptrdiff_t.  This type is (still) standard
: C, and I recall it being transplanted into standard C++ (still).  ptrdiff_t
: would also seem to address the original question.

I don't believe this is true.  Remember pointer subtraction is only
defined between members of the same object, so it is impossible to run
into this problem unless (number of bytes of memory) > (max ptrdiff_t
value); i.e. there is enough memory to allocate a _single_ block that
large.

Neither C nor C++ force the idea of 'absolute address' to have _any
meaning whatsoever_ which is why the original question cannot be
answered.

Another point is that a pointer is _not_ required to simply be an
address.  The extra 16 bits may hold alignment or other information.
In this case one could easily imagine 48 bit pointers with differences
that fit into 32 bits.

---------------------------------------------------------------------------
Tim Hollebeek         | Disclaimer :=> Everything above is a true statement,
Electron Psychologist |                for sufficiently false values of true.
Princeton University  | email: tim@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <1bda3410@Okway.okstate.edu> gindrup@Okway.okstate.edu (Eric
Gindrup) writes:

|> James Kanze US/ESC 60/3/141 #40763 wrote:
|> > In article <ww7mtmbznh.fsf@nellie.bby.com.au> Gregory Bond
|> > <gnb@bby.com.au> writes:
|> [... cast pointers to integrals and compare? ...]
|> > > The above discussions imply no.  Why not?
|> >
|> > What is the appropriate integral type.  Consider that there are, for
|> > example, implementations in which a pointer is larger than any
|> > integral type.  (I've worked on a system where pointers were 48 bits,
|> > but long's only 32.  Obviously, on such a system, there is no way to
|> > cast a pointer to an integer without some loss of information.)

|> Unless I have failed to remember correctly, such a system would be
|> incapable of supporting the type ptrdiff_t.  This type is (still) standard
|> C, and I recall it being transplanted into standard C++ (still).  ptrdiff_t
|> would also seem to address the original question.

Where is the problem supporting ptrdiff_t?  On the system in question,
the largest any single object could be was 2^32 bytes, so a 32 bit
ptrdiff_t would be as valid for this system as it would be for any
normal 32 bit system.  Remember that ptrdiff_t is the type resulting
from the subtraction of two pointers; this operation is only legal if
the pointers point into the same array.  Consider that ptrdiff_t is
typically a 16 bit int on MS-DOS implementations, although in model far,
pointers are 32 bits.

It's also worth remembering that ptrdiff_t is not guaranteed to be able
to handle everything.  On my system (Sun Sparc), I can theoretically
(and practically, with a large enough disk allocated to virtual memory)
declare an array "char a[3000000000]".  The expression
"&a[2999999999]-&a[0]" is undefined, since it results in overflow of the
signed result returned by the substraction.  (In fact, on the
implementations I use, it will result in a negative value, giving the
impression that a[2999999999] is below a[0] in memory.)
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <4pkb24$l38@silver.jba.co.uk> JdeBP@jba.co.uk (Jonathan de
Boyne Pollard) writes:

|> Eric Gindrup (gindrup@Okway.okstate.edu) wrote:
|> | James Kanze US/ESC 60/3/141 #40763 wrote:
|> | > I've worked on a system where pointers were 48 bits,
|> | > but long's only 32.  Obviously, on such a system, there is no way to
|> | > cast a pointer to an integer without some loss of information.)
|> |
|> | Unless I have failed to remember correctly, such a system would be
|> | incapable of supporting the type ptrdiff_t.

|> I don't have a copy of the C Standard, but isn't it true that ptrdiff_t is
|> defined to be an alias for the (implementation defined) signed integral
|> type that is returned from the subtraction of two pointers ?

|>  [Moderator's note: yes, that's correct. -fjh.]

|> If so, then, by [expr.add], which states that pointer subtraction is only
|> defined for the case that the two pointers point to objects in the same
|> array (or one past the end thereof), the only constraint upon such a system
|> so that it be conforming is that arrays cannot exceed 4Tb in size.

|>  [Moderator's note: I think you mean 2**32 bytes, i.e. 4Gb,
|>  not 4Tb.  -fjh.]

Actually, given his explination, I think he means 2^31 bytes (2GB).
Ptrdiff_t must be a signed type.

I also *think* (not sure) that in fact, the system can support larger
arrays, but that pointer substraction may cause overflow on them.

Which leads to another point: if my supposition is true... given two
pointers into the same array, is there any way of testing before
invoking undefined behavior (due to overflow in signed arithmetic)
whether the substraction is safe?
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

J. Kanze wrote:
[cut]
> I would personally be against requiring it, too, for exactly these
> reasons.  A user normally has no business comparing arbitrary pointers.
[cut]

I had a similar problem when I stored a finite element mesh to disk. I
wanted to associate a unique identifier to every node in the mesh before
storing to disk. One solution was to associate this identifier to the
memory location of the node i.e. (same problem)

map<Node*, Id, less<Node*> >

This seemed like a valid solution. I whould write each node only once to
the file but every object associated to this node would store it's Id.
But this was impossible for the same reason: the map could not sort
Node* (only == and != are legal). I did test this on many compilers and
it always worked but deep inside I know it's wrong. This seems like a
valid example where sorting arbitrary pointers whould be helpfull.
(of course the resulting order is unimportant). Any Suggestions?

Claude
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Claude Quizel wrote:
>
> J. Kanze wrote:
> [cut]
> > I would personally be against requiring it, too, for exactly these
> > reasons.  A user normally has no business comparing arbitrary pointers.
> [cut]
>
> I had a similar problem when I stored a finite element mesh to disk. I
> wanted to associate a unique identifier to every node in the mesh before
> storing to disk. One solution was to associate this identifier to the
> memory location of the node i.e. (same problem)
>
> map<Node*, Id, less<Node*> >
>
> This seemed like a valid solution. I would write each node only once to
> the file but every object associated to this node would store it's Id.
> But this was impossible for the same reason: the map could not sort
> Node* (only == and != are legal). I did test this on many compilers and
> it always worked but deep inside I know it's wrong. This seems like a
> valid example where sorting arbitrary pointers whould be helpfull.
> (of course the resulting order is unimportant). Any Suggestions?

I'm sorry if James and I have not been clear enough.  It is perfectly
reasonable to want an (arbitrary) complete ordering on pointers, for
just the reason Claude suggests.  However, it would overburden some users
for operator< to be required to provide this ordering.

The language does not currently provide *any* mechanism to generate a
total ordering of pointers.  The obvious place for such an extension
is as a partial specialization less<T*>, because it wouldn't require
any change to language syntax.  On implementations where operator<
already defines a total order, no explicit specialization is needed;
otherwise, the vendor would be obliged to provide it in the header
along with the definition of less<>.

There is no requirement in the draft, currently, for this behavior;
but there is an open issue in the Issues List for chapter 20 (Utilities)
that might be discussed in Stockholm.  Until it is accepted, any code
that depends on a total order of pointers, like Claude's above, is only
portable to those implementations that define operator< to provide a total
order on pointers.

It's not a moral problem, but one of documentation and limited portability.
Fortunately, if the proposal is accepted Claude's code will become correct
and portable with no changes.  In the meantime, there is no fully portable
alternative but to give each object a numeric ID and sort them on that
basis, or to hash the pointers and compare them for true equality during
lookup.

Nathan Myers
ncm@cantrip.org
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

As a corollary, would casting the pointers to an appropriate integral
type and then comparing the integers be a conforming total ordering?

The above discussions imply no.  Why not?

Greg.
--
Gregory Bond <gnb@bby.com.au>
Burdett Buckeridge & Young Ltd Melbourne Australia
``Efforts to maintain the "purity" of a language only succeed in establishing
  an elite class of people who know the shibboleths.  Ordinary folks know
  better, even if they don't know what "shibboleth" means.'' - Larry Wall
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Gregory Bond <gnb@bby.com.au> writes:

>As a corollary, would casting the pointers to an appropriate integral
>type and then comparing the integers be a conforming total ordering?

Not strictly conforming, no.

>The above discussions imply no.  Why not?

Two reasons.  Firstly, there's no guarantee that there will be any
appropriate integral type.  A system may have 32-bit longs and 64- or
128-bit pointers, for example.  Secondly, even if there is a sufficiently
large integral type, the conversion from pointer to integer is
implementation-defined, and there's no guarantee that this conversion
will be one-to-one.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <ww7mtmbznh.fsf@nellie.bby.com.au>, gnb@bby.com.au says...
>
>As a corollary, would casting the pointers to an appropriate integral
>type and then comparing the integers be a conforming total ordering?
>
>The above discussions imply no.  Why not?

For built-in integral types there is no promise that a large enough  integral
type exists.  From the April 95 DWP:

  "A pointer converted to an integer of sufficient size (if any such exists on
the implementation) ..."

Also, I believe there is nothing in the standard which requires all of the
bits in a pointer to be significant, or that there be a single unique
representation of a given address.  For instance the orignal Motorolla 68000
had 32 bit pointers, but only a 24 bit address space.  Only the low-order 24
bits of a pointer were significant.  I believe a conforming implementation
could implement
   T *p1, *p2;
   assert(p1 == p2);        // Look at low-order 24 bits.
   assert(int(p1) == int(p2)); // Look at all 32 bits.
and the code above could fail at the second assertion.

There is a promise that if all of the bytes in two pointers (of the same
type) are the same, they point at the same object.  This promise comes from
the promise that after
  T p1, p2;  // T is a scalar type, pointer types are scalar types.
  // assume p2 has a valid value
  memcpy(&p1, &p2, sizeof(p2));
  // p1 and p2 must now have the same value.

So the value of a pointer can not, for instance, be a function of the address
of the pointer, because the memcpy above would not successfully copy the value
of p2 into p1.

Other scalar values may have the property that two objects with the same value
have different representations.  In particular signed integer types using a
sign-magnitude representation might have two bit patterns which mean zero.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <ww7mtmbznh.fsf@nellie.bby.com.au> Gregory Bond
<gnb@bby.com.au> writes:

|> As a corollary, would casting the pointers to an appropriate integral
|> type and then comparing the integers be a conforming total ordering?

|> The above discussions imply no.  Why not?

What is the appropriate integral type.  Consider that there are, for
example, implementations in which a pointer is larger than any integral
type.  (I've worked on a system where pointers were 48 bits, but long's
only 32.  Obviously, on such a system, there is no way to cast a pointer
to an integer without some loss of information.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <31AA90B7.45C8@aquanet.co.il> Willy Wood
<ofile@aquanet.co.il> writes:

|> The following declaration of a set of pointers to class X
|> contains a serious flaw. Who can spot it.

|> #include <set.h>

|> class X
|> {
|> };

|> typedef set<X*,less<X*> > setX;

The normal default implementation of less invokes undefined behavior if
the pointers involved do not point to objects in the same array.

I presume that once implementations start supporting partial
specialization, they will provide a partial specialization for pointers
that will work.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze US/ESC 60/3/141 #40763 wrote:
>
> In article <31AA90B7.45C8@aquanet.co.il> Willy Wood
> <ofile@aquanet.co.il> writes:
>
> |> The following declaration of a set of pointers to class X
> |> contains a serious flaw. Who can spot it.
>
> |> #include <set.h>
>
> |> class X
> |> {
> |> };
>
> |> typedef set<X*,less<X*> > setX;
>
> The normal default implementation of less invokes undefined behavior if
> the pointers involved do not point to objects in the same array.
>
> I presume that once implementations start supporting partial
> specialization, they will provide a partial specialization for pointers
> that will work.

There is an open proposal to provide something like this, but unless/until
it's mentioned in the Standard, it cannot be presumed.

Some implementors say that providing a total ordering among pointers
of random origin (not all pointing within a single array) could be an
order of magnitude more expensive.  Hence, it should not be required for
built-in operator<() applied to pointers, because it would slow down
loops operating only within a single array.

Nathan Myers
ncm@cantrip.org


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <31AF3DEA.1815024A@cantrip.org> Nathan Myers
<ncm@cantrip.org> writes:

|> James Kanze US/ESC 60/3/141 #40763 wrote:

|> > |> typedef set<X*,less<X*> > setX;
|> >
|> > The normal default implementation of less invokes undefined behavior if
|> > the pointers involved do not point to objects in the same array.
|> >
|> > I presume that once implementations start supporting partial
|> > specialization, they will provide a partial specialization for pointers
|> > that will work.

|> There is an open proposal to provide something like this, but unless/until
|> it's mentioned in the Standard, it cannot be presumed.

|> Some implementors say that providing a total ordering among pointers
|> of random origin (not all pointing within a single array) could be an
|> order of magnitude more expensive.  Hence, it should not be required for
|> built-in operator<() applied to pointers, because it would slow down
|> loops operating only within a single array.

I would personally be against requiring it, too, for exactly these
reasons.  A user normally has no business comparing arbitrary pointers.
What I was suggesting was specializing the "less" template for pointers
in environments where normal comparison doesn't work.  In this way,
operator< is still efficient (but requires pointers into the same
array), and less<T*> works for arbitrary pointers (but is potentially
less efficient for pointers into the same array).
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

The following declaration of a set of pointers to class X
contains a serious flaw. Who can spot it.

#include <set.h>

class X
{
};

typedef set<X*,less<X*> > setX;


--
Willy Wood,  Israel.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]