HDTenEightyP/NetNews huggingface dataset:
From: mcgrant@rascals.stanford.edu (Michael C. Grant)
Subject: Re: zero-length datatype
Organization: Information Systems Laboratory, Stanford University
Distribution: comp
Date: 7 Sep 92 14:24:56

In article <TMB.92Sep7171355@arolla.idiap.ch>
tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

   Consider, for example, the following template class definition:

           template <class A,class B>
           struct Bar {
                   A x;
                   B y;
           };


   Now, the straightforward declaration obviously fails.

           Bar<int,void> s;

I don't find this straightforward at all. It seems to me that a
parametrized type is not properly parametrized if some of the types
may contain a 'void' entry like that. Perhaps there should be two
different parametrized types, one that contains B and one that
doesn't, and sufficient conversion operators, if necessary, between
the two of them.

   The following one compiles, but, unfortunately, "sizeof t" turns out
   to be 8, not 4 (I believe the C++ definition makes an effort to ensure
   that this is so):

   The non-existence of a zero length type is somewhat of a nuisance.

It is also quite necessary. Suppose that 'void' had zero length,
and you instantiated

Bar<void,int>s.

Then the pointer to member A would have the same address as the pointer
to member B! That should certainly not happen, since they are two different
objects. The ARM has something quite specific to say about that.
        
   One fix might be to allow definitions of objects of type "void", give
   them zero length, and introduce a single value for objects of type
   "void", denoted "void()". Of course, there would be some minor
   conflicts with the "function(void)" syntax, but those could be
   resolved compatibly. Alternatively, another built-in special type
   could be introduced, say, called "unit", that would be available
   (only) after "#include <unit.h>".


I certainly should not have to 'include' any definition of a built-in
type.

I don't understand why those 4 bytes are causing you such a stink. Perhaps
you could enlighten us as to why a truly zero length data type is even
necessary? Also, I would like to see what templated member functions that
operate on the above object would have to do to deal with the case of
a 'void' type.

Michael C. Grant



Newsgroups: comp.lang.c++
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: zero-length datatype
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Distribution: comp
Date: Mon, 14 Sep 92 13:49:16 GMT

In article <23659@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:
> In article <1992Sep11.185505.17536@cadsun.corp.mot.com> shang@corp.mot.com  
writes:
> 
> > That is why ISO C standard does not allow empty structure and zero 
> > number of array.
> 
> No, ISO C does allow empty structures.  It just says that they must
> occupy a non-zero amount of memory.
> 

Sorry. The SUN C in my computer does not allow empty structure. I shouldn't
assume that it conformed to standard C. But if structure must be non-zero-
sized, empty structure is really useless in C.

David Shang
Newsgroups: comp.lang.c++
From: g89s9112@hippo.ru.ac.za (Dirk Sturzebecher)
Subject: accessibility, HELP
Organization: Rhodes University, Grahamstown, South Africa
Distribution: global
Date: Sun, 13 Sep 1992 16:41:59 GMT

Hi,
I got a question,

for the follwoing definition

class a
{
  functionx ..
}

class b : a
{
  more functions ...
}

class c
{
  b array[8];

  more stuff;
}

why do I get a "a:functionx not accessible" if I try to use function x
in the followin manner

array[1].functionx()

??????

Any help ?
Any suggestions ?

Cheers, Dirk
-- 
-----------------------------------------------------------------------
Dirk Sturzebecher				g89s9112@alpha.ru.ac.za
Rhodes University Grahamstown			South Africa
From: matt@physics2.berkeley.edu (Matt Austern)
Newsgroups: comp.lang.c++
Subject: Re: Proposal: Subscripting with multiple arguments
Date: 14 Sep 92 22:19:04
Organization: Lawrence Berkeley Laboratory (Theoretical Physics Group)
	<MATT.92Sep14161955@physics.berkeley.edu>
	<1992Sep15.031111.15170@u.washington.edu>
Reply-To: matt@physics.berkeley.edu
NNTP-Posting-Host: physics2.berkeley.edu
In-reply-to: rons@hardy.u.washington.edu's message of Tue, 15 Sep 1992 03:11:11 GMT

In article <1992Sep15.031111.15170@u.washington.edu> rons@hardy.u.washington.edu (Ronald Schoenberg) writes:

> M++ has four dimensional arrays that can be generalized to any number
> of dimensions with minor changes in source code.  It, however, overloads
> operator() rather than operator[].  

Yep.  The problem with doing this, though, is that the designer of the
array class has to impose some arbitrary limit on the number of
dimensions---whether two, or three, or four, it's still arbitrary.  It
would be nice to have an array class where this wasn't true.

Note, by the way, that if you're overloading operator(), there's no
way around this, since the signature of that function is different
depending on the dimensionality of the array.  That is,
two-dimensional arrays work by overloading operator()(int,int), but
three-dimensional arrays work by overloading operator()(int,int,int).
You can't overload an infinite number of functions, so there has to be
some maximium on the dimensionality that you support.

This isn't really a practical problem: for several obvious reasons,
high-dimensional arrays aren't very common.  Still, arbitrary limits
like that seem FORTRAN-ish and inelegant, and it would be nice if I
could find a better way.
--
Matthew Austern                   Just keep yelling until you attract a
(510) 644-2618                    crowd, then a constituency, a movement, a
austern@lbl.bitnet                faction, an army!  If you don't have any
matt@physics.berkeley.edu         solutions, become a part of the problem!
From: kaykit@iti.gov.sg (Chan Kay Kit)
Newsgroups: comp.lang.c++
Subject: Help needed on extended memory management
Date: 14 Sep 92 04:26:05 GMT

Reply-To: kaykit@iti.gov.sg
Organization: Information Technology Institute, National Computer Board, S'pore
Date: Mon, 14 Sep 1992 03:16:00 GMT

Hello everyone!

	I have programmed for DOS for a fairly long time but recently I ran 
into memory management difficulties. 

	My program requires a lot of memory for dynamic data (eg. a 1.2 MB 
contiguous block) and thus needs to access extended memory. However, since I 
am only producing a prototype to show concepts, I do not wish to get entangled
in Windows programming. In other words, it would be best if I could just program 
as per normal as possible, with much of the work of managing the extended memory 
done by the compiler or some DOS extender. I am running MS-DOS 3.3.

	I would appreciate it very much if anyone can supply helpful tips to
satisfying the above requirements, and/or answers to the questions below:


(i) Does anyone know if Borland C++ or Zortech C++ allows one to write
and compile DOS programs that automatically use extended memory if 
necessary? What work must be done by the programmer, if any, to manage the 
extended memory? Is the extra work required so much that a switch to the
Windows environment would be more productive instead?

(ii) Any other C language products that come with extended memory management
facilities? 


	Please email replies to kaykit@iti.gov.sg. Thanks in advance!



Kay Kit



---
Kay-Kit CHAN    			| Internet: kaykit@iti.gov.sg
Knowledge Systems Lab			| Bitnet:   kaykit@itivax
Information Technology Institute	| Tel:      (65) 772-0920
National Computer Board of Singapore    | Fax:      (65) 770-3043
Newsgroups: comp.lang.c++
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c++
Subject: Re: Default assignment semantics
Date: 14 Sep 1992 19:06:03 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: usa
NNTP-Posting-Host: telecaster.think.com

In article <1992Sep14.152055.5825@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
>>Thus what I want to do in most of my assignment operators is
>>explicitly invoke the corresponding destructor and copy constructor.
>
>*****>	Ah..."most."  There are occasions, as I've already pointed out,
>	when one doesn't want the d'tor called.  To have this
>	flexibility is probably part of the reason the assignment
>	operator is as it is.

No one is suggesting taking that flexibility away from you.

I like the original poster's idea.  Why force the programmer to write three
functions when the compiler can often infer the third one from the first
two?  Sure, it may be possible to do better than calling the destructor and
copy constructor, but the current default assignment operator is almost
always wrong when these are defined.

If the language isn't changed, I would suggest that compiler implementors
add a warning when they see a class with a copy constructor and destructor,
but no assignment operator.

On a related note, I think that something needs to be done about the fact
that assignment operators aren't inherited.  I think the default assignment
operator for a class derived from classes with user-defined assignment
operators, and which doesn't have its own copy constructor or destructor
(so that it doesn't fall into the above case) should be to invoke the base
classes' assignment operators and then perform memberwise assignment on the
members that it adds.  And if this isn't done, I think compilers should
warn when a class derives from a base with an assignment operator but
doesn't also overload assignment; if a base class needs special assignment
semantics, it seems pretty unlikely that the default semantics would be
appropriate for the derived class.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Answers on a postcard...
Organization: TauMetric Corporation
Date: Thu, 10 Sep 1992 17:49:14 GMT

Karl Keyte <KKEYTE@ESOC.BITNET> writes:

|#include <iostream.h>

|class X {
|   private:    int           value;
|   public:     int           operator , (int i) { return i+10; };
|               int           operator + (int i) { return value+i; };
|               X &           operator = (int i) { value=i; return *this; };
|};


|void main()
|{
|   X         x;

|   cout << "Value is " << (x=1, x+1) << endl;
|}

In the expression in parens, it is unspecified whether "x=1" or
"x+1" is evaluated first.  They are arguments to the "operator,()"
function, not the left and right side of a comma-expression.  If
"x+1" is evaluated first, which is legal, it will use an
uninitialized "x.value".

Don't write code which depends on unspecified order of evaluation.

If there were no "op,()", the "," would mark a comma-expression,
and the "x=1" would have to be evaluated first; in that case the
whole expression would be well-defined.

Finally, use only an "int" return type for main(). The results of
doing otherwise are also undefined.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: mtsjej@gsusgi2.gsu.edu (cat_walker)
Subject: Turbo Vision
Summary: Turbo Vision--overriding streams
Keywords: turbo vision
Organization: Georgia State University
Date: Wed, 9 Sep 1992 16:53:19 GMT

does anyone have any examples on overriding streams in Turbo Vision...
i would like "*" to appear on the InputLine whenever the user types
something in(-password-)but am having trouble with the stream manager
and how to go about doing that...any help or examples greatly appreciated..
thanks in advance!!!!!



Newsgroups: comp.lang.c++
From: bellam@ntmtv.UUCP (Andrea Bell)
Subject: Pattern Matching Algorithm wanted
Originator: bellam@tucana
Reply-To: bellam@ntmtv.UUCP (Andrea Bell)
Organization: Northern Telecom Inc, Mountain View, CA
Distribution: ba
Date: Mon, 14 Sep 1992 17:34:58 GMT

Greetings,

I am looking for a pattern matching algorithm encorporating
wild cards and place holders.  I currently have the Knuth-Morris-
Pratt algorithm for simple pattern matching, but it is not specific 
enough.  I will be using this pattern matching algorithm on strings 
such as the following:

1)	match(415*,variable_number) where:

		415, 4141, 4159669097, etc are matches

2)	match(???2447788,variable_number) where:

		4082447788, 4152447788, etc are matches

3) 	match(4??*,variable_number) where:

		415, 408, 4153334444, etc are matches

The matching algorithm would be similar to what unix uses
for wild cards and place holders.  If you know of a good 
resource or have an appropriate algorithm, please send it
via email to address: 

			Andrea Bell

I will send out a reference document of all solutions that are 
returned to me. Thank you.

Andrea Bell
Northern Telecom
Newsgroups: comp.lang.c++
From: mattw@cssc-syd.tansu.com.au (Matthew Watson)
Subject: Re: C++ Grammar 
Organization: Customised Software Solutions Centres, AOTC
Date: Sun, 6 Sep 1992 23:20:16 GMT

kboyle@csfb1.fir.fbc.com (Kevin T. Boyle) writes:



>		I am interested in writing a syntax parser for C++ and
>	I wonder if anyone has a YACC compatible grammar that they
>	could supply me.  Your help would be very appreciated.
There is a grammar available at the same place you get c++-mode for emacs
from, ftp.cme.nist.gov:pub/gnu/?? I think. Sorry if this isn't right but
I know there is one out there. Try using archie.
-- 

-------------------------------------------------------------------------------
     -  Matthew Watson -  	   | MHSnet: mattw@cssc-syd.tansu.com.au
     Australian and Overseas	   |
Newsgroups: comp.lang.c++
From: ppc1@cec1.wustl.edu (Peter Pui Tak Chiu)
Subject: FULL HOUSE
Organization: Washington University, St. Louis MO
Date: Sun, 13 Sep 1992 14:43:15 GMT


hi everyone,

i am trying to find the probability of getting a hand of full house from a
shuffled deck of 52 cards.

theoretically, the probability (i think) is:

        (13 * 4C2) * (12 * 4C3)
        -----------------------  =  0.001440576
                 52C5

but i wrote a c program to calculate this probability and the results turn
out to be very different.

here is part of the results i have:

* the first column denotes the number of trials
* the second column denotes the probability obtained so far


5400000 0.00420815
5410000 0.00420758
5420000 0.00420867
5430000 0.00420829
5440000 0.00420937
5450000 0.00421046
5460000 0.00421154
5470000 0.00420987
5480000 0.00420967
5490000 0.00420765
5500000 0.004208  ..... this means after 5500000 trials, the prob. is 0.004208


from these results, i conclude that the probability would be pretty much around
0.00421 which is very different from the theoretical value.

does anyone know why???

i have included the program i wrote.  it is written in C++ and is very crude...
please try it and give me some feedback.

thanx a lot!

pete


// To calculate the probability of getting a full house

#include <iostream.h>
#include <time.h>
#include <stdlib.h>
#include <math.h>

int BAD,hand[5];		// BAD when the hand dealt is illegal
				// e.g. 5 of the same kind.
				// hand is an array holding the cards dealt
long COUNTER=0, GOOD=0;		// COUNTER = # of trials
				// GOOD = # of full house dealt


void init(){
for(int i=0;i<5;i++)hand[i]=rand()%13;	// deal the cards
}

int fullhouse(){			// determine if fullhouse or illegal
int counter[13],flag3=0,flag2=0;
BAD=0;
for(int i=0;i<13;i++)counter[i]=0;
for(i=0;i<5;i++)counter[hand[i]]++;
for(i=0;i<13;i++){
	if(counter[i]==3)flag3++;	// detect for 3 of a kind
	if(counter[i]==2)flag2++;	// detect for a pair
	if(counter[i]>4)BAD=1;}		// detect for a bad hand
return((flag3==1) && (flag2==1));
}

main(){
srand((unsigned)time(NULL));		// initialize random seed
while(1){
init();					// deal the cards
if(fullhouse())GOOD++;			// if a FULLHOUSE is dealt, increment
					// GOOD
if(!BAD)COUNTER++;			// if the hand dealt is legal
					// increment COUNTER
if(!fmod(COUNTER,10000))cerr<<COUNTER<<" "<<double(GOOD)/COUNTER<<"\n";
	// print out the result every 10000 trials in the format:
	// [ # of trials ] [ probability obtained so far to get full house ]
}}
From: cs911461@ariel.yorku.ca (CHRISTIAN D. ARMOUR)
Newsgroups: comp.lang.c++
Subject: Vector delete's anachronistic?
Date: 7 Sep 92 19:36:35 GMT
Distribution: all
Organization: York University, Toronto, Canada


Buenos dias netland,


I'm wondering if there's anyone who could offer me some information
on the following warning message from g++:

" Warning: use of vector delete is anachronistic "


All the books I've read (not including the ARM, which I have not
yet purchased) say that if I do this:

	string = new char [some_size];

then I have to do this to free it:

	delete string [some_size]


I'm able to glean from these clues that specifying the size during
deletion is the old way of doing things.  Can anyone tell me at 
which point (which cfront version) this became no longer necessary?

Many thanks,

C. Armour-Kidson
cs911461@ariel.yorku.ca
Newsgroups: comp.lang.c++
From: krc@wam.umd.edu (Kevin R. Coombes)
Subject: Re: new array w/ initializers...
Organization: University of Maryland, College Park
Date: Fri, 11 Sep 1992 13:04:57 GMT

In article <16945@ucdavis.ucdavis.edu> wagner@ike.ucdavis.edu writes:
>class Vector {
>	private:
>		double *vals;
>		int dim;
>	public:
>		Vector (int dimension) {
>			etc...
>		}
>	...
>};  //  End Class Vector
>
>main () {
>	Vector *vecs;
>	vecs = new Vector[10] (3);
>}
>
>The intent is to create an array of Vectors of dimension 3.
>I have run into this problem over and over again, and I don't
>see any logical reason for this not being possible (except
>possibly oversight).  Surely others have had this same idea.

Yes; and the solution is templates. The point to keep in mind for this
example is that the obvious operations on vectors (vector addition, in
particular) don't make sense between vectors of different lengths.
The natural mathematical type of a vector contains its length as part
of its specification -- as part of the type, not as a parameter to
the constructor. I'm sure that someone can (and will) followup with
an example where you really need to pass parameters to constructors
in an array, but I don't believe that vectors are such an example.

Kevin Coombes <krc@math.umd.edu>
From: dodd@dodd.UUCP (Mike Dodd)
Newsgroups: comp.lang.c++
Subject: Re: Numerical Recipes in C++?
Date: Tue, 08 Sep 1992 19:00:47 GMT
 <l9ba7lINN3re@almaak.usc.edu> <1992Sep1.124716.29134@eua.ericsson.se> <MATT.92Sep8111708@physics2.berkeley.edu>
Organization: Not
X-Newsreader: Arn V1.00 beta rel2

In article <MATT.92Sep8111708@physics2.berkeley.edu>, Matt Austern writes:

> In article <1992Sep1.124716.29134@eua.ericsson.se> euamts@eua.ericsson.se (Mats Henricson) writes:
> 
> > >NR in C++ is due within a few months.
> > 
> > This pisses me off considerbly!! I had my local computer bookstore
> > call Cambridge University Press to ask them if they had a C++ version
> > coming up, and they replied NO. So, I bought the C-version. Now I have
> > to put up even more cash when the new version comes, and I tell you,
> > the book isn't cheap...
> 
> The real question: will _Numerical Recipes in C++_ really be in C++,
> or just in C with a few extras?  That is: will it really be a book
> about object-oriented numerical programming?
> 
My understanding is that it will not be released.  This according to a 
previous poster.  

IMHO it would not be worth it.  The book as it is now is fine for 
plug-in programming, exactly as the title expresses numerical RECIPES in
C.  Do not use the coding examples as C examples of how to handle the
task best in that language, but as your assurance that the code REALLY
works.  A line by line analysis can be a 'mind-wrenching' experience.  It
is basically a machine-like translation from the FORTRAN text.

Numerical Recipes in C is worth every penny.  READ IT.  Don't try to 
understand every line of code, get the NUMERICAL RECEIPES Example Book
ISBN 0-521-35746-2 as well and try out the examples, this is where you
can play with the code a bit. (no pun)

IMHO the biggest benefit from C++ is that C is still alive and all those
books, and examples are too.  It is not like switching to ADA for instance
where you are for the most part starting from scratch.

Again, this is just IN MY HUMBLE OPINION.  I realize the benefits gained from 
a complete rewrite, it is just that I don't believe it will happen, and if
it did it would most likely NOT take advantage of all of the best aspects
of C++  anyway.  I am just trying to stop someone from causing themselves 
great damage to their posterior region :-) when in fact they made a proper 
decision to purchase a fine book.

			    -Mike

+-----------------------------------------------------------------------+
|   Michael E. Dodd		Internet:  dodd!dodd@seq.uncwil.edu     |
|   219 Pershing Court		Voice:     919/799-9453                 |
|   Wilmington, N.C. 28412	(Answering Machine on between 4-10PM)   |
+-----------------------------------------------------------------------+
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 5 Sep 92 17:04:34 GMT
Article-I.D.: alice.23634
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Aug31.170908.13389@us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:

> Bob, don't you realize that Bill has just given the strongest argument yet
> in favor of what you've been saying.  The only "clear and convincing argument
> that the code is correct" must use logical proof of correctness concepts.
> These concepts, at least in the literature I've seen, *only* address the three
> basic forms of program flow: sequence, iteration and conditional.

But since every program can be mechanically rewritten in that form,
it doesn't matter.  Moreover, if we do grant your premise, we might
argue that it is even easier to prove programs correct if we eliminate
iteration, which after all can always be expressed by recursion.
[Indeed, there is now a whole family of languages that do just that]

Incidentally, this whole discussion harks back to a debate that appeared
a number of years ago in ACM Software Engineering Notes.  It began with
an article called `Social Processes and the Proofs of Theorems and Programs'
(or something like that) by DeMillo, Lipton, and Perlis.  Among the points
in that article:

	The mathematical community does not automatically accept
	formal proofs as establishing truth; the proof might be wrong.
	Rather, they insist that the result fit in with their existing
	framework of knowledge.  In effect, new theorems are established
	primarily by social means -- a formal proof is important but
	not sufficient by itself.

	Similarly, if a program spits out a 20,000-line proof of the
	`validity' of some other program, is that going to convince
	anyone that the program is actually correct?  They argue no:
	if nothing else, it is necessary to show that what was proved
	is actually the property that the author wanted the program to have.

This article was the subject of a rebuttal from Edsger Dijkstra that
was so strident and emotional as to detract from its credibility.
The article was called `On a Political Pamphlet from the Middle Ages,'
and its tone was consistent with the title.  That led to a re-rebuttal,
and so on.  Fascinating reading.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Novice Questions
Date: Wed, 09 Sep 1992 20:56:39 GMT
Organization: Security APL, Inc.

The general meaning of "null" is something like "a special value of a type
which represents the absence of any of the conventional values".  See, for
example, SQL, where every type is defined to have a null value.  This is
perfectly consistent with the use of "null" both for null pointers and for
the character '\0' in C/C++.  (Although it is *possible* to write programs
in C which treat '\0' as just another character, neither the language nor
its libraries encourage this.  Instead, '\0' is treated as a special value
which does not represent a character.)