public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Paolo Carlini <pcarlini@unitus.it> To: bkoz@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: libstdc++/1704 Date: Mon, 28 May 2001 06:16:00 -0000 [thread overview] Message-ID: <20010528131604.4296.qmail@sourceware.cygnus.com> (raw) The following reply was made to PR libstdc++/1704; it has been noted by GNATS. From: Paolo Carlini <pcarlini@unitus.it> To: bkoz@gcc.gnu.org Cc: nicolai.josuttis@braunschweig.netsurf.de, bkoz@redhat.com, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org Subject: Re: libstdc++/1704 Date: Mon, 28 May 2001 15:11:36 +0200 --------------EEE41B84D882FF41F380C7A1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, so, I understand from your detailed analysis that this is just a QoI issue? Honestly, as a beginner C++ programmer I slightly prefer the solution adopted by STLport: a conversion error is issued at compile time. Otherwise I find this kind of programming errors *very* difficult to debug ... Thanks, Paolo Carlini. bkoz@gcc.gnu.org wrote: > Synopsis: Null output from Josuttis example > > Responsible-Changed-From-To: unassigned->bkoz > Responsible-Changed-By: bkoz > Responsible-Changed-When: Fri May 25 11:33:14 2001 > Responsible-Changed-Why: > Mine. > State-Changed-From-To: analyzed->feedback > State-Changed-By: bkoz > State-Changed-When: Fri May 25 11:33:14 2001 > State-Changed-Why: > I don't thing this is a bug, really. > In particular, > c = std::toupper(c, getloc()); > > where c == int_type attempts to instantiate > > template<typename _CharT> > inline _CharT > toupper(_CharT __c, const locale& __loc) > { return use_facet<ctype<_CharT> >(__loc).toupper(__c); } > > with _CharT == int. This is allowed, but keep in mind that the standard locale doesn't have ctype<int> as a standard facet, so thus use_facet has to fail: > > template<typename _Facet> > const _Facet& > use_facet(const locale& __loc) > { > typedef locale::_Impl::__vec_facet __vec_facet; > size_t __i = _Facet::id._M_index; > __vec_facet* __facet = __loc._M_impl->_M_facets; > const locale::facet* __fp = (*__facet)[__i]; > if (__fp == 0 || __i >= __facet->size()) > __throw_bad_cast(); > return static_cast<const _Facet&>(*__fp); > } > > > So, std::bad_cast gets thrown here. This is, I believe, standard conformant behavior. To use ctype<int>, you'd have to imbue it in the standard locale (and then add some kind of ctype<int> functionality, which is of course a bit of a job.) > > Instead, I suggest casting the argument to toupper to either char or wchart_t, so that the standard ctype facets are used. I suspect this is the intent of the code. > > Nico? > > -benjamin > > > class outbuf : public std::streambuf > { > protected: > virtual int_type overflow(int_type c) > { > if (c != EOF) > { > // convert lowercase to uppercase > try > { > // c = std::toupper(static_cast<char>(c), getloc()); > c = std::toupper(c, getloc()); > } > catch (std::exception& obj) > { > puts("trying to use ctype<int> in a locale that doesn't have it"); > } > > // and write the character to the standard output > if (std::putchar(c) == EOF) > return EOF; > } > return c; > } > }; > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1704&database=gcc --------------EEE41B84D882FF41F380C7A1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Hi, <p>so, I understand from your detailed analysis that this is just a QoI issue? <br>Honestly, as a beginner C++ programmer I slightly prefer the solution adopted by STLport: a conversion error is issued at compile time. Otherwise I find this kind of programming errors *very* difficult to debug ... <p>Thanks, <br>Paolo Carlini. <br> <p>bkoz@gcc.gnu.org wrote: <blockquote TYPE=CITE>Synopsis: Null output from Josuttis example <p>Responsible-Changed-From-To: unassigned->bkoz <br>Responsible-Changed-By: bkoz <br>Responsible-Changed-When: Fri May 25 11:33:14 2001 <br>Responsible-Changed-Why: <br> Mine. <br>State-Changed-From-To: analyzed->feedback <br>State-Changed-By: bkoz <br>State-Changed-When: Fri May 25 11:33:14 2001 <br>State-Changed-Why: <br> I don't thing this is a bug, really. <br> In particular, <br> c = std::toupper(c, getloc()); <p> where c == int_type attempts to instantiate <p> template<typename _CharT> <br> inline _CharT <br> toupper(_CharT __c, const locale& __loc) <br> { return use_facet<ctype<_CharT> >(__loc).toupper(__c); } <p> with _CharT == int. This is allowed, but keep in mind that the standard locale doesn't have ctype<int> as a standard facet, so thus use_facet has to fail: <p> template<typename _Facet> <br> const _Facet& <br> use_facet(const locale& __loc) <br> { <br> typedef locale::_Impl::__vec_facet __vec_facet; <br> size_t __i = _Facet::id._M_index; <br> __vec_facet* __facet = __loc._M_impl->_M_facets; <br> const locale::facet* __fp = (*__facet)[__i]; <br> if (__fp == 0 || __i >= __facet->size()) <br> __throw_bad_cast(); <br> return static_cast<const _Facet&>(*__fp); <br> } <br> <p> So, std::bad_cast gets thrown here. This is, I believe, standard conformant behavior. To use ctype<int>, you'd have to imbue it in the standard locale (and then add some kind of ctype<int> functionality, which is of course a bit of a job.) <p> Instead, I suggest casting the argument to toupper to either char or wchart_t, so that the standard ctype facets are used. I suspect this is the intent of the code. <p> Nico? <p> -benjamin <br> <p> class outbuf : public std::streambuf <br> { <br> protected: <br> virtual int_type overflow(int_type c) <br> { <br> if (c != EOF) <br> { <br> // convert lowercase to uppercase <br> try <br> { <br> // c = std::toupper(static_cast<char>(c), getloc()); <br> c = std::toupper(c, getloc()); <br> } <br> catch (std::exception& obj) <br> { <br> puts("trying to use ctype<int> in a locale that doesn't have it"); <br> } <p> // and write the character to the standard output <br> if (std::putchar(c) == EOF) <br> return EOF; <br> } <br> return c; <br> } <br> }; <p><a href=" http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1704&database=gcc" ;> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1704&database=gcc </a></blockquote> <br> </html> --------------EEE41B84D882FF41F380C7A1--
next reply other threads:[~2001-05-28 6:16 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2001-05-28 6:16 Paolo Carlini [this message] -- strict thread matches above, loose matches on Subject: below -- 2001-06-05 18:36 libstdc++/1704 bkoz 2001-05-28 12:26 libstdc++/1704 Benjamin Kosnik 2001-05-25 11:36 libstdc++/1704 bkoz
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20010528131604.4296.qmail@sourceware.cygnus.com \ --to=pcarlini@unitus.it \ --cc=bkoz@gcc.gnu.org \ --cc=gcc-prs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).