HDTenEightyP/NetNews huggingface dataset:
From: pjl@sparc22.cs.uiuc.edu (Paul Lucas)
Subject: Re: can != be used in compound if
Organization: University of Illinois at Urbana-Champaign
Date: Tue, 29 Sep 1992 19:56:56 GMT

In <1992Sep28.195425.26253@julian.uwo.ca> operator@julian.uwo.ca (Operator) writes:

>can -- not equal (!=) -- be used in a compound if statement???


>rnum is a random number generated by random()
>number_set[] is an array of 6 integers


>if (rnum != number_set[1] && rnum != number_set[2] && rnum != number_set[3])


>is this if statement correct because the computer has been hanging on it

>if it is not right, then can someone tell me what is wrong with it????
>your help is GREATLY appreciated!!!

*****>	Well, there's no such thing as a compound if statement; there
	are just if statements.  Yes, != can be used as many times as
	you want in any expression regardless of whether it's inside an
	if statement or not.

		int a, b;
		// ...
		a != b;		// silly, but perfectly legal
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: sriram@tcs.com (Sriram Srinivasah)
Subject: Re: Only 'public' stuff in .h file?
Organization: Teknekron Communications, Inc
Date: Wed, 7 Oct 1992 01:14:34 GMT

I suppose the only thing that you can do is to have a pointer to another class
which encapsulates all the private stuff.

class A {
	int public1;
	int public2;
	PrivateClassA *p;
}

PrivateClassA {
	// All private stuff here, which you can change later.	
}

Yuck !!

Sriram
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: declare keyword, type inference
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sun, 4 Oct 1992 09:21:16 GMT

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

[Re: declare a=b*c;]

>If this capablity was desired (and I disagree), then the sensible thing
>would be to make the "inferenced type" the default type, instead of the
>silly "default int" rule we are living with today.
>
>var=z+x*y;	// typeof(var) == typeof(z+x+y)  (long)
>const cvar=x/y;	// typeof(cvar) == const typeof(x/y) (const int)
>
>Anyway, what I _really_ wanted to say was this:
>
>Let's get rid of the "default int" rule first, IMHO that is
>far more important, since that rule seriously cripples
>compilers ability to do sensible error reporting/recovery.
>

	I agree. And it is possible too. We can keep
"default int" for extern "C" function return types .

The following code will be (thankfully) broken:

	const x=3.9; // defaults to int, x==3

Any C++ functions using the default int rule will also
be broken but  I dont care. Anyone who used default int
for a C++ function deserves to have their code broken!

I originally proposed "declare" just to have a keyword to make
the compilers job easier. I guess you dont need it though,
you can always write

	auto x=a+b;

Omitting the keyword would make assignment and initialisation
hard to distinguish (dont know if this matters?)




-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: chuan@stein.u.washington.edu (Chuan Lee)
Newsgroups: comp.lang.c++
Subject: Re: NIHCL error on HPUX
Date: 6 Oct 92 19:30:32 GMT
Article-I.D.: u.1992Oct6.193032.15388
Organization: University of Washington, Seattle

In article <feist.718381540@bau20.cad-bau.uni-hannover.de> feist@bau20.cad-bau.uni-hannover.de (Michael Feist) writes:
>I have compiled the whole nihcl on my HP under hpux.
>The only mistake I get is by running the example 7-3 for object read from file.
>I get the following run time error:
>
>NIHCL: fatal: [RDWRONGCLASS] Tried to read object of wrong class: expected s, was s
>
>This is a very mysterious error message for me.
>
>Is anybody else working with NIHCL under hpux.
>_______________________________________________________________________________
>			     Michael Feist	
>Institut fuer Stroemungsmechanik und Elektronisches Rechnen im Bauwesen; 
>			Universitaet Hannover

I believe you need to create a dummy file there so the file can
be read.  I don't know if that is the same error I got sometime
ago when I ran the example programs.  The example assumes the file
to be opened already exists.  I think I have run all the examples
supplied.

Chuan Lee
U of Washington, Seattle.
Organization: Penn State University
Date: Tue, 6 Oct 1992 08:04:58 EDT
From: <MKK2@psuvm.psu.edu>
Newsgroups: comp.lang.c++
Subject: C++ Review in Unix Review

The current issue of Unix Review reviews three "native code C++ compilers
for Intel".  Naturally 8-) they didn't include the GNU C++ compiler.  Besides
the fact that FSF rarely advertises in Unix Review, can anyone think of
a good argument for not including the GNU compiler?  It is a "native code"
compiler, isn't it?

email preferred
Newsgroups: comp.lang.c++
From: riipinen@dxcern.cern.ch (Petri Juhani Riipinen)
Subject: "Generic" Objects in a list.
Organization: CERN European Laboratory for Particle Physics
Date: Mon, 28 Sep 1992 09:07:43 GMT

Hello there.

I`m doing a C++ program for my school project and I need a bit of a help
with it. I have a working solution to problem, but it seems a little bit
of clumsy, so I was thinking, that maybe somebody could suggest a little
more "right-C++-style" solution.

So, my program is supposed to be a "interactive-graphics-processor"...:)
Well, basicly I have splitted to screen in two parts, there is this 5-line
input window in the bottom of the screen and the upper region is
reserved for the drawing. You draw objects to screen with simple commands
like: box 80 80 40 40 or circle 50 50 10.

Obviously, I want to have all the different objects represented in the
code as objects. I mean, that is the whole point of the project...:)

I just make a very small outline of the program:

class box { <varibles etc...>
public:   <initialization>
	  void draw();
}

class circle { <also some variables etc.>
public:      <initialization>
	     void draw();
}

The main thing with the objects is, that they all know, how to draw
themselves, thus they have their own drawing methods.

Now, I want to make a linked list of these objects:

typedef struct sdef { void *obj;
		      struct *next;
		    } one_object;

Notice, that the "*obj" could be pointing to any kind of object. Naturally,
it depends on the user, which objects he decides to draw to the screen.

Then, I want to have this global draw(), which will draw every object
in this list. So, it actually walks through the list and asks every
object to draw itself.

something like this:

void draw()
{ one_object *a = global_list;
  class box *ob;

  while (a!=NULL) { ob=(class box *)a->obj;
		    ob->draw();
		    a=a->next;
  }

Now, that works only, if all the objects are class box... I have not found
a way to call the draw() of an untyped object. I suppose, that it is not
even possible.

Now, my clumsy solution is to add an object type identifier in the struct
and do something like this:

void draw()
{ one_object *a = glob_list;
  class box *ob;
  class circle *oc;

  while (a!=NULL) { switch (a->type) {
		    case tpBOX   : ob=(class box *)a->obj;
				   ob->draw();
				   break;
		    case tpCIRCLE: oc=(class circle *)a->obj;
				   oc->draw();
				   break;
		    }
		    a=a->next;
  }

Now, that works, but is that really the only way of doing it? Because,
somehow, I get the feeling, that this not quite according to the principles
of object oriented programming.

But then again, I have only done oop-programming before with TP6.0 and
TVision, so there the DRAW-method always works, so maybe I have gotten
the wrong idea about this.

Any suggestions (please, in email)

- Petri -
Newsgroups: comp.lang.c++
From: dan@cae.prds.cdx.mot.com (Dan Breslau)
Subject: Re: declare keyword, type inference
Organization: none
Date: Mon, 5 Oct 1992 18:46:48 GMT

ark@alice.att.com (Andrew Koenig) writes:
> If starting with a clean sheet of paper, it would
>seem to be nicer to say that the default type is the same as that
>of the initializing expression (with any top-level const, volatile,
>or reference stripped), and there is no default in the absence of
>an initializing expression.  So, for example:

>	void foo() {
>		auto x = 3.5;	// x would be type double
>		auto y = x;	// ditto y
>		auto n = 70000;	// n would be int or long,
>				// depending on the machine
>	}

>and so on.  I use `auto' here because it is already part of the language.
>Moreover, using `auto' in this context immediately answers all questions
>about how to say that a variable of unspecified type is a const or a
>reference, because the syntax is already known.

>But we can't do this because C already requires x, y, and n to be int in
>the declarations above and I don't think we can get away with breaking
>C compatibility here.  The question therefore comes down to whether
>it's worth adding a new keyword and, if so, exactly what the rules
>for it should be.
>-- 
>				--Andrew Koenig
>				  ark@europa.att.com

Stepping into the language-extension-wars with some trepidation, I humbly
suggest:

	auto x <expr>

which is not valid C syntax, hence upward-compatible, and perhaps
(though I'm stretching here) a natural extension of the template
syntax.  (This example would create a variable of the same type
and initial value as 'expr'.)

Dan Breslau
dan@codex.com
Disclaimer:  I deny that I'm speaking for anyone, myself included.

Newsgroups: comp.lang.c++
From: mtsjej@gsusgi2.gsu.edu (cat_walker)
Subject: disableing evCommands in Turbo Vision
Keywords: turbo vision
Organization: Georgia State University
Date: Sun, 27 Sep 1992 20:23:50 GMT

hi....does anyone know how to disable commands such as cmOK when
you are in a modal dialog box...i am having problems using the
TCommandSet....any help appreciated!!!!
Organization: Middle East Technical University - Computer Center
Date: Saturday, 26 Sep 1992 16:07:25 TUR
From: Asuman Dogac <ASUMAN@TRMETU.BITNET>
Newsgroups: comp.lang.c++
Subject:    Public Domain Persistent C++ on DOS



Persistent C++ (called C* ) is available from Software Research and Development
Center of the Scientific and Technical Research Council of Turkey, on DOS.
The product is in its early stages of development and cooperation for
further development of the product is being sought.
To obtain the code and the related technical report, please send a mail address
 Cem Evrendilek
asuman@trmetu.bitnet
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: C++ Style
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 29 Sep 1992 15:05:15 GMT

In article <BvB81p.A6o@matilda.vut.edu.au> martin@matilda.vut.edu.au (Martin Schweitzer) writes:
>>|> Is there a stylistic advantage for puting the declarations closer to where
>>|> I use them? 
>
>I have my doubts about whether declarations placed close to the code
>in which it is referenced enhance readability.  I think that there are
>some good reasons to place declarations close to where they are 
>referenced, but from a point of readability, I think that I find my code
>more readable if at the top of each function I have all my declarations.
>
>This then acts as a sort of index of identifiers.  If I want to get 
>some information about a particular identifier, I know exactly where
>to look.
>
	Perhaps the question is moot, that is, in well written
code the average procedure is about 3 lines, so who cares?

(OK, I still write long C like procedures, but I'm not proud of them :-)


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: brad@meaddata.com (Brad Craig)
Subject: Bug in AT&T C++ 3.0.1 strstreambuf::overflow(int)?
Organization: Mead Data Central, Dayton OH
Date: Fri, 2 Oct 1992 13:21:07 GMT


I believe I found a bug in the overflow(int c) method for
strstreambuf. This is for AT&T C++ 3.0.1.  The method returns an int,
and there is a certain case where the method will return garbage (no
return statement is executed). For those who have the source code,
there is a point where the code determines that no space has to be
allocated. If it is at this point and the int passed as an argument is
EOF, then garbage will be returned. Has anyone else encountered this?
I think the fix in this situation is to return zapeof(c)?

Am I encountering something that has been already been discovered?

Anyone, ... anyone?

-- 
Brad Craig        | "A flute with no holes is   |              (513) 865-1536
Mead Data Central |  not a flute. A donut with  | Common Object Library Group
P.O. Box 933      |  no hole is a danish."      |           brad@meaddata.com
Dayton, OH 45401  |    -- Zen philosopher Basho |     ...!uunet!meaddata!brad
From: djd@csg.cs.reading.ac.uk (David J Dawkins)
Newsgroups: comp.lang.c++
Subject: Re: NIHCL Doc's
Keywords: NIHCL
Date: 28 Sep 92 14:38:59 GMT
Distribution: comp
Organization: University of Reading

michiel@baan (Michiel Wories) writes:

>I Just downloaded and compiled NIHCL for BC++3.1 and am now looking...
> <stuff deleted>

    What's NIHCL?

-dave

-- 
djd@uk.ac.reading.cs.csug
djd@uk.ac.reading.cs.csg
davidd@integ.uucp
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: declare keyword, type inference
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 5 Oct 1992 07:37:08 GMT

In article <TMB.92Oct4201915@arolla.idiap.ch> tmb@idiap.ch writes:
>
>It's not so clear to me that in the presence of a "declare" keyword,
>you couldn't get circular dependencies. For example, what about:
>
>	declare x = f(&x);

	This would only be legal if 

	int x = f(&x);

was legal. Surely you cant initialise a variable with itself like this?

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: noye@bcrka378.bnr.ca (Janet Noye)
Newsgroups: comp.lang.c++
Subject: Problems compiling libg++-2.1 for RS/6000
Date: 6 Oct 92 19:31:17 GMT
Reply-To: noye@bcrka378.bnr.ca (Janet Noye)
Organization: Bell-Northern Research, Ottawa, Canada

I am having problems building libg++-2.1 on the RS/6000.  When it gets to the 
String.cc file the assembler gives a list of errors.  I have the patch for
the RS assembler and was able to build gcc-2.1 and am using gcc to build
libg++.  I would appreciate any information from people who have run into
to this problem or have succesfully built gcc 2.x and libg++ 2.x for the
rs/6000.  I am running AIX 3.2

Thanks for your help,
Janet Noye

-------------------------------------------------------------------------------
Janet Noye : email : noye@bnr.ca                Bell-Northern Research Ltd.
             phone : (613) 763-5985             P.O. Box 3511, Station C
             fax   : (613) 765-4845             Ottawa, Ontario K1Y 4H7
                                                Canada
-------------------------------------------------------------------------------
Newsgroups: comp.lang.c++,comp.std.c++
From: adk@Warren.MENTORG.COM (Ajay Kamdar)
Subject: macro expansion
Organization: Mentor Graphics Corp. -- IC Group
Date: Tue, 6 Oct 1992 17:19:27 GMT

#include <generic.h>

#define ABCimplement(TYPE) TYPE
#define XYZimplement(TYPE) TYPE

#define TWOimplement(TYPE) \
	implement(ABC,TYPE) \
	implement(XYZ,TYPE)

implement(TWO,int)
/*
  What should an ANSI C preprocessor expand this macro to?
  
  If my interpretation of ARM 16.3.3 (pg. 375) is correct, this macro
  should expand to:
	int int

  A new compiler I have to use, when using an ANSI C preprocessor, expands
  this macro to:
	int implement(XYZ,int)

  I would like a sanity check before I rush into filing a bug report.

  Thanks.

  - Ajay
*/
-- 
I speak for none but myself.

Ajay Kamdar                               Email : ajay_kamdar@mentorg.com
Mentor Graphics, IC Group (Warren, NJ)    Phone : (908) 580-0102
From: feathers@serss0 (Michael Feathers)
Newsgroups: comp.lang.c++
Subject: Proposal: Preconditions and PostConditions in C++
Date: 7 Oct 92 01:15:14 GMT
Organization: Florida International University, Miami

I advance this idea with some trepidation... (ooh! noo! new language 
feature!) but has anyone considered adding Eiffel-style pre and post 
conditions to C++?

I once read an article by Bertrand Meyer in which he explained "contractual
programming" in Eiffel.  Each feature (henceforth called functions here)
could list a set of conditions which would have to be met before the body of
the function could be performed, and a set of conditions which should be
met before the function returned to its caller.  Failure to meet the 
conditions could be monitored in a debugger or tied to the exception
handling mechanism of C++.
 
The advantages of such a style of programming are numerous.  Foremost,
among them is the fact that placing these conditions in source is a good 
form of documentation.  The conditions under which a function is supposed
to work are immmediately obvious to readers of the source.  However, if
that was the only advantage, comments could be used.  The fact that conditions
could carry some weight... or be selectively enforced, would be useful.
I've read that Eiffel code often becomes cleaner with these conditions 
because they render many of the other checks in code redundant.  

I know that proposed features are routinely vetoed if there is some other
way of achieving the same effect using the current features of the language.
In this case, it would be ideal to have the signature of the offending 
function, and the condition, thrown or reported in a development as char 
pointers in a development environment.  The name of a function is not
available during preprocessing, so macros are no help unless programmers
type in the name of each function themselves.  This issue really looks 
like it touches on the environment a bit (unfortunately) but there is a real
benefit to be gained.

It seems to me that this feature would be extremely useful for writing safety
critical code and it would not incur any expense if it were not used.  As 
with all other good features of C++, it could be completely optional.
 
If anyone knows whether this has been proposed before, or any reason why it
can not or should not be, please reply.
 
 
Newsgroups: comp.lang.c++
From: silvia@rcf.rsmas.miami.edu
Subject: Re: UAE at install!
Reply-To: silvia@rcf.rsmas.miami.edu
Organization: RSMAS
Date: Wed, 30 Sep 92 20:35:23 GMT

In article <DZuVRB1w164w@admiral.uucp>, fsaleem@admiral.uucp (Farzan Saleem) writes:
>Well, I bought C++ off of a friend of mine and stuck in the install
>disk. When I tried to run install from the PM, I got a 
>General Protection Fault error in Kernel386.... Same error if I 
>try to run it in standard mode.
> 
>Any ideas, or do I demand my money back?????
> 
>FS!
>
>--
>fsaleem%admiral.uucp@yale.edu (Farzan Saleem) <yale!admiral!fsaleem>
>The Admiral's Public UNIX - Greenwich, CT - System Administrator: Doug Fields
>(HST/V32) (203)661-2873 -- (PEP/V32) -1279 -- (V32) -0450 -- (V29/MNP6) -2967
>>FREE!< Unix shell accounts, Usenet access, and Internet-style mail available
If that hapens it is usually the program is not for that version of Windows. I
were you i would ask for your money back.



                Manolo

Newsgroups: comp.lang.c++
From: vinoski@apollo.hp.com (Stephen Vinoski)
Subject: Re: templates and const parameters
Date: Mon, 28 Sep 1992 13:24:50 GMT
Organization: Hewlett-Packard Corporation, Chelmsford, MA

In article <stefans.717671879@bauv106> stefans@bauv106.bauv.unibw-muenchen.de (Stefan Schwarz) writes:
>The following peace of code causes trouble when compiling:
>
>template<class T> class A
>{
>private:
>	T _a;
>public:
>	A(void) {}
>	void set (const T a) { _a = a;}
>};
>
>main()
>{
>	A<int*> a;
>	const int *x = new int(1);
>	a.set(x);
>}
>
>error: bad argument  1 type for  A <int *>::set(): const int * ( const int * expectd)
>
>The problem doesn't occur with a class A<int>.

Parameter "a" to the set member function of the class template is of
type "const T".  Mentally making the substitution of "int *" for "T",
one might come up with:

	void set(const int *a) {_a = a;}

However, one would be wrong. :-) The template instantiation actually
results in:

	void set(int *const a) {_a = a;}

Apply const to the type T.  In this case, T is "int *", so we end up
with "a" being a "const pointer to int".

This is completely consistent with and similar to the treatment of
typedefs in the language.  For example:

	typedef int *IntPtr;
	const IntPtr p;

declares "p" to be a "const pointer to int", not a "pointer to const
int".

It might be easier to remind yourself of this behavior if you write
the declaration for the set member function like this:

	void set(T const a) {_a = a;}


-steve
-- 
Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
Newsgroups: comp.lang.c++
From: leary@progress.COM (James Leary)
Subject: Re: BC++ 3.0 TDW and Windows 3.1
Organization: Progress Software Corp.
Date: Fri, 2 Oct 1992 16:33:42 GMT

tpenttin@majakka.uku.fi (Tommi Penttinen) writes:

>"Can't load WINDEBUG.DLL". That's what my TDW tells me when I try to debug
>anything.. And I'v put WINDEBUG.DLL on the dos command path as told in a
>readme file on the distribution disk. So, what's the problem? Doesn't
>BC++ 3.0's Turbo Debugger for Windows work with Windows 3.1?
>HELP, please! (read: any help greatly appreciated:)

>+Tommi

Borland has a patch for WINDEBUG.DLL for C++ 3.0 when used with Windows
3.1 - contact Borland for additional information, or you can find it
(I believe) on Compuserve - GO BORLAND.

Good Luck.


--
------------------------------------------------------------------------------
Jim Leary             | My opinions are mine and do not reflect the opinions
Progress Software     | of my employer.
------------------------------------------------------------------------------ 
Newsgroups: comp.lang.c++
From: zlin@gmuvax2.gmu.edu (swimmer)
Subject: Re: C++ code to C Code (Re: 
Organization: George Mason University, Fairfax, Va.
Date: Fri, 2 Oct 1992 18:32:18 GMT

help on C++ to C code.
I am trying to generate C code from C++ code using " CC -Fc file.c ".
It did give me a C code. However, when I use "cc " to compile this generated C
code. It failed.
The error message is like:
ld: Undefined symbol
 _main

 __head

Can someone tell me the right way to do this?
Helps are appreaciated.

Chris Lin
CS department
GMU, VA

Newsgroups: comp.lang.c++,comp.lang.c