HDTenEightyP/NetNews huggingface dataset:
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: iostreams bug in BC?
Keywords: whitespace; stream; borland; cfront; fail
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Thu, 19 Nov 92 20:36:52 GMT

In article <1992Nov18.154925.5930@siesoft.co.uk>, huw@siesoft.co.uk (Huw Roberts) writes:
|> I have a problem with BC++ 3.1.  I'm not sure what the correct behaviour is
|> so I can't tell whether or not it's a bug.  The program certainly behaves
|> differently on cfront:
|> 
|>     ...
|>     istrstream fred (" 35    ");
|>     int x;
|>     fred >> x >> ws;
|>     if (fred.fail())
|> 	cout << "You're kidding!`n";
|> 
|> Borland produces the message, cfront does not.
|> 

Unfortunately all the original iostream "specification" said
was that ws "extracts whitespace".  It did not specify what
should happen if it encounters the end of file while doing
so.   Some implementers decided it should set an error bit.

The current words in the x3j16/sc22 working paper say
that ws is not supposed to set failbit when it encounters
EOF.  

The workaround is to write your own function. I have attached
below an "industrial strength" version.
	
    -- Jerry Schwarz
------------------------------------------

#include <ctype.h>
#include <iostream.h>


istream& myws(istream& in) {
    if ( !in.ipfx(1) )  return in ;
    streambuf* sb = in.rdbuf() ;
    for ( int c = sb->sgetc() ; 
          c != EOF && isspace(c) ; 
          c = sb->snextc() ) {
        /* do nothing */
    } 
    if ( c==EOF ) {
        in.clear(in.rdstate()|ios::eofbit) ;
    }
    in.isfx();
    return in ;
}
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Wanted: Real Example of MI
Organization: Rational
Date: Fri, 20 Nov 1992 18:47:07 GMT

Here is a "real" example which uses MI.  It can, of course, be
implemented in other ways using SI, but the MI approach has certain
benefits.  

class Shape { public: void Draw()=0 };
class Point : public Shape {public: void Draw(); private: int x,y;};
class Line : public Shape {public: void Draw(); private: Point *p1, *p2;};

class NamedObject {public: void SetName(char*); private: char* itsName;};

class NamedPoint: public Point, public NamedObject {public: void Draw();};
class NamedLine : public Line, public NamedObject {public: void Draw();};

Quite a few member functions have been omitted for the sake of
brevity.  The design should be clear.  There exist classes of objects
which are shapes, and classes of objects which have names.  There is a
certain interface common to all shapes and another which is common to
all objects with names.  Some shapes can also have names, and so they
should inherit both interfaces.

While this example is quite simple, it shows one of the real-world
benefits of MI.  NamedPoint and NamedLine objects can be used in any
context which requires either a Shape or a NamedObject.

Also, a NamedObject does not have to be a Shape.  Other kinds of
objects can be give names and can inherit the NamedObject interface.  

--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: grant@Manticore.COM (Grant J. Munsey)
Newsgroups: comp.lang.c++
Subject: PD source of some basic C++ classes?
Date: 19 Nov 92 20:45:08 GMT
Reply-To: grant@Manticore.COM

Can anyone point me to public domain sources for some basic C++ classes
like expandable arrays, lists, queues, matrix math, etc. I've just started
using C++ and would like some good examples. Thanks,
----
Grant Munsey, Mainticore, Inc. (408)252-1135
grant@Manticore.COM,  uunet!ub-gate!gouche!grant   NeXTMail ok.
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: New Employee Test
Date: 20 Nov 92 23:55:39 GMT
Organization: negligable

In article <1992Nov19.010534.19506@cs.yale.edu> rescorla@rtnmr.chem.yale.edu (Eric Rescorla) writes:
>
>Also, I'd note that you specified that the guy should create a bubble
>sort. One might believe that you had a specific reason why you wanted
>that. I certainly wouldn't tell someone who was writing code for me
>that I wanted a bubble sort unless that's what I actually wanted.
>

Yes, but how to you *know* that that is what you want?

How do I (the systems analyst) know that you are qualified
to make the judgement about which type of sort is appropriate?

Do you know about all of the options available (have you heard
of a combsort)?

The engineer that doesn't question the questionable parts
of a spec can run into trouble, especially when the customer
thinks he knows more about my job than I do.  (It's called
overspecification and can be a real pain in the A**!)


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
And the men who hold high places	|
must be the ones who start		|	-Richard Hartman	
to mold a new reality			|	hartman@uLogic.COM
closer to the heart!			|

Newsgroups: comp.lang.c++
From: pickerig@eee.bham.ac.uk (Guy Pickering)
Subject: AT&T debugger?
Summary: AT&T debugger available?
Date: Tue, 17 Nov 1992 09:45:32 GMT
Organization: The University of Birmingham, England
X-Newsreader: TIN [version 1.1 PL6]
Keywords: AT&T debugger

Does AT&T C++ V3.01 come with a source level debugger? If not
where can I get one?

Thanks,

Guy.

--
+--------------------------------+-----------------------------------------+
| Guy Pickering                  | School of Electronic & Electrical Eng,  |
| E-MAIL: G.PICKERING@uk.ac.bham | University of Birmingham,               |
| Tel: (021) 414 4340            | Edgbaston, Birmingham. B15 2TT.         |
+--------------------------------+-----------------------------------------+
| "I have ten pairs of trainers...One for each day of the week" - Sam Fox  |
+--------------------------------+-----------------------------------------+
From: frans@cwi.nl (Frans Heeman)
Newsgroups: comp.lang.c++
Subject: virtual base class and pointer to member function
Date: 23 Nov 92 12:51:52 GMT
Organization: CWI, Amsterdam

I have a class A that stores a pointer to a member function, that
function being defined in class A or one of its subclasses. If class B
is derived from A, and B defines B::f(), I can store a pointer to B::f()
in A. When I use that member function pointer with an object of type B,
B::f() gets invoked for that object (see code below).

However, when I specify A as a *virtual* base class of B, this no
longer works. When I now use the member function pointer with an object
of type B, B::f() gets invoked in the scope of A, even though A does not
define f(). Only when I explicitly cast the type of the function back
to (B::*)(), it gives the same result as above.

Which, if any, of the behaviors above is 'correct'?

I tried it with both
	<<AT&T C++ Translator 2.00 06/30/89>>
and
	GNU C++ version 2.2.2 [AL 1.1, MM 19] Silicon Graphics Mips
	compiled by GNU C version 2.2.2.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Frans Heeman                                       room: M361
CWI dept. of Interactive Systems                  phone: +31 20 592 4164
Kruislaan 413, 1098 SJ Amsterdam                    fax: +31 20 592 4199
P.O. Box 4079, 1009 AB Amsterdam                 e-mail: frans@cwi.nl
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- Example code---------------------------------------------------------
#include <stream.h>

class A; // forward declaration
typedef void (A::*PF)();
	// generic function pointer for A and its subclasses


class A {
    private:
	int avar;
    public:
	PF pf;
	A();
};

A::A() { avar = 10; pf = 0; };


class B : virtual public A { // try the code without 'virtual' too!
    private:
	int bvar;
    public:
	void f();
	B();
};
	
B::B() : A() { bvar = 5; };
void B::f()  { cout << "in B::f(), bvar = " << bvar << "\n"; cout.flush(); };


int main()
{
    A a;
    B b;

    a.pf = (PF) &B::f;

    // call pf through b:
    (b.*(a.pf))();	// prints: in B::f(), bvar = 10
    // should print: in B::f(), bvar = 5

    // cast pf to 'void (B::*)()' and call through b:
    void (B::*p1)() = (void(B::*)()) a.pf;
    (b.*p1)();		// prints: in B::f(), bvar = 5
    // this is OK!
}
Newsgroups: comp.lang.c++
From: swillden@news.ccutah.edu (Shawn Willden)
Subject: Re: question on REFERENCES
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Fri, 20 Nov 92 19:57:25 GMT

jbn@lulea.trab.se (Johan Bengtsson) writes:
: swillden@news.ccutah.edu (Shawn Willden) writes:

	[ Much stuff deleted ]

: : How is this different from a test for NULL?  The syntax may be slightly
: : cleaner but not much is really gained by this approach.
: 
: You can often arrange things so that it is safe to attempt quite a few
: function calls without checking anything at all (the first error is
: safely stored away in a global variable).  If on the average you make
: a few (say five) function calls before testing, you get a significant
: reduction in the number of error tests, making the real algorithm more
: easily recognizable.

Where this can be arranged, I would say it's a good idea.
 
: : Something must
: : still be returned and that something will be invalid if the function 
: : fails.  Why is the programmer more likely to remember to test an error
: : flag than to test a returned pointer against NULL?
: 
: Because the error flag does not go away.  A later check will detect the
: error.  Often this is quite acceptable, especially if the error is very
: rare.  Also, you can arrange for checking the error flag at program
: termination.  Any unhandled error at program exit can then be reported.
: Similarly, if an object keeps an internal error state, then its
: destructor should check the error state.  If there is an error, the destructor
: should report it when the object goes out of scope (the iostream classes
: do not do this, but IMHO they should).

Again, these are useful options.
 
 [...]
 
: : In addition, it requires all code
: : that uses an object to test its goodness and then take appropriate
: : action if not.  In many cases it is more convenient to design
: : the object such that a given instance is always valid and to just avoid
: : creating invalid ones.
: 
: Yes, and a nice variation is to return an object that checks the
: "goodness" flag itself, and performs safe default actions if it
: is an invalid object.  Sometimes this can be programmed by returning
: an object of a subclass of the return type (which is a reference),
: that overrides virtual functions appropriately.

This is an interesting variation that hadn't occurred to me.  It
would have to be used carefully, though, because in many cases the
value returned from a function is copied into another object instead
of being used directly.  How often have you found this approach 
worthwhile?  It seems to me that this would be a more useful option
if you return a pointer, which you could, of course, guarantee to be
non-NULL.

: -- 
: --------------------------------------------------------------------------
: | Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
: | Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
: --------------------------------------------------------------------------

--
Shawn Willden
swillden@icarus.weber.edu
From: ort@netcom.com (David Oertel)
Newsgroups: comp.lang.c++
Subject: Re: comp.lang.c++
Summary: re: ghettoizing newusers
Date: 16 Nov 92 18:10:24 GMT
Article-I.D.: netcom.1992Nov16.181024.21991
Organization: Netcom - Online Communication Services  (408 241-9760 guest)




>: In comp.lang.c++, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>: 
>: > 	It might be appropriate to have a comp.newuser.c++
>:                                           ^^^^^^^^^^^^^^^^
>: 
>Why split it up?  If newuser-type questions go in a different conference, they
>might not get the benefit of replies from more experienced c++ programmers who
>might avoid such a conference.  Let's stay together.

	I'm an experienced user who would like to see many of the things that I
	learned the hard way transmitted to the newusers.  I have to confess
	that the existence of a separate newuser group would create a 
	threshold of pain that I wouldn't bother to cross.  Separation is not 
	in the fraternalistic spirit of this community.  Another vote for 
	just one group.  Also, I don't think that anyone is above learning 
	new things from the newusers, because things are always changing and 
	nobody can be everywhere at once (except maybe God).

	ort@netcom.com

--
From: hosken@spss.com (Bill Hosken)
Newsgroups: comp.lang.c++
Subject: Re: self-reproducing C++ program
Date: 19 Nov 92 20:15:47 GMT
Organization: SPSS, Inc.

In article <mg.722138417@tyrolia>, mg@tyrolia (Michael Golan) writes:
> sakkinen@jyu.fi (Markku Sakkinen) writes:
> 
> >There is one possible problem, though.
> >When you start generating all possible legal C++ programs
> >in the order of ascending length, before the first self-reproducing
> >one you might run into an item about which you can prove _neither_
> >of the following alternatives: [...stuff deleted]
> 
> C++ only runs on finite state machines (computers). So the halting question:-)
> has nothing to do with it. All C++ programs terminate or go back to the 
> same state.
> 

The language, though, is independent of the machine on which it runs.
One can imagine asking for more and more floppies to be inserted, simulating
a Turing machine tape, and then the finiteness would be debatable.  Turing
machines have only a finite number of 'processor' states, but have an
unbounded tape.
Newsgroups: comp.lang.c++
From: pcm@cs.brown.edu (Peter C. McCluskey)
Subject: cfront bug with 2 nested classes
Organization: Brown Computer Science Dept.
Date: Sun, 22 Nov 1992 21:05:02 GMT

CC 3.0.1 (on a Sparc 1) thinks that A::C and A::D are the
same type. It ignores the type error on line 12 but falsely
complains that the operators on lines 16 & 17 are the same.

class A
{
 public:
  class C  {   public:    C(short,short){}  };
  class D  {   public:    D(float){}  };
  A(const C&){}
};
 
main()
{
   A g(A::D(1.0));             // line 12 - argument of wrong type
}
 
class ostream;
ostream& operator<<(ostream& o,const A::C&){ return o; }
ostream& operator<<(ostream& o,const A::D&){ return o; }  // line 17


/cs/bin/CC3.0.1/CC t.C
CC  t.C:
"t.C", line 17: error: two definitions of operator <<()
1 error

----------------------------------------------------------------------
  >> Peter McCluskey >> pcm@cs.brown.edu >>   Reunite Gondwanaland!
----------------------------------------------------------------------
From: grahamd@swdev.research.otca.oz.au (Graham Dumpleton)
Newsgroups: comp.lang.c++
Subject: Re: Finding memory leaks
Keywords: OOP,memory leaks
Date: 21 Nov 92 23:29:37 GMT
Organization: Technology Development Group, OTC Australia

In article <1992Nov21.145321.2297@ulrik.uio.no>, bosnes@boeygen.nr.no (Vidar Bosnes) writes:
> Mike Kirby (mpk9172@ultb.isc.rit.edu) writes:
> >   I would like to do the same kind of thing in C++.  Unfortunately, it
> >   seems that new is not as easy to #define over as malloc.  I thought
> >   (briefly) that I could do something like #define new new(__LINE__,__FILE__) 
> >   and then overload the new operator, but this causes a recursive macro.
> 
> There should be no problem in using the macro you suggested. The ARM
> (chap 16.3.3), Preprocessing; rescanning and further replacement, reads:
> 
>    After all parameters in the replacement list have been replaced, the
>    resulting list is rescanned for more macros to replace. If the name
>    of the macro being replaced is found during this scan or during
>    subsequent rescanning, it is not replaced.
> 
> Thus, there is no recursion involved. I have used this technique
> successfully with g++ and dec-cxx. If you use g++, note that this
> compiler uses non-standard syntax for the call to the overloaded
> new-operator (curly braces instead of parentheses).

There is a problem with using this approach if you define your own operator
new at either global scope or for a class. For example consider the following
code

  #define new new(__LINE__,__FILE__)

  class Foo
  {
    public:
      void* operator new(size_t);
  };

When this is expanded by the preprocessor you will end up with the operator
new in the class output as

  void* operator new(42,"??")(size_t);

which isn't going to compile.

Similarly you cannot do this for operator delete for the above reasons, although
there are other reasons why it cant be done for delete also.

-- 
Graham Dumpleton (grahamd@swdev.research.otca.oz.au)
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Binary File Streams (iostream derived)
Keywords: Binary Streams
Organization: TauMetric Corporation
Date: Mon, 23 Nov 1992 21:17:11 GMT

pbray@firebird.newcastle.edu.au (Peter Bray) writes:


>	Having just finished looking thru two book and the AT&T C++ v3.01
>manual pages, I was wondering if there was a simple interface to binary file
>streams, or whether one must open the file as usual and just use the 

>	ostream& write( const unsigned char* ptr, int n )

>interface and develop member I/O functions (wrappers), for each class for which
>one desires binary I/O.

There are two considerations: binary versus text files, and I/O
conversions versus no conversion.

Systems which distinguish between text and binary files have a flag
you can pass to the fstream constructor or open() function to tell
it to use binary rather than text mode.  Example:
	ofstream outfile("data.dat", ios::out|ios::bin);
(The flag is usually called "bin" or "binary" when it exists.)

The read() and write() functions (along with get() and put()) are the
only iostream functions which do no text conversion.  You can't use
the supplied "shift" operators for binary I/O.  Additionally, the
"shift" operators are not virtual, so replacing them with binary
versions is a bit risky.  You can write your own operators for your
classes that do binary I/O, however:
	class myclass { ... };
	ostream& operator<<(ostream& o, const myclass& c)
	{
	    o.write(c.data, sizeof(c.data));
	}
	myclass dat;
	ofstream outfile("data.dat", ios::out|ios::binary);
	outfile << dat;
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Newsgroups: comp.lang.c++
Subject: Re: Interobject member function calls while in construction
Date: 15 Nov 92 18:27:11 GMT
Organization: University of Birmingham

In article <1509TB8w165w@rhps.chi.il.us>, warlok@rhps.chi.il.us (Jon L Fincher) writes:
> So, now the situation is this - I have a member function screen::init()
> constructing a window.  window::window() calls other owned member functions
> (not a problem, right?) and some functions in screen (again, not a problem?).
> However, some member functions in screen call window member functions, which
> has, at this time, not finished instantiation.
> 
> Should this cause lot's of problems?  If so, I can devise a suitable
> workaround, but I want to keep the initialization member functions to a
> minumum, prefereably one per class.  Worst case scenario - redesign of basic
> structure.  Any help?  Code can be provided, if needed.
There should be no problem using a partially constructed object provided you
are aware that this is what is happening. I can't quite see how you can get
into the situation you describe as `screen::init()' must call
`window::window()' as part of a `new' expression and as this expression
has not completed I don't quite see how the `screen' class can call members
of `window' as at this point it still has no pointers to `window's.
Unless of course `screen' is calling static members of `window'. (You
did say all objects of type `window' formed a linked list didn'y you?)
The only thing to watch out for is that the window object under
construction is sufficiently constructed to allow the other member functions
to operate before doing anything that may call them. All the hidden book
keeping is done before the programmer supplied body of a constructor.
Now if you were calling virtual members of window whose definition was in a
subclass of window this could be a whole different story.

If you want to post me the source (preferably in UUE over ARJ,ZIP,ZOO or LZH) 
to look at that's OK but I can't promise anything.
-- 
    \\   ( )    No Bullshit!     |  Email: B.A.McCauley@bham.ac.uk   
 .  _\\__[oo        from         |  Voice: +44 21 471 3789 (home)
.__/  \\ /\@    /~)  /~[   /\/[  |    Fax: +44 21 625 2175 (work)
.  l___\\      /~~) /~~[  /   [  |  Snail: 197 Harborne Lane,
 # ll  l\\    ~~~~ ~   ~ ~    ~  |         Birmingham, B29 6SS, UK
###LL  LL\\   (Brian McCauley)   |   ICBM: 52.5N 1.9W
Newsgroups: comp.lang.c++
From: jones@pogo.den.mmc.com (Jonathan Jones)
Subject: Virtual Destructor Problem - Help
Organization: Martin Marietta WIS
Date: Tue, 17 Nov 1992 22:44:16 GMT


 *********************  Operating Enviroment **********************

   Running on a Macintosh IIfx
                System 7
                8 meg. of memory

                MPW 3.2  -- E.T.O # 8 

   
   We sent this problem to Apple by mail about 3 weeks ago, and to their Cplus.Bugs@AppleLink.Apple.Com a week ago.
   We have heard no response.  Is this the Norm for Apple ?  
   
   We would like to know if other people can reproduce the following problem ? 
   Does anyone have ANY solution to it ?
     

****************************  Problem   **************************************************

  Put in either "virtual" or both "virtual"s on the destructors and the compiler will fail!!

  It will only compile, if "virtual" is removed from BOTH destructors.


   

*************   Stripped Down Source Code  *** Note: No Include File for this small Example  ***

class Object
{
public:
    virtual  ~Object( void ) {}    
};


class Bool : public Object
{
public:
	virtual ~Bool( void ) {}
};


void f3() 
{
	Bool *p  = new Bool[10];
	
	delete [] p;      // no size necessary
}


*********************  Compile line   ****************************

      CPlus   fileName.cpp   




*********************  Output from C compiler, gets past Cfront ****************************
#
#
#?
### Error 211 Pointer type required
#?
### Error 24 ')' expected
#?
### Error 229 mismatch between formal and actual parameter types
#?
### Error 258 There are not enough arguments
#?
### Error 30 ';' expected
#?
### Error 22 error in factor
#?
### Error 212 Struct or Union type required
#?
### Error 23 identifier not declared
#--------------------------------------------------------------------------------------------------------------------------------
    File "HD:Cams:Tree:jjj.cpp"; Find !246:!1; Open "{Target}"
#--------------------------------------------------------------------------------------------------------------------------------





********************************************************************************* 
*
*   From :     Steve McCabe & Jonathan Jones
*              (303) 971-5124  (303) 971-5101
*
*   Reply to : /s=McCabe/g=Steve/ou=msmail/o=den.mmag/prmd=mmc/admd=telemail/c=us/@x400
*
*********************************************************************************






Newsgroups: comp.lang.c++