HDTenEightyP/NetNews huggingface dataset:
From: rgp@mpd.tandem.com (Ramon Pantin)
Newsgroups: comp.lang.c++
Subject: Re: tagged unions, an alternative to RTTI (Re: run-time type checking)
Date: 31 Jul 92 02:34:12 GMT
Organization: Tandem Computers, Micro-Products Division

In article <TMB.92Jul29125322@arolla.idiap.ch> tmb@idiap.ch writes:
>In article <1992Jul28.183746.24287@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>   >Consider the classic "List" class and "ListNode" class.
>   >ListNode is a base class, and assume there are two flavors
>   >of derived node.  We write a List that contains a mix of
>   >these nodes out to a file; now we want to read the List back
>   >in and reconstruct it.
...
>	   a) without some type information, it cant be done.
>	   b) without casting it can (and should :-) be done
>
>	   union hetero {
>		   type1 *p1;
>		   type2 *p2;
>	   };
>   And the list is homogeneous--all the elements are of type 'hetero'.
>It would, in fact, be nice if C++ had a tagged union type, like Pascal
>or SML. Something along the lines of:
>
>union hetero int {
>case 1: type1 *p1;
>case 2: type2 *p2;
>};
>
>int f(hetero h) {
>	switch(h) {
>	case 1: return h.p1->foo();
>	case 2: return h.p2->bar();
>	}
>}
...

The problem with this style of programming is that it goes
against the object oriented programming principles.  Whenever
you use unions of different representations of objects that
are "similar" (instead of having a virtual base class and multiple
classes derived from it) and the code that manipulates each type
of object is located inside a bunch of switch statements spread all
over your code you end up with traditional procedural programming
not with OOP.

When you ask, where is all the code that manipualtes an "hetero"
of "type1"? You have to go searching for all those switches.  What is
even worse, when you need to _add_ anoter type to your "hetero" union
(instead of simply deriving another class from your base class in OOP)
then you have to find all the switches and change them.  Instead of
writting and testing a new ".o" file that implements your new class
you have to change all your old code that contains the switches and
re-test it.

Another general problem with unions is that when you add another
field to your union it might grow.  If you have instances of your
unions stored somewhere (say on a file, from a previous incarnation
of your program) then the new version of the program (where the union
grew) will have know about the size change and have to deal with the
old and new sizes of the union.

Ramon Pantin
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Novice? question: Designing for mul
Date: 27 Jul 92 20:42:22 GMT

maxtal@extro.ucc.su.OZ.AU writes:

>In article <rmartin.711298357@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>>maxtal@extro.ucc.su.OZ.AU (John (MAX) Skaller) writes:

|>|#define KLUDGE
|>|#ifndef KLUDGE
|>|class V {public: virtual void f()=0; virtual void g()=0;};
|>|#else
|>|class V {public: virtual void f(){printf("ERROR V::g\n");} 
|>|	virtual void g(){printf("ERROR V::g\n");}};
|>|#endif
|>|class A1 : public virtual V {public: void f(){printf("A1::f\n");}};
|>|class A2 : public virtual V {public: void g(){printf("A2::g\n");}};
|>|class D : public A1, public A2 {};
|>|int main()
|>|{
|>|	D* d=new D;
|>|	A1 * a1=d;
|>|	A2 * a2=d;
|>|	V * v = d;
|>|	d->f(); a1->f(); a2->f(); v->f();
|>|	d->g(); a1->g(); a2->g(); v->g();
|>|}
|>
|>Yes, this is a problem.  There are ambiguities which are difficult to
|>resolve when trying to fit a jigsaw set of methods together through
|>MI.  Should pure virtual functions be preferentially overridden by
|>implemented virtual function muliply inherited from a sibling?  I am
|>sure that a counter example could be conceived.

|	I am sorry, but you are quite wrong. There is NO PROBLEM with
|overriding virtual functions. There is NO AMBIGUITY in the choice
|of the correct function here: read ARM.

ARM 10.3 "Pure virtual functions are inherited as pur virtual functions."

Your A2 has inherited pure virtual f.  So, should D inherit it too?
Or should it preferentialy choose the function defined in A1.  The ARM
seems to indicate in 10.10c that A1::f will be used by D, but 10.3
also seems to state that D::f will be pure virtual.  This is an
ambiguity.

|	The fact that it works when KLUDGE is defined PROVES that.

By setting KLUDGE, you take 10.3 out of the picture, and the ambiguity
is resolved.  

Should 10.3 hold sway in the presence of 10.10.c?  Good question.  I
can see arguments supporting both sides. 


--
+---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting         |
| rmartin@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering    |
|     (Uncle Bob.)     |-RRR--C----M--M--M-| OOA/OOD/OOP Training      |
+----------------------+-R--R--CCC-M-----M-| Product Design & Devel.   |
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: proceedings of c++ conferences
Date: 29 Jul 1992 02:03:38 GMT
Organization: U. C. Berkeley
Distribution: usa
NNTP-Posting-Host: forney.berkeley.edu

In article <1992Jul29.004924.19621@bellahs.com> balasubr@bellahs.com (Balasubramanian RD) writes:
>Does any know if the "c++ at work" conference publishes its proceedings? 
>I'll appreciate any information on how I can get hold of them (assuming
>they do publish.) Thanks. 

I have my copy of the '91 version of the C++ at work" proceedings in front
of me (with my paper in it).  The proceedings are thin compared to some
conferences: 112 pages.  It says the following:

For additional copies:

The C++ Report
588 Broadway, Suite 604
New York, NY 10012
Phone: 212-274-0640
Fax: 212-274-0646
$39 plus $10 for overseas mail


--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.lang.c++,comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 28 Jul 1992 18:37:46 GMT

In article <BryL9q.K5I@watcgl.waterloo.edu> rhbartel@watcgl.waterloo.edu (Richard Bartels) writes:
>As long as the downcasting discussion is open again,
>the example we are confronting which requires something like
>that, we think, is the issue of input from disk.
>
>I would love to have a solution that did not require the cop-out of
>isA() and cast/convert.
>
>Consider the classic "List" class and "ListNode" class.
>ListNode is a base class, and assume there are two flavors
>of derived node.  We write a List that contains a mix of
>these nodes out to a file; now we want to read the List back
>in and reconstruct it.
>
>Can it be done without resorting to an isA() member function,
>some member data to identify node type, and possibly some
>casting/conversion?

	a) without some type information, it cant be done.
	b) without casting it can (and should :-) be done

	union hetero {
		type1 *p1;
		type2 *p2;
	};


And the list is homogeneous--all the elements are of type 'hetero'.

>
>What's the authoritative answer?

	Dont know. Who's the authority?



-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: dwo1@gte.com (Donald W. Ottens)
Newsgroups: comp.lang.c++
Subject: tutoring and assistance
Keywords: tutoring assistance
Date: 30 Jul 92 01:52:42 GMT
Organization: GTE Laboratories Incorporated, Waltham MA

Greetings,

I am new to C++ (and C, in general).  Due to an unusually demanding
schedule during the next 10 days, I will require some tutoring on
C++ concepts and details.

Since I view this help above the notion of newsnet help, I am willing
to pay dollars ($), based on a negotiable rate.

I will only need some quick help for the next 10 days or so; after that, I
would like to keep the interaction going, as deemed necessary.

If there is anyone out there that can provide tutoring via email or
in-person (either is fine), please call or email me:

dwo1@gte.com


call:  617-466-2071


thanks!


posted:  7/29/92
Newsgroups: comp.lang.c++
From: ik@snoopy.ctt.bellcore.com (Ik Su Yoo)
Subject: virtual madness - problem with virtual base class
Reply-To: ik@ctt.bellcore.com (Ik Su Yoo)
Organization: Bell Communications Research
Date: Fri, 24 Jul 92 19:07:09 GMT

I'm using cfront 2.1 with ObjectCenter 1.1 and having problem with the
following code:

    #include <iostream.h>

    class A {
    public:
      virtual void f() { cout << "A.f()" << endl; };
    };

    class B: public virtual A {
    };

    main()
    {
      B bb;
      void* bbp = &bb;
      ((B*)bbp)->f();
      ((A*)bbp)->f();
    }

The program, when compiled and ran, leads to segmentation fault at the last
line in main(). Interpreting the code from ObjectCenter gives me an
"illegal array index" error.

When I change "public virtual A" to "public A", it runs fine. However, I
need to derive from A as public virtual, because eventually my class
hierarchy will be a DAG with A as the root.

Is this not a legal thing to do in C++? I thought I was allowed to cast to
void* and back. I also tried the above code with g++ and it also gave me
segmentation fault.

Any insight or solution to this problem is appreciated. Thanks.


Ik S. Yoo
RRC-1H229, x5764
ik@ctt.bellcore.com
Xref: sparky comp.lang.c++:11629 alt.sources.d:947 comp.sources.d:1133
From: brad@SSD.CSD.HARRIS.COM (Brad Appleton)
Newsgroups: comp.lang.c++,alt.sources.d,comp.sources.d
Subject: C++ command-line parsing
Summary: Options and CmdLine posted on comp.sources.misc
Keywords: Parsing the command-line in C++
Date: 27 Jul 92 15:39:26 GMT
Followup-To: comp.lang.c++
Organization: Harris Computers Systems Division, Fort Lauderdale,FL

I have just released on comp.sources.misc, two different C++ class
libraries for parsing command-line arguments: "Options" and "CmdLine".
Options is a "bare-bones" package that does just the basics with very
few bells and whistles thrown in. CmdLine on the other hand is a fully
object-oriented approach to command-line parsing that does more than
most of you could ever want. CmdLine also comes with a program named
"cmdparse" (which is similar to Parseargs) to parse arguments for your
shell-scripts (including perl and tcl).

If you are the least bit interested (or in need of) C++ command-line
parsing, then please take a look at one (or both) of these packages.
Although I have gone through extensive alpha and beta testing, I am
very anxious to get feedback and comments (constructive of course)
from the C++ programming community at large.

If you want more info about Options, CmdLine, or Parseargs, then
please send me e-mail.
______________________ "And miles to go before I sleep." ______________________
 Brad Appleton           brad@ssd.csd.harris.com       Harris Computer Systems
                            uunet!travis!brad          Fort Lauderdale, FL USA
~~~~~~~~~~~~~~~~~~~~ Disclaimer: I said it, not my company! ~~~~~~~~~~~~~~~~~~~
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: X3J16 spec
Organization: TauMetric Corporation
Date: Tue, 21 Jul 1992 16:33:28 GMT

jamshid@ut-emx.uucp (Jamshid Afshar) writes:

>According to the FAQ (ftp sun.soe.clarkson.edu, pub/C++/FAQ) you don't
>have to know or become a member. ...
>Is it a real, ready document?  How recent is it?
>... Does it provide much over the ARM?

It is a real document.  It is updated 3 times per year, and mailed
out to the C++ committee membership in February, June, and October.
There are no guarantees that anything you find in one version will
appear in any other version, since it is a working paper; each
contains the results of accepted proposals, "editorial" changes, and
miscellaneous errors.  The bulk of it (so far) is unchanged from the
ARM, except for minor edits.

If you order a copy from ANSI, I would hope you would get the latest
version.  There might be a lag between when a new version is created
and when it is available from ANSI.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: Power Operator vs NANs
Date: 21 Jul 1992 18:50:10 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <850@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
>C++ has abandoned ones-complement hardware and 6-char linkers, that C
>was unwilling to leave behind. Maybe it is time to leave behind non-IEEE
>floating point too.

That would require leaving behind Vaxes, Crays, IBM-370s and compatibles,
several fast floating-point DSP chips, and a few things I've left out.
When you're talking about womping companies as big as IBM, Dec, Cray,
and those that depend on those companies and their machines, you can
expect to lose.

However, in many of those alternate floating-point representations there
are entities that could be made to work like NaNs, to the point where
it might be possible to support IEEE arithmetic properly on IEEE machines
and do something roughly comparable on other machines.

For example, Vax floating point has illegal values that cause reserved
operand traps when used; trap handlers could probably be set up to
allow computation at full speed on normal values and to generate
reserved operands representing NaN, Inf, etc. on errors, with trap
handlers performing the computation on such values.  I don't know enough
about IBM-370s to know if a similar thing is possible; for Crays, I
would expect that it would be very hard to do.

One could still implement the comparison operators that you describe
that consider the possibility of unordered values (NaNs) and have the
same syntax work on machines that don't have NaNs.  It would just be
that the test for two values to be unordered would never come out true
on such machines.

--
Joe Buck	jbuck@ohm.berkeley.edu
From: robison1@husc10.harvard.edu (Keith Robison)
Newsgroups: comp.lang.c++
Subject: Novice question
Date: 21 Jul 92 19:39:40 GMT
Article-I.D.: husc10.robison1.711747580


	I couldn't find this on the FAQ.
I would like to set an iostream that is could be
connected to a file or to cin.  What is the cleanest
way to do this?

Keith Robison
Harvard University
Program in Biochemistry, Molecular, Cellular, and Developmental Biology

robison@ribo.harvard.edu
From: doug@foxtrot.ccmrc.ucsb.edu (Douglas Scott)
Newsgroups: comp.lang.c++
Subject: Overloaded operators and inheritance
Date: 21 Jul 92 23:37:26 GMT
Distribution: usa
Organization: Center for Computer Music Research and Composition, UCSB

I have a class in which I overload the = operator:

class QueryValue : public QueryLabel {
public:
	QueryValue(const char *, CharCheckFun ccf, LegalValueFun lvf);
	virtual ~QueryValue();
	...
	void operator = (const QueryValue& rhs);
	...
};

I then define several subclasses derived from this one:

class StringValue : public QueryValue {
public:
	StringValue(const char *, const char *, CharCheckFun ccf, LegalValueFun lvf);
	StringValue(const char *value=nil);
	virtual ~StringValue();
	...
};

etc.
The '=' operator is implemented such that any of the derived classes should be
able to be assigned to one another, because I use virtual function calls to
both the rhs and lhs instances in the expression:

void
QueryValue::operator = (const QueryValue& rhs) {
	set(rhs.value());
}

However, 

When I attempted to assign one of the derived class instances to another,
using '=', I got this compiler error:

./request.c:129: assignment not defined for type `StringValue'

I looked through Stroustup, but could find no information about how operator
functions are inherited by subclasses.  Why is '=' not defined?  How does this
work??

Thanks in advance.


-- 
Douglas Scott                              (805)893-8352
Center for Computer Music Research and Composition
University of California, Santa Barbara
Internet: (NeXTMail ok)   <doug@foxtrot.ccmrc.ucsb.edu>
Newsgroups: comp.lang.c++,comp.std.c++
From: mat@uunet.uu.net!mole-end
Subject: Re: Language extensions for run-time type identification
Summary: A union of X, Y, and Z is neither an X nor a Y nor a Z
Organization: :
Date: Sat, 25 Jul 1992 07:25:22 GMT

In article <1992Jul24.142452.756@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> In article <1992Jul23.183041.147@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:
> >In article <1992Jul22.150330.6160@cadsun.corp.mot.com>, shang@corp.mot.com (David (Lujun) Shang) writes:
> >> In article <1992Jul21.094204.20100@mole-end> mat@mole-end writes:

	[much STUFF omitted]

> >But without virtualization (polymorphic behavior) derivation is effectively
> >useless.  There is no reason to code inheritance without providing for
> >virtualization.  Then the case which you mention is of no use unless and
> >until it is provided with RTTI; providing RTTI for it using reasonable
> >and economical mechanisms would violate certain assumptions that C++ allows
> >its users to make (C struct compatability).
 
> 	But I would make that argument backwards.
 
> 	One often wants het. aggregates of unrelated types.
> 	Actually, these are aggregates of the *same* type,
> namely, the union of the unrelated types.

No, they are aggregates of objects which share some common property
represented by some base type.

A union of three types, related or unrelated, is not any of those types.
It is something else.
 
> 	On the otherhand, polymorphism is the mechanism by which
> the derived type NEED NOT BE KNOWN. Indeed, if we are to preserve
> the open/closed principle, MUST NOT BE KNOWN.

Not so, since the current RTTI proposal would not look past private
derivation.

> 	So you (well, X3) is considering using RTTI in
> precisely the case it is not needed, and not supplying it
> when it actually could be useful :-)

You are offering a type system error (union of A, B, and C as either
an A or a B or a C) instead of using the type system to support the
commonality deliberately programmed into the types.

(Anyone got a good intro to either classical or modern category theory?
And I don't mean the mathematical muddle on morphisms ...)
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
From: psmith@iies.ecn.purdue.edu (Paul Smith)
Newsgroups: comp.lang.c++
Subject: Re: Bizarre Borland stream bug
Date: 30 Jul 92 19:38:32 GMT
Organization: Purdue University Engineering Computer Network

In article <1992Jul30.185327.662@news2.cis.umn.edu> wright@epx.cis.umn.edu (Mark Wright) writes:
> 
>/*
>FILE 1:
>0001    111111.1111     111111.1111
>0009    222222.2222     222222.2222
> 
>PROGRAM OUTPUT:
>1: 111111.1111, 111111.1111
>0: 9, 222222.2222
> 
> 
>FILE 2:
>0009    222222.2222     222222.2222
>0001    111111.1111     111111.1111
> 
>PROGRAM OUTPUT:
>0: 9, 222222.2222
>25614: 0.2222, 1
>-19961: 0.1111, 111111.1111
>*/

Looks kinda like it is reading 0009 as an octal constant because of 
the leading zeros, except that 9 isn't a valid octal digit so it gets 
bumped to the next read.

Is this correct behavior?  I dunno.

-Paul
//
// Paul F. Smith - ADPC - Purdue University
// psmith@ecn.purdue.edu or pfsmith@adpc.purdue.edu
//
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: Coding Standards - Request for ammo
Date: 23 Jul 92 19:53:13 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 + PL3


mike@meiko.com (Mike Stok) writes:
: 
: Ellemtel, a Swedish telecomms company, put their Programming in C++
: Rules and Reccommendations up for grabs by anon. ftp.  I got them and
: was impressed by the clarity and general level of common sense
: displayed - enough control & structure to be useful without stifling
: creativity.
: 
: I can't remember the ftp address [...]

[This is from mail by Mats Henricsson at Ellemtel]

The document was written using FrameMaker, but has been saved in Postscript
and compressed. It can be accessed by anonymous ftp from our server:
   euagate.eua.ericsson.se   (Internet Address: 134.138.134.16)
It is in the directory:
   ~ftp/pub/eua/c++
The file is ~126k large and its name is:
   rules.ps.Z
   
If there are any problems in accessing or printing the file, please contact
us at:
   mats.henricson@eua.ericsson.se

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
From: michi@ptcburp.ptcbu.oz.au (Michael Henning)
Newsgroups: comp.lang.c++
Subject: Re: const on pass by value
Date: 30 Jul 92 03:14:51 GMT
Organization: Pyramid Technology Corporation

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

>>> >In article <1992Jul24.151010.11969@PacBell.COM>, pjcondi@lepton (Paul Condie) writes:
>>> >> Should pass by value arguments be declared as "const" for
>>> >> good coding style?  Or is that nit picking?
>>

>Furthermore the only reason why it might affect the confidence of the reader
>that the variables are not changed is if the reader does not understand the
>semantics of pass-py-value in C. (If this is the case then the reader,
>not the program, is broken :-). Besides, the "confidence of the reader" is
>a fairly dubious thing in general; this is very much a matter of style (ie.
>"nitpicking").

>Thus I still maintain that it IS just nitpicking.


I disagree. If a function declares a parameter as const, and I'm
reading that function, I can be sure that the value of the parameter will
be the same as the one passed initially, everywhere in the function body.

If the parameter is not declared const, the function may use it as a local
variable. If I then see the parameter used towards the end of the function,
I have to read the entire function body to see whether its value was
changed.

							Michi.
-- 
      -m------- Michael Henning                 +61 75 950255
    ---mmm----- Pyramid Technology              +61 75 722475 FAX
  -----mmmmm--- Research Park, Bond University  michi@ptcburp.ptcbu.oz.au
-------mmmmmmm- Gold Coast, Q 4229, AUSTRALIA   uunet!munnari!ptcburp.oz!michi
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Problem with C++ V3.0.1 on Sun3
Organization: TauMetric Corporation
Date: Fri, 31 Jul 1992 16:37:25 GMT

root@trl.oz.au (System PRIVILEGED Account) writes:

[ code simplified ]

| class	A {
| 	public:
| 		operator int();
| 		friend ostream&	operator<<(ostream&, const A&);
| };

| main()
| {
| 	A	a;
| 	cout << a << endl;
| }

| My problem is that the compiler complains about an ambiguous operator
| << defined for
| 	(ostream &, const A&) in the above source
| clashing with << defined for
| 	(ostaream &, int) defined in iostream.h.

| The problem is obviously caused by the int() operator in class A,
| and indeed removing this operator causes the problem to go away.

This is a compiler bug.  There is an exact match for the friend
function, and a user conversion for the iostream.h function.  hte
friend function should be preferred.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: luj@nationalrd.ecn.purdue.edu (John Lu)
Subject: Is It Illegal Construct ?
Organization: Purdue University Engineering Computer Network
Distribution: na
Date: Sun, 26 Jul 1992 06:49:22 GMT


---------------------
luj@mulberry [562]$ cat foo.C
typedef int Pint;

typedef struct {
    union Ploc_pets {
        struct Ploc_pet_r1 {
           Pint         unused;
        } pet_r1;
        struct Ploc_pet_r2 {
           Pint         unused;
        } pet_r2;
        struct Ploc_pet_r3 {
           Pint         unused;
        } pet_r3;
    } pets;
} Ploc_data;
luj@mulberry [563]$ CC -c foo.C
"foo.C", line 4: internal <<AT&T C++ Translator 2.1.03 08/31/90>> error:
Ploc_pets is not a class name
Compilation failed
errno: 1
---------------------

Where does the ARM say that above construct is illegal, or is this 
a compiler bug ?

--
-- John Lu 
   luj@ecn.purdue.edu
Newsgroups: comp.lang.c++,comp.editors