HDTenEightyP/NetNews huggingface dataset:
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Reading class internals (was Re: Criticisms Wanted)
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Fri, 13 Nov 1992 16:07:14 GMT

In article <1992Nov13.060823.1358@BofA.com> dan@BofA.com (Dan Brockman) writes:
>In article <1992Nov11.175117.15325@bcrka451.bnr.ca> sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:
>>
>>The real question is *why* does the user have to look into the inner workings of
>>the class?  Surely not to discover the inner workings, but to discover behavioural
>>characteristics of the class.  Will these be clear from looking inside the class?
>>Does the user enjoy poking his nose around where he doesn't belong?
>>
>
>Reading source code is hardly a crime.  He could be trying to fix the damned
>bug his benighted colleague wrote into the program.  He could be trying to 
>find the damned bug.  He could be looking for a good example of how to 
>perform some deft programming trick.  He could be making an enhancement.
>You are right to ask *why*, though.  It is a good question to ask.  But 
>do you intend to prohibit the reading of source code?  That is, *why not*
>look into the inner workings, even if you do not have to?
>-- 

Ok, yes I guess I overstated myself.  However, the discussion had been along
the lines of "I need to look at the source in order to use the class".  This
indicates a problem in documentation to me.  You are right that there are 
many valid reasons to look at how a class works.  

There are those who can't drive a car until they've found out where the engine
is and seen how the engine is constructed.  But it should not be necessary
to know about the engine to drive the car.

Stuart

--
: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
Newsgroups: comp.lang.c++
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Subject: Re: const char *
Reply-To: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Organization: University of Virginia
Date: Sat, 7 Nov 1992 01:49:47 GMT

Kayvon Z. Sadeghi <KSADEGH@auvm.american.edu> writes:
: mycall("");
: 
: 
: and then somewhere down in my code I have:
: 
:  mycall(const char *msg){
:      if(msg=="")
:           dothis();
:      if(msg!="")
:           dothat();
: }
: 
: Strange, but my compiler doesthat() instead of dothis().
: I even checked the value of msg and it *IS* equal to "". Is something wrong
: with my C++ compiler or what? or are strings treated differently in here?

You are comparing the addresses of msg and the string "".
Instead, compare the string values as follows:

void mycall (const char* msg) {
	if (::strcmp(msg, "") == 0) // (msg && *msg==0) would be better here
		dothis();
	else
		dothat();
}

-Sekar
From: kevinc@hpcc01.corp.hp.com (Kevin Collins)
Date: Thu, 5 Nov 1992 18:04:18 GMT
Subject: Inheritance & operator overloading
Organization: the HP Corporate notes server
Newsgroups: comp.lang.c++


I have a child of an array class that inherits an overloaded operator=.
I need to add some functionality to that operator= then I would like to
call the *inherited* operator=.  What is the syntax for this?  I've
done it many times for "normal" functions ... 

Thanks,

Kevin
-----------------------------------------------

template <class Type> 
class baseArray {

  public :

  Type&  operator[] (int i);

}

template <class Type> 
class child : public  Block<Type> {

  public :

   Type&  operator[] (int i);

}


template <class Type>
Type& child<Type>::operator[] (int i) {

   // do something of added value here ...

   return a call of inherited operator[] call here, meaning something like :
                    ---------
   
   return (*this)[i];  // but NOT this since this will create an infinite loop.

}
From: h8850513@d10.wu-wien.ac.at (Michael Tesar)
Newsgroups: comp.lang.c++
Subject: Binary Trees
Date: 6 Nov 1992 19:53:39 GMT
Organization: Wirtschaftsuniversitaet Wien
Distribution: world
NNTP-Posting-Host: d10.wu-wien.ac.at

Who can tell me how to write a binary tree in C++ which
works on the hard disk and not in memory
Thank you!
--
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Newsgroups: comp.lang.c++
Subject: Copying array members
Date: 6 Nov 92 19:07:36 GMT
Organization: University of Birmingham

Perhaps I should RTM but I'm ARMless and cannot find the answer to the
following in "The C++ Programming Language, 2nd Edition".

struct A {
  int member;
  A();
  A(const A&);
  A& operator=(const A&);
};

struct B {
  A array_member[10];
};

Do the compiler generated B::B() B::B(const B&) and B::operator=(const B&)
call their counterparts in A ten times?

I could check this on my compiler but I want to know what the _standard_ says
as this is just the sort of thing compilers often get wrong.

Is it possible for the programmer to write a B::B(const B&) that calls
A::A(const A&) ten times rather than calling A::A() ten times followed by
A::operator=(const A&) ten times?

This opens the whole issue of changing the standard so that one can initilise
an array with another array and assign to array variables.

If you with to reply WRT changing the standard, please do *not* do so here.
Please reply to my posting in comp.std.c++ entitled "Array anachronisms".
-- 
    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)          
 .  _\\__[oo  ============
.__/  \\ /\@
.  l___\\     E-mail: B.A.McCauley@bham.ac.uk
 # ll  l\\ 
###LL  LL\\
Newsgroups: comp.lang.c++
From: jlieb@is.morgan.com (Jerry Liebelson)
Subject: WANTED: A SOURCE CODE based C++ class browser for MS Windows.
Keywords: c++ browser 
Organization: Morgan Stanley & Company, Inc.
Date: Mon, 9 Nov 1992 20:32:26 GMT

Does anyone know a good C++ class browser for MS Windows that will
browse source code in multiple header and source directories? I don't
want to buy another compiler, just need the browser.  Such a class
browser should do the following:

   1. Let you specify a list of include and source directories and
optional preprocessor #defines and see something like a FileManager-like
class hierarchy tree.
   2. Then by clicking on any class, selectively list all/some/none inherited
methods and data by indicating how far up the inheritance tree to show.
   3. In addition, selectively show any combination of
public/private/protected and virtual/const/static functions and data.
   4. By clicking any particular method or data, see its complete declaration
and definition.

When I purchased Borland's C++ with App Frameworks, I was rather shocked
that the builtin class browser only worked on executables. I like what
Borland has done but honestly, any good OO development environment, C++
or otherwise, should have a class hierarchy browser for use with source code.
After all, code comes before executable!


-- 
Jerry Liebelson
jlieb@is.morgan.com
Compuserve: 73477,2740

Newsgroups: comp.lang.c++
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Debugging output
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Thu, 5 Nov 1992 23:49:25 GMT

In <1992Nov5.185929.15279@saifr00.cfsat.honeywell.com> murali@saifr00.cfsat.honeywell.com (R. Muralidhar) writes:

>In <Bx9369.3zL@cs.uiuc.edu> pjl@cs.uiuc.edu (Paul Lucas) writes:

>>In <spuler.720931050@coral> spuler@coral.cs.jcu.edu.au (David Spuler) writes:

>>>I was wondering whether anyone has any suggestions as to how to use the neat
>>>operator << to produce debugging output in a way that it can be removed
>>>easily from production code.  The obvious method is:

>>>#ifdef DEBUG
>>>   cerr << .....
>>>#endif

>>>but I'd like to avoid the #ifdef -#endif lines.

>>*****>	Why?  In a "final" version, you don't want debugging code in the
>>	object file.

>I, too, have felt a similar need like David Spuler. For one, those #ifdef -
>#endif lines interfere with neatly indented code, are unsightly, and make
>the code less readable. (I don't discount their usefulness, don't get me
>wrong.)

*****>	You can indent preprocessor directives too, you know.

>>>I've been trying to declare my own "dbg" streams by inheriting it
>>>from the standard "ostream" class and redefining the << operators.

>>	[stream that has flag whether to print elided]

>>*****>	This is overkill; the same thing can be achieved without
>>	inventing another class:

>>	#ifdef DEBUG
>>	#	define	CDEBUG	if ( debug ) cerr
>>	#else
>>	#	define	CDEBUG	//
>>	#endif

>>	CDEBUG << "here\n";

>This method will work only if all the information to be 'output' appears in
>one source line. What if I had to do (for readability purposes):

>        CDEBUG << "here is senetence one.\n"
>               << "here is sentence two.\n";

>The technique Paul Lucas suggests wouldn't work, but David's would.

*****>	Mine would work:

	CDEBUG << "here is senetence one.\n";
	CDEBUG << "here is sentence two.\n";

	you just have to use it, like all things, properly; David's class
	is, as I've said, overkill.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: coller@alnitak.usc.edu (Lee D. Coller)
Newsgroups: comp.lang.c++
Subject: Re: Multiple Header Files Problem
Date: 11 Nov 1992 10:35:40 -0800
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: alnitak.usc.edu

In article <rmartin.721442494@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>reindorf@us-es.sel.de (Charles Reindorf) writes:
>
>|In article <rmartin.721359424@thor>, rmartin@thor.Rational.COM (Bob Martin) writes:
>||> A more interesting variation on this issue is the problem of "circular
>||> 
>||> [ etc.]
>
>|It is usual, in header files, to structure them so :
>
>
>|| # ifndef <HeaderFileName>_h
>|| # define <HeaderFileName>_h
>|| 
>|| 
>|| ... body of include file ...
>|| 
>|| 
>|| # endif
>
>|This prevents cyclic dependencies and has been in common practice for, well, ages.
>
>Of course!  And of course I use this technique myself, and instruct my
>students to do the same. 
>
>What I had not realized, until you (and many others) pointed it out to
>me, is that the #ifndef convention breaks inclusion cycles.  Of course
>it does.
>

Actually it doesn't entirely solve the circular dependency problem.
Consider two files, file a.h containing:

#ifndef a_h
#define a_h

#include "b.h"

class a {
public:
	b* _b;
	void do_b_fnc() { _b->b_fnc(); }
	void a_fnc();
};
#endif

File b.h contains:

#ifndef b_h
#define b_h

#include "a.h"

class b {
public:
	a* _a;
	void do_a_fnc() { _a->a_fnc(); }
	void b_fnc();
};
#endif

Now if file a.c includes a.h, the compiler will generate an error at the
"a* _a;" line because a is undefined.  But how can this be because b.h
includes a.h which defines a?  The reason is by the time we get to b.h's
inclusion of a.h, a_h is already defined, but the class definition of
a has not been read.  When b.h includes a.h, the contents are skipped
because of the a_h is already defined.  Note that doing a forward
reference to "a" does not solve the problem because do_a_fnc() inline
needs a's definition.

I think this was the reason Bob mentioned in an earlier posting to avoid
inline definitions which require the inclusion of an additional header,
as there is no clean fix to this problem.  In this simple example the
problem is easy to track down, but I have seen examples in more complex
programs where it has taken several hours to track down the location
of the circularity.

-- 
-----------------------------------------------------------------
Lee D. Coller (coller@alnitak.usc.edu)		+1 (310) 379-0844
USC Behavioral Technology Labs, 250 N. Harbor Dr. Ste 309
Redondo Beach, California, 90277
Newsgroups: comp.lang.c++,comp.std.c++
From: dan@BofA.COM (Dan Brockman)
Subject: something nasty report
Organization: Bank of America, Capital Products, RMTG #5906
Date: Tue, 10 Nov 92 19:21:57 GMT

re:
During a C++ compilation ...
"Leg1.c", line 87: internal <<AT&T C++ Translator 
2.1.03 08/31/90>> error: bus error (or something 
nasty like that)
Compilation failed
 ------------------------

 I am grateful to all the people who helped me resolve
 this problem.  Many contributed advice and suggestions,
 but especially helpful were Gary Angel and
 Shankar Unni.  
 
 The error message may be symptomatic of a broad range
 of problems, for many tentative diagnoses were 
 nominated.  I found one problem.  It occurs in that
 part of the C++ translator called "cfront".  It is 
 not clear to me whether cfront contains a bug.

 The line of source at which the problem occurs is such as

        SwapLeg = (LegPtr)calloc(1, LEG_SIZE);

 Here is the fix:

	//#define LEG_SIZE sizeof(Leg)
	#define LEG_SIZE sizeof(struct leg)

 We had this pattern of code in six or eight programs.
 The line number cited in the error message is the
 closing bracket "}" of the function in which the
 error occurs.
  

 ----------------------------------------------
 
 Hypotheses proven false.
 
 1.  Big program uses too much memory.
 2.  ESQL causes it.
 3.  Unused argument list variables  cause it.
 4.  CC "+w" option causes.
 5.  Error occurs in cpp.
 6.  Error does not occur in cfront.
      
DanB

-- 
 --------------------------------------------------------------
 Daniel Brockman             tel 415-953-0406, fax 415-622-2892
 Bank of America, Dept 5906, 555 Calif St
 San Francisco 94104 USA    email uunet!odinba!dan dan@BofA.COM
From: kilitzir@antigone.csi.forth.gr (Xristos Kilitzirakis)
Newsgroups: comp.lang.c++
Subject: References in GNU question
Date: 6 Nov 1992 18:42:45 +0200
Organization: Institute of Computer Science, FORTH Hellas
NNTP-Posting-Host: antigone.csi.forth.gr
Summary: references in GNU
Keywords: references,GNU,question

Boys,
I'm newly born in oop world , so these are my "why" questions:
1.Reference pointers
  suppose the following:
     class dd{
       char **p;
     public :
       friend z();
     };
     friendz()
     {
         ..
         dd ddd;
         char ** &p = ddd.p;
         ...
     }
I got an error in GNU ,saying:
: type mismatch in initialization of `p' (use `const').
  well, I don't know where to pu const !
Is there an error? 
2.Someone has put here the gnu c++ without putting the manual in man.
 Do you know where I can ftp the manual ?
 (for Sun's).


Thanks in advance.


I've got to change my panties,now -please e-mail them in
kilitzir@csi.forth.gr
kilitzir@csd.uch.gr
From: flynn@cats.ucsc.edu (Eric Alan Flynn)
Newsgroups: comp.lang.c++
Subject: Re: Multiple Header Files Problem
Date: 11 Nov 1992 22:06:37 GMT
Organization: University of California; Santa Cruz
Distribution: world
NNTP-Posting-Host: am.ucsc.edu

(message paraphrased) why won't this work?
add the following line
class B;
This creates a forward declaration of the class B.

>class A
>{
>public
>   B* pB;
>   void foo();
>};
>void A::foo()
>{   
>   pB = new B(this);
>}
>class B
>{
>public
>   A* pParentA;
>   inline B(A* pA) {pParentA = pA};
};

Note that the only thing you can do is use B to create a B* pointer,
so if you want to members of A to access _methods_ of B,
 you will have to declare those methods of A out of
line, after the delcaration of the class B.

Hope this helps,

Eric

>TH Koh
>gthkoh@ntuix.ntu.ac.sg
Newsgroups: comp.lang.c++
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: Criticisms Wanted
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Wed, 11 Nov 1992 17:51:17 GMT

In article <1992Nov11.170816.24497@cc.gatech.edu> brianm@cc.gatech.edu (Brian N. Miller) writes:
>In article <BxGu0p.D3o@slipknot.rain.com> robert@slipknot.rain.com.UUCP (Robert Reed) writes:
>>
>>The argument goes that if you
>>still have to examine the internal workings of component classes to determine
>>how to best use them, then their value as components has been greatly
>>diminished.
>
>Ok.  So anybody have any ideas?

Documentation, anyone?
Obviously the C++ syntax for the class interface does not tell me anything about
how to use the class correctly for a given situation.  If I am a provider of a class,
surely it is my responsibility to identify the needs of my clients (the users of 
the class) and to give them sufficient information about the class.  

The real question is *why* does the user have to look into the inner workings of
the class?  Surely not to discover the inner workings, but to discover behavioural
characteristics of the class.  Will these be clear from looking inside the class?
Does the user enjoy poking his nose around where he doesn't belong?

I don't think that C++ is self-documenting code.  Usage notes should be provided
where appropriate.

Stuart

--
: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
Newsgroups: comp.lang.c++
From: dag@control.lth.se (Dag Bruck)
Subject: Re: enum labels
Keywords: enum labels
Organization: Department of Automatic Control, Lund, Sweden
Date: Mon, 9 Nov 1992 07:57:07 GMT

In <comp.lang.c++> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>
>I posted a kvetch about this a little while ago.  I agree that
>allowing overloading of the simple types (int long float etc)
>could lead to massive confusion and hard to find bugs, but an 
>enum is NOT a simple type, and does not need the same protections.

The C++ standardization committee has voted to allow overloading based
on enumerations, e.g.,

	enum Status {Fatal, Bad, Good};

	Status operator | (Status a, Status b)
	{
		if (int(a) < int(b))
			return a;
		else
			return b;
	}

I believe some compilers already permit it.

		-- Dag
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: Debugging output
Summary: call me crazy, but relying on compiler bugs is not a good idea
Date: 12 Nov 92 18:40:30 GMT
Reply-To: jamshid@emx.utexas.edu
Distribution: usa
Organization: The University of Texas at Austin; Austin, Texas

In article <BxAz2L.n4M@cs.uiuc.edu> pjl@cs.uiuc.edu (Paul Lucas) writes:
]In <1992Nov6.135017.6870@news2.cis.umn.edu> hansen@deci.cs.umn.edu (David M. Hansen) writes:
]>> 	#ifdef DEBUG
]>> 	#	define	CDEBUG	if ( debug ) cerr
]>> 	#else
]>> 	#	define	CDEBUG	//
]>> 	#endif
]>> 	CDEBUG << "here\n";

]>It is a bug because it means you have to be _very_ careful about how you 
]>comment your code.  For example, [...]

]*****>	I already pointed out that this only works on C++-ignorant
]	preprocessors; the above example is a well-known pitfall and I
]	consider it irrelevant.  You always have to do everything
]	carefully.

The only thing irrelevant here are your continued assurances that it
works on some broken C++ implementations.  So what?  Your code is
wrong.  Why even present, much less defend, your solution?

Jamshid Afshar
jamshid@emx.utexas.edu
Newsgroups: comp.lang.c++
From: root@berta.bln.sni.de (0000-Admin(0000))
Subject: Re: c++ & c+++
Organization: Siemens Nixdorf Informationssysteme AG, Berlin, Germany
Date: Tue, 10 Nov 1992 09:10:35 GMT

willittl@spock.NMSU.Edu (William  Little) writes:


>Okay, a couple quick questions.

>My employer recently bought Borland c++ compiler for
>windows and told me he bought some new C+++.  I personally
>have never heard of C+++.  Has anybody else?  Could he
>be confused about the Borland C++ 3 compiler for windows?

>Now, on to my c++ questions.

>In the past week I bought a couple books on c++ so I can 
>finally figure out what the difference is.  WOW!  I have
>been doing things the hard way!  But, I guess I will find
>out what it is worth when I start developing a windows
>application... ick.

>The books I bought were for beginners, and didn't tell me 
>much.  I went through them in a couple hours, and came up
>with some questions in areas they didn't cover.

>They made references to the functions and variables in 
>classes two different ways.

>first:

>class.variable
>class.function()

>That was expected...

>Then, they did this:

>class::variable
>class::function()

>Also, when they created a class such as:



>class test   (simplistic flow - no flames please)
>  {
>  define variables....

>  function1(){
>     code;
>     }

>  function2(){
>     code;
>     }

>  function3();
>  }   // end class

>test::function3() {
>   code;
>   }

>main() { did the goodies }

>They created function3 inside the test class, yet defined
>the code for it out of the class definition, and used those
>nasty ::'s that confuse me so well.

>What do the ::'s do??

>The books I bought used them all over the place,  but never
>told me what they did.

>Please help..  :)

>Joseph Good
>(The sole user of a good friends donated unix account)

>willittl@nmsu.edu

It's so trivial, maybe you should read your books more intensive !!!
:: is named the scope Resolution Operator, and one Application, beneath others,
is the definition of Memberfunctions out of the class defintion.

Lars Eisenblatt
Usually
lars@pfm.rmt.sub.org
Newsgroups: comp.lang.c++
From: leo@avs.com (Leo O'Donnell)
Subject: Objects in shared memory
Organization: Advanced Visual Systems Inc.
Date: Thu, 5 Nov 1992 20:10:13 GMT
X-Newsreader: Tin 1.1 PL4
X-Posted-From: aurora.avs.com
NNTP-Posting-Host: sol.ctr.columbia.edu

    This question has been asked before but...

    I need to pass pointers to objects between processes. I have a
    few ideas that might work, but would really welcome any suggestions
    that you may have. In the cases that I am considering, the classes
    will all be self-describing (ie will have a class type member).

Leo O'Donnell                Email: leo@avs.com
Advanced Visual Systems      Voice: (617) 890-4300 ext 2120
Waltham, MA
Xref: sparky comp.lang.c++:16208 comp.std.c++:1558
From: hf@telematik.informatik.uni-karlsruhe.de (Harald Fuchs)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: The fate of my exponentiation operator proposal
Date: 13 Nov 92 11:24:07
Organization: Karlsruhe University, Germany
NNTP-Posting-Host: whyaduck.telematik.informatik.uni-karlsruhe.de
In-reply-to: matt@physics16.berkeley.edu's message of 12 Nov 92 23:42:42

In article <MATT.92Nov12234242@physics16.berkeley.edu>, matt@physics16.berkeley.edu (Matt Austern) writes:

> I believe, however, that it is a mistake to dismiss the importance of
> syntax so readily.  Syntax matters!  Syntax is the reason why C++
> (unlike, for example, Objective C) supports operator overloading; for
> that matter, syntax is the only reason why C++ (again, unlike, for
> example, lisp) has operators at all.

I don't think so. At least the assignment operator is not merely
syntactic sugar. Together with the copy constructor it is used to
describe object cloning; thus it must be overloadable. Allowing the
other operators to be overloaded was then only the removal of a
restriction instead of a syntactic extension.
Hey, since the predecessor of C++, ``C with Classes'', didn't provide
operator overloading _except_ for operator=, this might have been the
way the language evolved. Maybe someone from AT&T can comment on this?
--

Harald Fuchs <hf@telematik.informatik.uni-karlsruhe.de>
Newsgroups: comp.lang.c++,comp.std.c++