HDTenEightyP/NetNews huggingface dataset:
From: swillden@news.ccutah.edu (Shawn Willden)
Subject: Re: Member function renaming proposal from the ARM
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Tue, 17 Nov 92 03:19:38 GMT

nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
: I have a question about an extension to the language to allow programmers 
: to specify inheriting and optionally renaming functions. The extension is 
: proposed in the ARM 10.11c (pp 236-237). 
: 

[ proposal and ARM's reason for dismissal deleted ]

: I see another use for this extension (see ARM also 13.1 pp310-312) ...
: 
: class Base {
: public:
: 	// ...
: 	virtual void set(int i);
: 	virtual void set(double d);
: 	virtual void set(char *s);
: 	};
: 
: class Derived {
: public:
: 	// ...
: 	void set(int) = Base::set(int);
: 	void set(double) = Base::set(double);
: 	virtual void set(char *s);
: 	};
: 
: This will prevent set(int) and set(double) being hidden by set(char *), 
: without any loss of efficiency in the calling mechanism.
: 
: Now I realise that there is no chance of including this in the current 
: standard (lets concentrate on getting it finished), but is it a sensible 
: enhancement to the language for some future date ? Or is there an existing
: construct which will do the job without any run-time efficiency penalty ?

The standard trick of defining Derived::set(int) and Derived::set(double)
as inline forwarding functions should work without any run-time penalty
if the compiler is smart.  All it has to do is recognize what is happening
and put the addresses of the Base methods in the Derived vtable.  Given
that this is such an easy optimization I don't think we need a language
extension for it (and another bit of syntax to learn).

: -- 
: 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.

--
Shawn Willden
swillden@icarus.weber.edu
Newsgroups: comp.lang.c++
From: kv07@IASTATE.EDU (Warren Vonroeschlaub)
Subject: Re: New Employee Test
Reply-To: kv07@IASTATE.EDU (Warren Vonroeschlaub)
Organization: Ministry of Silly Walks
Date: Sun, 22 Nov 1992 19:43:39 GMT

In article <1992Nov22.010912.10552@en.ecn.purdue.edu>,
krauskop@en.ecn.purdue.edu (Curtis D Krauskopf) writes:
>(Warren Vonroeschlaub) writes:
>>  I thought I would mention that, at least it in New York, it is 
>>  illegal to give
>>a test to prospective employees before hiring them.
>>
>>  We got into alot of trouble at the contracting firm when 
>>we tested prospective
>>employees to make sure they really knew how to use AutoCad.  A few weeks
later
>>we found one of the people who was turned down (to be exact he knew squat,
>>regardless of what his resume said) complained to one of the government
>>agencies.
> 
>Heh.  That should be a piece of cake to get around.  Just pay them $5.00
>(for their time) as a contract employee to take the test.

  Does it get you out of having to pay unemployment?

>  Note that I 
>do not have a company in New York nor do I know about any loopholes in
>this law, but it does seem to solve the problem.
> 
>BTW, just how does the state of New York expect employers to find out how well
>a person is able to do?

  By reading their resume and crossing your fingers they didn't lie.

>  Do they think employers are going to hire somebody
>for their great resume, find out they stink at the job and then fire them
>the same day?   

  I assume the law was made so that they would have to do this (or something
like it).  It is an "employee protection law" not an "employer protection law".

  Remember, this is New York, where a fleeing mugger can successfully sue the
police if he is shot trying to escape.

 |  __L__
-|-  ___  Warren Kurt vonRoeschlaub
 |  | o | kv07@iastate.edu
 |/ `---' Iowa State University
/|   ___  Math Department
 |  |___| 400 Carver Hall
 |  |___| Ames, IA  50011
 J  _____
From: mmehr@cup.portal.com (mike lee mehr)
Newsgroups: comp.lang.c++
Subject: Wanted: OOA/OOD Tool Information
Date: Thu, 19 Nov 92 00:31:28 PST
Organization: The Portal System (TM)
Distribution: world

I am posting this article for a friend. Please send replies by email to
mmehr@netcom.com. Thanks in advance.

------------------

We are looking for OOA/OOD tools for a large scale project involving C++ on
the Microsoft Windows, and eventually Windows/NT, platforms. We are currently
evaluating Paradigm Plus, the not-yet-released OMTool for Windows, and Atriom.
The notation we chose is based on "Object-Oriented Modeling and Design," by
James Rumbaugh, et al. The following are our criteria for evaluating the tool:

   o Support Object Diagrams, Dynamic Diagrams, and Functional Diagrams
   o ease of drawing and editing diagrams
   o complete support of the methodology
   o object repository
   o ease of declaring and editing classes, attributes, operations
   o workgroup support
   o rule or consistency checking
   o interconnection between objects and diagrams
   o support for large scale projects
   o code generation capability
   o runs on Microsoft Windows, with at least plans for Windows/NT version

We would appreciate hearing any information and/or experience people have had
regarding these OOA/OOD tools, or others we are not yet aware of. More weight
will be given toward tools that are already released, although we will not
totally rule out tools that are soon to be on the market. Your help will be
greatly appreciated. Thanks.

NOTE: Although we have tested various tools supporting the Booch notation, we
have found it to be less expressive and inappropriate to our needs. Please
send comments only about tools supporing Rumbaugh notation. Thanks.
Newsgroups: comp.lang.c++
From: pl2440@meibm31.cen.uiuc.edu (Paul Jay Lucas)
Subject: Re: operator overloading
Organization: University of Illinois at Urbana
Date: Tue, 17 Nov 1992 00:15:09 GMT

In <1992Nov16.200145.23491@aifh.ed.ac.uk> iab@cstr.ed.ac.uk writes:


>I'm looking for some help with operator overloading. I have
>successfully overloaded operators acting on statically declared  user
>defined classes but I would like to declare my classes dynamically and
>still use my overloaded operators. Is this possible, i.e. to use
>overloaded operators on pointers to a class without dereferencing
>explicitly.     

*****>	No; pointers are not first-class objects; operators can only be
	overloaded for class types.  This shouldn't work any more than:

		int i = 1, j = 2, *p = &i, *q = *j;

		if ( p == q )	// pointer comparison only!
			// ...
	
	should, i.e., pointers to class types shouldn't get any special
	treatment over pointers to built-in types.

	You might consider using references whereever you can.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: Just what is so great about streams?
Date: Tue, 17 Nov 1992 20:44:53 GMT
Organization: University of Birmingham

In article <mg.721969238@tyrolia>, mg@tyrolia (Michael Golan) writes:
> Any good reason why
>   cout << fmt("%5d %5d\n") << x << y ;
> or even
>   cout("%5d,%5d\n") << x << y ;
> do not exist?
Yes - nobody has written them.

To implement ostream::operator()() would of course require modification to
the ostream class and we'd like to avoid that.

A better implementation goes as follows:

struct fmt { const char *form; fmt(const char *f) : form(f) {}};

struct formstream {
  ostream& os; const char *form;
  formstream(ostream& o,const char *f) : os(o),form(f) {} 
  preprocess(); postprocess();
}

formstream operator<<(ostream& o,fmt& f) {return formstream(o,f.form);} 

template <class T>
formstream& operator(formstream& f,const T& t) {
  f.preprocess(); f.os << t; f.postprocess(); return f;
}

OK I've given you a start now do you want to try to implement it?

> Also, the book fails to mention that cin.get(c) is slower than getchar()
> by a factor of 2 or so. Same for fread vs. cin.read(), at least in the
> simple timing I made under BC++3.0. This is a serious problem, e.g., when
> you read a 32k chunks of bin data into memory. 
It may be a silly question but are you sure you have in-lining switched
on?
-- 
    \\   ( )    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: magerman@watson.ibm.com (David Magerman;046923)
Subject: Re: Nested Templates in g++
Date: Mon, 23 Nov 1992 06:12:46 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center

In article <1992Nov23.045517.10090@pasteur.Berkeley.EDU> henryc@ic.Berkeley.EDU (Henry Chang) writes:
>It is my understanding that nested templates in g++
>are not yet supported.  Does someone have a work-around?
>

What error message are you getting?  Using the xlC++ 1.1.1, trying to
refer to B<A<X,Y>> generates a syntax error, because the compiler
tries to interpret the >> as an operator.  If I use B<A<X,Y> >, it
compiles and runs fine.

However, since you're using g++, this might be irrelevant.  (Could two
independently written compilers have the same stupid error?)

-- David Magerman
magerman@watson.ibm.com
Newsgroups: comp.lang.c++
From: mg@tyrolia (Michael Golan)
Subject: Re: self-reproducing C++ program
Organization: Princeton University, Dept. of Computer Science
Date: 19 Nov 92 02:00:17 GMT

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.

 Michael Golan
 mg@princeton.edu
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Multiple Inheritance - Necessary?
Keywords: c++ inheritance
Date: 21 Nov 92 03:24:29 GMT
Article-I.D.: alice.24263
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <By17An.4uH@usenet.ucs.indiana.edu> ezachris@iroquois.ucs.indiana.edu writes:

> A friend of mine who programs in Objective-C argues that multiple  
> inheritance is unnecessary and complicated. 

Hmmm... Objective-C doesn't have multiple inheritance, right?

> Let's say you have a pencil-object and an eraser-object and to create a  
> pencil-with-an-eraser-on-it you'd inherit from both the pencil and the  
> eraser object, right?

Not unless you want to say that a pencil-with-an-eraser on it is both a
kind of pencil and a kind of eraser.  At least in ordinary circumstances,
I would consider it a pencil only, so I'd inherit from pencil but give
it a member of type eraser.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++,comp.unix.aix
From: tbel@oahu.cern.ch (Tim Bell)
Subject: Re: g++ on AIX 3.2?
Organization: CERN, European Research Center for Particle Physics
Date: Sun, 22 Nov 1992 17:30:15 GMT

The only problem I'm aware of is with a fix to the assembler.  Once
you have this, it is trivial to build g++ for AIX 3.2.

The fix is APAR IX26107, "Don't allow .csect name[BS] or [UC]"

According to the database, this is available in PTF U409205.  Call 
the support centre and ask for this.

Tim.
--
Tim Bell
IBM High Energy Physics European Centre
TBEL@CERNVM.CERN.CH


Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Calling pure virtual functions in base class constructor
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.20 $
Organization: Trumphurst Ltd.
Date: Mon, 23 Nov 1992 11:55:58 +0000

In article <1992Nov20.184142.26362@taumet.com> steve@taumet.com (Steve Clamage) writes:
> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> |	I suspect it is a quirk. To ban or not to ban a body for
> |a pure virtual? Bjarne chose to allow them. I now see and accept that
> |apart from some unrelated meaning for the body, some 'default' behaviour
> |or, better, 'core' behaviour might well be a good use.
> 
> Consider this:  An abstract base class may have a pure virtual
> destructor.  The destructor for that base class will be called when
> a derived object is destroyed.  Therefore, you must provide a
> definition for the pure virtual destructor.
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 ?

-- 
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: mat@mole-end.matawan.nj.us
Subject: Re: comp.lang.c++
Summary: Seperate group for design issues?
Organization: :
Date: Sun, 22 Nov 1992 19:09:44 GMT

In article <1992Nov20.094137.29839@planet.bt.co.uk>, njs@planet.bt.co.uk writes:
 
> |> I Also vote for a hierachy (if someone invents one)
> |> 
> |> i.e. 
> |> 	comp. lang. c++.  std	  (discusion on standard (old comp.std.c++)
> |> 			. advocay (discusion on new isues)
> |> 			. problems (bugs, code, problems)
> |> 			. tools    (tools ..., porting,)
> |> 			. source... 
> |> 			. don't_know_anmore_idea. bye.bye

> |> ciao vincent@datmuc.dat.de

How about a split between syntax problems and design problems?
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: rkinder@iat.holonet.net (Robert J. Kinder)
Subject: Re: Yacc++
Organization: HoloNet (BBS: 510-704-1058)
Distribution: comp
Date: Mon, 23 Nov 1992 00:16:13 GMT

kato@is.s.u-tokyo.ac.jp (Kazuhiko Kato) writes:
: 
: Does anyone know the address of Compiler Resources, Inc.,
: that provide Yacc++, Yacc extended with C++ integration,
: Lex feature, and extended BNF.
: 
: Experience or evaluation to Yacc++ is also very welcome.
: 

Yeah, I posted an answer to someone else in this news group about two
weeks ago on this.

Yacc++ and the Language Objects Library
Compiler Resources, Inc.
3 Proctor Street
Hopkinton, MA 01748

phone: (508) 435-5016
fax  : (508) 435-4847

We've had real good results with Yacc++.

-- 
// rkinder@holonet.net            International Software Solutions, Inc.  -
// Robert J. Kinder, Jr.                             Boca Raton, Florida  -
//                                                        1-800-788-4774  -
// "We're having a real Ted Bundy day here." - C. Bernholtz
From: ldup@ta7s49.alcbel.be (Luc Duponcheel)
Newsgroups: comp.lang.c++
Subject: self-reproducing C++ program
Date: 16 Nov 92 09:02:51 GMT
Organization: Alcatel Bell Telephone, Antwerpen, Belgium

Consider the following 'self-reproducing' C++ program 

******begin 'prog.c'***************

#include<iostream.h>
char*a="\"\\char*a=",*b="#include<iostream.h>",*c="main(){cout<<b<<endl<<a+2<<*a<<a[1]<<*a<<a[1]<<a[1]<<a+2<<*a<<','<<'*'<<'b'<<'='<<*a<<b<<*a<<','<<'*'<<'c'<<'='<<*a<<c<<*a<<';'<<c<<endl;}";main(){cout<<b<<endl<<a+2<<*a<<a[1]<<*a<<a[1]<<a[1]<<a+2<<*a<<','<<'*'<<'b'<<'='<<*a<<b<<*a<<','<<'*'<<'c'<<'='<<*a<<c<<*a<<';'<<c<<endl;}

******end 'prog.c'***************


Do the following :

$ CC prog.c
$ a.out > PROG.c
$ diff prog.c PROG.c
$


Can somebody find a SHORTER 'self-reproducing' C++ program?


NOTE :


Of course one can make a shorter 'self-reproducing' C++ program
using a user defined include file as follows :


******begin 'prog.c'***************

#include"x.h"
main(){cout<<x;}

******end 'prog.c'***************

******begin 'x.h'***************

#include<iostream.h>
char*x="#include\"x.h\"\nmain(){cout<<x;}\n";

******end 'x.h'***************

but this is 'cheating'.


BTW :

if you send a shorter program to comp.lang.c++, then please also send
it directly to me by email (ldup@alcbel.be) since I do not read comp.lang.c++
very often.
Newsgroups: comp.lang.c++
From: nh@cbnewsg.cb.att.com (nicholas.hounsome)
Subject: Re: Proposal - enhancement for switch statement.
Organization: AT&T
Date: Mon, 16 Nov 1992 09:32:52 GMT

From article <BxsHtz.8qJ@sti.com>, by dgreen@sti.com (Dan R. Greening):
> mcgrant@rascals.stanford.edu (Michael C. Grant) wrote:
>>In article <1992Nov15.190830.11622@cssc-syd.tansu.com.au>
>>pete@cssc-syd.tansu.com.au (Peter Alexander Merel) writes:
>>> [switch on any type using == proposal]
>>>  Any chance?
>>
>>I doubt it... Even before C++ came along, switch statements could not
>>handle floats, strings, structures, etc. Sure, a switch statement could
>>be turned into a set of if-then-else statements, but it isn't because
>>it usually is best turned into a jump table.
> 
> Smart compilers should put it into a series of jump tables and do binary
> search to identify the correct jump table.
> 
> The obvious rhetorical question is "why not require SwitchType to have
> a well-ordering relation using operator< and operator==?".  They you could
> at least do the binary search part instead of a sequence of "=="
> operations.
> 
> But the rhetoric is just that:  I'd prefer to keep it simple, and leave
> switch alone.
> 
> The reason is pretty simple: you as the programmer know your data much
> better than the compiler.  If you are going to use expensive operations,
> like a series of categorizing "==" operator calls, it seems like you 
> should tailor your "switch" to the data.  The compiler can't do that.
> -- 
> ____
> \  /Dan Greening    Software Transformation   1601 Saratoga-Sunnyvale Rd, #100
>  \/dgreen@sti.com   (408) 973-8081 x313       Cupertino, CA 95014

Most switches I have seen are so small that the overhead of range checking
and the possibility of having to have several tables make the whole thing a 
waste of time. 

I haven't checked what my sun compiler does but in the past when I checked
output from other compilers I found that they just implemented switches as
if-then-else anyway.

I find that switch statements tend to be much larger than if-then-else -
for some reason people seem less inclined to use subsidiary functions in switches  than
in if-then-else. I have no idea why this should be so.

I find that having break for both loops and switches means that I have
to create loop exit variables which I hate - I would much rather write
... if( c == 'q' ) break; than case 'q': quit = TRUE; break;

In this day and age we should expect compilers to recogize a sequence
of i-then-else which can be implemented as a jump table. The register
qualifier is now universaly unnecessary - the switch statement should
be as well.

If you use classes extensively there is no need for switch because
you cannot create jump tables which was its original raison d'etre.

Nick Hounsome
Newsgroups: comp.lang.c++
From: KOCHER@nvdv.e-technik.uni-stuttgart.dbp.de (HARTMUT KOCHER)
Subject: Template argument as base class
Organization: University of Stuttgart, IND (FRG)
Date: Fri, 20 Nov 1992 14:00:39 GMT
X-News-Reader: VMS NEWS 1.24

When I use a template argument as a base class, cfront generates
a "sorry, not implemented" message. 
Example:
template<class T>
class Test : public T {
...
};

Any ideas how I can workaround this until cfront is fixed? (HP-Cfront 3.0.1) 
Thanks
Hartmut

Newsgroups: comp.lang.c++
From: head@dorsai.com (Howard Pinsley)
Subject: Re: comp.lang.c++
Organization: The Dorsai Embassy +1.718.729.5018
X-Newsreader: Tin 1.1 PL4
Date: Fri, 13 Nov 1992 19:31:22 GMT

rog@hpscit.sc.hp.com (Roger Haaheim) writes:
: 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.

-- 

Howard Pinsley                                             Voice: (212) 836-8322
head@dorsai.com                                              Fax: (212) 836-8689

Newsgroups: comp.lang.c++
From: dak@messua.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: How to keep a member from being deleted thru a pointer?
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date: 17 Nov 92 17:51:07 GMT

barmar@think.com (Barry Margolin) writes:

>In article <1992Nov15.035153.18866@u.washington.edu> chuan@stein.u.washington.edu (Chuan Lee) writes:
>>Now if someone does a
>>	delete c.getItem("a member");
>>instead of using
>>	c.removeItem("a member");
>>  So how can I prevent that from happening?

>Make Item's destructor private.  Then only members and friends of Item can
>delete instances of Item.

>Note, however, that this will also prevent non-members/friends from
>declaring automatic Item variables, since they would have to invoke the
>destructor when the variable's scope ends.

Why don't you make the object's delete operator private?
Newsgroups: comp.lang.c++
From: rmadapat@alt.uucp (RamMohan R Madapati)
Subject: Re. Finite Elements, C++ libraries
Keywords: FEM, Finite Elements, Tensor Algebra, Class library
Organization: Unisys Corporation
Date: Thu, 19 Nov 1992 00:06:35 GMT

In article <1992Oct21.030821.1011@magnus.acs.ohio-state.edu> rwilhelm@magnus.acs.ohio-state.edu (Reiner Wilhelms) writes:
>Before continuing to re-invent the wheel I'd like to find out if C++ class libraries
>are available which deal with finite element implementations, and/or tensor mathematics,
>For those who know the basics of FEM (or are familiar with the jargon of it:) 
>I would like to implement, and am interested in existing work on some (elegant?)
>implementations of classes like "assembly", "node", "element", "solver", "timestepper",
>"shape_function", etc. (Rather than writing a long description of what these all
>
>Reiner Wilhelms, D. Sc.
>The Ohio State University

Though belated, I would like to inform to the (FEM/C++) interested folks
about an article I found in the C++ Journal. The article titled "Object-
Oriented Numerics" by Dr.Thomas Keffer throws light on the simple building
blocks for numerical models. As indicated in the part 2 i have read, in
part 1 (Vol1. No 4, 1992) he has given the ideology and pseudo code for
some of the primitive classes like vectors, matrices, LU factorization
and FFT servers. In part t he has introduced differential equations and
classes like TimeEqn, DiffusionEqn, TimeStepper. These articles are of
very good use for anybody who wants to build up C++ libs for big models
like FDM and FEM.

-Rammohan Madapati
-----------------------------------------------------------------------------
a(n ir)regular reader of news/literature.

email: alt!rmadapat@uunet.UU.NET
voice: (805) 389-4024
-----------------------------------------------------------------------------
-- 
this is only a test!
Newsgroups: comp.lang.c++