>Suppose I'd like to put const type_info*s in associative containers, and
>I'd like to map less<const type_info*> to type_info::before in the obvious
>fashion.  I gather that there's no portable way to write such software,
>i.e, that doesn't possibly violate the ODR.  Is this true?  (The only thing
>I want to write is less<const type_info*>.  I realize that I can use
>Andrei's earlier suggestion (assuming it's portable -- a question which
>remains open) or use other strategies to achieve the same behavior I'm
>shooting for with the specialization of less.)

Don't use std::less, there is nothing to prevent you from using:

class typeinfo_compare
{
  /* usual operators here */
};

As a template argument to std::map or std::set.

Does this fix the problem?


John Maddock
http://ourworld.compuserve.com/homepages/John_Maddock/
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Meyers wrote:
>
> > In particular, an implementation might have already specialized
> > less<const type_info*> for some reason, and your program would
> > be invalid.
>
> Suppose I'd like to put const type_info*s in associative containers, and
> I'd like to map less<const type_info*> to type_info::before in the obvious
> fashion.  I gather that there's no portable way to write such software,
> i.e, that doesn't possibly violate the ODR.  Is this true?  (The only thing
> I want to write is less<const type_info*>.  I realize that I can use
> Andrei's earlier suggestion (assuming it's portable -- a question which
> remains open) or use other strategies to achieve the same behavior I'm
> shooting for with the specialization of less.)
>

The standard prohibits specializing std::less. It does not prevent you
from writing your own class or template with the appropriate members and
using that. It won't be used as the default comparison type, so you'll
have to name it explicitly in the definition of your container's type.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> > Suppose I'd like to put const type_info*s in associative containers, and
> > I'd like to map less<const type_info*> to type_info::before in the obvious
> > fashion.  I gather that there's no portable way to write such software,
> > i.e, that doesn't possibly violate the ODR.
>
> Yes. I am not even sure that it's a good idea.

What would your concerns be, assuming we don't run into a collision with an
existing specialization for less<const type_info*>?

Scott

--
Scott Meyers, Ph.D.                  smeyers@aristeia.com
Software Development Consultant      http://www.aristeia.com/
Visit http://meyerscd.awl.com/ to demo the Effective C++ CD


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Meyers wrote:

[ specializing less<foobar*> ]

> > Yes. I am not even sure that it's a good idea.
>
> What would your concerns be, assuming we don't run into a collision with an
> existing specialization for less<const type_info*>?

You are simply breaking less.

--

Valentin Bonnard


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Meyers <smeyers@aristeia.com> wrote:
> Departing from the pure realm of the standard, it would be helpful to know
> whether real implementations are likely to specialize less, etc., for
> pointer types.  I know that several compiler implementers participate in
> this newsgroup.  Would any of them care to speculate on the likelihood that
> vendors will provide a specialization for type_info* (and maybe also int*,
> etc.)?

I'm not a compiler implementer, but the standard puts stronger
requirements on less-for-pointers than it does on operator< -- less
must produce a total order.  Implementations on segmented architectures
may have to specialize less for this reason.

But even if less is not specialized, library code may be using --
and relying on the semantics of -- the unspecialized less.  If you provide
your own specialization, you may break the library.  And it would be
difficult to place your specialization before every point of instantiation
in the library.

It's often best to take advantage of the "Compare" parameter of
associative containers when you're storing pointers.

                                             --Lisa Lippincott


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Meyers wrote in message ...
>
>> > Suppose I'd like to put const type_info*s in associative containers,
and
>> > I'd like to map less<const type_info*> to type_info::before in the
obvious
>> > fashion.  I gather that there's no portable way to write such software,
>> > i.e, that doesn't possibly violate the ODR.
>>
>> Yes. I am not even sure that it's a good idea.
>
>What would your concerns be, assuming we don't run into a collision with an
>existing specialization for less<const type_info*>?

The collision is the problem.

Suppose on a particular implementation, there are no redundant type_info
objects, in other words if two type_info objects compare equal they have the
same address.  The vendor writes, in <typeinfo> the following

namespace std
{
  inline bool type_info::before(const type_info& __rhs) const


    return less(this, &__rhs);     // Intended to call vendor's
specialization less<void*>
  }
}

If you also specialize less<type_info*>, you are in the realm of undefined
behavior.  In this case the behavior may be an infinite loop, as the
vendor's before() calls your less() which calls the vendor's before().

Was the vendor being unreasonable?  If not, who was?




[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> > How would value semantics be useful, and what is the advantage of the
> > adaptor over simply specializing less<T> for type_info*?
>
> That would be simple. Am I allowed to do something like this?

I believe so.  17.4.3.1 of the FDIS (because my PDF copy of the standard is
still copy protected, sigh) sez:

  1 [stuff] ...     A program may add template specializations for  any  stan-
    dard  library  template to namespace std.  Such a specialization (com-
    plete or partial) of a standard library template results in  undefined
    behavior  unless  the  declaration  depends  on a user-defined name of
    external linkage and unless  the  specialization  meets  the  standard
    library requirements for the original template.

So a specialization of std::less<T> for type_info* (actually const
type_info*) is allowed, but yields undefined behavior :-) I find it hard to
imagine a real implementation where it wouldn't work, however.

Scott

--
Scott Meyers, Ph.D.                  smeyers@aristeia.com
Software Development Consultant      http://www.aristeia.com/
Visit http://meyerscd.awl.com/ to demo the Effective C++ CD


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

smeyers@aristeia.com (Scott Meyers) writes:


>> > How would value semantics be useful, and what is the advantage of the
>> > adaptor over simply specializing less<T> for type_info*?
>>
>> That would be simple. Am I allowed to do something like this?

>I believe so.  17.4.3.1 of the FDIS (because my PDF copy of the standard is
>still copy protected, sigh) sez:

>  1 [stuff] ...     A program may add template specializations for  any  stan-
>    dard  library  template to namespace std.  Such a specialization (com-
>    plete or partial) of a standard library template results in  undefined
>    behavior  unless  the  declaration  depends  on a user-defined name of
>    external linkage and unless  the  specialization  meets  the  standard
>    library requirements for the original template.

>So a specialization of std::less<T> for type_info* (actually const
>type_info*) is allowed, but yields undefined behavior :-) I find it hard to
>imagine a real implementation where it wouldn't work, however.

The reason for the restiction to user-defined types is that an
implementation might have already provided a specialization on
a standard type. If the programmer also defined a specialization,
the code would violate the One-Definition Rule.

In particular, an implementation might have already specialized
less<const type_info*> for some reason, and your program would
be invalid.

--
Steve Clamage, stephen.clamage@sun.com


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> In particular, an implementation might have already specialized
> less<const type_info*> for some reason, and your program would
> be invalid.

Suppose I'd like to put const type_info*s in associative containers, and
I'd like to map less<const type_info*> to type_info::before in the obvious
fashion.  I gather that there's no portable way to write such software,
i.e, that doesn't possibly violate the ODR.  Is this true?  (The only thing
I want to write is less<const type_info*>.  I realize that I can use
Andrei's earlier suggestion (assuming it's portable -- a question which
remains open) or use other strategies to achieve the same behavior I'm
shooting for with the specialization of less.)

Departing from the pure realm of the standard, it would be helpful to know
whether real implementations are likely to specialize less, etc., for
pointer types.  I know that several compiler implementers participate in
this newsgroup.  Would any of them care to speculate on the likelihood that
vendors will provide a specialization for type_info* (and maybe also int*,
etc.)?

Thanks,

Scott

--
Scott Meyers, Ph.D.                  smeyers@aristeia.com
Software Development Consultant      http://www.aristeia.com/
Visit http://meyerscd.awl.com/ to demo the Effective C++ CD


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Meyers wrote:

> > In particular, an implementation might have already specialized
> > less<const type_info*> for some reason, and your program would
> > be invalid.
>
> Suppose I'd like to put const type_info*s in associative containers, and
> I'd like to map less<const type_info*> to type_info::before in the obvious
> fashion.  I gather that there's no portable way to write such software,
> i.e, that doesn't possibly violate the ODR.

Yes. I am not even sure that it's a good idea.

> Would any of them care to speculate on the likelihood that
> vendors will provide a specialization for type_info* (and maybe also int*,
> etc.)?

That's not the problem.

--

Valentin Bonnard


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> This class would have value semantics, plus it can serve for storing in
> an associative container, which is a boon for some apps.

How would value semantics be useful, and what is the advantage of the
adaptor over simply specializing less<T> for type_info*?

Scott

--
Scott Meyers, Ph.D.                  smeyers@aristeia.com
Software Development Consultant      http://www.aristeia.com/
Visit http://meyerscd.awl.com/ to demo the Effective C++ CD


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,


Do the pair of functions type_info::before and type_info::operator==
introduce a total ordering on the type_info set? In other words, would
this be an operator<= sporting the same properties as the arithmetic
operator <=?

bool operator<=(const std::type_info& lhs, const std::type_info& rhs)
{
    return !rhs.before(lhs);
}

If this is true, one can construct an extremely useful adapter for
type_info:

class ordered_type_info
{
public:
    ordered_type_info(const std::type_info& val)
    : pVal_(&val) {}
    friend inline bool operator<(
        ordered_type_info& lhs,
        ordered_type_info& rhs)
    {
        return lhs.pVal_->before(*lhs.pVal_);
    }
    friend inline bool operator==(
        ordered_type_info& lhs,
        ordered_type_info& rhs)
    {
        return *lhs.pVal_ == *lhs.pVal_;
    }
    ... plus trivially defined operator <=, >, >=, != ...
private:
    std::type_info* pVal_;
};

This class would have value semantics, plus it can serve for storing in
an associative container, which is a boon for some apps.

But it all relies on before behaving nicely. Does it?


Andrei


Sent via Deja.com http://www.deja.com/
Before you buy.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.125e982e4649be1d9896d7@news.teleport.com>,
  smeyers@aristeia.com (Scott Meyers) wrote:
>
> > This class would have value semantics, plus it can serve for
storing in
> > an associative container, which is a boon for some apps.
>
> How would value semantics be useful, and what is the advantage of the
> adaptor over simply specializing less<T> for type_info*?

That would be simple. Am I allowed to do something like this?

I was thinking of a couple of ways, including defining my own functor
for a map, but in the end I thought that a wrapper class with value
semantics for type_info would be quite handy. I can store vectors,
maps, lists of ordered_type_info, I can maneuver ordered_type_info very
easily, and I'll never make the mistake of comparing the raw pointers.
As we all know, comparing two pointers to type_info does not help much,
you have to call operator==.

Yes, I guess the usefulness of ordered_type_info is pretty much all
about ensuring that type_info is handled in a correct way.

Of course, if type_info::before and type_info::operator== don't
introduce a total ordering, ordered_type_info becomes useless.

Andrei


Sent via Deja.com http://www.deja.com/
Before you buy.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]