HDTenEightyP/NetNews huggingface dataset:
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Not supposed to use static variables in member fns?
Organization: Rational
Date: Sun, 10 Jan 1993 14:38:55 GMT

ghawkins@unix1.tcd.ie (George C. Hawkins) writes:


|If a member function wants to remember a value between calls to it
|then it must store that value in a varaible visible to all member
|functions. Is this right?

Yes.  Such a variable is called a "member variable".

There are two kinds.  Regular member variables are known to all member
functions, but are unique to each instance.  Each instance will have
its own space reserved for the variable.  We use these when we want to
remembers something specific about a single object.  Static member
variables are also known to all member functions, but there is only
one variable regardless of the number of objects.  We use static
member variables when we want to remembers something specific about
the class of objects.

class Person
{
  private:
    int itsWeight;
    static int theirAverageWeight;
};

In the example above, 'itsWeight' is a regular instance variable.  It
remembers the weight of a Person.  If many Person instances are
created, then each will have its own 'itsWeight' variable recording
the weight for that particular instance.  'theirAverageWeight' is a
static member variable.  Their is only one copy of this variable.  It
remembers the average weight of all the Person instances that exist.



--
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++
Newsgroups: comp.lang.c++,comp.object
From: mlim@ibx.com (Michael Lim)
Subject: C++ develpment environments
Organization: Independence Blue Cross
Date: Mon, 11 Jan 93 14:15:28 GMT


To all C++ people:

We are currently evaluating a few C++ development environments on Sun SPARC and would like 
to hear from those of you who have used or are using the following products:

	ObjectCenter by CenterLine
	Objectworks  by ParcPlace
	Energize     by Lucid

It would also be helpful to us if you could share with us the size of the application(s) you
are loading into your development environment. 

Your comments and information are greatly appreciated.

Thanks.


Michael Lim
mlim@ibx.com
Independence Blue Cross
215-241-4472

Newsgroups: comp.lang.c++,comp.object
From: muts@estec.esa.nl (Peter Mutsaers)
Subject: Re: Pros and cons of C++
Organization: European Space Agency
Date: Tue, 12 Jan 1993 10:00:46 GMT

>>On Thu, 7 Jan 1993 15:15:22 GMT, yjohn@gpu.utcs.utoronto.ca (John Ross) said:

  John> I have recently come to grips with having to learn C++; mainly due to
  John> the bandwagon effect. It doesn't look like there will be any pure C
  John> programmers left in a couple of years.  I agree that the language is
  John> very complex, and has many shortcomings.  

  John> Why then is it becoming so popular?  Why the deluge of texts,
  John> articles, magazines, news groups, compilers, etc?  It seems to

Because it is not complex, especially not if you already know C.
Sometimes pureness was offered to compatability with C, but that of
course also is an advantage. With minimal extra syntax (=> easy to
learn and remember) full OO support was added. If you look at the
minimal number of additions to C (most essential only a little
extension of the struct syntax) I think it is amazing.

The implications can be complex, but that is more due to OO than to
C++ in particular. But it pays for most applications.

IMHO the main criticism on C++ is that it does not *enforce* pure OO
structured programs. On the other hand, I, and many other programmers,
don't like to be forced too much in a direction and I think I can have
my own discipline to do things right, and like to have the freedom to
brake the pure rules in the rare cases where that is advantageous. Of
course most managers prefer other languages so that they can control
you better (like Ada).
--
_________________________________________________________________________
Peter Mutsaers.         |================================================ 
muts@pmcs.estec.esa.nl  |        Quod licet bovi, non licet Jovi
Newsgroups: comp.lang.c++
From: sdm@cs.brown.edu (Scott Meyers)
Subject: Re: Preventing inheritance
Organization: Brown University Department of Computer Science
Date: Mon, 11 Jan 1993 15:47:35 GMT

In article <1iqtnpINN283@news.cerf.net> hlf@nic.cerf.net (Howard Ferguson) writes:
| 
| If I create a class which I am supplying to other users, how do I
| make sure that they do not inherit from it ever. I could overload new
| and check the size of the object that is being allocated, but there
| are two catchs. The first minor one is that this is a run-time check,
| and it would be far preferable to catch this sort of thing at compile
| time. More seriously, they could over-ride the new operator and by-pass
| the check.

More seriously still, not all objects are allocated on the heap, so new
isn't always called. 

The solution to your problem sort of depends on whether you want to prevent
actual derivation or "moral" derivation.  If you only want to prevent
actual derivation, make everything in the class private and then create a
second class which is a friend to the first one:

  class StandAlone {      // nobody should derive from this class
    private:
       int x, y, z;
    
        StandAlone();
        ~StandAlone();
        void foo();
        int bar() const;

    friend class UseMe;   // this is the class clients actually use
  };

UseMe contains an instance of StandAlone, and calls to functions in UseMe
are just forwarded to this object:

  class UseMe {
    private:
      StandAlone s;

    public:
        UseMe() {}
        ~UseMe() {}
        void foo() { s.foo(); }
        int bar() const { return s.bar(); }
  };

You get extra style points for nesting StandAlone inside UseMe.  If you do,
not that StandAlone's members still need to be private, otherwise friends
of UseMe would have access to StandAlone.

There are two problems with this approach.  First, it's not utterly
iron-clad, because UseMe can still derive from StandAlone, like this:

  class UseMe {
    class Nested: public StandAlone { ... };
  };

Second, it doesn't prevent "moral" derivation:  clients can still use UseMe
as a base class, and you may not want that.

A different -- substantially less direct -- approach to the problem is to
just declare Standalone in the usual manner, but without any virtual
functions:

  class StandAlone {      // nobody should derive from this class
    private:
       int x, y, z;
    
    public:
        StandAlone();
        ~StandAlone();
        void foo();
        int bar() const;
  };

Because none of the functions is declare virtual -- notably the destructor
-- you might hope that clients catch on that this class is not designed for
use as a base class.  Unfortunately, that's the only thing you've got going
for you in this case: hope.

Scott


-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."
Newsgroups: comp.lang.c++
From: mlg@siemens.com. (Michael Greenberg)
Subject: Re: C++ coding style guide??
Organization: Siemens Corporate Research, Princeton (Plainsboro), NJ
Distribution: usa
Date: Wed, 6 Jan 1993 18:30:30 GMT

pkoch@news.weeg.uiowa.edu (Peter F Koch) writes:


>Anyone know of a good C++ coding style guide?

Try "C++ Programming Guidelines" by Plum & Saks, 1991 Plum Hall Inc. 
ISBN 0-911-537-10-4

--
Michael Greenberg                      email: mgreenberg@siemens.siemens.com
Siemens Corporate Research             phone: 609-734-3347
755 College Road East                  fax: 609-734-6565
Princeton, NJ 08540
Newsgroups: comp.objects,comp.lang.c++,comp.lang.smalltalk,comp.lang.ada
From: wellerd@ajpo.sei.cmu.edu (David Weller)
Subject: Re: example application software from Booch
Organization: Ada Joint Program Office
Date: Mon, 11 Jan 1993 06:48:12 EST

In article <1993Jan11.063842.11586@siswat.hou.tx.us> buck@siswat.hou.tx.us (Lester Buck) writes:
>In "Object-Oriented Design with Applications" by Booch, there is
>a reference near the front that the source code for the applications
>is available from the publisher.  But I can't find any reference
>to where or how to order this software.
>
>Does anyone have any pointers for ordering the Booch software for the
>example applications?
>
>Thanks alot,
>
>-- 

Drop a note to Grady.  His address is egb@rational.com.


-----------------------------------------------------------------------------
David Weller,         | Space Station Training Facility: Like the real
CAE-Link,             | thing, only you can step outside for a breath
Houston, TX           | of fresh air!
----I'm the Ultimate International Masochist: I speak Ada AND Esperanto!-----


Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: feedback wanted on appropriate OOPL
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 12 Jan 1993 17:07:30 GMT

In article <1itoe9INNi05@usenet.INS.CWRU.Edu> ac690@cleveland.Freenet.Edu (Edward Klimas) writes:
>	The message at OOPSLA-92 from two separate experience reports
>	was that Smalltalk was possibly as much as an order of
>	magnitude better than C/C++ in terms of quality of the resulting
>	code.  The result is that the current implementations of
>	type checking don't bring as much to the quality table as other
>	C++ issues like runaway pointers and memory management take away.

In 5 years, when Stalk is compared to C++ and not to C/C++,
and C++ has matured, the picture may change.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: How to prevent local instances, but allow "new"
Date: 7 Jan 93 16:32:04 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: TIN [version 1.1 + PL8]

Nikki Locke (nikki@trmphrst.demon.co.uk) wrote:
: 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.

: Leave the constructors public. Make the DESTRUCTOR private. Provide an
: inline member function ... 

Make the destructor PROTECTED.  He didn't say he wanted to
prevent inheritance too...

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
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: Sat, 9 Jan 1993 15:48:50 GMT

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. 

>>There are a number of possible ways that might fix this using templates.
>>You would have to do something like:
>>
>>	class B : public virtual A<B> { ...
>>
>>which seems dubious. Then the template class A<T> could create
>>the int A<T>::counter automagically. Dont know if this
>>works.
>>
>
>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)

In fact: if you actually WANT to count subobjects, then
DO use containment.

Do you want to count 'new'ed classes or ALL subobjects?

Wait! It is WORSE:

	class Q { X x; Y y; A<Z>; };

This counts 1 'X' object: for BOTH containment (shown) or
the inheritance method.

OH! You have posed a really HARD problem. 
Mm .. overload operator new??

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Xref: sparky comp.lang.c++:19045 comp.object:4769
From: pkron@corona.wa.com (Peter Kron)
Newsgroups: comp.lang.c++,comp.object
Subject: Re: Pros and cons of C++
Date: Tue, 12 Jan 93 12:40:42 PDT
Organization: Corona Design, Inc.
Reply-To: Peter_Kron@corona.wa.com

> Date: Tue, 12 Jan 1993 10:00:46 GMT
> muts@estec.esa.nl (Peter Mutsaers) writes:

> ...IMHO the main criticism on C++ is that it does not *enforce* pure OO
> structured programs. On the other hand, I, and many other programmers,
> don't like to be forced too much in a direction and I think I can have
> my own discipline to do things right, and like to have the freedom to
> brake the pure rules in the rare cases where that is advantageous...

Actually, my criticism is that it enforces *too* much. I much
prefer Smalltalk or Objective-C where the compile-time type
checking is not so rigorous. IMHO C++ *is* complex because
this type checking forces use of templates, casts, virtual
base classes--all of which muddy the water, and for very
little gain in practice.
---------------
Peter Kron
Corona Design, Inc.
Peter_Kron@corona.wa.com
From: tedx@logan.NoSubdomain.NoDomain (Ted Toth)
Newsgroups: comp.lang.c++
Subject: Genman
Keywords: genman
Date: 5 Jan 93 20:19:55 GMT
Organization: TIVOLI Systems

Where can I find a copy of genman2.0? It is supposed to be an AWK script which processes C++ headers into man page format.
Newsgroups: comp.lang.c++
From: swhall@eng.auburn.edu (Steven Wayne Hall)
Subject: MFC Programming
Reply-To: swhall@eng.auburn.edu
Organization: Auburn University Engineering
Date: Wed, 13 Jan 1993 02:53:29 GMT


---
I would like to correspond with other MFC programmers about any experiences with MFC.  I have been using it for a couple of months and I think they are great!!


    +================================================================+
    | /* Steven W. Hall */  | A theory can be proved by experiment;  |
    | Computer Engineering  | but no path leads from experiment to   |
    | Auburn University, AL | the birth of a theory.		     |
    |  	       	            |					     |
    |swhall@eng.auburn.edu  | Albert Einstein (1879-1955)            |
    +================================================================+

Xref: sparky comp.lang.c++:18757 comp.os.ms-windows.programmer.tools:1895
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++,comp.os.ms-windows.programmer.tools
Subject: Re: Protogen/ Owl directories
Summary: get Borland's Application Frameworks
Date: 6 Jan 93 16:49:46 GMT
Reply-To: jamshid@emx.utexas.edu
Followup-To: comp.os.ms-windows.programmer.tools
Organization: The University of Texas at Austin; Austin, Texas

Crossposted and followups redirected to a newsgroup devoted to
programming tools for Windows.

In article <1993Jan6.060043.28516@umr.edu> chrisg@cs.umr.edu (Chris Gorsuch) writes:
>I have recently purchased the Borland C++ 3.1 compiler.
>It came with the ProtoGen windows creator included with it.
>The problem is that Protogen is Looking for /borlandc/owl/owl.h
>and it causes an error when it realizes that I have no owl directory

ObjectWindows Library is Borland's class library for Windows.  OWL
comes with BC++ *with* Application Frameworks or with the Windows-only
Turbo C++ for Windows.  I highly recommend using OWL or some other
class library when programming for Windows (the C API is a nightmare).
I believe BC++ w/ AF is about $200 at an educ. discount and TC++4W is
<=$100.  Ask customer-support@borland.com (no tech support!) for more
info.  Btw, Protogen can probably output code which doesn't use OWL --
read the docs.

>Question 2 is what header file should I give protogen...
>ie how do I hook MY code into the individual menus I have set up.
>It would appear from the little pamphlet that I do all of the protogen
>work first and THEN create my code and hook it into it.
>but without being able to get by the owl problem I can't begin to tackle
>the second problem

Sorry I don't use Protogen but maybe someone else will answer.  I just
use OWL and the ResourceWorkshop.  I've seen a lot of people post in
c.o.m.p.t that Protogen was not very useful.  If you bought it in lieu
of OWL, I recommend you return it and get AF.

Jamshid Afshar
jamshid@emx.utexas.edu
Newsgroups: comp.lang.c++
From: erics@cadkey.cadkey.com (Eric Smith)
Subject: setjmp/longjmp question
Organization: cadkey
Date: Fri, 8 Jan 1993 19:56:13 GMT


In <setjmp.h>, Microsoft C has a #ifndef to comment out the entire
contents of the file if compiling a C++ program.  Other compilers I
use (Borland, ObjectCenter, and one other cfront implementation) allow
setjmp/longjmp even from a C++ program.

I realize the problems with stack unwinding and object destruction,
but why doesn't Microsoft let me use these?  It is kind of a problem
when I am porting a straight C program to C++ just to get some
additional type checking.

I could find no mention of this in the ARM.

Does anyone know of any other C++ compiler that doesn't allow setjmp?

Thanks.

Eric.

-- 
Eric V. Smith         | Technology ... the knack of arranging the
Cadkey, Inc.          |   world so that we need not experience it.
Windsor, CT           |
erics@cadkey.com      |     - Max Frisch
Newsgroups: comp.lang.c++
From: pwy6d@fulton.seas.Virginia.EDU (Phil Yarrington (SG))
Subject: pretty printer on c++
Organization: University of Virginia
Date: Mon, 11 Jan 1993 16:05:14 GMT


Can anyone tell me of an available pretty printer on c++ for the ibm?
The pretty printer that we have available works fine for regular c,
but bombs out when we try to use it with c++.  Apparently, c++ uses
some special characters that c does not use.  
E-mail responses please.
pwy6d@virginia.edu
Thanks in advance.  
-phil
Newsgroups: comp.lang.c++
From: wolf@merlin.mt.att.com (Thomas Wolf)
Subject: C++ and Solaris 2.x question
Reply-To: wolf@merlin.mt.att.com
Organization: AT&T Bell Laboratories
Date: Tue, 5 Jan 1993 13:09:53 GMT

Does anyone know of any C++/C implementations, aside from Sun's  SPARC compilers,
that can generate Solaris 2.x binaries?  I'm particularly interested in finding out
whether the GNU compilers/translators can now produce this new format.

Sorry if this question has been asked before.  Up to now, I haven't been paying too
much attention to Solaris 2.x...but with Sun making a serious effort to extinguish us
"backward" SunOS4.x developers, I thought it's time to investigate the inevitable :-)

Thnx in advance for any info,
Tom

P.S.  I know "a.out" format executables work (mostly) in Solaris 2.x's
"compatibility mode".  But I'm not sure what performance penalty one pays for
running under this mode.

---
+----------------------------------------+ ..I've been told my signature lacked
| Thomas Wolf   | (908) 957-3955         | originality...Of course it does!
| Bell Labs, NJ | wolf@merlin.mt.att.com | I'm a conservationist - and 
| MT 4D-213     | wolf@jolt.att.com      | originality, in my case,  is a
+----------------------------------------+ an extremely limited resource...
From: krc@wam.umd.edu (Kevin R. Coombes)
Newsgroups: comp.lang.c++
Subject: Re: semi-private public methods?
Date: 12 Jan 93 16:22:17 GMT
Distribution: na
Organization: University of Maryland, College Park

In article <RALPH.93Jan11143011@yo_dud.bell.ca> ralph@dci.pinetree.org writes:
>I would like to have a class that has some public methods that can
>only be used by a certain group of classes.
>Lets call this class A, and I want B,C,D &E to be able to use the
>public methods on A. (no problem so far)
>However, I don't want classes X, Y, &Z to be able to use the methods,
>nor any other similar classes added in the future.
>I don't want B,C,D &E to access the private data of A, so I can't make
>them friend classes.  A,B,C,D, &E aren't in the same heirarchy, so I
>can't use inheritance to have a solution to the problem.
>What I would like to be able to do is say that the public methods of A
>are only public to a certain group of classes, and private to all
>others.
>Any ideas?
>

As my newsreader asks, are you absolutely sure that you want to do this?

It sounds like you should look very carefully at the design of the classes
before trying to do this; the wrong class is hoarding some data, or your
design is missing a class.

Can you explain why the "public" methods of A aren't really public? Do they
allow clients to disturb the integrity of the data? Do they produce objects
with incoherent data?

Anyway, supposing you really DO want to do this, can you do the following:

class A {
  public:
    void really_public_method();
  protected:
    void semi_public_method();
  private:
    int dont_touch_me;
};

class SemiPublic : public A {
  friend class B;
  friend class C;
  // etc.
};

Now B and C can access the protected methods of A, since they are part of
the interface of SemiPublic. They can't touch the private members of A,
because SemiPublic can't touch them.

Kevin Coombes <krc@math.umd.edu>
From: dschieb@muse.cv.nrao.edu (Darrell Schiebel)
Subject: template constructor specialization (question)
Organization: National Radio Astronomy Observatory
Distribution: comp
Date: Tue, 5 Jan 1993 18:00:12 GMT


I have another question regarding templates, if I have the following 
templates:

	template<class t> id {
	  id();}
	template<class t> class templ {};

And now I want to write a specialized constructor for "id":

	template<class t> inline id<templ<t> >::id() {};

What is the correct syntax for this?? I want a constructor which will be
called for any instantiation of "templ".


						Thanks,
						Darrell Schiebel
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Standard library functions and macros
Date: 04 Jan 93 21:56:52 GMT
Organization: Microsoft Corporation

In article <930101234006_76336.3114_EHJ42-1@CompuServe.COM> 76336.3114@CompuServe.COM (Kevin Dean) writes:
|>If this is not acceptible, then simply don't include that standard header
|>file.
|
|All well and good but I've seen some compilers (Microsoft's among them)
|that, with certain optimizations turned on, reserve the function name
|anyway even though its corresponding header has not been included.  (I
|don't know if this applies to MSC 7.0 since I haven't played with it yet
|but it was certainly the case with 6.0).

What you refer to is compiler support for certain intrinsic functions,
if you have the option on for the compiler to supply you with these
intrinsic functions.  An example being that the compiler supplies you
with highly-optimized inline code to do a strcpy, for example.

What happens in a C program with intrinsics turned on, and the header
not included, is that the first use of strcpy *implicitly* defines the
function, as is C tradition.  Then the compiler-supplied intrinsic function
matches your implicit declaration of the function.  If it weren't for the
intrinsic you'd still get an "accidental" match to the strcpy in the C
standard libraries -- unless you don't link to the C standard libraries either.

Note that this is not the same with a C++ program.  C++ does not allow
implicit declarations of functions.  So, without the header included in
C++ you get an error message that the function is used without being defined.
No problem there.