HDTenEightyP/NetNews huggingface dataset:
From: carter@iscnvx.lmsc.lockheed.com (Mark R. Carter)
Subject: Re: Borland C++ 3.0 for Sale
Organization: Lockheed Missiles and Space Co.
Date: Wed, 15 Apr 92 20:27:31 GMT

Sorry for the double post. I meant Borland C++ 3.0 is $69.95 
"out here" in Silicon Valley.

				Mark R. Carter, Ph.D
From: chrism@col.hp.com (Chris Magnuson)
Date: Mon, 13 Apr 1992 16:30:33 GMT
Subject: OO Structured Design Question
Organization: HP Colorado Springs Division
Newsgroups: comp.lang.c++

Is there a *standard* object-oriented structured design notation?  I'm looking
for the object-oriented equivalent of the Yourdon notation from the book
Structured Design for procedural languages.

I have read some articles that use a notation suggested in a book by Rumbaugh,
but I'm wondering if there are others, or if this particular notation is
*non-standard.*

Thanks in advance,
Chris Magnuson
chrism@col.hp.com
From: jamiller@hpcupt1.cup.hp.com (Jim Miller)
Date: Tue, 7 Apr 1992 00:04:12 GMT
Subject: Re: Surprise!! A bug in C for ANY compilor.
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.lang.c++

> zzang@pine.circa.ufl.edu (ZANG)
> I shouldn't say ANY compilor here. It is impossible to
> try all the compilors. I actually tried on the Ultrix4.02
> VMS and BORLANDC++2.0.
> Here is the bug.
> ----------------------------------------------
> /** bug: the scanf() gets() cant be together  **/
> /** fix: move scanf() after gets()  **/
> 

Besides the responses already posted I'd like to add a pedantic note:
the "bug" is not a compiler feature, but a library feature.  No matter
what compiler you use, if you use the same library you'd get the same
behavior.

On any single issue this may not be important, but it is important in
trying to understand "language/compiler" quirks which may pop up in
other places in the compiler vs. "library" quirks which may pop up in other
calls to the library.

Trust me, it can be helpful to understand which is doing a job on your code,
the compiler or the library.


   jim miller
   jamiller@cup.hp.com
   (a.k.a James A. Miller; Jim the JAM; stupid; @!?$$!; ... )
   Anything I say will be used against me ...
   But my company doesn't know or approve or condone anything of mine here.
From: chetl@donald.tamu.edu (Chet Laughlin)
Newsgroups: comp.lang.c++
Subject: Assigning values from an object's private data
Date: 7 Apr 92 23:41:01 GMT
Organization: College of Architecture, Texas A&M University

WARNING: Potential Newbie question.

I am having trouble getting data held inside a C++ Class available
to simple variables using the equals operator.  During compilation,
the compiler does not complain about my class, but does complain
about my assignment statements.  What am I doing wrong?

It seems to me that the compiler would use the 1st equal operator I
defined in the class, but it does not.  I get the following error
message.

Line 26: Cannot convert 'port' to 'int'
---------------------- SOURCE CODE ---------------------
#include <stdio.h>
#include <dos.h>


class port {                            // new class object
  int value;                        	// value for port
  int address;                          // port address
  public:
    port( int newaddr, int newval = 0) {         // class constructor
	address = newaddr;
	value = newval;
    }
    int operator = (class port)          // variable = port(..);
	{ return(value); }
    port operator = (int newval)         // port(...) = variable;
	{ outport(address, newval); return(value = newval); }
};


main()
{
	port myport(0x2F8);      // create a port
	int d;

	myport = 10;             // set port value
	d = myport;              // get port value (error here..)
	printf("%d", d);         // did we get the port value?
	return(0);
}

---------------------------------------------------------------------
| Chet Laughlin                  reply:chetl@archone.tamu.edu       |
| "There is no Computer Science, it is all witchcraft."             |
|                                MIT Math department, 1958          |
| I do not speak for Texas A&M University, and they rarely speak    |
| for me.                                                           |
---------------------------------------------------------------------
~
Newsgroups: comp.lang.c++
From: pete@borland.com (Pete Becker)
Subject: Re: Borland's design decisions
Organization: Borland International
Date: Fri, 10 Apr 1992 16:26:40 GMT

In article <1992Apr9.123716.1061@pictel.com> boba@pictel.com (Bob Alexander) writes:
>
>>>Secondly, Borland extended C++ with dynamic dispatch virtual tables.  Why?
>>
>>	Since there are 64K possible Windows messages, any class that could
>>handle them all would have a rather large vtable.
>
>Several people gave this answer, and it sounds like a pretty good reason.
>But now I'm curious: how do other class libraries for Windows handle this?
>Microsoft's MFCs don't rely on compiler extensions (I think.)  There's
>also a product called zApp that doesn't rely on compiler extensions.
>

	Another way to do it is to build your own association list, mapping
message numbers to functions.
	-- Pete


Newsgroups: comp.lang.c++
From: vinoski@apollo.hp.com (Stephen Vinoski)
Subject: Re: Call by reference using * and &
Organization: Hewlett-Packard Corporation, Chelmsford, MA
Date: Fri, 17 Apr 1992 14:38:26 GMT

In article <ABRAHAM.92Apr16181753@galilei.iesd.auc.dk> abraham@iesd.auc.dk (Per Abrahamsen) writes:
>
>>>>>> On 14 Apr 92 13:57:17 GMT, davisonj@en.ecn.purdue.edu (John M Davison) said:
>
>In article <DOUGM.92Apr14053216@bradbury.cns.caltech.edu> dougm@cns.caltech.edu (Doug McNought) writes:
>Doug> With the address passed explicitly it is clearer that this is a
>Doug> VAR parameter (as we ex-Pascal types say :).
>
>John> No, it isn't.  A responsible C++ programmer will make intelligent use
>John> of the "const" keyword to distinguish between read-only and "write/modify"
>John> access, e.g.
>
>John> int foo(const thing &baz)     baz is read-only, passed by reference
>John> int foo(thing &baz)           baz is writable, passed by reference
>
>That makes it clear from the function declaration, not the function
>call.  Unless you have a rather advanced programming environment, the
>simple rule "do not use non-const references when avoidable" will make
>potential side effects more obvious at the point of the function call.

True, but only to a degree:

extern void bar(Thing *x);

void
foo()
{
    Thing t;
    bar(&t);
}

So far, so good.  We know by looking at the invocation of bar that object t may
be modified.

extern void baz(Thing *x);

void
bar(Thing *x)
{
    // many
    // many
    // many
    // lines of code
    baz(x);
}

Here, x could potentially be changed by function baz, but in this case that
fact is certainly not clear from looking at the invocation of baz.

The only reliable way to determine whether or not a function could potentially
modify its arguments is to look at its declaration.

-steve

-- 
Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Cooperative Object Computing Division
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
From: abraham@iesd.auc.dk (Per Abrahamsen)
Newsgroups: comp.lang.c++
Subject: Re: Call by reference using * and &
Date: 16 Apr 92 17:17:53 GMT
	<DOUGM.92Apr14053216@bradbury.cns.caltech.edu>
	<1992Apr14.135717.7010@en.ecn.purdue.edu>
Organization: HUGIN Expert A/S


>>>>> On 14 Apr 92 13:57:17 GMT, davisonj@en.ecn.purdue.edu (John M Davison) said:

In article <DOUGM.92Apr14053216@bradbury.cns.caltech.edu> dougm@cns.caltech.edu (Doug McNought) writes:

Doug>Some people don't like using references for [deleted] purpose,
Doug>since when reading the code it is not immediately obvious from
Doug>the form of the function call that a variable might be changed by
         ~~~~~~~~~~~~~~~~~~~~~~~~~
Doug>the function.

John> Like when you pass an array in C?

[ I believe C's treatment of arrays is considered a misfeature... ]

Doug> With the address passed explicitly it is clearer that this is a
Doug> VAR parameter (as we ex-Pascal types say :).

John> No, it isn't.  A responsible C++ programmer will make intelligent use
John> of the "const" keyword to distinguish between read-only and "write/modify"
John> access, e.g.

John> int foo(const thing &baz)     baz is read-only, passed by reference
John> int foo(thing &baz)           baz is writable, passed by reference

That makes it clear from the function declaration, not the function
call.  Unless you have a rather advanced programming environment, the
simple rule "do not use non-const references when avoidable" will make
potential side effects more obvious at the point of the function call.
Newsgroups: comp.lang.c++
From: nagle@netcom.com (John Nagle)
Subject: Re: C++ Critique (3 of 4) (long)
Date: Fri, 10 Apr 92 17:19:45 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

       Many of his points are well-taken.

       A key point, as is gradually becoming clear, is that a higher
level of language safety than C++ provides is required to support 
software components.  If a user is to use a software component without
looking at its innards, software components must be more than minimally
robust.  Most "reusable software components" for C++ are not really
components, but language extensions which define how the entire program
must be built.  NIHCL and MacApp are examples.  The distinction becomes 
clear when you try to use two such "components" in the same program.

       The notion that pointers are too low-level a construct may be
a good one.  See Hermes for an example of a language without pointers
or arrays.  This idea has not yet caught on but may be the next big
step in programming.  It will take several more languages to get it right,
though.

       Garbage collection is not a real solution for a language with
destructors.  It's adequate for getting memory back, but if important
actions like the release of locks and closing of windows, files, and 
other objects take place at deallocation, deferred deallocation can
produce very strange results.  Reference counts combined with
uncontrolled pointers result in unreleasable circular lists, of course.
This remains a major unsolved problem with pointer-based languages.

					John Nagle
From: grossman@cs.arizona.edu (Ed Grossman)
Newsgroups: comp.lang.c++
Subject: Forward Declaration for typedefs
Date: 7 Apr 92 17:38:29 GMT
Reply-To: grossman@cs.arizona.edu (Ed Grossman)
Organization: U of Arizona, CS Dept, Tucson


I'm using templates fairly intensively, along with typedefs 
to make code easier to read and understand.  I've run into
the problem that if I try to say:

class intList;

where intList is a typedef for list<int>, the compiler thinks I'm 
redefining intList, when in fact I'm merely trying to do a 
forward declaration.  The solution I've come with so far is to
have intList inherit fromm list<int> instead of doing a typedef,
but is there a way of doing a forward declaration of the form I want?

Thanks,
Ed Grossman
From: avs@inf.rl.ac.uk
Newsgroups: comp.lang.c++
Subject: C++ Coding Standards
Date: 14 Apr 92 16:46:03 GMT

Help Wanted

We are involved in a multi institution Office Automation project which 
is using C++.  As we are just starting the coding phase, we are looking for 
any guidelines as to "good" coding style, along the lines of the "AT&T 
Indian Hill C Style and Coding Standards".  While most of these C guidelines 
also apply to C++, there is a lot more syntax to be handled, e.g. class 
declarations.  There is also a number of closely related issues, 
e.g. references vs pointers.

We know from experience that a common style makes code comprehension much 
easier and debugging simpler.  Before inventing our own guidelines, 
or adopting what emerged from earlier projects, we thought we would ask 
if anybody working on large C++ projects could give us guidelines, or even 
stylistic hints that we could develop into a "style standard" or point us 
to the appropriate literature.

Thank you.

Damian Mac Randall (damian@inf.rl.ac.uk)
Anne Shrimpton (avs@inf.rl.ac.uk)
From: Jean_Laviolette@softworx.access (Jean Laviolette)
Newsgroups: comp.lang.c++
Subject: Re: C++ (timesharing)
Distribution: world
Date: 15 Apr 92 00:46:11 PST
Organization: Subterrainian Softworx BBS

In a message dated Tue 14 Apr 92 09:15, Ilan@seas.gwu.edu (ilan Berkner)
wrote:

 IB> I'm basically looking for some sort of C or C++ or Pascal code
 IB> which simulates a mini multiprocessing - timesharing environment on a
PC.

I remember a multi-tasking kernel called CTASK in the simtel archives do do
just that  (Full source).  Sounds like a good starting point at least.


-- Via DLG Pro v0.991
From: cyberman@toz.buffalo.ny.us (Cyberman)
Newsgroups: comp.lang.c++
Subject: Re: Question about classes and interrupt handlers
Date: 16 Apr 92 23:55:07 GMT
Organization: The Tower of Zot - (716)838-0220

sam4628@zeus.tamu.edu writes:
> Is it legal to define a class member function as an interrupt handler
> (MS-DOS using BC++3.0)? If so, does it therefore have to be a public
> function? (this could result in antisocial behavior if someone tried
> hard enough...)  Am I totally clueless and missing an obvious point?
> Thanks in advance for any help on this...

I could UUCODE you an example of this.  It's a serial class.  [it's pretty 
nice in handleing the interrupts] Works nicely you might say!
Cyberman  
 


************************************************************
* Cyberman@TOZ.BUFFALO.NY.US                               *
*   "Life is what you put into it" - Cyberman              *
* Optimistic - running through a barn of manure looking    *
* for the horse!  /\ [] ( )                                *
From: andreww@cscx.cs.rhbnc.ac.uk (Andrew Waters)
Newsgroups: comp.lang.c++
Subject: Re: Gunnar Teege's Emacs C++ class browser
Date: 10 Apr 92 16:37:00 GMT
Reply-To: andreww@cscx.cs.rhbnc.ac.uk (Andrew Waters)
Organization: Dept of Comp Sci, Royal Holloway & Bedford New College Uni London

Try using the machine ftp.informatik.tu-muenchen.de

The file has been updated to version two so you require

/pub/GNU/emacs/contrib/c++-browse-2.tar.Z

Andrew

what .signature?
From: 850347s@aucs.acadiau.ca (Hume Smith)
Newsgroups: comp.lang.c++
Subject: Re: Cricket Program
Keywords: Can't compile it.
Date: 6 Apr 92 20:41:33 GMT
Organization: Acadia University

cobra@chopin.udel.edu (Jay Bhartkumar Patel) writes:

>I got this program from someone and  I can't compile it. 
>I typed in CC crip.cc.  Can someone tell me what is wrong with this program.  

it might work better to type csh crip.cc.  that's csh and awk code.
From: ctan@solomon.technet.sg (Tan Chee Weei)
Newsgroups: comp.lang.c++
Subject: Nested class name and static member
Date: 8 Apr 92 04:21:27 GMT
Article-I.D.: nuscc.1992Apr8.042127.11054
Organization: National University of Singapore

Is there a problem with having nested class and a static data member names
be identical?  For eg.

class X
{
  public:
    class Y {};
    int Y;
};

int X::Y = 0; // initialization of static member

void f(void)
{
  X x;      // defining instance of class X
  X::Y y;   // defining an instance of nested class Y
  X::Y = 1; // setting value of static member
}


Is the above legal?  Using the Sun C++2.1 compiler, the initialization
and assignment of the static member are reported as syntax errors.
If not, can anyone direct me to the section in the ARM which says it isn't?
Somehow, despite the fact that they both share the same name, one a type and
the other a declarator, isn't its usage here unambiguious?  Also, is the
ordering of which declaration (nested class or static member) important?
In the following:

class X
{
public:
  class Y { };
  static int Y;
};

void f(void)
{
  X x;
  x.Y = 2;
}

The compiler complains that the Y in X.Y is undefined ("Y__1X undefined").
However, switching the order of the nested class and static member declaration
fixed the problem.  

Thanks in advance for any assistance.

CW
From: acoles@bwdls59.bnr.ca (Andrew Coles)
Newsgroups: comp.lang.c++
Subject: Virtual function problem/warning
Date: 14 Apr 92 19:14:41 GMT
Reply-To: ACOLES@BNR.CA
Organization: BNR Woodline, Ottawa

Sorry, I screwed up on the posting of this problem.  There are actually three
virtual functions, each give the same warnings (code does run though)

Here's the corrected version of this problem...



class clEditableListWidget : public clWindow
   {
   ..... ....
   public:
         virtual   void       NewSearchInformation (obj_idst proKey);
         virtual   void       NewSearchInformation (personst *info);
         virtual   void       NewSearchInformation (pr_edst *info);

   ..... ....
   };

file clEditableListWidget.cpp - the other two virtual functions do the same
   {
   .... .....

      void   clEditableListWidget :: NewSearchInformation (pr_edst *info)

      {
         // For lint...
         if (info) {}
      }
   .... .....
   }




Warning compiling this class....

class clCilDatasetsELW : public clEditableListWidget
   {
   ..... ....
   public:
         void            NewSearchInformation (pr_edst *info);
   ..... ....
   };

file clCilDatasetsELW.cpp
   {
   .... .....
      void clCilDatasetsELW :: NewSearchInformation (pr_edst *info)
      {
         ..... ....
         ..... ....
      }
   .... .....
   }


I could be blind but I can't see a problem.  Can you?


ACOLES@BNR.CA
From: Garym@qube.OCUnix.On.Ca (Garym)
Newsgroups: comp.lang.c++
Subject: overloading [] for bitvectors?
Distribution: world
Date: 10 Apr 92 07:25:29 PST
Organization: The QuBE BBS

A few days ago, I passed by a posting here dealing with overloading
the [] and = operators; at the time it didn't seem that important, but
now I wonder.

What I want to do is pure syntactic sugar, but it would be very nice
and a noble gesture of implementation hiding.  I have a bit-array class
to store large lists of bit values in a compact form, and in a nutshell
what I would like are statements like the following:

     bitvector[17] = TRUE;
     if (bitvector[3]) do_something();

The rvalue side seems easy, as I can overload [] to compute the byte
index and the mask and shift-right values to reduce the proper byte to
the corresponding bit value to return.  What this would do on an
lvalue is anyone's guess.

For the lvalue, there doesn't appear to be a solution: my C++
reference, Schildt's Complete Reference, only explains overloading [] to
produce a reference value, which would work for bytes and structures
but obviously would not work at the bit level.

My next guess would be to make [] return the reference to the byte,
and then overload =, but I don't see how '=' can know the [] index
needed to compute the mask and bit-shift, and this would complicate
the rvalue.

For the moment, I am using getBit(bit) and setBit(bit,value) member
functions and I fear I may be stuck with this, but I would really
prefer to use these bit-vectors like any other array.  Any suggestions?

-- Via DLG Pro v0.991

    Gary Lawrence Murphy -- Garym@qube.ocunix.on.ca -- (613) 230-6255
      -------------------------------------------------------------
  "The view from the high mountain is worth the climb" - Dr. Morita Shoma
Newsgroups: comp.lang.c++
From: pete@borland.com (Pete Becker)
Subject: Re: Borland's design decisions
Organization: Borland International
Date: Mon, 13 Apr 1992 17:20:41 GMT

In article <3340@daily-planet.concordia.ca> strider@concour.cs.concordia.ca (GEORGAKAKIS peter) writes:
>
>Maybe not, but it would be usefull to have.  You position yourself to
>the element and start inserting/removing/(insert favorite operation).
>
>I view iterators as objects that maintain currency on a collection and
>tell the collection what what current element they are pointing to
>when queried by the collection.  Furthermore collections know what
>iterators are iterating over them and can properly adjust the
>iterators when necessary (that is when the collection is modified).
>

	Suppose you have an unordered collection of objects with an open
iterator on that collection.  If you insert a new object into that collection,
what is the correct behavior of that iterator with respect to that object?
i.e., will the iterator give you back that object before reaching the end
of the collection or not?  Can you specify the behavior of that iterator in an
implementation-independent manner without imposing excessive overhead on the
container and the iterator?
	-- Pete
From: ges@stiatl.salestech.com (Gerald Sullivan)
Newsgroups: comp.lang.c++
Subject: Re: Borland's design decisions
Date: 8 Apr 92 13:48:27 GMT
Organization: Sales Technologies, Inc.

boba@pictel.com (Bob Alexander) writes:



>I have been reading up on Borland's class library and application frameworks,
>and I'm curious about two of the design decisions they made.  I'm sure they
>must've had good reasons for what they did, but I don't see them.

>In the class libraries, they have a doubly-linked list object.  They have
>member functions that delete from either end of the list, but it seems
>there's no way to remove an item from the middle of the list.  I always
>considered that ability to be one of the great advantages of doubly
>linked lists.  Why leave it out?

They probably forgot. We are using Commonvu 2.0 and have run into many similar
situaions (ie unable to insert into first position of a list, unable to
insert at an arbitrary position in a list, 
unable to get the parent of a window). I think these types of ommisions
indicate a lack of maturity in libaries. I often wonder if anyone has actually
used Commonvu 2.0 for commercial development beyond "hello world" programs.

>Secondly, Borland extended C++ with dynamic dispatch virtual tables.  Why?
>Why not just just create virtual member functions like WMLButtonDown that
>always receive a particular message and that the user can override?  What
>do DDVTs add that is so worthwhile as to justify a non-standard extension
>to C++?

I can see one great advantage for Borland. Nonportability. They distribute
library source for OWL. They use the nonstandard dispatching mechanisms. Now
OWL and all code written using it cannot be compiled with any other compiler.
You cannot use any other compiler, ever. I think this is very bad. On the
other hand, Borland seems to have a decent product and doesn't seem likely
to disapear soon.

>Thanks,
>     Bob Alexander                                     boba@pictel.com
-- 
___________________________________________________________________
Jerry Sullivan, Sales Technologies, Inc.  Atlanta,GA 
ges@salestech.com,...uupsi!stiatl!ges I don't speak for my employer.
Withdrawing in disgust is not apathy. Vote none of the above.
From: wbos@uhura.cc.rochester.edu (Wayne Bosma)
Newsgroups: comp.lang.c++
Subject: Another thing on C++ books
Date: 9 Apr 92 16:33:04 GMT
Organization: University of Rochester (Rochester, NY)


There have been some recent questions on C++ books posted, so here's my 
perspective, and another question.

I've purchased H. Schildt's "C++  The Complete Reference" (Osborne Mcgraw-Hill,
1991, based on version 2.1 of the language).  I am not an accomplished C 
programmer, and so I like the fact that it is separated into a part with C-like
features and a part with features exclusive to C++.  It is furthermore a fairly
pedagogical book.  I like it, so far.  Now for the question:  Does anybody know
of any significant errors/misstatements in this book?  There are two reasons
for my asking this:

1)  It's the first edition ( ==> possible typos )
2)  Part one is a condensed version of "C:  The Complete Primer" 
 ( ==> Possible inclusion of C-like features of C++ which are not there). 

I certainly have found no such problems (unless the answer to my previous
post is "no"), but if somebody else has, I'd appreciate knowing what they are.


					Wayne Bosma
					University of Rochester
					Department of Chemistry

appreciate knowing about it.
Newsgroups: comp.lang.c++