From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: *
X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,HEADER_SPAM,
	PP_MIME_FAKE_ASCII_TEXT,REPLYTO_WITHOUT_TO_CC autolearn=no
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII
X-Google-Thread: 103376,b30bd69fa8f63cb2
X-Google-Attributes: gid103376,public
X-Google-Thread: fc772,b30bd69fa8f63cb2
X-Google-Attributes: gidfc772,public
X-Google-ArrivalTime: 2003-06-16 15:40:40 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!uwm.edu!rpi!not-for-mail
From: Francis Glassborow <francis.glassborow@ntlworld.com>
Newsgroups: comp.lang.ada,comp.lang.c++.moderated
Subject: Re: C bug of the day
Date: 16 Jun 2003 18:42:54 -0400
Organization: Southfield Microcomputer SS
Sender: cppmods@netlab.cs.rpi.edu
Message-ID: <qsd$P5A4sY7+Ewfg@robinton.demon.co.uk>
References: <1054751321.434656@master.nyc.kbcfp.com>
 <memo.20030605193115.9141A@brangdon.madasafish.com>
 <d6652001.0306100323.338a2a1c@posting.google.com>
 <Xns9396BDBB14558jimmaureenrogers@204.127.36.1>
 <bc8423$gt53a$1@ID-14036.news.dfncis.de>
 <Xns9398BD1E07E3Ejimmaureenrogers@204.127.36.1>
 <WXiGa.11515$KF1.273500@amstwist00>
 <V1ggZeGK6g6+EwQn@robinton.demon.co.uk>
 <CnRGa.11791$KF1.273607@amstwist00>
 <jhPtsFBx6F7+EwOv@robinton.demon.co.uk>
 <lB5Ha.11929$KF1.273430@amstwist00>
Reply-To: Francis Glassborow <francis@robinton.demon.co.uk>
NNTP-Posting-Host: netlab.cs.rpi.edu
X-Original-Date: Mon, 16 Jun 2003 10:17:44 +0100
X-Submission-Address: c++-submit@netlab.cs.rpi.edu
X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated
	iQBVAwUAPu5H3UHMCo9UcraBAQGhQAH7B69BxR0b3Rx05uERcPMEfJJZ1BAHepF5
	d+UNc2BKQTTrDa2T4+c6Jv4XhBdY0JbKomwW4NsnoqCDtNEHGghW7w==
	=1ek2
Xref: archiver1.google.com comp.lang.ada:39291 comp.lang.c++.moderated:68463
Date: 2003-06-16T18:42:54-04:00
List-Id: <comp.lang.ada>

In message <lB5Ha.11929$KF1.273430@amstwist00>, Terje Sletteb� 
<tslettebo@chello.no.nospam> writes
> > // These templates provide safe input for any type that supports
> > operator>>
> > // 1) from console with prompt
> >
> >         template<typename in_type>
> >         in_type read(std::string const & prompt, int max_tries = 3){
> >                 in_type temp;
>
>I thought your point was that you avoided the use of uninitialised
>variables? However, that still happens, here.
>
>So maybe your point was that you have a function for providing safe
>input using streams? (As we've discussed at the ACCU begin-cpp mailing
>list)

For some reason I elided my thoughts when I transferred them to the 
keyboard. I was thinking more in terms of an analogy with not having new 
used unwrapped in a class whose dtor  calls the corresponding delete.

I meant to write:

Any half-way competent programmer has a mechanism to ensure that:

1) variables can support an operator >> (istream, T) can always be 
initialised except

2) within a function that handles failure of the call to operator>>

I agree that what I wrote was far from this.

I think that seeing cin >> in top level code sends a similar message to 
seeing delete at the same level, neither belongs at that level though 
both can be useful when properly encapsulated.


-- 
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]