 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Johan Johansson
Guest
|
 Posted: Wed Jul 06, 2005 9:36 am Post subject: Rationale for standard library template parameters wrt strin |
 |
|
Hi
There are a few cases in the standard library where strings are produced
or accepted, e.g. bitset::to_string with the following prototype:
template <class charT, class traits, class Allocator>
basic_string<charT, traits, Allocator> to_string() const;
Why not
template <class stringT>
stringT to_string() const;
as all the present template parameters could be accessed if so desired
as stringT::value_type, stringT::traits_type and stringT::allocator_type?
The same thing seems to go for the stringstreams.
This requires the implementation to explicitly name basic_string which
would seem in contradiction to the slogan of "to use the STL is to
extend it" and slogans aside, I don't see any particular benefit of
requiring the string to be a basic_string.
Does anyone know/remember?
Johan
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
kanze@gabi-soft.fr
Guest
|
| Posted: Thu Jul 07, 2005 2:46 pm Post subject: Re: Rationale for standard library template parameters wrt s |
|
|
Johan Johansson wrote:
| Quote: | There are a few cases in the standard library where strings
are produced or accepted, e.g. bitset::to_string with the
following prototype:
template <class charT, class traits, class Allocator
basic_string
Why not
template <class stringT
stringT to_string() const;
as all the present template parameters could be accessed if so
desired as stringT::value_type, stringT::traits_type and
stringT::allocator_type?
|
Why not just return an std::string, so the user doesn't have to
specify?
One would have thought that the classical solution would be to
return an iterator whose value_type is char -- and which could
thus be used to initialize any container whose value_type can be
initialized by a char. (This is, at any rate, the solution I
normally use.) Of course, the two iterator idiom means that in
fact, you need two functions: to_string_begin() and
to_string_end(), but it's quite doable. If you need a string,
you just write:
std::string s( bv.to_string_begin(), bv.to_string_end() ) ;
But of course, it works just as well with std::vector
any other container.
--
James Kanze GABI Software
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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
johanj@ipunplugged.com
Guest
|
| Posted: Fri Jul 08, 2005 1:09 am Post subject: Re: Rationale for standard library template parameters wrt s |
|
|
Using std::string wouldn't accomodate for wide strings would seem to be
the obvious answer. If you return iterators, there is precedent in
returning a std::pair of iterators, as I'm sure you're aware of (e.g.
equal_range). But is that really a more canonical solution than taking
a reference to a string? That would have the benefit of being able to
deduce the template parameters as well.
In any event this brings us no closer to responding to the original
question.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Sat Jul 09, 2005 1:44 am Post subject: Re: Rationale for standard library template parameters wrt s |
|
|
[email]johanj (AT) ipunplugged (DOT) com[/email] wrote:
| Quote: | Using std::string wouldn't accomodate for wide strings would
seem to be the obvious answer.
|
True, but pratically, that would require a different function
anyway. Something with widen( '1' ) and widen( '2' ).
| Quote: | If you return iterators, there is precedent in returning a
std::pair of iterators, as I'm sure you're aware of (e.g.
equal_range). But is that really a more canonical solution
than taking a reference to a string? That would have the
benefit of being able to deduce the template parameters as
well.
|
I don't know -- do any functions in the standard library take a
reference to an object.
Alternatively, one could pass an iterator to the function. This
does introduce all of the problems C has with sprintf et al,
where the function writes to a target container without knowing
its size. But this doesn't seem to bother anyone with
std::copy. Typically, of course, I would expect an insertion
iterator to be used. And it does have the advantage that the
caller can also decide the order he wants: use a reverse
iterator or a front insertion iterator, if you want the reverse
order of what the standard normally gives.
| Quote: | In any event this brings us no closer to responding to the
original question.
|
Well, yes and no. If the function returns an iterator, it isn't
even a template anymore. Of course, you typically have to have
a template in order to use the results, but I'd guess that 9
times out of 10, what will be written is something like:
std::string( bv.begin_string(), bv.end_string() ) ;
Unless you wrap the iterators in the iterator wrappers (part of
TR1?), so that they call widen and return a wchar_t, of course.
--
James Kanze GABI Software
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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
johanj@ipunplugged.com
Guest
|
| Posted: Sat Jul 09, 2005 6:30 pm Post subject: Re: Rationale for standard library template parameters wrt s |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:
| Quote: | johanj (AT) ipunplugged (DOT) com wrote:
Using std::string wouldn't accomodate for wide strings would
seem to be the obvious answer.
True, but pratically, that would require a different function
anyway. Something with widen( '1' ) and widen( '2' ).
|
Not really. My naive approach would probably involve a stringstream
whose type would depend on the type used to instantiate the to_string
function, to stick to the bitset example.
| Quote: | [suggestion about returning iterators accidentally cut out]
But is that really a more canonical solution
than taking a reference to a string? That would have the
benefit of being able to deduce the template parameters as
well.
I don't know -- do any functions in the standard library take a
reference to an object.
|
No, you're right of course. I was thinking in more general C++ terms,
but it is true that the standard library uses iterators where one might
otherwise expect to see a reference, as per your next suggestion:
| Quote: | Alternatively, one could pass an iterator to the function.
|
Nail, head, hit. I think.
| Quote: | This
does introduce all of the problems C has with sprintf et al,
where the function writes to a target container without knowing
its size. But this doesn't seem to bother anyone with
std::copy.
|
Or transform, or merge. I'm sure there are more. Actually there is
someone who is bothered: Microsoft. VS2005 will produce warnings if you
pass "unchecked iterators" to std::copy. There were a couple of good
posts about this, in the sense of explaining what is going on and why,
on the boost mailing list a few days ago from Herb Sutter and Martyn
Lovell.
| Quote: | In any event this brings us no closer to responding to the
original question.
Well, yes and no.
|
I don't think it does. My question was why was the choice made to
forward the template parameters of basic_string, which makes the call
more awkward and forces basic_string to be used, when the exact same
information could have been extracted from the instantiated string type
through the typedefs of basic_string?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Paul Groke
Guest
|
| Posted: Wed Jul 13, 2005 10:31 am Post subject: Re: Rationale for standard library template parameters wrt s |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:
| Quote: | Johan Johansson wrote:
There are a few cases in the standard library where strings
are produced or accepted, e.g. bitset::to_string with the
following prototype:
template <class charT, class traits, class Allocator
basic_string
Why not
template <class stringT
stringT to_string() const;
as all the present template parameters could be accessed if so
desired as stringT::value_type, stringT::traits_type and
stringT::allocator_type?
Why not just return an std::string, so the user doesn't have to
specify?
One would have thought that the classical solution would be to
return an iterator whose value_type is char -- and which could
thus be used to initialize any container whose value_type can be
initialized by a char. (This is, at any rate, the solution I
normally use.) Of course, the two iterator idiom means that in
fact, you need two functions: to_string_begin() and
to_string_end(), but it's quite doable. If you need a string,
you just write:
std::string s( bv.to_string_begin(), bv.to_string_end() ) ;
But of course, it works just as well with std::vector
any other container.
|
Why not just make the function take an output iterator like in
// inside class definition
template<class U>
void to_string( U& outit ) const // or not const - whatever
{
*outit++ = 'A';
*outit++ = 'B';
//...
}
That way you don't have to provide two functions, and the
implementation becomes way easier when you don't want to "cache"
the string representation after calling "to_string_begin".
And compared to a "caching" implementation it should usually
have the benefit to be thread-safe automatically, wheras the
caching implementation probably won't.
Of course there are disadvantages - the code for creating a
string with the wanted value becomes a 2-liner, and 2 phase
construction (or assignment to some existing object) is enforced.
| Quote: | --
James Kanze GABI Software
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
|
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
