HDTenEightyP/NetNews huggingface dataset:
From: fjh@cs.mu.OZ.AU (Fergus Henderson)
Subject: Re: Incomplete structure declarations: only within structs?
Organization: Computer Science, University of Melbourne, Australia
Date: Sun, 11 Oct 1992 01:40:02 GMT

scs@adam.mit.edu (Steve Summit) writes:

>I'm not sure why people are so eager to define typedefs for
>structs.  It is, I suppose, a pattern followed by many textbook
>authors, and it is also done automatically for you in C++.
>However, if you insist on defining typedefs for structures, you
>can run into several problems:
>
>     1.	This one (bar.h can't be #included before foo.h because
>	it uses FOO)

Yes, but as you note, they can easily be solved by 2:

>     2.	Nested header files, if you use them to solve problem 1,
>	and if you consider them a problem (I don't)

I don't consider them a problem either.

>     3.	It's easy to fall into a trap in which you think you
>	can't declare a self-referential structure (e.g. a linked
>	list), or a pair of mutually-referential structures (see
>	the FAQ list again)

OK, you have to bear this in mind, but it's not really terribly difficult.

>     4.	To solve problem 3, you have to use two names for the
>	structure (a struct tag name and a typedef name), which
>	isn't the end of the world, but it means that you either
>	have to use foo for both the tag and the typedef, or
>	differentiate between foo and FOO, or between foo and
>	foo_t, which upsets some people

I tend to use foo_struct, which makes the meaning obvious (to me :-).

>     5.	I'm pretty sure I've come across other problems, but I
>	forget them right now.
>
>"But wait," you say.  "typedefs are a Good Thing, because they
>promote Data Abstraction."  Perhaps.  In my poor addled brain,
>the only thing that a typedef for a struct usually buys you is
>that you don't have to type the seven characters "struct " when
>declaring objects, pointers, or functions of the struct type.
>If you promise not to peek inside of a struct foo,
>
>	struct foo f;
>
>is just about as abstract as
>
>	FOO f;

Maybe it doesn't really buy much, but I like it.
I find the "struct " distracting.
Usually I use each type name a lot of times (and only define it once),
so it _does_ save quite a bit of typing.
I find that "struct " makes indenting the code neatly harder.

void f() {
	struct whatever_it_is	foo;
	int    /* big gap */	bar;
	...
}

Also I much prefer

	Foo (*funcptr) (Foo *arg1, Bar *arg2, Bar *arg3);

to

	struct foo (*funcptr) (struct foo *arg1, struct bar *arg2, struct bar *arg3);		/* it won't fit on one line <sigh> */
From: dgil@pa.reuter.COM (Dave Gillett)
Newsgroups: comp.lang.c
Subject: Re: Estimating (was Productivity of a C programmer )
Date: 16 Oct 92 02:11:16 GMT
Organization: Reuter:file Inc  (A Reuter Company) Palo Alto, CA


      The analogy to the construction industry overlooks a major difference
 between civil engineering and software engineering -- and the example of the
 Chunnel points it up.

      Construction companies rarely have to solve brand new problems.  There's
 unlikely to be a major component of the next house to be built that the
 estimator hasn't seen 20, 30, perhaps a hundred or more times before.  The
 exact juxtaposition of the components can vary a lot, and sometimes their
 size, but the resulting interface and loading issues have usually been
 handled by the architect before the construction estimator comes on the
 scene.
      In other words, as a construction company gets familiar with a specific
 detail, the time involved in that becomes constant and the estimator's job
 gets easier.  As a software development team gets to the same level of 
 familiarity with a specific component, the time involved in that component
 drops toward zero, if only because programmers are using boilerplate code.
      Software development time is dominated by the time taken for breaking
 new ground, for doing things that the developers are unfamiliar with.  It's
 not just that there are no full-time estimators and no collected hard data on
 which to base estimates:  there's no way to usefully *collect* such data.

      I do agree that soft/negotiated estimates are a problem -- I just think
 there are good reasons why software estimates tend to be soft.

                                                  Dave Gillett
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Binary files.
Date: 15 Oct 92 13:16:29 GMT
Organization: University of Helsinki

jth54363@uxa.cso.uiuc.edu (Zog) writes:
>How can I write to a binary file on the bit level? ie. just a 1 or 0?

The smallest amount of data that can be read or written in is one char,
also known as one byte.  You could try collecting the output bits until
you have enough for one byte, and then output that byte.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
Newsgroups: comp.lang.c
From: lezz@merlin.dev.cdx.mot.com (Lezz Giles)
Subject: Re: question about duplicate declarations
Reply-To: lezz@merlin.dev.cdx.mot.com (Lezz Giles)
Organization: Motorola Codex, Canton, MA
Date: Fri, 16 Oct 1992 16:12:09 GMT

In article <1992Oct16.024907.28552@CSD-NewsHost.Stanford.EDU>, amorgan@csd-d-3.Stanford.EDU (Crunchy Frog) writes:
|>In article <1992Oct13.211753.15516@phri.nyu.edu> 
|>  roy@mchip00.med.nyu.edu (Roy Smith) writes:
|>>
|>>foo (int x)
|>>{
|>>	int x;
|>>
|>>	...
|>>}
|>>
|>>What should you expect a compiler to do?  
|>
|>Exactly what it did.  Compile without error.
|>
|>>In my case, the second "int x" was
|>>a mistake; it shouldn't have been there at all.  Apparantly, though, the
|>>compiler treated it as if it was simply a declaration of a new x inside a
|>>local block.  Is that the reasonable thing to do?  Should it have issued
|>>some sort of warning about duplicate declarations?
|>
|>It doesn't have to.  It might be useful if it did.  Remember: When in
|>doubt, C will let you blast your own leg off if you tell it you would
|>like to.

Which is why 'lint' exists - any serious C programmer should make sure
that all his C code gets through lint cleanly, or at least he should make
sure that he understands all the lint warnings.  (I've heard that gcc
with various flags is also a good replacement for lint).

Lezz Giles
Newsgroups: comp.lang.c
From: Josef Moellers <mollers.pad@sni.de>
Subject: Re: line number in C program
Date: Wed, 7 Oct 1992 09:19:03 GMT
Organization: Siemens Nixdorf Info.Sys. AG, Paderborn, Germany

In <rfries.107@fries_Robert@ub.ub.com> rfries@fries_Robert@ub.ub.com (Robert Fries) writes:

>In article <rfries.106@fries_Robert@ub.ub.com> rfries@fries_Robert@ub.ub.com (Robert Fries) writes:

>>In article <1992Oct5.193542.11024@cs.brown.edu> hm@cs.brown.edu (Harry Mamaysky) writes:


>>>Is there a way for me to find out what line number is currently being
>>>executed in a c program from within that program?

>>>Will this method also work in C++?

>>>Harry.

>>>hm@cs.brown.edu


>>No.

>What am I saying?!? Of course you can, with the __LINE__ directive.
>Assuming ANSI C.

No need for ANSI C.
__LINE__ (and __FILE__) were introduced way before ANSI got a grip on C!
-- 
| Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG  |
|  USA: mollers.pad@sni-usa.com	| Abt. STO-XS 113	   | Riemekestrasse   |
| !USA: mollers.pad@sni.de	| Phone: (+49) 5251 835124 | D-4790 Paderborn |
Newsgroups: comp.lang.c
From: dlsteven@nyx.cs.du.edu (Doug Stevens)
Subject: C++ for Mac
Organization: Nyx, Public Access Unix @ U. of Denver Math/CS dept.
Date: Wed, 14 Oct 92 01:36:16 GMT

Does anyone know if Borland has a Turbo C or Turbo C++ for Macintosh?
Newsgroups: comp.lang.c
From: wells@cdsmn.mn.org (Rich Wells)
Subject: Re: Strings and integer sizes
Organization: Dicomed, Inc
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 8 Oct 1992 18:21:46 GMT

Nancy Rehak (rehak@breeze.rap.ucar.edu) wrote:
: In article <718167097snx@grendel.demon.co.uk> jes@grendel.demon.co.uk (Jim Segrave) writes:
: >
: >In article <9227705.8771@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
: >> >Multiple choice question:
: >> >
: >> >A string is stored
: >> >	a. in an array of characters
: >> >	b. in an array of characters terminated with 0
: >> >	c. in an array of characters terminated with '\0'
: >> 
: >> Well, the answer is:
: >> 	d. all of the above
: >
: >What about:
: >
: >char zoe[3] = "123";
: >
: >neither b. nor c. applies here.
: 
: Actually, b. and c. both apply here as the string "123" is actually "123\0" and
: the \0 is stored in the byte following the end of the array zoe.  Big problem!

Sorry, not so.  If there is not enough room for the null terminator,
it is left out.  Any C compiler which blows past the end of the array
by placing the null there is seriously flawed.

(Caveat: my source is _ANSI C: A Lexical Guide_ by Mark Williams
Company.  While I have found some minor mistakes in this book, I am
reasonably enough sure that they are correct on this point to risk
embarrassing myself here.)
-- 

Richard Wells  wells@cdsmn.mn.org  or  ...!tcnet!cdsmn!wells
From: kdq@quest.UUCP (Kevin D. Quitt)
Newsgroups: comp.lang.c
Subject: Re: Strings and integer sizes
Date: Fri, 09 Oct 92 09:13:13 PDT
Reply-To: srhqla!quest!kdq
Organization: Job quest  (805) 251-8210,  So Cal: (800) 400-8210

mike@pacsoft.com (Mike Stefanik) writes:
> >I disagree that char zoe[3] = "123"; would be an erroneous initializer.
> 
> This *is* an erroneous initializer because you are initializing a three-
> character array with four characters.

    Sorry, read the ANSI spec. It's perfectly legitimate.  It wouldn't
be if it were "1234", but it isn't.


> The side effects can be subtle; for

    The subtlety here is the difference between a array of characters
and a string.  One is null terminated, the other need not be, and can
contain nulls as part of its content.  A string in C is stored in an
array of characters, but is logically a different entity.

> example, consider the following program:
> 
>     #include <stdio.h>
>     char foo[3] = "foo";
>     char bar[3] = "bar";
>     main()
>     {
>         printf("%s is %d characters\n", foo, strlen(foo));
> 	return 0;
>     }
> 
> On my system (UNIX, GCC compiler) this produces "foobar is 6 characters".

    On your system, with your compiler, these two character arrays
happen to be allocated contiguously, in sequence.  Because of this,
when you erroneously try to treat an array of characters as a string,
you get incorrect results.  Note the following program: 

float foo = 1.0;
main()
{
   printf( "foo is %d\n", foo );
}

    I'll bet it produces the wrong results, too.  And for precisely the
same reason as your program.

 _
Kevin D. Quitt                                 Job Quest (805) 251-8210
srhqla!quest!kdq                               Learn How to Get a Job in SoCal

                96.37% of all statistics are made up.
Newsgroups: comp.lang.c
From: richk@grebyn.com (Richard Krehbiel)
Subject: Checkpointable malloc library?
Organization: Grebyn Timesharing
Date: Mon, 12 Oct 1992 20:34:26 GMT


Here's what I'd like to be able to do:

main()
	{

	for(;;)					/* Part of a long-running program */
	{
		chkpt = malloc_chkpt();		/* Save current state of dynamic memory */
		if(setjmp(jmp_b))			/* setup for exception exit */
		{
			/* Something in work_process() threw an exception. */
			malloc_restart(chkpt);	/* discard any allocations made
									   following the checkpoint */
			continue;
		}

		work_process();			/* Work */

		malloc_forget(chkpt);	/* Forget the checkpoint; anything
								   still allocated is needed. */
	}
}

Has anyone ever seen something like this?  Thanks.
-- 
Richard Krehbiel                                 richk@grebyn.com
OS/2 2.0 will do for me until AmigaDOS for the 386 comes along...
From: rick_h@unkaphaed.UUCP (Richard Hamilton)
Newsgroups: comp.lang.c
Subject: Alt. Keyboard reading
Date: Wed, 07 Oct 92 08:33:40 GMT
Organization: Unka Phaed's UUCP Thingy

How else can I read the keyboard to determing if a function key has been 
pressed besides by using Turbo C++'s BIOSKEY()? I'm tinkering around with 
SERIAL.C found in Turbo C++ Tips & Techniques and would like to be able 
tuse the function keys to do different things. Can I use either INT86() 
or perhaps INT86X()? How would I be able to read the F1 key for example?

--
rick_h@unkaphaed.UUCP (Richard Hamilton)
Unka Phaed's UUCP Thingy, (713) 943-2728 in Houston, Texas
1200/2400/9600/14400 v.32bis/v.42bis
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Union-initialization portability
Date: 8 Oct 92 19:00:28 GMT
Article-I.D.: ulogic.400
Organization: negligable

I am *very* confused.   I don't even know why the "you can't use a function
call in a constructor" line was there, as the original question doesn't
seem to be attempting to do that.  "constructor" seems to be referring
to a C++ question.....  And (upon review) there doesn't seem to be any
function calls in the initializer in the original question....

maybe I've just been staring at this screen too much....


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Blasting, bursting, billowing forth with	|
the power of ten billion butterfly sneezes,	|	-Richard Hartman	
Man, with his flaming fire,			|	hartman@uLogic.COM
has conquered the wayword breezes.		|
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: question about const type qualifier
Keywords: const, odt
Date: 8 Oct 92 18:36:47 GMT
Organization: negligable

As far as I can tell you are correct ... how old is the GNU code?

That should be written as:

	const char *array[20] = {
		"hello, world\n",
		"something else",
		...

If it's supposed to be an array of pointers to unchanging strings
then there is no reason not to initialize them right off, no?

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"186,000 mi/sec.  Not just a good idea, it's the LAW!"

Newsgroups: comp.lang.c,comp.lang.fortran,comp.lang.pascal,sci.math.num-analysi
From: ungar@leland.Stanford.EDU (Jeffrey Ungar)
Subject: Re: Numerical Analysis on a PC-languages?
Organization: DSG, Stanford University, CA 94305, USA
Date: Thu, 15 Oct 92 03:03:52 GMT

In article <1992Oct14.234123.14543@draco.macsch.com> dnl@convex.is.macsch.com (David Lombard) writes:
> [stuff deleted for brevity]
>	Optimizations with pointers.  VERY FEW COMPILERS DO
>		A TRULY GOOD JOB WITH THESE.  My own personal fave
>		compiler writers are Cray.  IMHO - they are without
>		peer in optimizing both Fortran and C.

Ha! But perhaps true on Crays... I thought the message mentioned 
486 PC's, though.
>
>YOU WOULD HAVE TO BE INCREDIBLY MASOCHISTIC TO DO ANY MANNER OF NUMERICAL
>WORK IN PASCAL.

That's true (and you will undoubtledly want to move the
code off a PC someday).
>
>On a PC, I'd probably want to know how good the compiler was in optimization
>and let that guide me.  For PC Fortran, I've hear that RM Fortran is good.
>

Do they still exist? Take WATCOM FORTRAN 77/386 and/or WATCOM C/386
instead. Great optimization and *excellent* technical support! 

>Regards,
>DNL

Jeff
Newsgroups: comp.lang.c
From: "hans friedrich steffani" <GM08@DKAUNI2.BITNET>
Subject: problem with sin on MSC7.0
Organization: University of Karlsruhe, Germany
Date: Wed, 14 Oct 1992 08:42:22 GMT

> #define	ENTKOP
>
> #include <math.h>
> #include <stdio.h>
>
> #include "PORTAB.H"       /* */
>
>
> /*** Definition moduleigener Prozeduren ***/
> #include "C_ENTK.H"
>
>
> /* Vereinbahrung der Modul Variablen */
> extern FLT tsin[L_SIN_TAB+L_4_SIN_TAB+1]; /* SINUS-TABELLE zum schnellen Zugri
ff */
>
>
> 	/****************************************************************/
> 	/*	Aufgabe:	Initialisierung des Entkopplungs Modul	*/
> 	/*			- Init. sin/cos Tabellen		*/
> 	/****************************************************************/
> 	/*	Parameter:	keine					*/
>     	/*	Rueckgabe:	keine					*/
> 	/****************************************************************/
> 	/*	Aenderungen:	1.0	Erstellung			*/
> 	/****************************************************************/
> void init_entkop()
>
> { /* INITALISIERUNG */
>
>     WORD i;		  /* Laufvariable	 */
>     DBL	 argument;	  /* Argument	 */
>
>
>     for (i = 0; i < L_SIN_TAB + L_4_SIN_TAB; i++)
>     { /* Berechnung sin Tabelle */
>
> 	argument = (FLT)2.0 * (FLT)PI / (FLT)L_SIN_TAB
> 		 * (FLT)i;
>
>
>        tsin[i]	 =  (FLT) sin( argument );
>     } /* Berechnung sin Tabelle */

i have this funktion to build a sin-tabular. normallay
it should be a part of an other module with some other
funktions but this doesnt work. tsin will get silly
values. when i extract the init_entkop() and putting
it as a several module (changing tsin from static to
extern wich isnt fine too) it work but is ugly.
i cannot explain better because i dont know better.

perhaps there a some square-brackets lost; tsin
is a array of L_SIN_TAB elements.


hans friedrich steffani
uni karlsruhe
deutschland
gm08@dkauni2.bitnet
steffani@imbaibrs1.bau-verm.uni-karlsruhe.de
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: How does free() work ?
Date: 12 Oct 92 23:53:56 GMT
Organization: negligable

In article <1992Oct12.182006.3996@darwin.ntu.edu.au> cjw@dme.nt.gov.au writes:
>I am just curious about the function of free(). If
>I have a linked list and I free the head of it ie.
>
>free(first_name) ;
>
>where name contains further linked lists called
>say, male_friends & female_friends, does free() then 
>de-allocate their memory as well ? 

No.  free() has no knowledge of your struct's internal structure.

>Or is it necessary
>to do something like the following :
>
>free(first_name->first_male_friends) ;
>free(first_name->first_female_friends) ;
>free(first_name) ;

It would probably be more complex than just this.
You could write your own recursive free()

	free_names(struct person *p)
	{
		if (p == NULL)
			return;				/* you could warn em if you want...
								   but I'm using this to avoid a bunch
								   of protections for the next few lines */

		free_names(p->male_friends);
		free_names(p->female_friends());
		free_names(p->next);
		free(p);
	}

Of course this assumes that each item is a) of the same type "struct person"
and b) that no "person" will appear on more than one chain.

In general, if you did a bunch of malloc()s to create the list,
you will have to do a bunch of free()s to get rid of it.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lazy day, Sunday afternoon.			|
Like to get your feet up, watch TV.		|	-Richard Hartman	
Sunday roast is something good to eat,		|	hartman@uLogic.COM
must be lamb to day 'cause beef was last week!	|
From: scotth@felix.filenet.com (Scott Hopson)
Newsgroups: comp.lang.c
Subject: Re: What is RPG ???
Date: 9 Oct 92 21:56:20 GMT
Reply-To: scotth@fritz.filenet.com (Scott Hopson)
Distribution: na
Organization: FileNet Corp., Costa Mesa, CA

In article <drice.718499569@ponder> drice@ponder.csci.unt.edu (Keith Rice) writes:
>In <1992Oct3.052108.14157@mnemosyne.cs.du.edu> amwalker@nyx.cs.du.edu (Art Walker) writes:
>

<< Misc Deleted >>

>>To be more specific, RPG is almost exclusive to IBM minicomputers (what they
>>like to call "midrange" systems) such as the System/36, System/38, and AS/400

>It's not almost exclusive to minis.  I learned RPG on an IBM 4381 running
>VSE and know of many IBM shops that use, or used, RPG.

The IBM 4300 series are all Mini Computers, reguardless of what some uninformed
might say, the 4300 series are NOT mainframes. 

RPG has been available in the past on larger machines like 3090s but today you
usually find it on IBM Minis. It is or was also available on HP3000 series
computers. I believe it was even found on some earlier HoneyWell machines. It
may have been available for PDP-11s but I don't really know.

Now that lets get back to beautiful, wonderous 'C' which is available on almost
every computer still working today. :-)








-- 
Scott Hopson   (scotth@filenet.com)
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: multidimensional arrays as parameters
Date: 14 Oct 1992 20:34:13 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

In article <1992Oct13.224918.21890@kakwa.ucs.ualberta.ca>
bill@chaos.phys.ualberta.ca (Bill Burris) asks a Frequently Asked
Question about arrays of arrays as parameters, giving as an example
an array declared as:

	int array2d[10][20];

Articles <behrenss.719056199@hphalle6> and
<hjv.719079093@groucho.phil.ruu.nl>, by
behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens) and hjv@phil.ruu.nl
(Hendrik Jan Veenstra), both offer the same erroneous answer:

>void fun2d( int **data2d );

One of the two articles claims that

>fun2d (int **foo) or fun2d (int *foo[]) or fun2d (int foo[][]). All
>of these are equivalent ...

which is also wrong, and advises

>And now go and buy a book on C :)

Alternatively, read the Frequently Asked Questions posting, *especially*
before answering Frequently Asked Questions.

Note that the issue of arrays of arrays is confusing, and there may well
exist books about C that are outright wrong in their descriptions about
them.

In a prototype or formal parameter definition---but ONLY there---the
types

	int **x

and

	int *x[]

act equivalently.  In all other contexts, these types (which do in fact
differ) have different meanings.

The `array2d' declaration gives the object this type:

	array 10 of array 20 of int	[%]

The Rule about arrays in value contexts says:

	In a value context, an object of type `array N of T' becomes
	a value of type `pointer to T', pointing to the first element
	of that array, i.e., the one with subscript 0.
-----
[%] Others prefer to write this as `array of 10 arrays of 20 ints'.
    Either is fine, but I prefer not to mess about with plurals.
-----

An actual parameter to any function is always in a value context, so The
Rule tells us that this `array N=10 of T=array 20 of int' changes to
a value of type `pointer to T', or `pointer to array 20 of int'.  This
is expressed in C as

	int (*)[20]

In a prototype, this might be written as:

	void fun2d(int (*data2d)[20]);

Note that fun2d() can ONLY take pointer to objects of type `array 20 of
int', so

	fun2d(array2d);

is OK, but given

	int other[10][5];

the call

	fun2d(other);		/* error */

is illegal.

The FAQ offers several other approaches as well; these require changes
to the definition of `array2d' itself.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.lang.c
From: devlin@sfu.ca (Tim Devlin)
Subject: IBM EBCDIC Packed Decimal encoded data
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Thu, 15 Oct 1992 17:45:14 GMT

I need C code to convert this type of data on a record by record basis.  The  
task is somewhat complicated by the fact that some data in a record needs  
conversion from EBCDIC strings to ASCII strings while other areas need the  
packed decimal conversion.  With all the "downsizing" going on out there,  
surely someone has done this.  Sources, pointers to sources, or even hints on  
approaches would be greatly appreciated.
Xref: sparky comp.lang.c:14920 comp.lang.c++:14933 comp.os.msdos.programmer:9880