HDTenEightyP/NetNews huggingface dataset:
From: pete@cssc-syd.tansu.com.au (Peter Alexander Merel)
Subject: Re: Proposal - enhancement for switch statement.
Organization: AOTC - CSSC
Date: Tue, 24 Nov 1992 02:46:00 GMT

mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:

>In article <1992Nov19.163944.19935@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>[It's illegal]
>Of course it's illegal!
>What is being discussed is the merit of allowing the switch command to 
>accept an argument of any type and resolve cases using the appropriate == 
>operator.

Or any extension that achieves the same end - to allow switch to deal with
types that don't go onto int.

>no such thing as a compile-time class object constant this implies that
>the case clause would have to be able to take an expression if
>this proposal were accepted. 

Yes.

>It would also mean that switch was not
>a primitive operation (unless it happened to obey C rules in which
>case it would optimize back to a primative operation). 

So far no one's suggested a reason this could not be made so.

>The ability for
>the compiler to detect duplicate cases would also be lost when varaible
>expressions where use in case clauses (or when the == operator was not
>inline). 

The compiler can still check for duplicate cases when switch devolves to 
the simple C variety, and of course this won't break code (it is more 
permissive than otherwise).

>The range issue was introduced as an amendment and I was demonstrating
>that it was redundant given the implications of the original proposal.

Yah.

>IMHO...
>On balance the extension of switch to operate on any class is probably
>unecessary and the extension to case to take ranges is therefore a good idea. 

I'd rather have a simple semantic extension that does the job for a broad
range of expressions than a syntactic hack that doesn't do much of the
job at all. Ranges won't, for a good instance, allow use of switch with
string classes.

>Adding a new syntax (or worse still token) to the language should not
>be done lightly.

You ain't just whistling dixie.

-- 
Internet: pete@cssc-syd.tansu.com.au   UUCP: {uunet,mcvax}!munnari!cssc-syd!pete
Snail: 1/18-20 Orion Road, Lane Cove NSW 2066 Australia    Phone: +61 2 911 3130
I am a big pond in a small fish.
Newsgroups: comp.lang.c++,comp.std.c++
From: wai@csuvax1.csu.murdoch.edu.au (Julian Wai)
Subject: Unhandled exception error in BC++3.1
Organization: Murdoch University
Date: 22 Nov 92 12:05:23 GMT


Hi,

Does anyone know what the following error mean ?  Any suggestions will be
appreciated.


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

        UNHANDLED EXCEPTION 0D at 00B7:229A Error code: 034C

         AX = 000D   BX = 0000   CX = 0148   DX = 0050
         SI = 0057   DI = 0045   BP = 0FE2   SP = 0FDA
         CS = 00B7   Limit =240F
         DS = 00BF   Limit =219F
         ES = 00BF   Limit =219F
         SS = 005B   Invalid segment
         - 00B7:2292   3D 1E 06 2E 8E 1E 05 00  FF 1E 87 21 07 1F 5F CF

         You may hit [T] to terminate, but you should reboot as soon as possible,
         as the system is unstable ...t
         Unhandled exception 000D at 00B7 229A ErrCode 034C  



Thanks in advance.

Julian
wai@csuvax1.csu.murdoch.edu.au 
Newsgroups: comp.lang.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: Just what is so great about streams?
Date: Thu, 19 Nov 1992 13:17:02 GMT
Organization: University of Birmingham

In article <1992Nov18.205139.12711@bcrka451.bnr.ca>, sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:
> In article <1992Nov18.182420.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
 ...
>>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.
> 
> Perhaps I was thinking too general.  If the class of fout does not need to
> redefine operator<<(), everything is ok.  But if there is some processing
> that has to be done before the data is passed to the underlying stream, 
> doesn't the class of fout have to redefine operator<<()?  In which case
> my example does not work.  Because operator<<() is *not* virtual.  I don't
> think it is true that TimeStamp can properly write to *any* class that 
> is ultimately derived from ostream.  And if it can, I'd sure like to know how.

Yes this is true. This is why classes derived from a stream class should
_not_ redifine operator<<.  Different stream classes differ only in their
IO end not their data formatting end.

For a way to work round this problem don't
derive your class form a stream class but give it an ostream& member
and pass though all define:

template <class T> inline
PseudoStream& operator<<(PseudoStream& ps, const T& data) {
  ps.RealStream << data;
}

Now you can define PseudoStream::operator<<(const SpecificType&)

Note PseudoStream objects can only be used in << statements not in the
other ways that streams can be used.  
-- 
    \\   ( )    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++,comp.sys.mac.programmer
From: jcav@quads.uchicago.edu (JohnC)
Subject: Re: Is anyone using MacApp for serious development?
Reply-To: jcav@midway.uchicago.edu
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Fri, 20 Nov 1992 17:47:38 GMT

In article <k12guB2w165w@coyote.datalog.com> ferdie@coyote.datalog.com (fred jarvis) writes:
>   Is anyone using MacApp for serious development?

Our new copy of Claris MacProject Pro just arrived, and the credits say that
it was written using MacApp.

Just a data point.

-- 
John Cavallino                  |  EMail: jcav@midway.uchicago.edu
University of Chicago Hospitals |         John_Cavallino@uchfm.bsd.uchicago.edu
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g++ k s++ e+ h- pv    |         Chicago, IL  60637
Newsgroups: comp.lang.c++
From: pl2440@meibm31.cen.uiuc.edu (Paul Jay Lucas)
Subject: Re: Protected Derivation
Organization: University of Illinois at Urbana
Distribution: usa
Date: Tue, 17 Nov 1992 00:02:56 GMT

In <4296@cvbnetPrime.COM> skochhar@cvbnet.prime.com (Sandeep Kochhar x4618 5-2) writes:

>In the ARM, I seem to find no mention/explanation of protected derivation
>(i.e., class Foo: protected B {...};).  But I know some compilers support
>it... Is it a recent addition to the ARM or the language?  Where is
>it explained?  What does it mean (briefly)?

*****>	It *is* is the ARM if you read the grammar in the back; it's
	just not explained anywhere.  It is explained in Lippman, 2nd
	ed., and in my book, and perhaps other places.

	The only difference between protected and private derivation is
	that the protected parts of the base become part of the protected
	parts of the derived class as opposed to part of the private
	parts of the derived class.

	One example that I can think of for using it is:

		class List {};
		class Dequeue : protected List {};
		class Stack : private Dequeue {};
		class Queue : private Dequeue {};
	
	Now Stack and Queue will have access to the protected parts of
	List whereas if Dequeue were privately derived, they wouldn't.

	Of course, you're doing all this inheritance here for *code*
	reuse and *not* because a Queue nor a Stack is-a Dequeue nor a
	List, nor is Dequeue a List.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: johns@pcad.UUCP (John Storey)
Newsgroups: comp.lang.c++
Subject: Beginner OOD question
Keywords: OOD dungeon interface
Date: 23 Nov 92 18:33:29 GMT
Organization: Personal CAD Systems, Westford, MA

Just learning C++ (and MS-Windows, as an aside).  I was putting together a test program
for the following two classes: STICON and STBITMAP, which basically are just encapsulating
some functionality for manipulating icons and bitmaps on a Microsoft Windows window.

So I decided the classic hero and monster in a dungeons would work nicely, and came up 
with the following classes:

	Dungeon ('has a' hero, a monster (as icons) and walls and corridors (as bitmaps))
	Hero
	Monster
	VIO (basically, I want to hide the MS-Windows specific stuff - handles to windows,
		etc., from the first three classes, so I figured that I could have them
		communicate their information to VIO who would take care of it -
		so Hero would say to Dungeon "Move me north one space" and if that
		was ok Dungeon would say to VIO "Draw a corridor at (x,y)" which is
		Hero's previous position, and then tell Hero "Draw yourself at (x,y)"
		causing Hero to tell VIO "Draw Hero at (x,y)"

	
My problem with all this, is that the Hero and the Dungeon know all about each other.  So I wanted
to separate them.  This led me to recreating (so I'm told) the Smalltalk interface - I had everyone
have a common ancestor object UMC (Universal Message Center) which allowed them to send messages to
each other - at the same time learning how to use static data members, Borland's Templates, and
the importance of virtual destructors, so even though is the wrong approach I at least learned alot.

So, does anyone have any suggestions as to how to best keep the Dugeon and Hero separate here?  I've
been thinking that another class which keeps the position of all moveable objects in the dungeon stored,
which makes replacing one Dungeon with another easy, but it seems like now that both the Dungeon and
Hero class still have a pretty high degree of coupling, just now with the new class instead of each other.

My other problem here is that there is no reason for my original two classes (STICON and STBITMAP
) to be known about by anyone other that the VIO class, so I have to have the Hero class and
the VIO class would contain an STICON corressponding to the Hero.  This actually strikes me as the
correct approach, but it's seems needlessly complicated to have two classes representing the
same icon on the screen.

Sorry if I'm a bit unclear hear - I really explain things much better with a whiteboard so I can
draw the class interactions as I talk, and truth to tell some points are muddled in my mind as well
(else I wouldn't need to post, eh?)

Thanks in advance,
John Storey
mail to: uunet!pcad.odin!johns
 
Newsgroups: comp.lang.c++
From: mcgrant@rascals.stanford.edu (Michael C. Grant)
Subject: Re: Template functions as class members
Organization: Information Systems Laboratory, Stanford University
	<1992Nov22.191502.1156@mole-end.matawan.nj.us>
Date: 23 Nov 92 10:30:44

In article <1992Nov22.191502.1156@mole-end.matawan.nj.us>
mat@mole-end.matawan.nj.us writes:

   In article <1ej5hqINN1lb@cardamom.compnews.co.uk>, rogera@compnews.co.uk (Roger Allen) writes:
   > ... is it possible to have template functions as class member functions?
   > I've tried it ... but it complains at the syntax ... I sat and pondered
   > this and can't think why this shouldn't be possible.
   Sorry, no, you can't.  But remember that every member function of a template
   class IS a template.
   Oh, why not?  Well, for one thing a user can provide an explicit version
   for any templated function.  Since the member function has access to the
   class's private parts, this would allow anyone to write a function that
   would violate encapsulation without any changes to or actions with the
   class header.
   Think about it.
(Thanks for the arrogant tone, by the way)

That's not a good enough reason, in my opinion. I can perform exactly that
abuse with non-templated functions by writing my own implementations of
private member functions (even adding some of my own to the header) and
linking them in with my main program. So, are you telling me I shouldn't
be allowed to keep a class's source code in more than one file, since I
can access private variables in that fashion?

I'm guilty of similar abuses already, for example. I hate the way that AT&T
wrote their <complex.h> header, (I've said so before on the net), and I
have completely re-written it to my specifications, making .re and .im
public, removing all of the constructors so I can put complexes into a
union (perhaps my BIGGEST complaint), and adding new member functions. I'm
proud of it, too, because I can maintain the ORGANIZATION that class
structures provide without forcing myself to accept another class
designer's shortcomings (which, of course, are always in the eye of the
beholder).

(Time for a flame!) C++'s attempt at information hiding is SUCH a joke...
Why do people insist on intercepting every possible 'abuse' by lopping off
a portion of the language's functionality? I don't need some OO
ultra-purist tying my hands behind my back in the name of true OO design...

Thanks for listening!
Michael C. Grant
--
"Long hair, short hair--what's the difference once the head's blowed off?" (?)
Newsgroups: comp.lang.c++
From: isc@panix.com (David Koosis)
Subject: Re: Need Yacc & Lex retargeted to C++
Date: Mon, 16 Nov 1992 22:44:12 GMT
Organization: PANIX Public Access Unix, NYC

>In article <BxJ8Gp.B9L@iat.holonet.net> rkinder@iat.holonet.net (Robert J. Kinder) writes:
>>You might also look into a product called YACC++ by Compiler Systems (I
>>think that's the company?).  Call or send e-mail and I'll look up the
>>phone number for you.  It is very nice and much simpler than MKS YACC/Lex.

That's:

Compiler Resources
Three Proctor St.
Hopkinton, MA  01748
508-435-5016

It's a decent product, and getting better.
For more info, see the brief product review (by yours truly) in "C++ Report"

-David Koosis
Newsgroups: comp.lang.c++
From: rescorla@rtnmr.chem.yale.edu (Eric Rescorla)
Subject: Re: New Employee Test
Organization: Rescorla for himself.
Date: Sat, 21 Nov 1992 19:07:41 GMT

In article <640@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>In article <1992Nov19.010534.19506@cs.yale.edu> rescorla@rtnmr.chem.yale.edu (Eric Rescorla) writes:
>>Also, I'd note that you specified that the guy should create a bubble
>>sort. One might believe that you had a specific reason why you wanted
>>that. I certainly wouldn't tell someone who was writing code for me
>>that I wanted a bubble sort unless that's what I actually wanted.
>Yes, but how to you *know* that that is what you want?
>
>How do I (the systems analyst) know that you are qualified
>to make the judgement about which type of sort is appropriate?
>
>Do you know about all of the options available (have you heard
>of a combsort)?
>
>The engineer that doesn't question the questionable parts
>of a spec can run into trouble, especially when the customer
>thinks he knows more about my job than I do.  (It's called
>overspecification and can be a real pain in the A**!)
Yes, I'm aware of this and in fact I was complaining that I
believed the problem to be overspecified. But I believe your problem
is that you're looking at this from the wrong perspective.
1) This is a test of the potential employee. It is not a project
to produce something useful. Therefore whether the overall design
is foolish is not clearly relevant.

2) This is not a project in which a bubble sort is a part. It
is a test to CREATE a bubble sort. Nothing more.

Given these two facts, I think that I would be rather inclined to
just go ahead and write the blinking bubble sort in this scenario,
though if I were working on a project and were told to do so, I
would surely protest. 

-Ekr





-- 
-------------------------------------------------------------------------------
Eric Rescorla, DoD#431 (Nighthawk S)              rescorla@rtnmr.chem.yale.edu
Former chemist now CM400 mechanic                 ekr@eitech.com(preferred)
                "Meet the new boss, same as the old boss."
Newsgroups: comp.lang.c++
From: krauskop@en.ecn.purdue.edu (Curtis D Krauskopf)
Subject: Re: New Employee Test
Organization: Purdue University Engineering Computer Network
Date: Fri, 20 Nov 92 04:28:05 GMT

(Greg Compestine) writes:
>
>   Another item mentioned in the book is a protfolio.  I've
>put together one for myself that contains samples of code and
>documentation that I've written.  I personally think a portfolio
>would be a better measure of a programmer than a pop quiz.
>

I agree.  I have always been impressed by the candidates that have
had the forsite (or experience) to bring samples of their code.
A programmer without coding samples is like a graphics artist without
examples -- the only sales technique available is to talk about 
their work.  Not very convincing, in most cases.

Curtis

Xref: sparky comp.lang.c++:16816 comp.std.c++:1612
From: shankar@sgi.com (Shankar Unni)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: "Invalid" argument(s) in template class declaration, how to realize?
Date: 24 Nov 1992 01:00:23 GMT
Organization: Silicon Graphics, Inc.
NNTP-Posting-Host: boris.wpd.sgi.com
X-Newsreader: Tin 1.1 PL5

Xiaojun Zhu (xjzhu@math.uwaterloo.ca) wrote:

> Q: When designing a template class, how to make sure that its argument
>    can only be certain classes or certain predefined types?
> 
> Another words, can we build a template class such that it only accepts 
> certain types as its arguments, while for others it will generate an
> error message such as:
> 
>    This type is not supported by this template.

You can't do that now, but if the proposal for RTTI (Run-Time Type
Identification) ever gets into the standard in some form, you will be
able to do this by doing a run-time check (usually statically
determinable by the compiler).

--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-390-2072
From: cnc@sweep.bt.co.uk (Colin Crist)
Newsgroups: comp.lang.c++
Subject: Re: Just what is so great about streams?
Date: 17 Nov 92 19:39:52 GMT
Reply-To: cnc@sweep.bt.co.uk
Organization: British Telecom

Michael,

There used to be...

	char* form(char* ...) ;

eg.	cout << form("%s", i) ;

At least I used it with GNU 1.37ish. I have a feeling it's no longer supplied
with iostream - I may be wrong though.

Colin.

-----------------------------------------------------------------------
Colin Crist	
BT Research Labs			+44 473 648136
Martlesham Heath			cnc@muppet.bt.co.uk
Suffolk
United Kingdom				Standard disclaimer...
Newsgroups: comp.lang.c++
From: krauskop@en.ecn.purdue.edu (Curtis D Krauskopf)
Subject: Re: New Employee Test
Organization: Purdue University Engineering Computer Network
Date: Fri, 20 Nov 92 03:22:27 GMT

(Eric Rescorla) writes:
>I don't believe that in fact quicksort is a standard library function.
>You should not be fooled by the fact that the standard library function
>is called qsort(). K&RII certainly doesn't specify that the algorithm
>used to do the sort will in fact be quicksort. It could, for instance,
>be heapsort, as far as I can tell. 
>

The idea behind suggesting quicksort (or qsort) shows that the
applicant is aware of functions in a standard commercial C library
and will not attempt to reinvent the wheel.  I _did_ interview one
fellow that admitted he didn't use the library functions 'because he
didn't trust them'.  *shrug*  Good thing I found that out before
he was on my payrole.

>Also, I'd note that you specified that the guy should create a bubble
>sort. One might believe that you had a specific reason why you wanted
>that. I certainly wouldn't tell someone who was writing code for me
>that I wanted a bubble sort unless that's what I actually wanted.

I try to make it clear to the candidate that they are free to make
suggestions, but you are correct that I do not specifically tell them
that.  I will try doing that for the next few interviewees to see how
that works out.  I do not want a 'yes-man' working for me and I like to
see creativity in an applicant's ideas.  On the other hand, I do not want
to eliminate a potentially excellent employee simply because they were
intimidated by the interviewing process.

Good points.

Curtis


Newsgroups: comp.lang.c++
From: erc@netcom.com (Eric Smith)
Subject: Re: New Employee Test
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Fri, 20 Nov 1992 01:45:09 GMT

In article <1992Nov19.184553.12439@fcom.cc.utah.edu> swillden@news.ccutah.edu (Shawn Willden) writes:
>myself and friends.  While I have written plenty of non-trivial programs
>(of non-trivial size and in conjunction with other programmers) I don't 
>have a *company* name to put on my resume, and it has hurt me.  A 
>programming test would offset this disadvantage.

In a recession with high unemployment it doesn't seem very smart to be
looking for a job.  You have too much competition, so you will have to
waste too much time and effort finding a job when you could be spending
that time working.

The best way is to start your own software company.  You don't need a lot
of money, you can start a software company on a shoestring.  Your biggest
expense will be your living expenses while developing your software, and
those can be cut by living like a miser until you get income.

The overwhelming advantage of being your own boss is that superficial
factors such as resumes, company politics, what kind of degree you have,
etc., don't matter much.  The only thing that really matters is that
you can do honest work and come up with a high quality product customers
want.

You can earn a lot more that way too, if you are worth more.  An employee
earns according to complicated factors having to do with company politics,
etc., but a self-employed person earns exactly what he is worth and no
more nor less.  This is what Shakespeare meant by "the edge of husbandry"
and is what makes free enterprise interesting.  Not only that you can
earn what you are worth, but also that you risk finding out that you are
worthless.
Newsgroups: comp.lang.c++
From: J.March@lut.ac.uk
Subject: Compiler Bug (AT&T 2.1) ?
Keywords: declaration constructor
Reply-To: J.March@lut.ac.uk (Jonathan March)
Organization: Loughborough University, UK.
Date: Tue, 17 Nov 92 18:13:06 GMT

Consider this:

                ______ start file.c _______
class Elt
{
public:
                Elt(int*);
                Elt(const Elt&);
                Elt& operator=(const Elt&);
                ~Elt();
};



class List
{
public:
                List();                                 
                List(const Elt&);
                List(const List&);
                List& operator=(const List&);
                ~List();
};


void main()
{
        List L(new int(1));
}


                ______ end file.c _______

compiled with:

        CC +w file.c 

to give:

ld: Undefined symbol 
   Elt::Elt(int*) 
   List::~List()  
   Elt::~Elt()   
   List::List(const Elt&) 
Compilation failed

Fair enough,

BUT:  Shouldn't this fail because the declaration of L doesn't match any of 
        the constructors for class List?


Jon March


Newsgroups: comp.lang.c++