HDTenEightyP/NetNews huggingface dataset:
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: feedback wanted on appropriate OOPL
Organization: Rational
Date: Sun, 10 Jan 1993 14:00:55 GMT

Regarding Smalltalk and C++ and the different styles used in each.

I learned OOP in 1985 by studying Goldberg's Smalltalk-80 books and
obtaining a Smalltalk compiler.  I learned C++ in 1986 by reading
Stroustrup's book and eventually playing with cfront. 

While I find that there are gross differences in the languages, and
that they do indeed promote different styles of programming.  I also
note that they are unified under the concept of Object Oriented
Design.

The *General* principles of OOD apply equally to C++ and stalk.
Certainly there are specific aspects of OOD which do not, such as MI.
But the mainstream concepts are equally applicable.  It is quite
possible to design an application using OOD and then implement it
either in stalk or C++.

This issue, imho, is far more importnat than the style that stalk or
c++ engenders.  If the style of the application is driven by the
language being used, it implies that the application was not designed.
The style of the application should be driven by the design.  The
effects that the language has on that style should be peripheral, and
not very significant.

A language can have a significant impact, however, on quality,
run-time efficiency and coding efficiency.  C++ will certainly catch
more programmer errors than stalk, and probably generate faster code.
But stalk's incremental environment is a joy when one or two guys are
in fast prototype mode.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: gajdos@hpavla.lf.hp.com (Larry Gajdos)
Date: Tue, 5 Jan 1993 22:07:32 GMT
Subject: Re: Borland C++ 3.1 problem under DOS
Organization: Hewlett-Packard Little Falls Site
Newsgroups: comp.lang.c++

In comp.lang.c++, skwok@nyx.cs.du.edu (Stephen Kwok) writes:


> I have installed Borland C++ 3.1 on my PC, but I have problem when 
> running BC.EXE under DOS, my machine will hang whenever I run BC.EXE.
> But when I start up the compiler under Window 3.1, I believe it is 
> BCW.EXE, it works.  Any idea or comment on what the problem is?

> Machine config:  Intel 486DX-33, 8M memory, Trident TVGA 8900C, 200M HD

> Thanks for any help in advance.

BC uses its own DPMI server when not running under windows and uses
Windows' DPMI server when it is running under windows. The main README
file (my install put it in the \borlandc directory) talks about DPMI
a little and gives some instructions for using a program called DPMIINST
to install your machine into the server's database.

I haven't had any problems so I can't give you any first hand info,
but this seems like an excellent place to start. Borland's tech support
should be helpful on a problem of this nature, as well!

Larry Gajdos
Not speaking for HP
From: wanling@swl.spec.ptg.sony.co.jp (Quak Wan Ling)
Newsgroups: comp.lang.c++
Subject: 0-mode file created with ofstream
Date: 5 Jan 1993 19:32:12 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

I am new to C++ programming and was trying out the filecopy program
in the "The C++ Programming Language, 2nd edition" on a SGI running 
AT&T C++ 2.0.

When I copy a file to a *non-existing* file, the new file that is
created has mode 0. It is the same when I specify

	ofstream	dest(argv[2], ios::app);

If the destination file already exists, then I do not have any problems.

Can anyone please tell me how to create a new file with, say, for example,
mode 644 ?

Thanks in advance.

------------------
Quak Wan Ling
wanling@swl.spec.ptg.sony.co.jp
------------------

Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Restatement and clarification of "static inheritance" question
Keywords: inheritance
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 11 Jan 1993 04:55:42 GMT

In article <1ipp5oINNg0e@news.cerf.net> hlf@nic.cerf.net (Howard Ferguson) writes:
>In article <1993Jan9.154850.5939@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>>In article <1ikg2tINN2d3@news.cerf.net> hlf@nic.cerf.net (Howard Ferguson) writes:
>>>>>WHAT I AM INTERESTED IN IS THE FUNCTIONALITY OF "COUNTING ONE'S
>>>>>OWN INSTATIATIONS", NOT COUNTING THE TOTALITY OF ALL INSTATIATIONS OF
>>>>>CLASS A. 
> -- stuff deleted --
>>>
>>>I still do not see a reason for inheritance when containment will do.
>>>Can anybody clarify this???
>>>
>>
>>	Sure. If you use containment you end up counting
>>subobjects of the base classes too:
>>
>>	class X { A<X> ax; };
>>	class Y { A<Y> ay; };
>>	class Z { A<Z> az; };
>>
>>	Z z;
>>
>>// WOOPS: now we count 1 Z (correct) and 1 X and 1 Y (wrong)
>
>Have you missunderstood, and thought that there is only one static
>created for all of the A's. (I think) you are wrong here. The template
>semantics create one static for each class and A<X> is a different class
>from A<Y> so thge result would be 1 Z , zero X's, and zero Y's.
>
	Sorry: I messed the example!
Try again:

	class X { A<X> ax; };
	class Y { A<Y> ay; };
	class Z {
		A<Z> az;
		X x;		// containment!
		Y y;
	};
	Z z;

Now the count for 'X' objects is 1. 

	class ZZ : public X, public Y { // inheritance
		A<Z> az;
	};
	ZZ zz;

Now the count for 'X' objects is 2.

I'm assuming in this case you want Z==1, ZZ==1, X==0, Y==0?

-- 
;----------------------------------------------------------------------
        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: isc30243@nusunix1.nus.sg (OOI SZU-KHIAM)
Subject: Nu-Mega
Keywords: Nu-Mega
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Sat, 9 Jan 1993 05:37:04 GMT

	Does anyone know how to contact Nu-Mega through the Internet ?

Thanks for any reply. 

Ooi Szu-Khiam@ibmunx.iscs.nus.sg

Newsgroups: comp.lang.c++
From: eddie@alberti.ee.adfa.oz.au (Eddie O'Brien x8191)
Subject: Re: A Fine Beginner's Book on C++
Organization: University College UNSW ADFA
	<1993Jan11.000023.1@email.bony.com>
Date: Mon, 11 Jan 1993 23:14:19 GMT

I haven't seen this particular book but I was once silly enough to buy a
book by Herb Schildt, "Advanced Modula-2". It was my greatest ever waste of
money on a book. It was trite, superficial and specialised in errors. I now
recommend that if the author is Schildt, look for another book.

I agree that the Stroustrup book (2nd Ed.) is good, but a beginner might
find that Lippman's "C++ Primer", 2nd Ed. is more readable. When you get
serious, have a look at Coplien's "Advanced C++ ....".

That was my 1.34 cents worh (well we've dropped relative to the $US).


   Eddie O'Brien          __  /\    Electrical Engineering Department,
                         /  \/  \   University College UNSW,
                        /        \  Australian Defence Force Academy,
 ++61  6 2688191 (w)   /         /  Canberra  ACT  2600.
 ++61  6 2811839 (h)   \   __  */   AUSTRALIA.
 ++61  6 2688443 (fax)  `-'  \_/
 eddie@adfa.oz.au             . 
 
Newsgroups: comp.lang.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: Standard library functions and macros
Date: Fri, 8 Jan 1993 05:21:10 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

It seems to me that, even if the C++ standard prohibits implementing
standard library functions as macros, an implementation could still
allow programs to write something like

   #pragma macros
   #include <stdio.h>

or

   #define __STANDARD_MACROS
   #include <stdio.h>

to get C-style function declarations (external declarations,
possibly masked by macros).

Such an implementation would permit programmers to get the
C-style declarations with one simple change to their programs.
Furthermore, this change could easily be automated if it were
necessary to change a large number of source files.

My guess is that a very small percentage of programs would be
adversely affected by the prohibition of macros, so requiring
the maintainers of such programs to make a small change like
this seems reasonable to me.

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
Newsgroups: comp.lang.c++
From: oper7@ee05.ncu.edu.tw (Anthony Shih Hao Lee)
Subject: TVISION:how to disable a TWindow growing relatively?
Organization: Dep. of EECS, National Central University, Chungli, Taiwan, R.O.C.
Date: Sat, 9 Jan 1993 10:28:34 GMT

Hi, TVS experters:

Look the BC++ IDE, you can find the project window is locked, and cannot
move out the view (it may use dmLimitAll in dragMode) and only growing on
the left side and bottom side ( it may use gfGrowHiX | gfGrowHiY in growMode)
but when I use these features in my own apps, I find that if I put the window
on the bottom of desktop, then I drag the growing box downward, the strange
things happened: the window growing upward. why? do I must clear some bit
to avoid such behavior?
any suggest are welcomed.
tony
-- 
>>> Anthony Li <Li3, Shih4 Hao2><Li:fruit's Name><Shih:Scholar><Hao:Hero>   <<<
<<< Institute of CSEE, National Central Univ, Chungli, Taoyuan, Taiwan, ROC >>>
>>> Internet:	oper7@mbox.ee.ncu.edu.tw	 oper2@ncuee.ncu.edu.tw	    >>>
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: feedback wanted on appropriate OOPL
Date: 11 Jan 93 01:07:38
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<TMB.93Jan10170408@arolla.idiap.ch> <1993Jan10.220917.22879@netcom.com>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: erc@netcom.com's message of Sun, 10 Jan 1993 22:09:17 GMT

In article <1993Jan10.220917.22879@netcom.com> erc@netcom.com (Eric Smith) writes:
>In article <TMB.93Jan10170408@arolla.idiap.ch> tmb@idiap.ch writes:
>>It is only true to say that _at compile time_, C++ will catch more
>>programmer errors than Smalltalk.
>>
>>If you take into account both compile time and runtime, Smalltalk will
>>catch more "programmer errors" than C++: not only will Smalltalk catch
>
>But when is runtime?  When the program starts running, or when it
>encounters unusual data several years after it's put into production?
>
>The advantage of compile time error detection is that all the errors
>that can be caught by the compiler are caught before the program is
>released.

Detecting errors at compile time is better than detecting them
at runtime. But detecting errors at runtime is better than not
detecting them at all.

Unfortunately, the majority of errors that are detectable at all can
only be detected at runtime. C++ has no support for runtime error
checking, and C++ programmers leave out most of those checks (many
couldn't be coded efficiently in user code anyway). That makes
C++ programs relatively untrustworthy, but gives everybody the
illusion that C++ is a "fast" language.

I believe that safety will become of paramount importance in software
over the next decade. C++ will either adapt by mandating more runtime
checks (integer overflow, pointer checks, garbage collection), or
other languages will take over its niche. But even if C++ adapts, it
is still at a disadvantage, since it seems that many runtime safety
features are more expensive to provide in C++ in a way that is
compatible with C++ than in other languages that aren't hampered
by backwards compatibility.

					Thomas.
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.lang.c++
Subject: Re: Dyad M++ Re-compilation?
Date: 8 Jan 93 22:11:35 GMT
Reply-To: bright@nazgul.UUCP (Walter Bright)
Organization: Zortech, Seattle

In article <1993Jan5.134938.9240@syma.sussex.ac.uk> jonesa@syma.sussex.ac.uk (A Jones) writes:
/I've been using the M++ matrix class library for research towards my PhD
/and would have to say that it is very good. However my PC has only 16M
/of RAM and I need to work with ~100M data structures. The library source
/code came with Zortech C++ and I'm wondering if anybody has any leads as
/to the legality of re-compiling the source for a SPARC clone for
/personal use. If so has anybody got a make file to accomplish this?

I believe you are welcome to modify the software for personal use.

/Or the address of Dyad?

Dyad's phone numbers are

(206) 637-9427
(206) 637-9428 FAX
(800) 366-1573
From: buck@siswat.hou.tx.us (Lester Buck)
Newsgroups: comp.lang.c++
Subject: Intel 960 & moving C++ code to new platforms
Date: 10 Jan 93 00:32:25 GMT
Organization: Photon Graphics

A friend needs to port some C++ code to an Intel 960 platform.
He claims that there do not exist any C++ ports yet.  If anyone
knows of a C++ port for the 960, could they please let me know.

Assuming there is no C++ port for the 960, could anyone summarize the
pros and cons of the available development strategies:

1.  License and port cfront to the 960.  (There are C compilers for the
    960.)

2.  Compile the C++ into C on another platform and move the C code
    to the 960.

3.  Any other ideas?

In particular, what is available to demangle C++ names into better
names to allow the use of existing C debuggers on the 960?  Some
debugging will have to occur on the 960 itself.

Thanks alot!

-- 
A. Lester Buck   buck@siswat.hou.tx.us   ...!uhnix1!siswat!buck
From: mm@FileServ1.isc (Martin Malich)
Newsgroups: comp.lang.c++
Subject: Sniff1.6 / fonts ?
Date: 12 Jan 1993 12:08:09 GMT
Organization: Sun Microsystems
Distribution: world
Reply-To: mm@FileServ1.isc
NNTP-Posting-Host: fileserv1.mi.uni-koeln.de


Hello,

I`m working with Sniff 1.6 and would like to use other fonts and colors than 
the default ones. Can somebody give me some hints?


Thanks,
Martin



*****************************************************************************
   Martin Malich                                Tel.: 	++49-221-470-2210  
   mm@risc3.mi.uni-koeln.de
   Mathematisches Institut   		        
   University of Cologne    			Fax.: 	++49-221-470-5160
   Weyertal 80           
   D-5000 Koeln 41          			privat:	++49-212-55439
   Germany                              
*****************************************************************************
From: dayne@cc.usu.edu (869883 Medlyn)
Newsgroups: comp.lang.c++
Subject: C++ ouput problem
Keywords: C++,c++
Date: 11 Jan 93 19:42:41 GMT
Reply-To: dayne@cc.usu.edu (869883 Medlyn)
Organization: Digital Equipment Corporation

I have a 10 line C++ program that does not work.  The program is as follows:

#include <stdio.h>
#include <stream.h>

main()
{
int j;

cout << "Enter value j: ";
cin >> j;

// problem:: printf statement does not put output on the screen.
printf("%d\n",j);  // or any printf statement
}

The output for this program looks like this:

localhost> a.out
Enter value: 1
localhost>


I am running NS 3.0 using the libg++-1.39.0 g++ libraries that I have been able to install.  Anybody have any idea what the problem is or what a fix might be or has anyone even had this problem?  Thanks

Dayne Medlyn
dayne@cc.usu.edu
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: static "inheritance" question
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 5 Jan 1993 05:19:40 GMT

In article <1993Jan4.144320.5586@dayfac.cdc.com> pault@dayfac.cdc.com (Paul Thompson;DAYFAC-ITS;) writes:
>Consider class A which counts its 'live' instantiations.
> 
>            class A { 
>                static int nr;
>              public:
>                A() {nr++;}
>               ~A() {nr--;}
>                int getNrInstances () {return nr;}
>            };
>            ...
>            A::nr = 0;
> 
>A has useful functionality which I would like to use in other
>classes with MINIMAL change to the other classes. One way
>is to try:
> 
>    class B :public A { ....};
>    class C :public A { ....};
>     ...
>    B b1, b2, b3;
>    C c1, c2;
>    cout << B::getNrInstances();
> 
>But this doesnUt work because static variables aren't inherited
>(at least not in my compiler).

	What do you mean 'aren't inherited'?

>Could anyone enlighten me as to how to acquire the functionality
>of a class like A that depends on a static variable with LEAST
>modification to the acquiring class ? Thanks.
> 

	IF: you want to count all objects allocated (of any type):

	Sure: two type of class: base classes and working 
classes. The base classes NEVER inherit A.
The working classes inherit from A when you want a counter.
It is not allowed to derive from a working class though.

	class B { }
	class C { }
	class D { }

	class BCD : public virtual B, public virtual B, public virtual C
	{ ... }

// BCD is the class you want to play with.

	.....
	BCD* bcd;
	{
		class dummy : public virtual BCD, public virtual A
		{ dummy() : BCD(...) {} };
		bcd=new dummy;
	}

// Dummy is a local class

IF: you want to partition the counts, you can do this:

	class C1 {}; class C1 {}; class C3 {};

and now make 'A' a template class and use A<C1>, A<C2> or A<C3>
as appropriate.

IF: you want to count instances of EACH class, you must
declare the static variable for each class .. no getting
around this. However, you CAN automate the increment
and decrement somewhat:

	class Counter {
		virtual int* counter()=0;
	public:
		Counter() { (*counter())++; }
		~Counter() { (*counter())--; }
		int TellCount()const {return *counter();}
	};

	class X : 
		public virtual Counter { // (1)
		static int count; // (2) must declare
		int * counter() {return &count;} // (3)
	...
	};

and lines 1-3 could be made a macro:

#define autocount public virtual Counter { static ....

so

	class X : autocount
	...
	};

(Yuk)
(PS: I havent tested this)
Note the use of a private virtual function here :-)

-- 
;----------------------------------------------------------------------
        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: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Clarification of Callbacks in C++
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Trumphurst Ltd.
Date: Mon, 11 Jan 1993 13:47:51 +0000

In article <1il5pcINNblt@news.cerf.net> hlf@nic.cerf.net (Howard Ferguson) writes:
> I was to 
> supply my colleges who are coding in C++ with some classes written in
> C++ which require calbacks. My point is that I should be able to
> provide something cleaner than what I must use if I am writting a
> C library which may be used by C++ coders ( e.g. Xview).

It is pretty unusual to need callbacks as such in C++. Normally speaking, 
you would provide an abstract base class containing a virtual function. 
Users then derive their class from that abstract base, overriding the 
virtual function to do whatever their callback function would do.

A typical example might be ...

class Shape {
public:
	virtual void draw() = 0;
	};

A user creating a Rectangle (say) would derive from Shape. They would pass
a Shape pointer to to your library functions, which would call draw for 
that Shape whenever they want to draw it.

Of course, the situation can get more complex - e.g. when you want to 
perform some arbitrary (unknown at compile time) action on some arbitrary 
object in your library function.

I have found it convenient in these cases to provide a template class
(which I call a Command) to encapsulate such a callback ...

#include <iostream.h>

// You write this bit
class Comd {
public:
	virtual int doit() const = 0;
	};

template <class X> class Command : public Comd {
	X &to;
	int (X::*f)(void);
public:
	Command(X &destination, int (X::*function)(void))
	: f(function), to(destination) {}
	int doit() const { return (to.*f)(); }
	};

int libraryFunction(const Comd &command)
{
	// Do some internal library stuff
	if(command.doit())
		{
		return 1;	// Do some stuff which depends on success
		}
	else
		{
		return 0;	// Do some stuff which depends on failure
		}
}

// The user writes this bit
class Test {
	int i;
public:
	Test(int x) : i(x) {}
	int test1() { cout << i << " test1\n"; return 1; }
	int test2() { cout << i << " test2\n"; return 1; }
	};

main()
{
	Test t1(1), t2(2);
	Command<Test> c1(t1, &Test::test1), c2(t2, &Test::test2);

	libraryFunction(c1);
	libraryFunction(c2);
	return 0;
}

Obviously, this can easily be extended to allow the "callback" to take 
arguments, or have different return values. I use a similar Command class 
in my DOS text mode user interface toolkit, for attaching to buttons and 
menu options - when the button is pressed (or the option is selected), the
Command is executed. In this context, an enhancement which springs to mind 
is undo-able Commands, which have a virtual undo function, and which 
register themselves on an undo stack (or similar).

-- 
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Newsgroups: comp.lang.c++
From: dschieb@muse.cv.nrao.edu (Darrell Schiebel)
Subject: Re: template disappointments ... (suggestions?)
Organization: National Radio Astronomy Observatory
	<1993Jan1.170812.26511@taumet.com> <1993Jan2.081410.22955@ucc.su.OZ.AU>
Date: Mon, 4 Jan 1993 15:54:42 GMT


In article <1993Jan2.081410.22955@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>  (Is there an LALR grammar for C++ anyhow?)

brain.vifp.monash.edu.au
	/pub/src/programming
		-rw-r--r--     753962  Nov  4 09:21  c++grammar2.0.tar.Z
ics.uci.edu
	/gnu
		-rw-r--r--     753962  Jul 24 1991  c++grammar2.0.tar.Z
rs3.hrz.th-darmstadt.de
	/pub/programming/languages/C++/tools
		-rw-rw-r--     753962  Jul 24 1991  c++grammar2.0.tar.Z

You might also want to check the grammar that comes with g++.


							Darrell Schiebel
Newsgroups: comp.lang.c++
From: eb@ascent.com (Ed Barton)
Subject: Re: How to prevent local instances, but allow "new"
In-reply-to: bruceb@roadrunner.denver.sgi.com's message of Tue, 5 Jan 1993 19:42:23 GMT
Date: 7 Jan 93 09:21:24
Organization: Ascent Technology, Inc., Cambridge Massachusetts

In article <1993Jan5.194223.19400@odin.corp.sgi.com> bruceb@roadrunner.denver.sgi.com (Bruce Bailey) writes:

   In article <1icij0INNdhc@news.cerf.net>, hlf@nic.cerf.net (Howard Ferguson)
   writes:
   |> I wish to define a class in a library which the library user
   |> can create by dynamic allocation via the new operator, but
   |> I want to prevent him from creating automic instances.

   Make the destructor private.

In at least one compiler implementation, making the destructor private
will also prevent ever having any subclasses of the class.  In many
cases where you are making the constructor or destructor private, you
actually want to make it protected so that subclasses will be
possible.

By the way, note that when you want to prevent automatic allocation on
the stack so that you can do "delete" later, you also want to prevent
containment in other objects, whether or not those other objects are
allocated on the heap.  Most solutions that prevent automatic
allocation also prevent containment, but I have found that many people
forget about containment when they are thinking about this issue, and
remember only stack variables and "new" allocations.


Xref: sparky comp.lang.c++:18994 comp.object:4758