HDTenEightyP/NetNews huggingface dataset:
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Mon, 27 Jul 92 14:50:18 GMT

In article <1992Jul25.172045.24675@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU  
(John MAX Skaller) writes:
> 
> 	OK. My design is flawed. Why? Because I didnt write the
> spec properly.
> 
> 	Spec1: All animals can have a go at mating.
> 	If they are of one species (and opposite sex) then
> 	the female is flagged as pregnant.
>
Your spec. is still wrong. The proper spec. should be:

 	Spec.: All animals of the same species can have a go at mating.
 
> This spec REQUIRES the interface:
> 
> 	void Animal::mate(Animal&);
>

This spec REQUIRES the interface:

        void Animal::mate(thiscalss&);

> because the spec says 'All animals can have a go at mating'.
>
because the spec should prohibit possible mismatch as much as possible.
 
> To check if the animals are of the same type, I provide
> type information:
> 
> 	virtual char* Animal::Species()=0;
>
Here you provide your own RTTI! We can always do that when we need RTTI.
 
> and the sex:
> 
> 	enum {male,female,infertile} sex;
> 
> Now I can write:
> 
> 	void Animal::mate(Animal& x)
> 	{
> 		if(sex==infertile || x.sex==infertile)return;
> 		if(strcmp(Species(),x.Species())) return;
> 		if(sex==x.sex)return;
> 		if(sex==female) pregnant=TRUE;
> 		else x.mate(*this);
> 	}
>
If we can provide a presice specification, why should we leave so many troubles  
to the implementation?! If the implementor happened to forget to check the  
species, what is the result?! And in most cases, we can check the species at  
compile-time, why should we leave it to run-time?

What I asked above just illustrates the difference of your own RTTI and the  
language supported RTTI. The latter is much better and safer.

> NOW: I want to demonstrate why using RTTI is WRONG in this case,
> and why the Species() function is required.	
>
Remenber, your function Species() IS JUST FOR THE PURPOSE TO PROVIDE RTTI. 
> 
> The demonstration is so simple, and applies so generally, I wonder
> why I didnt think of it before.
> 
> 	class DOG : Animal { ....
> 	class HUND : Animal { .. // german programmer
> 
> See: BOTH classes are IMPLEMENTATIONS of the very same animal
> species. But their exact types are different.
> So they could never mate. Tell that to German Shepard
> and an Alsatian :-)
> 
This is never an execuse. If it is, your Species() function has the same  
problem:

 	char* DOG::Species()
        { return "DOG"; }
 	char* DOG::Species()
        { return "HOUND"; }   // german programmer

I'm rather confused: first, you provide your own RTTI function for this case,  
then you try to prove that using RTTI is wrong. What on earth are your trying  
to say?

David Shang


Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: C++ 3.1 vs. 3.0 vs. 2.2 ....
Organization: TauMetric Corporation
Date: Thu, 23 Jul 1992 19:12:47 GMT

mbrinn@bbn.com (Marshall Brinn) writes:

>Could anyone give (or point me to ) a brief description of the language 
>differences between the different recent revisions of C++. That is, what 
>does a 3.1 compiler provide that a 3.0 compiler doesn't? 3.0 vs. 2.2? 

These numbers usually refer to release versions of individual compilers,
not to the C++ language as such.

Releases of the 'cfront' compiler from AT&T (now from USL) have
represented major changes to the language: 1.2, 2.0, 2.1, and 3.0.

1.2 was the first widely-available release of C++.
2.0 added multiple inheritance, access keywords, and other language features.
2.1 added nested types, plus minor language features and changes.
3.0 added templates, plus minor language features and changes.

Release version numbers from other vendors sometimes track the cfront
release version numbers at least approximately, but need not do so.

The C++ language described in the first edition of "The C++ Programming
Language" was a pre-1.2 version of the language.

The full C++ language described in the second edition (and in the ARM)
has not yet been implemented by any commercial compiler.

The ARM in chapter 18 summarizes language changes since the original book.

In "C++ Primer", 2nd edition, by Stan Lippman, Appendix D discusses the
differences between cfront 2.0 and 3.0.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Handling of operator . proposal
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 25 Jul 1992 17:55:44 GMT

In article <1070008@speedy.CND.HP.COM> dds@speedy.CND.HP.COM (Darren Smith) writes:
>
>The argument that operator.() is only a syntactic operation is
>essentially a meaningless, though true, statement.  The question is:
>is there a good reason that it should remain so?  That is the issue
>that should be addressed when you say it's not a runtime operation.
>What problems are caused by it having the possibility of being a runtime
>operation?  Are they solvable?

	NO problems CAN be caused by operator.() in a class that
doesn't define operator.(), so no existing program is broken.

	There is a more important question.

	Operator.() is proposed in part for symmetry, and in part
	to provide smart references.

	If there is another way to provide smart references that
	is better does this EXCLUDE operator.()?

	Or should be allow BOTH idioms?

	Or should we provide operator.() for symmetry ANYWAY,
	and do it NOW because its specification and impact is
	clear and because it is a simplification rather
	than an extension :-)

Now I would ask all compiler implementors to provide 
an 'experimental options' switch which when enabled allows
experimental options to be tested.

And to provide opertor.() as one of those options. Please.
Lets FIND OUT about operator.() by USE not talk.
Then if it works well, we have prior art,
and if it doesn't we have prior art 'decco' :-)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: amonge@cs.ucsd.edu (Alvaro Monge)
Newsgroups: comp.lang.c++
Subject: Name generator
Date: 21 Jul 92 22:57:38 GMT
Distribution: usa
Organization: CSE Dept., U.C. San Diego

I have finally suceeded in compiling/linking C programs with
added C++ modules.  Thanks to all for the help given to me.

Now for my most recent problem:

I am looking for C++ source code to a dynamic name generator.
One of the most important operations which this generator
should do is:

   create a name different from any other name
   given in a list of names.

Also, the names that it creates should have some order to
them.  For example alphabetical order.

Is there an ftp site in which I can find archives of C++
classes, C++ related applications?

Thanks for any help.
Al Monge.
amonge@cs.ucsd.edu
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Language extensions for run-time type identification
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 24 Jul 1992 14:24:52 GMT

In article <1992Jul23.183041.147@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:
>In article <1992Jul22.150330.6160@cadsun.corp.mot.com>, shang@corp.mot.com (David (Lujun) Shang) writes:
>> In article <1992Jul21.094204.20100@mole-end> mat@mole-end writes:
>> > 
>> > The assumption underlying the decision to include only classes with
>> > virtual functions is that a class that has no polymorphic behavior
>> > whatsoever (not even a virtual destructor) cannot be used in any way
>> > that is both safe and interesting even with the proposed runtime type
>> > support.  Can you refute this assumption?
>> > -- 
> 
>
>> First of all and to be specific to C++, it is the class hierarchy, or  
>> inheritance and the polymorphic pointers that lead to the necessity of
>> run time type checking. It is not the virtual behaviors of a class.
>> We still need run time type check even if we disallow any virtual behaviors
>> in C++. Therefore, the assumption is laid on the wrong ground.
>
>But without virtualization (polymorphic behavior) derivation is effectively
>useless.  There is no reason to code inheritance without providing for
>virtualization.  Then the case which you mention is of no use unless and
>until it is provided with RTTI; providing RTTI for it using reasonable
>and economical mechanisms would violate certain assumptions that C++ allows
>its users to make (C struct compatability).

	But I would make that argument backwards.

	One often wants het. aggregates of unrelated types.
	Actually, these are aggregates of the *same* type,
namely, the union of the unrelated types.

	On the otherhand, polymorphism is the mechanism by which
the derived type NEED NOT BE KNOWN. Indeed, if we are to preserve
the open/closed principle, MUST NOT BE KNOWN.

	So you (well, X3) is considering using RTTI in
precisely the case it is not needed, and not supplying it
when it actually could be useful :-)


-- 
;----------------------------------------------------------------------
        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: hansen@pegasus.att.com (Tony L. Hansen)
Subject: Re: Efficient 64-bit integer arithmetic
Organization: AT&T
Date: Wed, 29 Jul 1992 15:17:17 GMT
Summary: See The C++ Answer Book
Keywords: 64-bit integers

In article <711997458snx@trmphrst.demon.co.uk>, nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
> I need to implement efficient 64-bit signed integer arithmetic in C++ (or C)
> on a machine with a 32-bit long (actually, 60 significant bits + sign
> would do fine). 
> 
> I need addition, subtraction, multiplication, division, remainder, and 
> efficient multiply and divide by 10 (for conversion to/from strings).
> 
> I have looked at the bignum package, which implements arbitrary precision,
> but I feel the extra constraint of having only 60 significant bits should 
> enable a much more efficient implementation to be possible.
> 
> Does anyone know of any such code available for anonymous ftp ? Or have 
> any suggestions ?

See classes LINT and arbint (sections 6.10 and 6.11) from The C++ Answer
Book (Hansen, 1990, Addison-Wesley). It has everything you're asking for and
the code is available via ftp from research.att.com (login as netlib, use
your login id as a password, and cd to "c++/answerbook"), or via email
server (send mail which says "send 6.10 from c++/answerbook" to
netlib@research.att.com). The algorithms used are based on Knuth's
algorithms.

					Tony Hansen
			    hansen@pegasus.att.com, tony@attmail.com
				att!pegasus!hansen, attmail!tony

Newsgroups: comp.lang.c++
From: ken@tlc-486.clemson.edu (Ken Bauman)
Subject: dynamic array of pointers to a class type
Organization: SAES, Clemson University
Date: Wed, 29 Jul 1992 23:56:08 GMT


(Using Borland C++ 3.1)

Got a small problem here.  I am trying in one class to create a list of 
pointers to another class.  The size of the list may vary widely upon 
creation of the class containing the list.  This seems obviously a job for 
the constructor.  However I can't quite seem to get it right.  In the 
following simple example the intent is for class B to create a list of 
pointers to class A.

class A { int i; };

class B
{
private:
   A *list[];  // list should be an open array of pointers to objects
               // of type class A
public:
   B(int);
};

B::B (int size)
{
   list = new A *[size];  // this (I think) should allocate the space for
                          // an array of pointers to class A
   // However, I get a compiler error Lvalue required
}

I can get around this by declaring in class B
   A **list;
instead of 
   A *list[];
but this seems rather ungracefull and unintuitive?  and perhaps bad 
programming practice.  I know that list is a pointer to an array of pointers 
and thus may be considered a pointer to a pointer but it doesn't seem to me 
to be quite the same thing.

Can anyone provide some insight, both as to correctness and good programming 
practice?  Much thanks.

Ken

 /---------------------------------------------------------\
/  Ken Bauman @         |    My opinions are irrelevant.    \
\  tlc-486.clemson.edu  |  Everything I say is fact.  NOT!  /
 \---------------------------------------------------------/
Xref: sparky comp.lang.c++:11841 comp.std.c++:1003
From: garyp@manutius.UUCP (Gary Powell)
Newsgroups: comp.lang.c++
Subject: Standards decided via E-mail
Date: 21 Jul 92 15:37:42 GMT
Reply-To: garyp@manutius.UUCP (Gary Powell)
Organization: Aldus Corporation, Seattle WA

I agree with Jim, it is unresonable to make everyone with a good idea travel
to the far corners of the world to set up a standard for the language.  In
these days where I can call Austria, Sweden, or E-mail Germany physical travel
is not required for information to be transfered.

However in the name of fun junkets I think those who can get their companies
to pay for these excursions are doing well.  A lot of work can be done
in a short amount of time when people meet face to face.  Having said that
I don't see that all changes to the language should be subject to this
process.  Rather I suggest you mail your questions directly to the suggestee
ie Jim on the operator.() and if you decide in your wisdom that this addition
to the language still fails to meet the basic requirements of the language then
write that down.  I have yet to see convincing arguments. The arguments so
far boil down to 1) No address operator, &, * -> or . should be overloaded
because people can abuse the notion of a C pointer. and 2) -> is already
in the language, just use that instead. (Koeing and Strustrups' basic argument)

On the evolution of C -> c++ -> D? 
Clearly most of us working stiffs have to BUY our compilers and thus are
forced to use the standards which the manufactures of those compilers  rush
to implement.  When a given language chooses to ignore a segment of the problems
encountered in the real world, other languages are devised.  Ie: Objective C,
Effiel..et.al.  Clearly while we may despise the choices of a particular 
language we HAVE to abide by them.

On abusing our fellow C++ users.
Yes, net flame mail is unbecoming those who participate.  It rarely accomplishes
its goal of changing the mind set of the readers.  However it is easy to see
why a particular person who feels left out of the process could get frustrated
by the other group members who seem to be doing their best to alienate the 
rest of us by being very cliquish.  It is the tendancy of any group to consider
non members as "Them" vs "US" whenever an idea challenges the status quo.
I would remind the members of such groups to look back at the fate of other
such groups who choose to ignore the influx of ideas presented by the masses.


   -Gary-

Gary Powell ------------+ Internet:     garyp@aldus.com
c/o Aldus Corporation   | uunet:        manutius!garyp@uunet.uu.net
411 1st Ave South       | uucp:         camco!manutius!garyp
Seattle, WA 98104  USA  | Voice:        (206) 622-5500
Newsgroups: comp.lang.c++
From: hansen@pegasus.att.com (Tony L. Hansen)
Subject: Re: strdup() Was: Re: Renew?
Organization: AT&T
Date: Fri, 31 Jul 1992 14:39:32 GMT
Summary: look again
Keywords: strdup, null pointers

< From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
<
< hansen@pegasus.att.com (Tony L. Hansen) writes:
<<    #include <string.h>
<<    char *nstrdup(const char *s)
<<    {
<<	if (!s) s = "";
<<	char *ret = new char[strlen(s) + 1];
<<	if (ret) strcpy(ret, s);
<<	return ret;
<<    }
<
< Elegant answer but has a little problem.
<
< char* ptr = nstrdup(0); // ptr = ""; not allocated by new
< delete [] ptr;		// error
<
< Therefore, I suggest the following change.
<
< if (!s) return 0;

Look again.

It's not the value of "" which is returned, but a new'd copy of "" which is
returned. If the pointer passed in is a null pointer, then that pointer is
replaced with a value of "", which is then copied into the new'd space. In
other words, it's always the value which came from operator new which is
returned, and never the value of "".

Here's a version of nstrdup() which is heavily commented:

/*
    NAME
	nstrdup - duplicate string into new'd heap space

    SYNOPSIS
	char *nstrdup(const char *string)

    DESCRIPTION

	The nstrdup() function allocates storage space (with a call to
	operator new) for a copy of string, and returns a pointer to the
	storage space containing the copied string. The function returns 0
	if operator new returned 0. If the string pointer is null, an empty
	string is used in its place.
*/
	
#include <string.h>
char *nstrdup(const char *s)
{
    if (!s) s = "";			  // if null pointer, use empty string default
    char *ret = new char[strlen(s) + 1];  // allocate space
    if (ret) strcpy(ret, s);		  // copy string
    return ret;				  // return value returned by operator new
}

					Tony Hansen
			    hansen@pegasus.att.com, tony@attmail.com
				att!pegasus!hansen, attmail!tony
From: dwo1@harvey.gte.com (Donald W. Ottens)
Newsgroups: comp.lang.c++
Subject: tutoring apology
Keywords: tutoring apology
Date: 30 Jul 92 14:16:34 GMT


Dear Folks,

As you may have seen, a lot of pesky messages were posted by me yesterday.
I am writing to apologize on behalf a quirk in our news net application.

It turns out that all of my messages were sent and I only meant to have one
sent to the world!

(I'm not that desparate for help, for crying out loud!).

So please accept our apologizes for taking up bandwidth with a bunch of
repetitive messages.  It was an accident.

I still would like some tutoring though, so please call or email me at:

617-466-2071

dwo1@gte.com

Willing to pay $

thank you,

don o
Xref: sparky comp.lang.c++:11250 comp.lang.c:11400
From: christ@cps.msu.edu.cps.msu.edu (Oliver Christ)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: Borland charges before delivers
Date: 21 Jul 92 17:04:32 GMT
Reply-To: christ@cps.msu.edu.cps.msu.edu (Oliver Christ)
Organization: Dept. of Computer Science, Michigan State University
Originator: christ@whale.cps.msu.edu

In article <1992Jul21.002536.20968@thunder.mcrcim.mcgill.edu> leying@alpha (Leying Zhao) writes:
>I ordered BC++ 3.1 on June 21 (BEFORE THEIR SHIPPMENT BEGAN) and I
>have not get it now (today is July 20). But I get the BILL! It billed
>on June 24 throug Master Card. I called them again. A rep told me
>that I have 2 choices:  1) just wait. 2) cancel the order, they
>reverse the charge and reorder again. But I will lose my position on
>the waiting line. It sounds that I made a mistake!

The mistake was to go through Borland.  I got my copy in 2.5 weeks
through a local dealer.  Advice:  The dealer probaly doesn't have
it in stock.  Make them call their distributor to give you an exact
estimate of how long it will take to get the copy, don't just 
"take their word" for it!  Order times vary with dealers.

-------------------------------------------------------------------------------
 Oliver Christ                                  Department of Computer Science
 christ@cps.msu.edu                               Michigan State University
-------------------------------------------------------------------------------
Xref: sparky comp.lang.c++:11513 comp.os.msdos.programmer:8064 alt.msdos.programmer:2066 comp.windows.ms:17994 comp.windows.ms.programmer:7354
From: shyam007@ccwf.cc.utexas.edu (Shyam sundar P Cherlopalle)
Newsgroups: comp.lang.c++,comp.os.msdos.programmer,alt.msdos.programmer,comp.windows.ms,comp.windows.ms.programmer
Subject: BC 3.1 (owl) -- PStreamError  -- Help !
Date: 22 Jul 92 21:27:10 GMT
Reply-To: shyam007@ccwf.cc.utexas.edu (Shyam sundar P Cherlopalle)
Followup-To: comp.lang.c++
Organization: The University of Texas at Austin, Austin TX
Originator: shyam007@doc.cc.utexas.edu


Hi,

  I have been trying to use the TStreamable class of Borland's ObjectWindows
  and write a stream to a file. The class is derived multiply from
  TNSCollection and TStreamable classes. As required by decendents of 
  TStreamable I defined the four operator overloading functions, read, 
  write, build etc and registered the class using 


	TStreamableClass RegClassname(....);

  But when I tried to write an instance of the above class to a file I have
  been getting an error saying

     PSTREAM ERROR CONDITION -- Type not Registered.

  The class I defined is very similar to the class TPointArray in the steps
  example of ObjectWindows. Can somebody help me get around this by suggesting
  probable error I might have committed.

  I have been working on this problem for a week now and have been unable to
  hack around it. It would also be very helpful if some kind soul could send
  me some source code which shows the usage of the above.

  Thanks in advance,

  -- Shyam
----------------------------------------------------------------------------
Shyam Cherlopalle                              University of Texas at Austin
email : shyam007@ccwf.cc.utexas.edu        
----------------------------------------------------------------------------

Newsgroups: comp.lang.c++
From: LANG@129.69.123.1 (MARTIN LANG)
Subject: RE: ztc 3.0 bug Ternary operator & chars
Organization: University of Stuttgart, IND
Date: Tue, 21 Jul 1992 07:05:08 GMT
X-News-Reader: VMS NEWS 1.20

This behavior is not a bug. The ternary operator evaluates arithmetic 
expressions. Your character constants are handled as expressions and
typecasted. That is the standard. (see ARM page 78)

 Martin
Newsgroups: comp.lang.c++
From: davgot@auto-trol.com (David Gottner)
Subject: Re: C++ compiler macros
Organization: Auto-trol Technology Corporation
Distribution: usa
Date: Thu, 23 Jul 1992 14:30:46 GMT

>I wouldn't want to bet on the test of __STDC__ not generating an error
>when __STDC__ was not defined, either, although it worked just fine on
>Sun C++ when I tried it. Sun C++ seems to treat undefined symbols as
>having a value of 0 -- something I can find no justification for (though
>I haven't tried very hard). Anyone know if this can be relied on?

The ANSI standard specifies that undefined symbols in #if expressions
get the value 0.
-- 
Amrit Prem			|
davgot@auto-trol.com		| This area is intentionally left blank
{...}ncar!ico!auto-trol!younam 	|