Jens Theisen <jth02@arcor.de> writes:

> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:
>
>> The forwarding problem is well known as "strstr" problem. C++ must have two
>> separate versions of strstr, one with const, one without. Same thing happens
>> for most definitions of operator[], begin()/end() in containers etc.
>>
>> Is there any proposal for this problem?
>
> I think the rvalue reference proposal also solves the forwarding
> problem, though I'm not familiar with the details.

It does.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.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://www.comeaucomputing.com/csc/faq.html                      ]

* David Abrahams:
> Jens Theisen <jth02@arcor.de> writes:
>
>> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:
>>
>>> The forwarding problem is well known as "strstr" problem. C++ must have two
>>> separate versions of strstr, one with const, one without. Same thing happens
>>> for most definitions of operator[], begin()/end() in containers etc.
>>>
>>> Is there any proposal for this problem?
>> I think the rvalue reference proposal also solves the forwarding
>> problem, though I'm not familiar with the details.
>
> It does.

An example of solving that problem, and a link to the proposal, would be
nice.

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

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

Dnia Sat,  4 Nov 2006 21:39:46 CST, David Abrahams skrobie:
> Jens Theisen <jth02@arcor.de> writes:

> > Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:
> >
> >> The forwarding problem is well known as "strstr" problem. C++ must have two
> >> separate versions of strstr, one with const, one without. Same thing happens
> >> for most definitions of operator[], begin()/end() in containers etc.
> >>
> >> Is there any proposal for this problem?
> >
> > I think the rvalue reference proposal also solves the forwarding
> > problem, though I'm not familiar with the details.

> It does.

Hmm... I'm not sure I got it.

Does the rvalue-reference type adapt to any possible cv-qualification or
something?


--
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

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

alfps@start.no ("Alf P. Steinbach") writes:

> * David Abrahams:
>> Jens Theisen <jth02@arcor.de> writes:
>>
>>> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:
>>>
>>>> The forwarding problem is well known as "strstr" problem. C++ must have two
>>>> separate versions of strstr, one with const, one without. Same thing happens
>>>> for most definitions of operator[], begin()/end() in containers etc.
>>>>
>>>> Is there any proposal for this problem?
>>> I think the rvalue reference proposal also solves the forwarding
>>> problem, though I'm not familiar with the details.
>>
>> It does.
>
> An example of solving that problem, and a link to the proposal, would
> be nice.

Google up the papers in the committee mailings.  That's exactly what I
would have to do.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.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://www.comeaucomputing.com/csc/faq.html                      ]

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
writes:

> Dnia Sat,  4 Nov 2006 21:39:46 CST, David Abrahams skrobie:
>> Jens Theisen <jth02@arcor.de> writes:
>
>> > Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:
>> >
>> >> The forwarding problem is well known as "strstr" problem. C++ must have two
>> >> separate versions of strstr, one with const, one without. Same thing happens
>> >> for most definitions of operator[], begin()/end() in containers etc.
>> >>
>> >> Is there any proposal for this problem?
>> >
>> > I think the rvalue reference proposal also solves the forwarding
>> > problem, though I'm not familiar with the details.
>
>> It does.
>
> Hmm... I'm not sure I got it.
>
> Does the rvalue-reference type adapt to any possible cv-qualification or
> something?

yeah..."or something." :)

      template <class T>
      int f(T& x)

already "adapts" to any possible cv-qualification for lvalues; it just
doesn't handle non-const rvalue arguments.

      template <class T>
      int f(T&& x)

does all that, plus it accepts non-const rvalues.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.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://www.comeaucomputing.com/csc/faq.html                      ]

* David Abrahams:
> alfps@start.no ("Alf P. Steinbach") writes:
>
>> * David Abrahams:
>>> Jens Theisen <jth02@arcor.de> writes:
>>>
>>>> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:
>>>>
>>>>> The forwarding problem is well known as "strstr" problem. C++ must have two
>>>>> separate versions of strstr, one with const, one without. Same thing happens
>>>>> for most definitions of operator[], begin()/end() in containers etc.
>>>>>
>>>>> Is there any proposal for this problem?
>>>> I think the rvalue reference proposal also solves the forwarding
>>>> problem, though I'm not familiar with the details.
>>> It does.
>> An example of solving that problem, and a link to the proposal, would
>> be nice.
>
> Google up the papers in the committee mailings.  That's exactly what I
> would have to do.

Only too glad to be of help; see <url:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html>.

However, that paper does not AFAICS contain an example or explanation of
solving the problem described by Sektor van Skijlen, which you maintain,
above, that the proposal does solve.

An example + explanation would be nice.

For example, given current C++ code like

   class Vec
   {
   public:
       typedef Whatever Element;

       Element& at( std::size_t i ) { ... }
       Element const& at( std::size_t i ) const { ... }
   };

How is this solved using rvalue references?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

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

alfps@start.no ("Alf P. Steinbach") writes:

> For example, given current C++ code like
>
>   class Vec
>   {
>   public:
>       typedef Whatever Element;
>
>       Element& at( std::size_t i ) { ... }
>       Element const& at( std::size_t i ) const { ... }
>   };
>
> How is this solved using rvalue references?

Oh, I see.  The forwarding problem by definition is one where an
exponential number of overloads is required in order to forward
function calls with N arguments transparently.  While this
verbosity-of-handling-member-function-constness causes real pain, it
only causes two overloads, rather than 2^N where N is the number of
arguments, so it's a misnomer to call this "the forwarding problem"
(and IIUC we get to say what the forwarding problem is since we
defined the term ;^) ).

That said, it is a problem in the same general ballpark, and I believe
there are other proposals working in that area, e.g.:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1784.htm
  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1821.htm

although I don't think that either of these solves this particular
problem of code replication, and I agree that it ought to be solved.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.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://www.comeaucomputing.com/csc/faq.html                      ]

Dnia Mon,  6 Nov 2006 19:53:41 GMT, David Abrahams skrobie:
> > Does the rvalue-reference type adapt to any possible cv-qualification or
> > something?

> yeah..."or something." :)

>       template <class T>
>       int f(T& x)

> already "adapts" to any possible cv-qualification for lvalues; it just
> doesn't handle non-const rvalue arguments.

>       template <class T>
>       int f(T&& x)

> does all that, plus it accepts non-const rvalues.

That's fine, but does not look like anything concerning the forwarding
problem.

In general, the forwarding problem is when you return a value (or a reference)
to something that is passed to a function, and has appropriate
cv-qualification attribute. You do nothing about this object but maybe reading
from it or returning some of its internals or returning some value associated
with this. Anyway - these two values shere the same cv-qualification and the
cv-qualification of the returned value should be transparently passed through
this function from the received value.

It wouldn't be stated "a problem" if it didn't occur that many times the same
way and always require either duplicating code/using preprocessor/using
const_cast.


--
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

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

ethouris@guess.if.gmail.com.is.valid.or.invalid (Sektor van Skijlen)
writes:

> Dnia Mon,  6 Nov 2006 19:53:41 GMT, David Abrahams skrobie:
>> > Does the rvalue-reference type adapt to any possible cv-qualification or
>> > something?
>
>> yeah..."or something." :)
>
>>       template <class T>
>>       int f(T& x)
>
>> already "adapts" to any possible cv-qualification for lvalues; it just
>> doesn't handle non-const rvalue arguments.
>
>>       template <class T>
>>       int f(T&& x)
>
>> does all that, plus it accepts non-const rvalues.
>
> That's fine, but does not look like anything concerning the forwarding
> problem.
>
> In general, the forwarding problem is when you return a value (or a reference)
> to something that is passed to a function, and has appropriate
> cv-qualification attribute.

That is a brand-new definition of "the forwarding problem" AFAICT, and
not the one we used in the original committee papers identifying The
Forwarding Problem.

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm

If you have an earlier reference to the term than that, I'd appreciate
seeing it.  In that case we should have chosen a different phrase to
describe our problem... although now it has achieved currency (at
least with many people) and I don't think changing our terminology
makes much sense.

> You do nothing about this object but maybe reading
> from it or returning some of its internals or returning some value associated
> with this. Anyway - these two values shere the same cv-qualification and the
> cv-qualification of the returned value should be transparently passed through
> this function from the received value.
>
> It wouldn't be stated "a problem" if it didn't occur that many times the same
> way and always require either duplicating code/using preprocessor/using
> const_cast.

Yes, that's a real problem, but compared to The Forwarding Problem as
defined in n1385, well, it's O(1) vs. O(2^N): no contest.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.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://www.comeaucomputing.com/csc/faq.html                      ]

* Sektor van Skijlen:
> The forwarding problem is well known as "strstr" problem. C++ must have two
> separate versions of strstr, one with const, one without. Same thing happens
> for most definitions of operator[], begin()/end() in containers etc.
>
> Is there any proposal for this problem?

Don't know.  But the declarations

     template< typename T > struct Const{ typedef T const Type; };
     template< typename T > struct NonConst{ typedef T Type; };

     #define CONSTNESS_TEMPLATE  \
         template< template<typename> class Constness >

     #define CONSTNESS( t ) typename Constness<t>::Type

(not perfect, but simple and good enough for practical work) allows one
to write things like

     class Vec3
     {
     private:
         double  myCoor[3];

         CONSTNESS_TEMPLATE
         static CONSTNESS(double)& atImpl(
             CONSTNESS(Vec3)&    v,
             std::size_t         i
             )
         {
             assert( i < 3 );
             return v.myCoor[i];
         }

     public:
         Vec3(): myCoor() {}

         double const& at( std::size_t i ) const
         { return atImpl<Const>( *this, i ); }

         double& at( std::size_t i )
         { return atImpl<NonConst>( *this, i ); }
     };

With language support this could be specified directly in the member
function declaration, e.g. like

     class Vec3
     {
     private:
         double  myCoor[3];

     public:
         Vec3(): myCoor() {}

         double constness& at( std::size_t i ) constness
         {
             assert( i < 3 );
             return myCoor[i];
         }
     };

where upon seeing 'constness' the compiler is obliged to generate two
versions, one with 'constness' replaced with nothing, and one with
'constness' replaced with 'const'.

A manual inspection of Google code search results (unfortunately I'm not
an expert on regexp expressions!) found only 2 instances of 'constness'
used as an identifier in C++ code, namely

   <url: http://tinyurl.com/y56sjl> (declaration) and
   <url: http://tinyurl.com/y7l3gw> (implementation) code for
   <url: http://home.mweb.co.za/sd/sdonovan/underc.html>, and

   <url: http://tinyurl.com/t4q2j> code for
   <url: http://www.archiveopteryx.org/>.

In both cases it's a 'bool' function argument that's not assigned to, so
a rule that if the two versions generated for 'constness' are
effectively identical, then one of them should be discarded, would
ensure backward compatibility with known existing usage, and also allow
tentative declarations to be refined later.

Should I write this up as a proposal? ;-)

Of course, a more general solution could in one direction be some sort
of 'like' facility (idea from Eiffel anchor types), and in another
direction could be some sort of function attributes, and in yet a third
direction could be some variation on ordinary templates, a kind of
restricted template that could be applied to virtual functions.  But I
fear those would be solutions looking for the problems to solve.  And
would in actual usage be just as much to write as one currently must.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

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

Sektor van Skijlen wrote:
> The forwarding problem is well known as "strstr" problem. C++ must have two
> separate versions of strstr, one with const, one without. Same thing happens
> for most definitions of operator[], begin()/end() in containers etc.
>
> Is there any proposal for this problem?

I think I've seen a proposal for cv-qualifier template arguments:

    template <cvqual CV>
    CV char* strstr(CV char* haystack, const char* needle);

    template <cvqual CV>
    CV value_type& operator[](size_type) CV;

I don't know whether anything like that is actually being considered
for standardization by the committee.

--
Seungbeom Kim

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

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

> The forwarding problem is well known as "strstr" problem. C++ must have two
> separate versions of strstr, one with const, one without. Same thing happens
> for most definitions of operator[], begin()/end() in containers etc.
>
> Is there any proposal for this problem?

I think the rvalue reference proposal also solves the forwarding
problem, though I'm not familiar with the details.

--
Cheers, Jens

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

Sektor van Skijlen wrote:

> The forwarding problem is well known as "strstr" problem. C++ must have two
> separate versions of strstr, one with const, one without. Same thing happens
> for most definitions of operator[], begin()/end() in containers etc.

> Is there any proposal for this problem?

I'm not sure I see the problem.  In the case of strstr, the only
problem is dealing with a legacy interface; had the functions
been designed for C++, they'd be templates in the algorithm
section, with only one copy of the source code (but an infinity
of implementations).  In the other cases, the functions may not
differ in the way the code is written, but they will differ in
other significant aspects, like return type (e.g. iterator or
const_iterator), in various ways depending on the class.  (My
operator[] often return proxies, with different, unrelated proxy
types as return values.)  Given that the differences are often
as important as the similarities (and both functions can use a
private member function for the similar parts, if they are
important), I don't see any real problem to be solved.

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


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

Dnia Wed,  1 Nov 2006 16:33:28 CST, James Kanze skrobie:
> Sektor van Skijlen wrote:

> > The forwarding problem is well known as "strstr" problem. C++ must have two
> > separate versions of strstr, one with const, one without. Same thing happens
> > for most definitions of operator[], begin()/end() in containers etc.

> > Is there any proposal for this problem?

> I'm not sure I see the problem.  In the case of strstr, the only
> problem is dealing with a legacy interface;

Ok, looxlike you don't get it, so I'll explain, using strstr as an example.

int f()
{
 const char* s1 = "simplestring";

 char s2 [] = "some longer string";

 // find in a constant string
 const char* p1 = strstr( s1, "string" );

 // find in a mutable string
 char* p2 = strstr( s2, "string" );
}

Now: how do you write a header for 'strstr' function so that it can be used as
above and simultaneously does not lead to break the cv-qualification?

For ANSI C, this is the header:

char* strstr( const char*, const char* );

But it leads to break the cv-qualification. You can still pass a const_pointer
to this function, but the result is a mutable pointer. This way you may have
an implicit const_cast.

For C++, so far, the following method is used (based on overloading):

extern "C" const char* strstr( const char*, const char* );

char* strstr( char* base, const char* in )
{
 return const_cast<char*>( strstr( (const char*)base, in ) );
}

This means that you can't have only one definition of strstr; either you must
write it twice or redirect from one to another using const_cast. Same
situation is in, for example, vector::operator[], vector::begin() etc. You
always have to provide two separate definitions.

Something that might be a solution would be looking like that:

template <const CvQual>
CvQual char* strstr( CvQual char*, const char* );

This way, the returned pointer has the same cv-qualification, as the received
pointer.

If the return type differs, this may still be used together with the template
type mapping - something like that:

template <typename T> struct ittypemap {
typedef typename T::iterator iterator;
};

template <typename T> struct ittypemap<const T> {
typedef typename T::const_iterator iterator;
};

template <const CvQual>
ittypemap<CvQual ThisType>::iterator begin() CvQual { ... }

It even does not make a difference if types are unrelated. Most definitions of
begin(), operator[] etc. don't differ beside this small thing that they have
different signatures.


--
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

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

James Kanze wrote:
> Sektor van Skijlen wrote:
>
> > The forwarding problem is well known as "strstr" problem. C++ must have two
> > separate versions of strstr, one with const, one without. Same thing happens
> > for most definitions of operator[], begin()/end() in containers etc.
>
> > Is there any proposal for this problem?
>
> I'm not sure I see the problem.  In the case of strstr, the only
> problem is dealing with a legacy interface; had the functions
> been designed for C++, they'd be templates in the algorithm
> section, with only one copy of the source code (but an infinity
> of implementations).  In the other cases, the functions may not
> differ in the way the code is written, but they will differ in
> other significant aspects, like return type (e.g. iterator or
> const_iterator), in various ways depending on the class.  (My
> operator[] often return proxies, with different, unrelated proxy
> types as return values.)  Given that the differences are often
> as important as the similarities (and both functions can use a
> private member function for the similar parts, if they are
> important), I don't see any real problem to be solved.

A related question would be if the compiler could reconize that
the object code for a successful exansion of a template for
type parameter const T could generally be reused as the
expansion for (non-const) T.   The compiler would have
to generate distinct object code if the template used
functions that were overloaded for both const T and T.

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

* Sektor van Skijlen:
>
> Something that might be a solution would be looking like that:
>
> template <const CvQual>
> CvQual char* strstr( CvQual char*, const char* );

I think it's ungood to use the template mechanism, because the solution
has to be able to be applied to virtual functions, and a special kind of
template might later have to be reconciled with a more general
restricted template mechanism.  Besides, it's wordy.  And unreadable,
and very easy to confuse with ordinary templates.

And I think it's ungood to drag 'volatile' into this.  Rather that wart
on the language should not just be deprecated, but flensed off with a
sharpish knife.  It's good for nothing except complexity & bugs, and a
good preparation for the final flensing could be to ignore it here.

So, in short, I'm advocating the single keyword 'constness'. ;-)  It's
readable, it conveys the intention, it's easy to understand, etc.

KISS,

- Alf


--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

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

Sektor van Skijlen wrote:
> Dnia Wed,  1 Nov 2006 16:33:28 CST, James Kanze skrobie:
> > Sektor van Skijlen wrote:

> > > The forwarding problem is well known as "strstr" problem.
> > > C++ must have two separate versions of strstr, one with
> > > const, one without. Same thing happens for most
> > > definitions of operator[], begin()/end() in containers
> > > etc.
>
> > > Is there any proposal for this problem?

> > I'm not sure I see the problem.  In the case of strstr, the only
> > problem is dealing with a legacy interface;

> Ok, looxlike you don't get it,

I think it's you that didn't get it.  The problem with strstr is
that it is a legacy interface, designed before const was
introduced into the language.

> so I'll explain, using strstr as an example.

I'm quite familiar with the interface of strstr.

> int f()
> {
>  const char* s1 = "simplestring";
>
>  char s2 [] = "some longer string";
>
>  // find in a constant string
>  const char* p1 = strstr( s1, "string" );
>
>  // find in a mutable string
>  char* p2 = strstr( s2, "string" );
> }

> Now: how do you write a header for 'strstr' function so that
> it can be used as above and simultaneously does not lead to
> break the cv-qualification?

To begin with, I wouldn't, because that's not the way we do
things in C++.  In C++, the interface would probably be more
along the lines of:

    template < class ForwardIterator1 , class ForwardIterator2 >
    ForwardIterator1 strstr (
        ForwardIterator1 first1, ForwardIterator1 last1,
        ForwardIterator2 first2, ForwardIterator2 last2 );

Except that one would probably not call it strstr.  More likely
something along the lines of find_first_of.

> For ANSI C, this is the header:

> char* strstr( const char*, const char* );

> But it leads to break the cv-qualification.

And before ANSI C, the interface was:

    char* strstr( char*, char* ) ;

As I said to begin with, we're trying to hack new concepts into
a legacy interface.  The problem doesn't exist in C++ modern,
and I can't see introducing additional baggage into C++ just to
make it easier to implement legacy interfaces that have been
slightly hacked.

> You can still pass a const_pointer to this function, but the
> result is a mutable pointer. This way you may have an implicit
> const_cast.

> For C++, so far, the following method is used (based on overloading):

> extern "C" const char* strstr( const char*, const char* );

> char* strstr( char* base, const char* in )
> {
>  return const_cast<char*>( strstr( (const char*)base, in ) );
> }

> This means that you can't have only one definition of strstr;
> either you must write it twice or redirect from one to another
> using const_cast.

Or use some compiler magic:-).  But surely you aren't proposing
extending the language just to facilitate implementing
interfaces we inherited from C.

> Same situation is in, for example, vector::operator[],
> vector::begin() etc. You always have to provide two separate
> definitions.

But the return type in this case is different.  It isn't a case
of just having a different const-qualifier---it is an unrelated
type.  The issues aren't the same.

As I said, if there is a significant amount of identical code,
C++ has a feature called functions which permit factoring it
out.

> Something that might be a solution would be looking like that:

> template <const CvQual>
> CvQual char* strstr( CvQual char*, const char* );

> This way, the returned pointer has the same cv-qualification,
> as the received pointer.

Which would help for strstr, which doesn't really interest
anyone, but not for cases like operator[].

    [...]
> It even does not make a difference if types are unrelated.
> Most definitions of begin(), operator[] etc. don't differ
> beside this small thing that they have different signatures.

They do and they don't.  Most implementations of begin() or
operator[] are so small that the return type can be considered a
significant part of the code.  And when they have more in common
(e.g. bounds checking in operator[]), you use a private member
function to factorize the common behavior.

However you look at it, the problem isn't great enough to
warrent addressing at the language level.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


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

The forwarding problem is well known as "strstr" problem. C++ must have two
separate versions of strstr, one with const, one without. Same thing happens
for most definitions of operator[], begin()/end() in containers etc.

Is there any proposal for this problem?


--
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

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