HDTenEightyP/NetNews huggingface dataset:
From: feustel@netcom.com (David Feustel)
Subject: What is the ATT Class Library?
Organization: DAFCO: OS/2 Software Support & Consulting
Date: Fri, 20 Nov 1992 23:44:14 GMT

Does anyone know what's in the ATT Class Library? Could Someone post
the contents Please? Thanks.
-- 
Dave Feustel N9MYI <feustel@netcom.com>
 
GE knew there was lots of money to be made in the diagnostic medical
machine field since it was only a matter of time before people started
getting sick from the effects of all of GE's toxic and radioactive
waste dumping. I expect GE to get into the Mortuary business next.
From: skip@taygeta.oc.nps.navy.mil (Skip Carter)
Newsgroups: comp.lang.c++
Subject: Re: Just what is so great about streams?
Date: 16 Nov 92 21:32:29 GMT
Reply-To: skip@taygeta.oc.nps.navy.mil (Skip Carter)


	In this thread about why one should WANT to use streams,
	there has been a lot said about type-safety, runtime efficiency,
	and extensibility with regard to I/O for new types.  However I have
	yet to see anyone mention this advantage:   polymorphism with regard
	to the I/O stream.

	Consider the following,

class TimeStamp                     // writes a timestamp to a file
{
	 
        private:

               .....

        public:
          TimeStamp();
         ~TimeStamp() {}

         friend ostream& operator<<(ostream& os, const TimeStamp& t);
};


             so I could write within an application (with an anonymous object),


	ofstream fout(....);

	fout << TimeStamp();                           // writes a timestamp to the file attached to fout


	Now suppose I wrote a comment class for writing lines delimited by a user defined
	comment sequence:

class Comment : public ostrstream                   // write a comment to a file, with user defined start and end
{                                                                             //  comment sequences
        private:

                     ....
                            
        public:
          Comment(ostream& user_os, const char *cstart = "//",
          	  const char* cend = "\n");
          Comment(ostream& user_os, const char cstart,
          	  const char cend = '\n');
         ~Comment() {}

             ....


};


	Now the TimeStamp class can write a comment WITH NO CHANGES MADE TO
	THE TIMESTAMP CLASS.

	Comment fout(...);

	fout << TimeStamp();


	In fact, TimeStamp can properly write to any class that is ultimately derived from ostream.


--- 
 Everett (Skip) Carter             Phone:  408-646-3318 FAX: 408-646-2712
 Naval Postgraduate School         INTERNET: skip@taygeta.oc.nps.navy.mil
 Dept. of Oceanography, Code OC/CR  UUCP:     ...!uunet!taygeta!skip
 Monterey, CA. 93943               TELEMAIL: s.carter/omnet
Xref: sparky comp.lang.c++:16470 misc.education:4363
From: antoy@antares.cs.pdx.edu (Sergio Antoy)
Newsgroups: comp.lang.c++,misc.education
Subject: Undergraduate course in C++
Date: 17 Nov 92 23:41:23 GMT
Article-I.D.: antares.ANTOY.92Nov17154123
Reply-To: antoy@cs.pdx.edu
Organization: Portland State University, CS Dept.

I have been asked by my chairman to make a proposal for an junior
undergraduate course covering C++.  I am looking for suggestions
on textbooks, compilers, environments, OOP, etc.  I would like to
hear both positive and negative experiences.  The prerequisites
currently considered are a course in C and a course in data
structures.

Please e-mail you answer.  Thanks in advance.

Sergio Antoy
Dept. of Computer Science
Portland State University
P.O.Box 751
Portland, OR 97207
voice +1 (503) 725-3009
fax   +1 (503) 725-3211
internet antoy@cs.pdx.edu
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: static data members of private types impossible?
Summary: ARM says illegal, committee's debating it. I think it should be legal
Date: 22 Nov 92 23:06:00 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

In article <5207@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
>johnh@tt.com (John Hasselkus) writes:
>: class A {
>:     enum FOO { FOO_1, FOO_2 };
>:     static FOO foo;
>: };
>: 
>: A::FOO A:foo;	// <- Compiler won't let you use private types out here

While I would not have interpreted the ARM this way, I have been told
that its intentions are that the above is illegal.  I've also been
told this matter is being discussed by ANSI and that and they are
leaning towards relaxing the rules to allow the above code.  Otherwise
nested types would have to be made public in many situations where the
class writer really doesn't want them to be.

>To support this, the compiler would need to parse the entire declaration,
>before deciding if in fact the type name is accessible.  My guess is that
>compilers rather not do that.
>To prove my point, the following declaration should definitely be illegal:
>A::Foo A::foo, anotherVariable;

The compiler could simply give an error that A::Foo is not accessible
at file scope unless the object being declared has access.  I think
this situation is very analogous to that of resolving overloaded
functions, some of which might not be accessible.  From ARM 11.3c

	As mention in $11, C++ provides access control, not visibility
	control; that is, the object, function or whatever referred to
	in an expression is determined WITHOUT REGARD TO ACCESS
	SPECIFICATION, then type checking is done, and only if no error
	was found is access control applied.
	[emphasis mine]

Making non-public types inaccessible at file scope even when declaring
a member would also mean that member functions could only return
non-public types:

	class A {
	   enum FOO { FOO_1, FOO_2 };
	   static FOO foo();   // impossible to define this
	//...
	};

Or, even weirder, it would mean they could only be defined inside the
class.  Granted, this type of restriction does have precedence with
local classes.

Btw, there's some code in ARM 9.7 p187 that uses a private type in
file scope and I think contradicts the ARM intentions (unless typedef
declarations don't count):

	class enclose {
	   class inner { ... };
	};
	typedef enclose::inner ei;
	//...

Was this changed in the ARM reprinting (May92)?  Anyway, I hope ANSI
does decide to allow the use of non-public types in file scope when
declaring members and I hope compiler writers are quick to respond.

Jamshid Afshar
jamshid@emx.utexas.edu
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Idempotent header file proposal
Date: 20 Nov 92 20:04:35 GMT
Organization: Microsoft Corporation

In article <1992Nov19.090742.23696@cbfsb.cb.att.com> nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:
|One problem with C++ is that when used properly it requires huge
|numbers of header files most of which are included multiple times.
|Of course I know that there is the crude workaround :
|
|#ifndef HEADER_H
|#define HEADER_H
|
|stuff
|
|#endif
|
|But the preprocessor still has to find, open , and read the whole file
|so it does not realy gain you any efficiency.

These statements are already contradicted by many C++ compilers that feature
precompiled headers.  In such compilers the preprocessor *doesn't* have to
find, open, nor read the header files.  Rather, the information in the header
file simply preexists as if the header files had already been read.  
In my experience using precompiled headers often can reduce my compile times 
to a couple seconds when compiling on an old 386/20.  Frequently this 
represents a 10X compilation speed up -- use precompiled headers if the
option is at all available to you!  So what you describe is not a problem
with "C++" -- rather it is a problem with some compilers not yet supporting
precompiled headers.  Ultimately we will begin to see more and more C++
development environments that not only offer precompiled headers, but
incremental compile/link support as well.

Newsgroups: comp.lang.c++
From: jjamison@bellahs.com (John Jamison RD AC)
Subject: Re: Is Ctor X() required for the object of class X to be able to be dynamically allocated?
Keywords: constructor X(), dynamic allocation
Organization: Bell Atlantic Healthcare Systems
Date: Fri, 20 Nov 1992 17:54:58 GMT

In article <1992Nov20.080626.9582@netcom.com> ort@netcom.com (David Oertel) writes:
>
>
>>>In article <BxxC3p.Btn@math.uwaterloo.ca> xjzhu@math.uwaterloo.ca (Xiaojun Zhu) writes:
>>>Q: Is it necessary to have a constructor which took no argument in order
>>>   for the object of a class to be able to be dynamically allocated?
>>>
>>>More specifically,  I have a class X, when I can say
>>>
>>>X *x=new X[10] ?
>>>
>>>Is it required that class X have a constructor X()?
>>>
>>I can't cite chapter and verse, but such a constructor is required to
>>create arrays of objects.
>
>	This is wrong, the compiler should automatically generate the 
>	default constructor as well as the copy constructor, the assignment
>	operator, and the address-of operators, if you don't explicitly
>	specify them.
>
>	ort@netcom.com

Then CenterLine's implementation of AT&T CFront is misbehaving by generating the following
output:
CC  tst.cc:
"tst.cc", line 10: error: array of class foo that does not have a constructor taking no arguments
1 error

on the following input:
gaia:$ more tst.cc
class foo {
	public:
	   foo (int j) {i=j;};
   private:
	   int i;
};

main()
{
	foo * fooarr = new foo [30];
}

>-- 


-- 
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
John Jamison
Bell Atlantic Healthcare Systems
jjamison@bellahs.com
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Help with nested class and constructor
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.20 $
Organization: Trumphurst Ltd.
Date: Fri, 20 Nov 1992 17:33:30 +0000

In article <Bxyxrv.EJ3@news.cso.uiuc.edu> macg9505@uxa.cso.uiuc.edu (Michael Alan Corn) writes:
> I could use a little help on nested classes:
>       I would like to include one of Borlands Array classes in another class,
> in the private data section, but since the constructor requires an int to
> initialize the class, I'm not sure how or where to give it the value:
> 
> class foo {
>       private:
>       Array myarray(10); ///this doesn't work, the compiler chokes
You want ...
class foo {
      private:
      Array myarray;

And in you constructor write ...

foo::foo(/* arguments, if any */)
: myarray(10)	// Other initialisers
{
// Code, if any
}

> so I've tried this, which seems to work
> 
> class foo {
>       private:
>       void *myarray;
> 
> and then in the constructor for foo I do the following:
> 
> foo::foo()
> {
> Array temp(10);
> myarray = &temp;
Oops - your void pointer points to a local variable on the stack. This 
pointer will become invalid as soon as you return from the constructor.

> Fine, the compiler seems to like this, but now I can't figure out how to
> access the member functions of the object I store in myarray.  I use the Array
> function ptrAt to get a pointer to the object:
> 
> myarray->ptrAt(index) and then, since ptrAt returns a Object * I do the
> following to get at that objects member function
> myarray->ptrAt(index)->memfunc();  This doesn't work.  The compiler complains
> about every "->"; I assume that this is a precedence problem, but I really
> don't know.  Any help would be greatly appreciated.  Thanks
> macg9505@uxa.cso.uiuc.edu
But you have declared myarray as a void pointer. A void pointer is not an
Array pointer. 

I think you would gain a lot from reading the C++ Frequently Asked 
Questions list.

Many thanks to Marshall Cline for compiling and maintaining it. 

It can be obtained ...

Via ftp - Anonymous ftp from sun.soe.clarkson.edu [128.153.12.3] :pub/C++/FAQ

Via mail - send mail 
To: archive-server@sun.soe.clarkson.edu
Subject: send C++/FAQ

-- 
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Newsgroups: comp.lang.c++
From: xjzhu@math.uwaterloo.ca (Xiaojun Zhu)
Subject: Is Ctor X() required for the object of class X to be able to be dynamically allocated?
Keywords: constructor X(), dynamic allocation
Organization: University of Waterloo
Date: Wed, 18 Nov 1992 18:16:36 GMT

Q: Is it necessary to have a constructor which took no argument in order
   for the object of a class to be able to be dynamically allocated?

More specifically,  I have a class X, when I can say

X *x=new X[10] ?

Is it required that class X have a constructor X()?

I had some experience with TC++(V1.00) which seems that X() is
required. Anybody has any experience? Why or why not such a ctor
is needed?

Pointer to where I may find the answer is also appreciated.
(I have ARM, C++PL(2nd Ed.) and Lippman's C++ Primer(1st Ed.))

--------------------------------------------------------------
   A template version of signature class is under repair.
Symptom: I can't seem to be able to dynamically allocate it.

                                       xjzhu@math.uwaterloo.ca
--------------------------------------------------------------
Newsgroups: comp.lang.c++
From: richieb@bony1.bony.com (Richard Bielak)
Subject: Re: problems designing lists with templates
Organization: multi-cellular
Date: Thu, 19 Nov 92 16:56:02 GMT

In article <1992Oct28.163105.9062@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

[...]

>
>	There are 3 ways I can think of off hand to do this.
>
>	1) Supply operator[] for the list class. This what I do.

[...]

>
>	2) Do as you suggested.  

[...]

>	
>	3) Use an iterator.

[...]

>
>No doubt there are even more solutions. The iterator technique is probably
>the best and hardest. The first technique is easy to work with and code.
>It is not necessarily slow either, by providing a cache it is as fast
>for sequential access as the methods (2) and (3) which are constrained
>to sequential access, whereas (1) gives the appearance of random access.
>
>-- 

The fourth way is to use a list with "cursor".  The cursor can be a
separate class, or be part of list. You can set the cursor to point to
the first or last element and then move it around. Code my look
something like this:

        curs.set_list (list);
        curs.start;
        curs.forth;

        x = curs.item;  // gets the item at the cursor


The user still doesn't need to see ListElement.

This approach is described in more detail in "Object Oriented
Software Construction" by B. Meyer.



...richie




-- 
* Richie Bielak   (212)-815-3072   |                                          *
* Internet:       richieb@bony.com | Rule #1: Don't sweat the small stuff.    *
* Bang {uupsi,uunet}!bony1!richieb | Rule #2: It's all small stuff.           *
*    - Strictly my opinions -      |                                          *
From: kevinc@hpcc01.corp.hp.com (Kevin Collins)
Date: Fri, 20 Nov 1992 16:20:13 GMT
Subject: SC List Memory Leak?
Organization: the HP Corporate notes server
Newsgroups: comp.lang.c++


I've been using an internal tool to detect memory leaks in some linked
lists we use.  I've been unable to get the SC List class to pass cleanly
and want to know where I am going wrong. 

I've got a simple program which reads /etc/passwd, sticks Password objects
onto a PasswordList class (with the put function), derived from SC List, 
then deletes them and the List itself.  The two versions of the commands 
used to delete the objects on the List are :

    // method 1

    Password* P;

    if (length () > 0) {

        while ((*this).unput (P) != 0)
            delete P;
     }

    // method 2

    Password* PP;

    while ((void*)(*this)) {
        (*this).unput (PP);
            delete PP;
    }

    cout << "length = " << length () << endl;

Both of these result in output like :

only in dump 2: 1012 bytes, trace = malloc+0x0000004f
        mbschr+0x000000db
        __d_syserror+0x807a2207
        Pool::grow(void)+0x00000013
        D$4+0x0000002f
        D$6+0x00000027
        D$17+0x00000023
        fill__12PasswordListFv+0x0000027f
        main+0x00000097

This basically shows the stack of calls that lead to the memory which 
was not de-allocated.  'fill__12PasswordListFv' is the 'fill" method of 
my PasswordList class.  The call of "Pool::grow(void) is apparently 
something called by the List code which eventually calls malloc.

Are my methods of clearing the List insufficient?  Is there something
else wrong?  

Please email any responses.

Thanks,

Kevin
Newsgroups: comp.lang.c++
From: dechc00@tohi.DMI.USherb.Ca (CHRISTIAN DECHAMPLAIN)
Subject: Re: self-reproducing C++ program
Organization: Universite de Sherbrooke -- departement de Mathematiques et
	d'Informatique
Date: Wed, 18 Nov 1992 02:04:54 GMT


>[question about the smallest self-reproducing C++ program deleted]

Is that an undecidable problem.  The type of problem you waiste your life
trying to solve only to finaly discover it is undecidable.

Anyways I warned you.

--
Christian Dechamplain|
(819) 563-8951       |
dechc00@dmi.usherb.ca|
----------------------
Newsgroups: comp.lang.c++
From: young@cs.UAlberta.CA (Young Allan Andrace)
Subject: any c++ graph routines out there?
Summary: looking for c++ graph routines
Keywords: graph
Organization: University of Alberta, Edmonton, Canada
Date: Mon, 23 Nov 1992 22:15:50 GMT


programming question: c++ graph routines 

Greetings fellow netters,

I'm about to begin work on a c++ class to work with
graphs.  The type of graph I'm referring to (for example)
is diffined by a vertex set V and an edge set E.
I'm not referring to the plot x,y type of graph.

Now,  before I re-invent the wheel twice,  I am 
wondering if there is any c++ code out there   
that might help me?

If you know of any freely available c++ graph
routines out there could you please inform me
where I can find them?

Thanks in advance,

Allan
 
You can send mail to me at:

    young@manning.cs.ualberta.ca
or  c201-045@sol.ucs.ualberta.ca

Newsgroups: comp.lang.c++
From: nh@cbnewsg.cb.att.com (nicholas.hounsome)
Subject: Idempotent header file proposal
Organization: AT&T
Date: Thu, 19 Nov 1992 09:07:42 GMT

One problem with C++ is that when used properly it requires huge
numbers of header files most of which are included multiple times.
Of course I know that there is the crude workaround :

#ifndef HEADER_H
#define HEADER_H

stuff

#endif

But the preprocessor still has to find, open , and read the whole file
so it does not realy gain you any efficiency.

The best available soloution is:

#ifndef HEADER_H
#include "header.h"
#endif

but this is clumsy. 

Can we not have a standard pragma to say that a header file is idempotent
(A long word  I discovered that means that it only need be included once).
eg. put #pragma IDEMPOTENT in the header and have the preprocessor
understand that it need not bother reading this file again it seems
very easy to implement provided only that you use an ANSI preprocessor
and it requires no language extension since it is only a convention
which the preprocessor can ignore if it does not understand it.

Nick Hounsome
Newsgroups: comp.lang.c++
From: hansen@atto.cs.umn.edu (David M. Hansen)
Subject: Re: Calling pure virtual functions in base class constructor
Organization: University of Minnesota
Date: Tue, 24 Nov 1992 01:02:22 GMT

In article <722544958snx@trmphrst.demon.co.uk>, nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
|> Aha, a man who knows ! That's that one explained entirely to my 
|> satisfaction. 
|> 
|> However, what I _really_ wanted to know is why, in a constructor or
|> destructor, you still have to specify the scope override operator to call 
|> a pure virtual.
|> 
|> Example :
|> 
|> class A {
|> public:
|> 	A() { 
|> 		pure_virtual();		// undefined behaviour - WHY ?
|> 		A::pure_vurtual();	// O.K.
|> 		}
|> 	virtual void pure_virtual() = 0;
|> 	};
|> 
|> void A::pure_virtual()
|> {
|> 	cout << "A::pure_virtual() called\n";
|> }
|> 
|> What is the logical reason for this, then ?

At the bottom of p. 215 of the ARM it states, "The reason this makes technical
sense is that the explicit call A::f() avoids use of the virtual call 
mechanism (S10.2) that cannot be used for a pure virtual function from within a 
constructor.  If A::f() calls a pure virtual function for its object then it
in turn will encounter a disaster just as the constructor would have."

Note that this is valid only if the pure virtual function is defined.

					-=Dave

Newsgroups: comp.lang.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: Just what is so great about streams?
Date: Wed, 18 Nov 1992 18:24:20 GMT
Organization: University of Birmingham

In article <1992Nov18.134551.5782@bcrka451.bnr.ca>, sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:
> In article <6994@taurus.cs.nps.navy.mil> skip@taygeta.oc.nps.navy.mil (Skip Carter) writes:
>>	Now the TimeStamp class can write a comment WITH NO CHANGES MADE TO
>>	THE TIMESTAMP CLASS.
    ...
>>	In fact, TimeStamp can properly write to any class that is ultimately
>>      derived from ostream.
>>
> 
> What about     fout << t << t << endl;   
> The wrong operator<<() will be called for the second output unless you provide
> the appropriate friend function for TimeStamp, no?
No.

What wrong operator<<()? There only is one that can possibly be called:
  ostream& operator<< (ostream&,const TimeStamp&)

Are you thinking that << associates right?

fout << t << t << endl;
  is not...
operator<<(fout,operator<<(t,operator<<(t,endl)))                             

  it is..
operator<<(operator<<(operator<<(fout,t),t),endl)                             
                      \-----v---------/
                  Returns a ref to `fout'
           \---------------v--------------/
                Returns a ref to `fout'

the inner to calls to operator<< call the same operator.
OK so an ostream& is used to refer to `fout' but when we get down to
the nitty-gritty of stream io everything is virtual so this doesn't matter.
-- 
    \\   ( )    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: jss@lucid.com (Jerry Schwarz)
Subject: Re: Idempotent header file proposal
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Thu, 19 Nov 92 22:19:07 GMT

In article <1992Nov19.090742.23696@cbfsb.cb.att.com>, nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:
|> Of course I know that there is the crude workaround :
|> 
|> #ifndef HEADER_H
|> #define HEADER_H
|> 
|> stuff
|> 
|> #endif
|> 
|> But the preprocessor still has to find, open , and read the whole file
|> so it does not realy gain you any efficiency.
|

Some compilers/preprocessor recognize this construct in the header,
remember it, and don't even reopen the file when HEADER_H is #defined at
the point of the #include. 

I suggest you push your vendor to do this intelligent optimization 
rather than asking for a #pragma.

   -- Jerry Schwarz