HDTenEightyP/NetNews huggingface dataset:
From: steven@monu6.cc.monash.edu.au (Steve Stergakis)
Newsgroups: comp.lang.c++
Subject: INFO NEEDED on OOA Methodologies
Date: 8 Apr 92 09:34:20 GMT
Organization: Monash University, Caulfield Campus


NOTE: this message has been posted for persons that either use, teach 
or have some opinion regarding current OOA methodologies being 
used...

THIS MESSAGE HAS BEEN CROSS POSTED TO MANY NEWS GROUPS.  PLEASE 
DISREGARD IT IF HAS BEEN POSTED TO AN INCORRECT AREA.

i am a postgraduate student who is currently studying OOA and 
would greatly appreciate any information regarding experience
you have had with object oriented methodologies

as i am about to write a critical review of the current OO methodologies i 
would appreciate if you could tell me which approach you prefer.. or if
you know of any article that have compared current OOA methods, that would
also be greatly appreciated...

i am especially interested in persons who use such methodologies 
in practice.. their extent of their use in your work area.. 
the type of work you do.... and your opinion!

PLEASE feel free to comment on any of the above questions.. if you do
not wish to relate specific information pertaining to your work /
work environment, then leave it out

NOTE: if possible please reply directly to me 

thanks in advance

+------------------------------------------------------------+
| Steven Stergakis      steven@monu6.monash.cc.edu.au        |
|                                                            |
|                       (Post Graduate)                      |
|                       Faculty of Computing and Information |
|                       Technology                           |
|                                                            |
|                       Monash University - Australia        | 
+------------------------------------------------------------+
From: rmartin@willing.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: OO paradigms for control structures?
Date: 6 Apr 92 16:33:47 GMT

rantapaa@s10.math.umn.edu (Erik E. Rantapaa) writes:

>Consider the following code which implements an interpreter for a simple
>machine language:

>  int a;

>  while ((c = getchar()) != EOF) {
>    switch(c) {
>      case '0': case '1': ... case '9':
>        a = c - '0'; break;
>      case '+':
>        a++; break;
>      case '?':
>        printf("%d\n", a); break;
>      default:
>        perror("illegal instruction\n"); break;
>    }
>  }

>I'd like to treat this interpreter as a class so that I can create
>variants of it which can inherit, redefine and add to the actions
>of parent classes.  

Try this:

class Interpreter;

void interpret(Interpreter& i)
{
    while (cin)
    {
	char c;
	cin >> c;
	switch(c)
	{
	  case '0':
	  case '1':
	    .
	    .
	    .
	  case 9:
	    i.digit(c);
	    break; 

	    case '+':
	    i.add();
	    break;; 
	    
	    case '?':
	    i.print();
	    break;
	    
	    default:
	    cerr << "Illegal instruction" << endl;
	    break;
	}	    
    }
}

Interpreter is an abstract base class with at least the following pure
virtual methods:  digit(char), add() and print().  You can derive many
different interpreters from this class.  

I recently wrote encountered a problem where I had to use the same
gramatical syntax to solve two very different problems.  I wrote a
yacc++ parser for the grammar, and used the above idiom to interface
the parser to the two different behaviors.




--
+---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting         |
| rmartin@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering    |
|     (Uncle Bob.)     |-RRR--C----M--M--M-| OOA/OOD/OOP Training      |
+----------------------+-R--R--CCC-M-----M-| Product Design & Devel.   |
Newsgroups: comp.lang.c++
From: mcgrant@isl.stanford.edu (Michael C. Grant)
Subject: Adding infix operators to C++
Organization: Information Systems Laboratory, Stanford University
Date: 13 Apr 92 17:17:08


Has anyone besides myself longed for a much wider range of overloadable
infix operators in C++?  Personally, I would like to be able to overload
\ , .* , ./ , .*., @, #, or basically any symbol whose purpose has not
yet been nailed down. I understand that there are certainly limitations to
the forms that such operators could take, defined by the limits of the 
ability of the C++ compiler to store them/parse them/translate them. But,
certainly it would not have been difficult to add even add limited 
abilities to do the above. I'm tired of being nailed down to the few
operators that are already used for other purposes in C++!

If this hasn't been submitted to the appropriate ANSI channels before, I'd
love to converse with someone about what it would take to draw up a proposal
for such an extension. Any E-mail or News correspondence would be appreciated.

Michael C. Grant
Information Systems Laboratory
mcgrant@isl.stanford.edu
From: cox@cbnewsm.cb.att.com (michael.cox)
Newsgroups: comp.lang.c++
Subject: Re: Can any MSDOS C compiler handle big files?
Date: 15 Apr 92 20:19:31 GMT
Distribution: usa
Organization: AT&T

In article <664@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
>In article <1992Apr10.043730.26451@m.cs.uiuc.edu> jyelon@dante.cs.uiuc.edu (Josh Yelon) writes:
>/Is there any MSDOS C compiler that doesn't say "error: code segment
>/too large" when you give it a big source file? 
>/This is absurd behavior for a compiler. Code segments and other
>/machine-specific details are the compiler's job --- That's what I use
>/a compiler for! "Code segment too large" is nothing but a glorified
>/compiler bug.
>
>One of the consequences of C being close to the machine is that not only
>do you pick up performance, but you pick up the machine limitations.
>If you are compiling for a 16 bit target, you are simply going to have
>problems with various 64Kb limitations. To make that go away,
>o	Use a higher level language than C.
>o	Use a 32 bit target (possible under DOS with some compilers)

Sounds like you might be using small memory model (the default on most
compilers).  Using the medium or large memory model will put the code
generated from each file in a different 64K code segment, e.g. MYCODE.C
code is put in segement MYCODE_TEXT.

If you're already using medium/large memory and you have a single file
generating a code segment >64K, you need to break up that source file
into multiple source files.  IMHO, a source file that generates >64K
code probably has major maintainability problems.

-- 

==========================================================================
Michael H. Cox			ARPA:  cox@garage.nj.att.com
AT&T Bell Labs			UUCP:  ihnp4!edsel!cox
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (Tim Lister)
Subject: Re: Borland's design decisions
Organization: Uni Computing Service, Uni of Sydney, Australia
Date: Tue, 14 Apr 1992 19:10:15 GMT

In article <1992Apr8.003300.20919@borland.com> pete@borland.com (Pete Becker) writes:
>In article <1992Apr2.131624.245@pictel.com> boba@pictel.com (Bob Alexander) writes:
>>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++?
>>
>
>	You could create a base class that responded to every possible Windows
>message, but you'd have to provide 64K identical functions, each calling
>DefWindowProc().  Then your derived class could override the ones that were
>appropriate.  Now you've got two rather large vtables...
>	-- Pete
>
Pete, IMHO your explanation is inadequate. I have a window management 
mechanism that handles messages and doesn't use DDVTs or 64K.
The method:
 1) define a basic class with say messages 1-10 decoded by a switch
    and calling 10 virtual functions. All other messages go to
    MyDefWinProc, which is virtual. All these virtuals call DefWindowProc().
 2) Just use it. Now wait, you want to use message 11?
    OK, two methods:
    a) Override MyDefWinProc to filter out message 11, else call 
       immediate base class version of MyDefWinProc.
    b) Same as above, but instead of doing it on the fly, package it
       away for reuse.

In effect, this does the same as a DDVT, but the code is written in C++
not 8086 assembler. It is not as fast, requires more user support,
won't work with existing windows etc, but it doesn't require
any non-standard language, and it doesn't require 64K.

I ask for opinions on Borlands language extension.
Pete, perhaps you might post a proper explanation of the syntax and its
purpose for those not using BC.
Please email me, I'll summarise in a few weeks.

 John Skaller, Maxtal P/L.



Newsgroups: comp.lang.c++
From: jrk@nittany.tcs.com (John Koper)
Subject: Coverage analysis on Sun
Followup-To: comp.lang.c++
Keywords: C++ coverage analysis Sun
Organization: Teknekron Communications Systems Inc.
Date: Wed, 8 Apr 1992 16:57:51 GMT

Hello,

I am trying to gather test coverage information for a C++ program.  Basically,
I want to see which member functions are being executed in each class.

I am aware of a tool called "tcov" available on the Sun's which I have
successfully used for C programs with useful results.  However, when I
compiled  (using Sun's C++ compiler with the "-a" flag to count how many times
each basic block is executed) and ran my C++ program I got the following error
message:

<correct program output>
count: Could not open /tmp/C++.3594/testC.d, errno 2


It looks like the C++ compiler generates a temporary directory where
it store various files it needs to compile the code.  This directory
is removed after the compilation phase is complete.  At run-time, the
program expects the C source file to be in that directory but it isn't
and the logging information is lost.

The trivial C++ program I am using as an example follows:

// begin
#include <iostream.h>

class foo {
public:
        void MemberA() {cout << "A" << endl;};
        void MemberB() {cout << "B" << endl;};
        void MemberC() {cout << "C" << endl;};
};

main()
{
        foo *bar = new foo;

        bar->MemberA();
        bar->MemberA();

        bar->MemberB();
}
// end


I searched the cc and CC man pages but did not find any useful information
about how to solve this problem in either.

I could get coverage information by profiling the code (with the "-pg" flag)
and then running "gprof" and searching for 0% run-time but I would rather
use "tcov" (it is much cleaner).

If you have any ideas of what I may be doing wrong, suggested work-arounds,
or if what I am attempting is even possible I would appreciate hearing about
it.

thanks in advance,
-----------------------------------------------------------------------------
John Koper				| jrk@tcs.com
Software Engineer			| 2121 Allston Way, Berkeley, CA 94704
Teknekron Communications Systems, Inc.	| (510) 649-3592
From: acoles@bwdls59.bnr.ca (Andrew Coles)
Newsgroups: comp.lang.c++
Subject: Borland support
Date: 14 Apr 92 14:17:44 GMT
Reply-To: ACOLES@BNR.CA
Organization: BNR Woodline, Ottawa

I`ve been trying for the past 3 days to get borland technical support.
All I get is being on hold for 1/2+ an hour...long distance.

Does anyone know if Borland supports their products on Compuserve, email or
FAX besides the dreaded telephone?


ACOLES@BNR.CA
Newsgroups: comp.lang.c++
From: pete@borland.com (Pete Becker)
Subject: Re: Borland's design decisions
Organization: Borland International
Date: Mon, 6 Apr 1992 16:23:25 GMT

In article <1992Apr2.131624.245@pictel.com> 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?
>
	The function detach() will do what you want.

>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++?
>

	Since there are 64K possible Windows messages, any class that could
handle them all would have a rather large vtable.  Since almost all of those
messages are handled by the default handler, there would be a lot of redundant
information in the vtable, as well.  DDVTs, in effect, tell the compiler to
generate a sparse array to hold dispatching information, rather than filling
in all those default entries.
	-- Pete
From: npw@coos.dartmouth.edu (Nicholas Wilt)
Newsgroups: comp.lang.c++
Subject: Re: tree iterator, how?
Date: 15 Apr 92 13:12:14 GMT
Organization: Dartmouth College, Hanover, NH

In article <10245@goanna.cs.rmit.oz.au> dmh@goanna.cs.rmit.oz.au (Darren Hosking) writes:
>I've got a simple binary tree class that I'd like to iterate through with
>an iterator class. Each node of the tree maintains data and a left and right
>node pointer. How can I write an iterator class for the tree class?
>
>Without a class I can simply use recursion to traverse the tree but I cannot
>put recursion into a class (can I?).

If you include a parent pointer in each node, you can iteratively go to
the predecessor or successor of a given node.  It works something like this
(duplicating out of my head from my template-based binary tree class):

BinaryNode<T> *
Minimum(BinaryNode<T> *x)
{
  while (x->left)
    x = x->left;
  return x;
}

BinaryNode<T> *
Successor(BinaryNode<T> *x)
{
  if (x->right)
    return Minimum(x->right);
  BinaryNode<T> *y = x->parent;
  while (y && x == y->right) {
    x = y;
    y = y->parent;
  }
  return y;
}

Precedessor code is symmetric.

Reference: _Introduction to Algorithms_ by Cormen, Leiserson and Rivest

--Nicholas Wilt
  npw@coos.dartmouth.edu

>	Thanks in advance, dmh
>
>Darren Hosking			ACSnet: dmh@goanna.cs.rmit.oz	 
>Department Of Computer Science	ARPA:   dmh%goanna.cs.rmit.oz.au@uunet.uu.net
>RMIT				CSNET:  dmh%goanna.cs.rmit.oz.au@australia
>GPO Box 2476V			UUCP:   ...!uunet!goanna.cs.rmit.oz.au!dmh
>Melbourne Vic., Australia 3001	PH: +61 3 660 3299 FAX: +61 3 662 1617
From: tmb@ai.mit.edu (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: good and bad points of C++ (was: C++ Critique (1 of 4) (long))
Date: 12 Apr 92 09:36:29 GMT
Organization: MIT Artificial Intelligence Lab
In-reply-to: ian@syacus.acus.oz.au's message of 8 Apr 92 11:52:59 GMT

In article <1992Apr8.115259.16238@syacus.acus.oz.au> ian@syacus.acus.oz.au (Ian Joyner) writes:
> A C++ Critique by Ian Joyner
> [many comments about the deficiencies of C++]

My conclusion is that you would probably be happier with Eiffel. It
seems to address all your complaints. But I think some of the
suggestions you make, which you claim are more in an OO-style and
actually have been adopted in Eiffel, would make C++ much less useful.

The major deficiencies I see in C++ (many of which you also point out)
are the lack of a hierarchical module/environment system, the lack of
runtime range- and type-checks, the absence of a garbage collector,
and the lack of closures (the C++ class concept can compensate
partially for some of these deficiencies, but that is an imperfect
solution).

On the other hand, the large number of small syntactic and semantic
quirks that C++ undoubtedly has, and which figure so prominently in
the complaints of many people about C++, don't really bother me that
much. I care primarily about the functionality that a programming
language provides; learning where to put parens and semicolons is
pretty trivial.

What makes C++ useful to me is the fact that it generates code that
performs acceptably, that it supports true polymorphism (in the form
of templates), exceptions, and overloading (which is very useful for
numerical programming), and that it has a convenient "foreign function
interface".

Interestingly, the OO component of C++ is of little importance to me.
After having programmed both in OO and non-OO programming languages
for many years, I have come to the conclusion that inheritance and
virtual functions are not very useful for most kinds of programming.
The major exceptions are graphical user interfaces, simulations, and
certain kinds of data bases; however, such applications are probably
better served by a concurrent, message-passing approach, rather than a
strict OO approach.

Furthermore, the OO approach to ADT's leads to monolithic type
hierarchies and very unpleasant name conflicts that actually inhibit
software reuse. I think these fundamental problems with the OO
paradigm will ultimately spell the end for C++ and many other OO
languages that are being touted as the solution to the "software
crisis". Personally, I suspect that a functional approach together
with a powerful module system (along the lines of SML) is a much
better approach to ADT's. But for the time being, C++ is an acceptable
compromise and a very useful tool.

					Thomas.


Newsgroups: comp.lang.c++
From: timk@wynnds.xenitec.on.ca (Tim Kuehn)
Subject: Re: A really good way to do this is?
Organization: TDK Consulting Services
Date: Thu, 09 Apr 1992 23:07:59 GMT

In article <1992Apr8.004446.3033@ncsu.edu> easchwei@eos.ncsu.edu (ERIC ARNOLD SCHWEITZ) writes:
[stuff deleted...]

>each time a member function is called a hidden member function,
>eg. an access function, is called and when the member function
>exits a `deaccess' function is called.  

>Anyhow, if I do a ``obj.spill_guts();'' call I'd like the object
>to fix its location in memory, do whatever it was supposed to do,
>and then free itself to walk around memory again.  There seem to
>be some simple approaches, such as forcing the user to call an
>``access'' and ``de-access'' function before and after each call.

Here's an example: 

class lock_obj	{
    public:
	virtual void spill_guts(void );

    private:
	void access(void );
	void deaccess(void );

    };


void lock_obj::spill_guts(void)
{
access();

/* spill guts code in here */

deaccess();
};

lock_obj::access and lock_obj::deaccess would be defined to do whatever
you wanted them to do.

So, when you go:

class inh_obj: public lock_obj {
    public: 
	virtual void access(void );
	virtual void deaccess(void );
   };

the new methods access() and deaccess() won't over-ride the corresponding
methods in the parent class lock_obj.

+-----------------------------------------------------------------------+
| Tim Kuehn | TDK Consulting |(519)-888-0766| timk@wynnds.xenitec.on.ca |
| <><       | Services       |	       	    |  (This space for rent)    |
+-----------------------------------------------------------------------+
From: lcp@fig.citib.com (Larry Poleshuck)
Newsgroups: comp.lang.c++
Subject: Re:    COOL for cfront 2.1
Date: 15 Apr 92 18:13:00 GMT
Organization: Citibank IBISM
Originator: lcp@hen


In article <92101.113736MPACE@ESOC.BITNET>, <MPACE@ESOC.BITNET> writes:
|> I'd like to know if some of you knows about the public availability
|> of COOL for cfront 2.1 (and, why not, cfront 3.0).
|> 
|> I have COOL for cfront 2.0 and had problems to compile
|> it with 2.1, so I gave up trying that.
|> 

We have built the 2.0 COOL on Sun's cfront 2.1 C++ compiler, with just a
few minor modifications to the library.  Specifically, a few type
casts were required on system functions.

I did have a problem getting the container destructors to call our own
class's destructors -- when using containers of my own type (e.g.
List<foobar>).  It turned out that the developers had commented out the
"virtual" keyword on the destructor of the Generic base class (the comment
referenced 1.2 problems).  Also two or three base classes which do not
inherit from Generic (e.g.  List_Node) needed an explicit virtual
destructor.

In order to get the best support from the sun debugger (dbxtool), I am
using Sun's CC rather than COOL's CCC.  This requires telling CC to use the
COOL cpp (-Qpath) and requires using the DECLARE, IMPLEMENT method for
compiling class methods rather than the -X method.

I have reviewed (and bought) several commercial class libraries.  I have
found COOL to be by far the best of the lot.  It supports a type checking
interface (via templates) rather than a Smalltalk-style interface.  It
requires minimum intervention in your own classes (you provide =, ==, <, >
and << operators -- it does the rest.  And it a full set of methods and
features.  My compliments to its designers and implementors at TI!

I would be very interested in hearing from anyone else who is using COOL.
What have been your experiences porting it to other platforms (e.g.
RS/6000 and HP)?  Would you be interested in sharing modifications?  Is
there a mailing list of interested parties?


=============================================================================

Larry Poleshuck
Citibank
111 Wall Street
New York, NY  10043

Phone:  212-657-7709
Fax:    212-825-8607
E-Mail: lcp@fig.citib.com
-- 
=============================================================================

Larry Poleshuck
Citibank
Newsgroups: comp.lang.c++
From: diessel@informatik.unibw-muenchen.de (Thomas Diessel)
Subject: Re: Gunnar Teege's Emacs C++ class browser
Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
Date: Fri, 10 Apr 1992 12:12:26 GMT

brianw@philips.oz.au (Brian Wallis) writes:

>Does anyone know much about this?

>I read somewhere that it should be ftp'able from ftp.informatik.tumuenchen.de
>in the file /pub/GNU/emacs/contrib/c++browser91.tar.Z.

>Unfortunatly I can't even find the machine!
It should read:
ftp.informatik.tu-muenchen.de
                 ^
But I don't know whether it is really available there.

; <<>> DiG 2.0 <<>> ftp.informatik.tu-muenchen.de any any
;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 7
;; flags: qr rd ra ; Ques: 1, Ans: 1, Auth: 0, Addit: 0
;; QUESTIONS:
;;      ftp.informatik.tu-muenchen.de, type = ANY, class = ANY

;; ANSWERS:
ftp.informatik.tu-muenchen.de.  86400   CNAME   dsrbg2.informatik.tu-muenchen.de
.

;; Sent 3 pkts, answer found in time: 2831 msec  sent 1 too many pkts
;; FROM: gretchen to SERVER: default -- 137.193.60.44
;; WHEN: Fri Apr 10 14:14:22 1992
;; MSG SIZE  sent: 47  rcvd: 93

; <<>> DiG 2.0 <<>> dsrbg2.informatik.tu-muenchen.de
;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 7
;; flags: qr aa rd ra ; Ques: 1, Ans: 1, Auth: 0, Addit: 0
;; QUESTIONS:
;;      dsrbg2.informatik.tu-muenchen.de, type = A, class = IN

;; ANSWERS:
dsrbg2.informatik.tu-muenchen.de.       86400   A       131.159.0.110

-----
Thomas Diessel
Federal Armed Forces University, Munich  -  Computer Science Department
Werner-Heisenberg-Weg 39  -  W-8014 Neubiberg
Germany
--
Thomas Diessel
Federal Armed Forces University, Munich  -  Computer Science Department
Werner-Heisenberg-Weg 39  -  W-8014 Neubiberg
Germany
Newsgroups: comp.lang.c++
From: blk@mitre.org (Brian L. Kahn)
Subject: Initializing static class members?
Organization: The MITRE Corp. Bedford, MA
Distribution: comp
Date: Thu, 2 Apr 1992 18:19:55 GMT


I can't find a good way to initialize my static class members.  I want
to have some structures with data in them for one of my classes, but I
am prevented from using the initializer syntax of
  static int serveMeans[MACHINES][PARTS] = {{6, 1}, {5, 3}, {0, 2}};
which I would like to use.  I do not want to write a class initializer
to copy a constant declared in the initializer routine into a static
member because of the complexity of some structures and the ugliness
of that approach.  I am currently using globals for what should be
static class members.

There may not be a nice solution, but can anyone explain why C++ won't
allow the initializer form for static members?  I just don't
understand the difficulty, and it looks consistent with C syntax.

--
B<   Brian Kahn   blk@security.mitre.org   "may the farce be with you"

Newsgroups: comp.lang.c++