On May 16, 11:20 am, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
> 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.

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

On May 21, 12:03 am, "s...@roguewave.com" <s...@roguewave.com> wrote:
[...]
> 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                      ]

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                      ]

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

Alberto Ganesh Barbati wrote:
> 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]

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

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.

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                      ]

sebor@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? ;-)

> 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.

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