 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Marcus Lindblom
Guest
|
 Posted: Sun May 13, 2007 2:46 am Post subject: ostream_iterator design question |
 |
|
Hi,
The ostream_iterator class is templated on the output type, so that
assignment operator has the following (simplified) declaration:
template<class T, ...> ostream_iterator<T, ...>::operator=(const T& t);
However, couldn't it work with just that function being templated on T,
so that any object could be output with the same iterator object?
template<...>
template<class T>
ostream_iterator<...>::operator=(const T& t);
It would work in most cases, methinks, but I'm guessing the current
design is due to there being iterator_traits or something?
Just curious. :)
Cheers,
/Marcus
---
[ 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 ] |
|
| Back to top |
|
 |
Alberto Ganesh Barbati
Guest
|
| Posted: Mon May 14, 2007 9:41 pm Post subject: Re: ostream_iterator design question |
|
|
Marcus Lindblom ha scritto:
| Quote: | Hi,
The ostream_iterator class is templated on the output type, so that
assignment operator has the following (simplified) declaration:
template<class T, ...> ostream_iterator<T, ...>::operator=(const T& t);
However, couldn't it work with just that function being templated on T,
so that any object could be output with the same iterator object?
template<...
template<class T
ostream_iterator<...>::operator=(const T& t);
It would work in most cases, methinks, but I'm guessing the current
design is due to there being iterator_traits or something?
|
Such an iterator might be more flexible, but there are cases where you
want to coerce the output type. Consider this code:
char str[] = "Hello, world\n";
std::copy(str, str + sizeof(str),
ostream_iterator<int>(cout)); // int, not char!
you cannot obtain the same effect with your proposed iterator.
Ganesh
---
[ 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 ] |
|
| Back to top |
|
|
Marcus Lindblom
Guest
|
| Posted: Tue May 15, 2007 1:13 am Post subject: Re: ostream_iterator design question |
|
|
Alberto Ganesh Barbati wrote:
| Quote: | Marcus Lindblom ha scritto:
Hi,
The ostream_iterator class is templated on the output type, so that
assignment operator has the following (simplified) declaration:
template<class T, ...> ostream_iterator<T, ...>::operator=(const T& t);
However, couldn't it work with just that function being templated on T,
so that any object could be output with the same iterator object?
|
[snip]
| Quote: | Such an iterator might be more flexible, but there are cases where you
want to coerce the output type.
|
Ah. Makes sense.
Thanks! :)
/Marcus
---
[ 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 ] |
|
| Back to top |
|
|
sebor@roguewave.com
Guest
|
| Posted: Tue May 15, 2007 3:49 am Post subject: Re: ostream_iterator design question |
|
|
On May 14, 10:41 am, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
[...]
| Quote: | Such an iterator might be more flexible, but there are cases where you
want to coerce the output type.
|
That's a good point, although generalizing the case above might
produce
unexpected results due to sign extension when char is a signed type.
FWIW, I believe iostreams (including stream iterators) would have been
better designed as the OP suggests without the extensive
parametrization,
with the benefit being a dramatic reduction in the amount of object
code
generated from all the templates. For instance, there is no reason why
it shouldn't be possible to insert a wide character string to a narrow
stream (such as std::cout) with the exact same result as inserting the
same wide string into a wide stream (std::wcout). I have prototyped
an overloaded operator<<(const wchar_t*) in the Apache C++ Standard
Library and, provided it's found useful, plan to propose it as an
extension
to the C++ Standard.
---
[ 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 ] |
|
| Back to top |
|
|
Alberto Ganesh Barbati
Guest
|
| Posted: Wed May 16, 2007 10:20 pm Post subject: Re: ostream_iterator design question |
|
|
sebor (AT) roguewave (DOT) com ha scritto:
| Quote: | On May 14, 10:41 am, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
[...]
Such an iterator might be more flexible, but there are cases where you
want to coerce the output type.
That's a good point, although generalizing the case above might
produce
unexpected results due to sign extension when char is a signed type.
|
If a char is a signed type and you have a character with negative value,
the code would nicely print a negative integer. What is unexpected in
that? Unless you expected that code to actually print ASCII values...
but you didn't really expect that, did you? ;-)
| Quote: | generated from all the templates. For instance, there is no reason why
it shouldn't be possible to insert a wide character string to a narrow
stream (such as std::cout) with the exact same result as inserting the
same wide string into a wide stream (std::wcout).
|
????
Could you please elaborate? How could that be possible if the wide
characters you have to insert have no corresponding narrow characters?
It seems to me that you claim can be true if and only if the string is
composed by characters from a limited character set and there is a
trivial encoding between narrow and wide chars from such a set. In the
general case what you claim is simply *not* possible.
| Quote: | same wide string into a wide stream (std::wcout). I have prototyped
an overloaded operator<<(const wchar_t*) in the Apache C++ Standard
Library and, provided it's found useful, plan to propose it as an
extension
to the C++ Standard.
|
Unless you are going to properly and portably support generic multibyte
encodings, your code won't be very useful.
Just my opinion,
Ganesh
---
[ 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 ] |
|
| Back to top |
|
|
sebor@roguewave.com
Guest
|
| Posted: Mon May 21, 2007 6:03 am Post subject: Re: ostream_iterator design question |
|
|
On May 16, 11:20 am, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
| Quote: | s...@roguewave.com ha scritto:
On May 14, 10:41 am, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
[...]
Such an iterator might be more flexible, but there are cases where you
want to coerce the output type.
That's a good point, although generalizing the case above might
produce
unexpected results due to sign extension when char is a signed type.
If a char is a signed type and you have a character with negative value,
the code would nicely print a negative integer. What is unexpected in
that? Unless you expected that code to actually print ASCII values...
but you didn't really expect that, did you? 
|
I said "might produce unexpected results." As in "may or may not,"
depending on what one's expectation is. Not everyone is aware that
char may be a signed (or unsigned) type and novices familiar with
one environment often assume that the signedness will be the same
in others.
| Quote: |
generated from all the templates. For instance, there is no reason why
it shouldn't be possible to insert a wide character string to a narrow
stream (such as std::cout) with the exact same result as inserting the
same wide string into a wide stream (std::wcout).
????
Could you please elaborate? How could that be possible if the wide
characters you have to insert have no corresponding narrow characters?
|
The wide character inserter I prototyped in the Apache C++ Standard
Library uses the codecvt facet installed in the locale imbued in the
stream object to convert the source characters into the corresponding
multibyte characters that can be manipulated by the streambuf. Where
there are no such corresponding chartacters the inserter fails, just
like
inserting a wchar_t into a wide stream fails today under the same
conditions.
---
[ 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 ] |
|
| Back to top |
|
|
sebor@roguewave.com
Guest
|
| Posted: Mon May 21, 2007 5:52 pm Post subject: Re: ostream_iterator design question |
|
|
On May 21, 12:03 am, "s...@roguewave.com" <s...@roguewave.com> wrote:
[...]
| Quote: | The wide character inserter I prototyped in the Apache C++ Standard
Library uses the codecvt facet installed in the locale imbued in the
stream object to convert the source characters into the corresponding
multibyte characters that can be manipulated by the streambuf. Where
there are no such corresponding chartacters the inserter fails, just
like
inserting a wchar_t into a wide stream fails today under the same
conditions.
|
Here's a working example program with the prototype:
http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/examples/manual/insert_wchar.cpp
The program uses the "UTF-8@UCS" name to select a UCS to UTF-8
codeset conversion in the codecvt_byname facet. The name is specific
to the Apache implementation of the C++ Standard Library and most
likely will not be recognized by other implementations. Feedback on
the inserter or the example program is welcome!
---
[ 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 ] |
|
| 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
