public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/4458
@ 2001-10-29  8:36 Phil Edwards
  0 siblings, 0 replies; 3+ messages in thread
From: Phil Edwards @ 2001-10-29  8:36 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR libstdc++/4458; it has been noted by GNATS.

From: Phil Edwards <pedwards@disaster.jaj.com>
To: kanze@gabi-soft.de
Cc: Martin Sebor <sebor@roguewave.com>, gcc-gnats@gcc.gnu.org,
        gcc-bugs@gcc.gnu.org
Subject: Re: libstdc++/4458
Date: Mon, 29 Oct 2001 11:34:20 -0500

 On Sun, Oct 28, 2001 at 12:16:01PM +0100, James Kanze wrote:
 > I conclude that if I want to implement the iso_8859_1 locale for ctype,
 > it should be sufficient to provide the correct table.  I don't need it
 > for my current work, so finding time for it isn't necessarily easy, but
 > if I can get around to it, do I have to do anything special to get it
 > integrated into the normal g++ releases?
 
 http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/contribute.html
 
 You might want to contact libstdc++@gcc.gnu.org first, to avoid duplication
 of effort.
 
 
 
 Phil
 
 -- 
 If ye love wealth greater than liberty, the tranquility of servitude greater
 than the animating contest for freedom, go home and leave us in peace.  We seek
 not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
 and may posterity forget that ye were our countrymen.            - Samuel Adams


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: libstdc++/4458
@ 2001-10-28  2:16 James Kanze
  0 siblings, 0 replies; 3+ messages in thread
From: James Kanze @ 2001-10-28  2:16 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

The following reply was made to PR libstdc++/4458; it has been noted by GNATS.

From: James Kanze <kanze@YAST_ASK>
To: Martin Sebor <sebor@roguewave.com>
Cc: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: libstdc++/4458
Date: 28 Oct 2001 12:16:01 +0100

 Martin Sebor <sebor@roguewave.com> writes:
 
 |>  http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=4458&database=gcc
 
 |>   |>  It's not required to do so for efficiency (see 22.2.1.3.2, p5).
 
 |>   §22.2.1.1.1/1: concerning std::ctype<>::is:
 
 |>       Returns: do_is(m,c)
 
 |>   Can't be any clearer than that.  The function do_is is required by
 |>   the standard to be virtual, which means that the actual function
 |>   called (and thus the actual semantics of the function is) depend on
 |>   the dynamic type of the object.  This is, after all, the whole
 |>   point behind defining the protected virtual functions -- any other
 |>   interpretation, and having the protected interface makes sense.
 
 |>  No, you're quoting the requirement on the primary template, but your
 |>  issue (titled std::ctype<char>::is ...) is with the specialization
 |>  on char. The requirement I referred you to in 22.2.1.3.2, p5 is the
 |>  one that's relevant here. The reason for not calling the virtual
 |>  function from the ctype<char>::is() is, as I said earlier, for
 |>  efficiency.
 
 I've found it now.  It never occurred to me that the standard could
 require that a specialization have different semantics than the basic
 template.  I guess the bug is in the standard, and not in g++.
 
 I conclude that if I want to implement the iso_8859_1 locale for ctype,
 it should be sufficient to provide the correct table.  I don't need it
 for my current work, so finding time for it isn't necessarily easy, but
 if I can get around to it, do I have to do anything special to get it
 integrated into the normal g++ releases?
 
 -- 
 James Kanze                                mailto:kanze@gabi-soft.de
 Conseils en informatique orientée objet/
                     Beratung in objektorientierter Datenverarbeitung
 Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: libstdc++/4458
@ 2001-10-14 14:06 Martin Sebor
  0 siblings, 0 replies; 3+ messages in thread
From: Martin Sebor @ 2001-10-14 14:06 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

The following reply was made to PR libstdc++/4458; it has been noted by GNATS.

From: Martin Sebor <sebor@roguewave.com>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org,
 	kanze@gabi-soft.de, gcc-bugs@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/4458
Date: Sun, 14 Oct 2001 15:02:40 -0600

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=4458&database=gcc
 
  |>  It's not required to do so for efficiency (see 22.2.1.3.2, p5).
  
  §22.2.1.1.1/1: concerning std::ctype<>::is:
  
      Returns: do_is(m,c)
  
  Can't be any clearer than that.  The function do_is is required by the
  standard to be virtual, which means that the actual function called (and
  thus the actual semantics of the function is) depend on the dynamic type
  of the object.  This is, after all, the whole point behind defining the
  protected virtual functions -- any other interpretation, and having the
  protected interface makes sense.
 
 No, you're quoting the requirement on the primary template, but your
 issue (titled std::ctype<char>::is ...) is with the specialization on
 char. The requirement I referred you to in 22.2.1.3.2, p5 is the one
 that's relevant here. The reason for not calling the virtual function
 from the ctype<char>::is() is, as I said earlier, for efficiency. 
 
 Regards
 Martin


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2001-10-29  8:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-10-29  8:36 libstdc++/4458 Phil Edwards
  -- strict thread matches above, loose matches on Subject: below --
2001-10-28  2:16 libstdc++/4458 James Kanze
2001-10-14 14:06 libstdc++/4458 Martin Sebor

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