HDTenEightyP/NetNews huggingface dataset:
From: val@news.ccutah.edu (Val Kartchner)
Subject: Re: Proposal - enhancement for switch statement.
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Wed, 18 Nov 92 23:58:47 GMT

nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:
: 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.

The problems with doing if-else statements instead of switch statements are:

   1) it is easier to see that a switch statement is comparing against a
      single statement.

   2) Compilers don't currently do this kind of optimization.  (Though as
      you pointed out, they should.)

However, you do have a point about breaks not exiting loop constructs.
The simplest way to solve this would be to add loop labels and break <label>.

Rather than adding another keywork (like 'breakc'), you could just add
another syntax to break to cause automatic breaking after every case.
This syntax could be of the form of 'switch[c]'.  This would not interfere
with any valid code since the use of the square brackets would have no
valid meaning in previous versions of the language.  ('switch' is always
a reserved word, so it could never be an array.)

				-=:[ VAL ]:=-
--
|================== #include <disclaimer.h> ==================///=============|
| "AMIGA: The computer for the creative mind" (tm) Commodore /// Weber State  |
| "Macintosh: The computer for the rest of us"(tm) Apple \\\///   University  |
|== "I think, therefore I AMiga" -- val@csulx.weber.edu ==\///= Ogden UT USA =|
Newsgroups: comp.lang.c++
From: kanze@us-es.sel.de (James Kanze)
Subject: Re: Just what is so great about streams?
Organization: SEL
	<KANZE.92Nov13200446@slsvhat.us-es.sel.de>
	<1992Nov14.014733.534@frumious.uucp>
Date: 17 Nov 92 19:21:53

In article <1992Nov14.014733.534@frumious.uucp> pat@frumious.uucp
(Patrick Smith) writes:

|> kanze@us-es.sel.de (James Kanze) writes:
|> |Does anyone know of a better way of handling IO formatting in a
|> |type-safe, extensible manner.  It's too late to change the iostream
|> |syntax, but I am curious as to what the alternatives are.

|> I've always thought it would be nice to be able to write
|> something like

|>    int i = 20, j = 17;
|>    cout["i = %d, j = %d\n"] << i << j;

|> This wouldn't involve any loss of type safety, since a separate
|> routine would be invoked for each type of value to be printed.
|> With some work, it could probably also be set up so that it
|> could be extended to printing user-defined types.

This is great.  The really nice thing about it is that it is a natural
extention to the current streams library; it doesn't break anything
and it doesn't really add still another idiom.  I'd probably put the
format string in parentheses, though, and overload the operator(), but
that's just nit-picking.

What is really nice is that it can do automatic type conversions,
which even printf couldn't, ie:

	cout( "i = %f , j = %f\n" ) << 0 << 1 ;

Typically, once I got used to printf, the only place I regularly
fouled up is when I had a variable with the format (which was the same
for a number of printf's), and at some point, wanted to use a constant
(like 0) instead of a variable.  Inevitably, I'd forget that it had to
be 0.0.

Here, of course, the overloaded operator( fmtstream& , int )
recognizes that the requested format is %f, converts the int to
double, and passes it to operator( fmtstream& , double ).
--
James Kanze			GABI Software, Sarl.
email: kanze@us-es.sel.de	8 rue du Faisan
				67000 Strasbourg
				France
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: Sun, 22 Nov 92 01:09:12 GMT

(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.  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?  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?   

Wondering...

Curtis
From: gray@celia.UUCP (Steve Gray)
Newsgroups: comp.lang.c++
Subject: Re: Multiple Inheritance - Necessary?
Keywords: c++ inheritance
Date: 23 Nov 92 23:26:10 GMT
Reply-To: celia!gray@usc.edu (Steve Gray)
Organization: Rhythm & Hues, Inc., Hollywood

One of the problems with multiple inheritance is that is makes run-time
binding of messages (which of course, you can't do in C++) more difficult.

We currently are writing in C++ using a run-time message binding layer on
top of it.  We disallow multiple inheritance in classes which use the
run-time layer.

Another disadvantage of allowing mulitple inheritance is that you can not
have a "propagateToParent" operator (since the definition of parent is
ambiguous).  This is an incredibly useful operator (I know you can cheat
it in C++...but it's not as clean).

However, having said all of this, there are times when I wish I could use
multiple inheritance rather than combination to produce hybrid classes.
Newsgroups: comp.lang.c++
From: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
Subject: Re: C++ tools/facilities for EMACS
Date: Tue, 17 Nov 1992 16:16:31 GMT
Organization: TU Darmstadt

In article <9f170a15@p3.f6.n249.z2.fidonet.org>, Gilles_Kohl@spam.fido.de (Gilles Kohl) writes:
> I know about c++-mode and the C++ awareness of etags, but would be interested 
> in hearing about anything that goes a bit further. Is there a c++-mode that 
> offers more than the c-mode functionality in C++ sources, are there other tools 
> available ?
> 
> (Browsers, maybe ? Tags with type information included ?)

How about the C++ Browser for GNU Emacs? I've never used it myself,
may anybody comment on its stability / usability / etc.? Is it worth
looking into?

Fetch it via anonymous ftp from the C++ archive at Darmstadt:

	ftp.th-darmstadt.de [130.83.55.75]
	directory pub/programming/languages/C++/tools
        file C++browser.tar.Z

--
Joachim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
Newsgroups: comp.lang.c++
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Idempotent header file proposal
Date: Mon, 23 Nov 1992 15:40:49 GMT
Organization: Security APL, Inc.

In article <1992Nov22.173734.2042@taumet.com> steve@taumet.com (Steve Clamage) writes:
>frank@Cookie.secapl.com (Frank Adams) writes:
>>In article <1992Nov20.010009.24900@taumet.com> steve@taumet.com (Steve Clamage) writes:
>>>nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:
>>>>Can we not have a standard pragma to say that a header file is idempotent
>>>
>>>This solves a problem outside the language, and for that reason is
>>>probably not appropriate to put in the language Standard. [...]
>
>>This is a generic problem; it
>>does *not* apply only to some systems.  So a standard is appropriate; but if
>>it is neither to be a language standard nor a standard pragma, how is it to
>>be done?
>
>Some compilers are very slow.  How about a standard pragma "#pragma fast"
>which would direct the compiler to compile more quickly if it could.
>Some compilers require too much memory at compile time.  How about a
>standard pragma "#pragma small" which would direct the compiler to use
>less memory if it could.  If the compiler could not comply, it would
>ignore these pragmas.
>
>I hope these suggestions sound silly to you.  These, along with the
>repeated include file problem, are not C++ (or C) language problems.
>They are "quality of implemenation" issues.

I can't agree.  Whether I want an include file inserted only the first time
it is seen, or every time, is part of the specification of the program.
Inserting #if !defined ... #endif around the body of the file is already a
kludge.  One can make a compiler which deals with this kludge better; this
is indeed a quality of implementation issue.

But it is not a quality of implementation issue to ask for the feature I and
a lot of other people really want, instead of a kludge to get around its
absence.

Based on this, it would seem that a pragma is the wrong way to go.  I would
suggest #once.  (#idempotent suggests that including the file more than once
is the same as including it once.  But if we take out the #if[ndef] hack,
this is no longer the case.)
Newsgroups: comp.lang.c++,comp.object
From: lewisc@ucsu.Colorado.EDU (Christopher J. Lewis)
Subject: How do you sell OOP to management?
Organization: University of Colorado, Boulder
Date: Wed, 18 Nov 1992 16:49:04 GMT

Here is my question: How do you sell OOP to management?

Basically, my co-workers and I have found ourselves in the position of trying
to explain to management why we, as a programming center, should switch from
procedural programing to OO programming.  Since many of our managers are not
programmers, we are at somewhat of a loss on how to justify the switch.

For the past several months, our group has been writing a class library in
C++.  We started the library from scratch and stopped using C cold turkey.
All we had was a written spec of what the individual 'objects' should do.
We designed, reviewed, argued, coded, and redesigned.  All during this time
we were learning C++ and what OOP design really means.  At this point we are
in a good position to talk with the other programmers in the center about our
experiences.  We can answer questions on design times, the learning curve, the
available references and tools, the compilers we used, how portable the code
is, and so on.  We can answer most questions except the big one.

In OOP, design is everything.  Design takes time.  Time is money.  OOP costs
money; simple managerial math. Then add to this equation the time
it takes to train the programmers and the time it takes them to become
proficient.  All this time for what?  Design.  Where is the payoff?  I'm
extrapolating from my own questions and concerns but I'm sure you see the
point.  The payoff for the significant expenditure of time and money has
to be significant.  This is what our group needs to show.

We see the best place to recoup that investment is with diminished maintenance
and service costs.  We simply need to prove it.  What we are looking for are
references with concrete examples specifically aimed at answering the payoff
question.  Also, if you've been through what we are attempting we'd like to
hear from you.

Please e-mail me and I will post a summary of the replies.

- C. Lewis (lewisc@ucsu.colorado.edu)

  
-- 
===
  There must have been a moment, at the beginning, where we could have
  said - no.  But somehow we missed it.
			-Rosencrantz and Guildenstern are Dead
Newsgroups: comp.lang.c++
From: pete@cssc-syd.tansu.com.au (Peter Alexander Merel)
Subject: Templates parameterized on templates (!)
Organization: AOTC - CSSC
Date: Thu, 19 Nov 1992 21:59:56 GMT

I've been thinking of a template that is parameterized on a class, and
on another template. You read that right - it's supposed to be parameterized
on a template. What I want to do is employ any one of a number of different
parameterized containers within my template ... I can't give a full
example for reasons of company confidence, but imagine something like

template<template Container, class T>
class troppo
:
    public Container<T>
{
    ...
};

Now at the moment I'm using an adaptation of the COOL preprocessor courtesy
of the AOTC OSE library (which tips a bucket over any other templated class
library I've ever seen, but it isn't PD so I can't give you anything to
do with it, and don't ask me; but believe me, you want it) in order to do 
templates, and I'm not up on whether real live 3.0 compilers will do this 
or not. If they don't I think they should. 

My ARM doesn't say a word about it. Comments?

-- 
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++
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: self-reproducing C++ program
Organization: University of Jyvaskyla, Finland
Date: Wed, 18 Nov 1992 11:30:06 GMT

In article <c164-aa.722076580@po.berkeley.edu> c164-aa@po.berkeley.edu (Paul DuBois) writes:
>dechc00@tohi.DMI.USherb.Ca (CHRISTIAN DECHAMPLAIN) writes:
>
>>Is that an undecidable problem.  The type of problem you waiste your life
>>trying to solve only to finaly discover it is undecidable.
>
>I think not -- assuming a self-reproducing program of finite size exists,
>one can surely generate all possible inputs to a compiler of equal
>or lesser size.  If an input compiles (!), testing for self-reproduction
>is easy (diff).
>
>An example has been given, therefore the assumption is valid.  QED.

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:

1. It terminates (i.e., in finite time you can see whether it
   is self-reproducing or not).

2. It does not terminate (BTW, if it will certainly perform
   no further output after reproducing itself, it should qualify).

3. Its output is different from its source, whether it terminates or not.

This situation does not seem likely, especially since the halting
theorem does not apply directly:  it says that a _fixed program_
cannot decide about all possible programs whether they are terminating
or not.  Here we are allowed to use any ways and means of reasoning.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Newsgroups: comp.lang.c++
Subject: Re: Simple question: class objects & pointers
Date: 17 Nov 92 12:58:09 GMT
Organization: University of Birmingham

In article <1992Nov16.162130.11475@cis.ohio-state.edu>, beery@clipper.cis.ohio-state.edu (brian david beery) writes:
>   *o.value=0;
> causes an error message, to the effect that the right side of the '.' must
> be a structure.  (I am using Borland C++, if that matters.)  How do I access
> member data of an object referenced by a pointer?
What you have here is a precedence problem
  `*o.value' means `*(o.value)' what you want is `(*o).value'

Most of the time `(*o).value' is abbrieviated `to o->value'
-- 
    \\   ( )    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: rescorla@rtnmr.chem.yale.edu (Eric Rescorla)
Subject: Re: New Employee Test
Organization: Rescorla for himself.
Date: Sat, 21 Nov 1992 20:02:48 GMT

In article <Nov21.193415.44805@yuma.ACNS.ColoState.EDU> sailors@CS.ColoState.EDU (robert sailors) 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
>
>So, the best bonus question might be, "Excuse me sir/Ma'am, do you have a
>good reason to use the bubble sort?  I could maybe make a faster one, if you
>want."
Yeah, but do I get extra points for suggesting bogo-sort?
-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: thssjyh@iitmax.iit.edu (Jianqing Hu)
Subject: Re: Unhandled exception error in BC++3.1
Organization: Illinois Institute of Technology
Date: Tue, 24 Nov 92 03:23:48 GMT

In article <1992Nov23.183940.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
>In article <wai.722433923@csuvax1>, wai@csuvax1.csu.murdoch.edu.au (Julian Wai) writes:
>> 
>> 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.
>> 

I got similar problem when I try to run TC++ on a 286 with a bad memory
board. Later, I changed some memory chips, and this thing never happens
so far.

Jianqing Hu                         |  Internet: thssjyh@iitmax.iit.edu
ECE Dept.  Illinois Inst. of Tech.  |  
Chicago, IL 60616                   |  Office phone: 312-567-6971
From: dgil@pa.reuter.COM (Dave Gillett)
Newsgroups: comp.lang.c++
Subject: Re: Multiple Header Files Problem
Date: 18 Nov 92 03:06:31 GMT
Organization: Reuter:file Inc  (A Reuter Company) Palo Alto, CA

In <5189@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:

>Problem is that a.hh gets #included, #includes b.hh, which tries to
>#include a.hh.  This will fail, since b.hh will not see all declarations
>in a.hh (A_HH is already defined).

     If the #ifndef convention is being used, b.hh's attempt to include a.hh
will include no text; many people have suggested ways in which it need not
even re-open the file.  Infinite recursion or poor performance are not really
the issue here.

     The "real" issue is that if b.hh really refers to information in a.hh,
the compile will fail because a.hh has only partially been seen at that point.
Now, how does b.hh depend on a.hh?  I can think of three scenarios:

1. There is a member of B of type A, and a member of A of type B.
      That's an infinitely recursive definition; there is no way to write
      this and no way to compile it, and I doubt it would make sense if you
      could.

2. There are A methods which refer to members of B, and B methods which refer
   to members of A.
      The only way this can be an issue in the header files is with inline
      methods.  a.hh should #include b.hh *after* the A class definition but
      before the definition of inlined methods, and b.hh should do likewise.
      I usually prefer to put my inlined definitions inside the class
      definition, but in this case they *must* go outside.

3. There is a member of B of type A; there are A methods which refer to 
   members of B.
      This is a degenerate (asymmetric) case; the same remedy as above for
      case 2 will also fix this, although only one of the a.hh really needs
      to do this.

     It's pretty hard to get into this fix except by making heavy use of
inline methods.  Dare I suggest that anyone who regards this as a "very
serious" problem is *probably* inlining too much? 

                                    Dave Gillett

[Experienced software engineer seeks Bay Area employment opportunity.
Resume available on request.]
Newsgroups: comp.lang.c++
From: eny@ermes.enea.se (Erik Nykvist)
Subject: Re: C++ and Shared Memory (Was: Linked Lists in Shared Memory: )
Organization: Project ERMES, Teli Telecom Sweden
Date: Mon, 16 Nov 1992 19:39:35 GMT

ameesh@lsil.com (Ameesh Desai) writes:
> In article 22735@ermes.enea.se, eny@ermes.enea.se (Erik Nykvist) writes:
> >> >=========
> 
> [stuff deleted]
> 
> >The proposed technique uses the new-operator  with placement-syntax to
> >fix the vtbl-pointer in the object. 
> >I have not thought about this very much. I have written ONE example
> >program that uses this. 
> >My idea is that if you know the address of the object in shared memory
> >you could access it after having fixed the vtbl-pointer.
> >If you fork your process it is NOT necessary to fix the vtbl-pointer
> >because the forked process has the vtbl at the same address as the
> >parent process.
> >
> >Erik Nyquist
> >
> 
> 
> I guess if all processes that were to access the shared mem were to have the
> same parent (forked from one single process), what you say is true. However,
> in a more general case, you would like to provide access to the shared 
> memory to processes that do not share the same parent.
> 
> It is not clear to me if there is a "clean" way to share the pages simultaneously
> accross such processes. (when the pages contain C++ objects with vtbl ptrs).
> 
> Ameesh
> 
My idea was to change the value of the vtbl-pointer each time a
context switch occurs. 
There are many disadvantages with this approach. 
One is that only one process may call virtual functions for the object at
the same time. Another one is that it is difficult to design a
constructor that doesn't change the object.

The opposite approach seen in some articles is to make certain that the 
vtbl-address doesn't have to change when a contex switch occurs. This
method requires that the executables are linked in a way that
guarantees that the same address is used for the vtbl in both
processes. 
The only problem with this approach is that it is linker-dependent. 

Well, ...

Erik Nyquist email: erny@enea.se