In article <33B65B8B.3980@cds.duke.edu>, mtew@cds.duke.edu wrote:
>     The standard seems to provide this representation under
> the rubric of <list>. Actually using <list> (Plauger's
> implementation for Microsoft) proved to be much harder than it
> should have been.  It seems that <list> insists on having the
> ordering operator between the elements of the list be defined.

This is a known bug in Microsoft's implementation of the STL. The
standard does not require an ordering operator for the elements of a list or
vector. The bug reference from Microsoft's Web page is C2784.

Joachim

---
private:  joachim@wimsey.ca
work:     joachim@mercury.bc.ca
www:      http://www.wimsey.ca/~joachim
---
[ 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                             ]

Background:

    I am writing an application that requires a (actually
several) set of objects in the externally visable interface. The
order of the set elements is defined by the user of the
application. The natural implementation seems to be a link list.

    The standard seems to provide this representation under
the rubric of <list>. Actually using <list> (Plauger's
implementation for Microsoft) proved to be much harder than it
should have been.  It seems that <list> insists on having the
ordering operator between the elements of the list be defined.
Since one of the main reasons for using <list> was to define
the order, defining the ordering operators is either an
exercise in recursion or an unneeded complexity.

    The specific problem was with the .unique and .sort
member functions, but the draft standard does call for the
definitions of these operators between the elements.

    I solved the problem by dropping back to the HP/STL's
<list.h> implementation.

Opinion:

    While <list> and other containers are properly called
sequences and do provide a natural ordering mechanism,
insisting that ordering operators be defined between the
elements in simple lists is undesirable. The requirement
that an ordering operator be defined between the elements
represents code that is not, and in some cases should not,
be used.

    There are situations where sortable lists are what is
needed, but these are a super-set of the basic operations
needed for simple lists. There should be a heirarchy of
containers with different ordering operation requirements.

Hi,
Max TenEyck Woodbury (mtew@cds.duke.edu) wrote:
:     The standard seems to provide this representation under
: the rubric of <list>. Actually using <list> (Plauger's
: implementation for Microsoft) proved to be much harder than it
: should have been.  It seems that <list> insists on having the
: ordering operator between the elements of the list be defined.

No. It only insists on having them defined if the corresponding
relational operators of 'list' are used.  Otherwise no such requirement
is imposed. This is actually quite clear from the list of requirements
stated in the corresponding section of the DWP
(lib.container.requirements paragraph 3).

:     The specific problem was with the .unique and .sort
: member functions, but the draft standard does call for the
: definitions of these operators between the elements.

If you use 'unique()' or 'sort()' you obviously need the relational
operators. Well, actually you only need them if you use the version of
'unique()' or 'sort()' which does not take a comparator as argument.
In any case, although these members are part of 'list's interface, they
do not impose any constraint on the value type unless they are actually
used. If a compiler insists in the comparison operator although no
'list' member depending on them is used, the compiler does not conform
to the [forthcoming] C++ standard.

:     While <list> and other containers are properly called
: sequences and do provide a natural ordering mechanism,
: insisting that ordering operators be defined between the
: elements in simple lists is undesirable. The requirement
: that an ordering operator be defined between the elements
: represents code that is not, and in some cases should not,
: be used.

But... there is no such requirement. My opinion is that there should be
members 'unique()' and 'sort()' because they can be more efficient than
unrelated functions 'unique()' and 'sort()'. Especially, since they do
not harm unless they are used. And if they are use, you cannot really
say that they are harmful!

:     How can this heirarchy be added to an implementation
: and still be in conformance with the standard?

Actually, there is no need for this to be added! It is simply there.

: Or a better question: How can the standard be extended
: to include this heirarchy without breaking existing code?

The question is more: "Why do compiler vendors claim to be standard
conformant although they are not?" There is no need to extend the
standard. Actually the standardization committee is very careful about
existing code and only as few existing code as possible is broken.
However, there are compiler implementations which insists on stronger
requirements than those imposed by the standard and thereby existing
code is broken.

The whole thing bases on the fact, that unused members of a template
class are never checked for correctness. I currently cannot cite the
section of the DWP but I know it is there and I can look for it if it
is necessary (maybe someone else knows it right away). There are
several compilers which fail to implement this rule as found in the DWP
(I think mainly because it was added relatively recent).
--
<mailto:dietmar.kuehl@uni-konstanz.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I'm seeking a new employment - See my homepage for details
---
[ 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
]

kuehl@horn.informatik.uni-konstanz.de (Dietmar Kuehl) writes:

|>  The question is more: "Why do compiler vendors claim to be standard
|>  conformant although they are not?"

A more relevant question: "How can a compiler vendor claim to conform to
a standard that isn't (yet)?"  Any claims of standard conformance are
obviously misleading advertisement, since there is no standard.

A valid claim might be that the compiler conforms to "the <somedate>
draft standard."  Of course, since different vendors will have different
values for <somedate>, depending on when they froze development, such a
claim doesn't do much for portability.  (In practice, of course, the
reason compiler vendors don't do this is that they use different values
for <somedate> for different parts of the compiler.)

If you are developing production code, a more important claim is ARM
conformance, or even CFront compatibility.  While the language thus
defined is not as complete, or as up to date, it isn't changing three
times a year, either.  (Actually, I think that most good compilers have
an option for this, at least where it makes a significant difference --
e.g.: if you support "mutable", there is no real necessity of being able
to turn it off, whereas you definitly should be able to compile with the
for-scope defined in the ARM, and it isn't a bad thing to be able to
revert to CFront lifetime of temporaries, even if the CFront rule was
never even guaranteed by CFront.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
            -- Conseils en informatique industrielle --
---
[ 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
]