bumgard@my-deja.com wrote:
>
...
> I would argue that it makes more sense make the
> stateT& argument const and to require that the
> stateT type be copy-constructable such that the
> internal state can be duplicated within the
> do_length() function, so that the length
> calculation can be performed without changing the
> stateT argument.

But then if the sequence passed to do_length() ended in a state other than the
one passed in how would the function communicate the changed state to the caller
(e.g., in order to resume do_length() at the end of the external sequence)?

In a recent discussion on this topic on c++std-lib@research.att.com Howard gives
this possible implementation:

Howard Hinnant wrote:
>
> To: C++ libraries mailing list
> Message c++std-lib-8175
...
> template<class internT, class externT, class stateT>
> int
> codecvt<internT, externT, stateT>::do_length(stateT& state,
>         const externT* from, const externT* from_end, size_t max) const
> {
>    vector<internT> buf(max);
>    internT* to = &buf[0];
>    intenrT* to_limit = to + max;
>    internT* to_next;
>    const externT* from_next;
>    do_in(state, from, from_end, from_next, to, to_limit, to_next);
>    return int(from_next-from);
> }

With state being const you'd have no way to tell what the state at from
[do_length(...)] is.

>
> Otherwise, the do_length() method really behaves
> as "skip" function.
>
> I would think that length() and do_length() would
> be most useful when used in "preflighting" a
> conversion to determine how much space is
> required to store a result.  If that were the
> case, then the do_length() function should not
> change the supplied stateT argument.

You're not the only one wondering about the purpose of the function :) In the
same thread as above, Nathan Myers suggests that the original intent of the
function was to serve as a C++ alternative to mb[r]len, and gives the following
alternate definition:

Nathan Myers wrote:
>
> To: C++ libraries mailing list
> Message c++std-lib-8182
...
>   inline int
>   mblen(char const* s, size_t n, std::locale const& l, std::mbstate_t& st)
>   {
>     return std::use_facet<codecvt<...> >(l).length(st, s, s+n, 1);
>   }


Hope this helps.
Martin

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

The defect described by issue #75 of the Standard
C++ Library issues list,
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-
defects.html#75, proposes that the conflicting
signatures defined the length() and do_length()
methods be corrected so that all references
indicate that these methods accept a stateT& as
their first argument.

The rationale for this change is that a stateT
object must be used to perform the operation
described for these functions, and that the
internal state of the stateT object may be
modified as result.  Hence, the change from a
const stateT& to stateT&.

This change is made on the assumption that the
supplied state should be changed by this method.

I would argue that it makes more sense make the
stateT& argument const and to require that the
stateT type be copy-constructable such that the
internal state can be duplicated within the
do_length() function, so that the length
calculation can be performed without changing the
stateT argument.

Otherwise, the do_length() method really behaves
as "skip" function.

I would think that length() and do_length() would
be most useful when used in "preflighting" a
conversion to determine how much space is
required to store a result.  If that were the
case, then the do_length() function should not
change the supplied stateT argument.

-g.b.


Sent via Deja.com
http://www.deja.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]