On 28 f   v, 19:06, "Daniel Kr   gler" <daniel.krueg...@googlemail.com>
wrote:
> Hmmh, I wonder why nobody answered yet?!
>
> Does it mean that this question is so rediculous that
> it's not worth a single response?

I don't think so :)

My (personnal) opinion is that sub_match inherits std::pair for wrong
reasons (not to mention that this pair is really a range, but that's
another problem I guess). The goal of this forced inheritance is to
import pair::first and pair::second into sub_match, but that's only an
implementation convenience. Drawbacks are that the semantic of
sub_match is not respected (no, a sub_match is not a pair; one of its
characteristics is that it has a range (begin, end)) and that (as you
noted) slicing is introduced. So that's (IMHO) a design error with two
major consequences, a semantic one and an implementation one - not to
mention your other arguments, that I find quite valid as well.

> Member functions already exists, so there is no real
> reason to stay from further accessors (e.g. begin/end),
> including those which would make sub_match a basic
> range which could be reused according to the range
> proposal:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2068.html
>
> And for the struct-like proponents (I confess that I slightly
> tend to belong to this group in this affair) it would seem
> reasonable enough to just add to members first and second
> of type BidirectionalIterator and that's it. Please note also
> that this approach would increase the usefullness of the
> configurable (now being a real POD-) allocator of the
> sub_match sequence match_results.
>
> Just my last 2 cents on this issue,
>
> Daniel Kr   gler

I'm also all in favor of adding either a range or the two std::pair
members into sub_match and to make sub_match a base class (i.e. to
remove the std::pair inheritance).

Of course, I don't have half of the knowledge of any valuable member
of this group, so let's say that it was just my own, very personnal
opinion :)

Best regards,

-- Emmanuel Deloget


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

I wonder what where the reasons that lead to the decision,
that sub_match<BiIt> is publicly derived from pair<BiIt, BiIt>,
as seen in 28.9/1 of N2134?

On the first sight it seems to be astonishing, that inheritance
is used here, because std::pair is actually not designed for
that, being actually an entity usually known as "value type".
Furtheron there seem not to exist a relevant number of
advantages for this: std::pair has actually no reusable
member functions useful for the derived class.
Even the predefined comparison operators are not
reused but replaced by new ones. Thus the only visible
advantages see to be that sub_match is per-se a tuple.
Since sub_match also introduces further public data members
("bool matched;"), users could easily stumble accross
slicing error. Another point is that the Standard
obviously uses a technique, that *usually* is not
recommended one (and with no convincing advantages
as far as I see). Deriving from member-free tagging classes
like iterator_traits, unary/binary_function and similar ones
is much easier to explain than in the sub_match/pair case.
Just recently we had the thread " STL non virtual DTOR"
comp.lang.c++.moderated,

http://tinyurl.com/3xk6cv

where practically all answers had a similar tone. How
should we justify future questions going into the same
direction? It's not unusual that people argue by comparison
to existing Standard code. And in this case we don't have
the excuse anymore, that "this is just the baggage from C
or from early C++ implementations (c.f. <iostream.h>)"

Recapitulating, I really can't see that these design
decisions outweight the possible traps. I would really
appreciate, if someone could explain the reasons for
it!

Be asured that my question is a honest, desperate
one, I don't want to blame anyone personally.

Thanks in advance,

Daniel Kr   gler


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Hmmh, I wonder why nobody answered yet?!

Does it mean that this question is so rediculous that
it's not worth a single response?

I would really appreciate any input, even if this
would just be a affirmation of the status quo.
Personally I see large problems for educational
reasons - maybe this sentence is provocating enough? -
and I would appreciate if sub_match would not specify
that it inherits from std::pair.

Here some more arguments against the current design
decision: While using a pair<Iterator, Iterator> smells
so struct-like, it essentially forbids sub_match to be
a POD - I mean in the sense of the newly proposed,
extended POD definition explained in:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2062.html

Member functions already exists, so there is no real
reason to stay from further accessors (e.g. begin/end),
including those which would make sub_match a basic
range which could be reused according to the range
proposal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2068.html

And for the struct-like proponents (I confess that I slightly
tend to belong to this group in this affair) it would seem
reasonable enough to just add to members first and second
of type BidirectionalIterator and that's it. Please note also
that this approach would increase the usefullness of the
configurable (now being a real POD-) allocator of the
sub_match sequence match_results.

Just my last 2 cents on this issue,

Daniel Kr   gler



---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]