C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  ostream_iterator design question          C++Talk.NET Forum Index -> C++ language, library and standards 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 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language, library and standards All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  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 Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.