HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: PROPOSAL: Hidden private parts of classes
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 10 Nov 1992 01:19:38 GMT

In article <1992Nov9.032225.10320@taumet.com> steve@taumet.com (Steve Clamage) writes:
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>>	Having hidden data variables causes the compiler some minor
>>inconvenience, not knowing the length. However private non-virtual
>>member functions cause no problems (if they were allowed). These are
>>IMHO needed so as to be able to write small helper members in
>>the implementation, I've suggested this be allowed, a suitable 
>>syntax does not suggest itself though.
>
>If you mean private non-virtual member functions which don't appear in
>the class definition, it would cause another language change.

	Yes, I propose ad additional keyword 'hidden' as well.
Hidden is like private, but is truly invisible not just inaccessible.
Static and non-virtual hidden functions can be defined without
declaring them in the clas interface, data must be declared in the
interface (but is still not visible outside the class).

>Overloading is resolved before accessibility is checked.  Suppose we have:
>
>	class X {
>	    foo(double);	// private
>	public:
>	    foo(int);
>	};
>	void bar()
>	{
>	    X x;
>	    x.foo(2.0);		// which foo() ?
>	}
>
>This code is in error, since the best match is a private function.  The
>semantics would change if "foo(double)" did not have to appear in the
>publicly-used class definition; "foo(int)" would be called.  Overloading
>is resolved first precisely to avoid quiet semantic changes based only
>on access rights.

	I know. I do not propose to change 'private', but only add 'hidden'.
It would even be possible to have two different definitions of hidden
functions in different modules (thought perhaps not desirable).
Similar calls in private functions and public ones might resolve
differently, which is not nice, but neither the deriver nor the public
will need to cope with this, only the programmer of the class
implementation. 

	In anycase there are several situations where one might
desire something like hidden functions. Often I am implementing
a class and need a helper member, I do not want this arbitrary
part of the implementation to be visible or cause recompilation
of client modules. Such helpers are particularly needed in C++
which does not allow nested functions. It is possible to write
non-member static helper functions, but not members.

	Perhaps there is a better way to do it.

-- 
;----------------------------------------------------------------------
        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: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Discriminating Variant Records Without switch() ??
Date: Thu, 12 Nov 1992 22:00:50 GMT
Organization: Security APL, Inc.

In article <BAB.92Nov12074430@se39.wg2.waii.com> bab@se39.wg2.waii.com (Brian Button) writes:
>->"Matthew" == Matthew Holiday <holiday@bnr.ca> writes:
>   Matthew> switch statement! :-) There ought to be a convenient way
>   Matthew> to create objects from network messages, i.e., some way to
>   Matthew> register message types and their matching class types,
>   Matthew> such that for every incoming message, its body (an array
>   Matthew> of bytes) gets turned into the correct object, which would
>   Matthew> be derived from a root generic message object.
>
>There is such a way using factory classes such as the RogueWave
>RWFactory class. The problem I'm having is figuring out how to deal
>with these objects after they are already created. Since there's no
>common set of operations which are performed on each of the objects,
>there is no set of methods which may be made virtual and overloaded.
>Herein lies the problem. This seems to point towards using special
>purpose code for each class, which would necessitate using a switch.
>
>Have I painted myself into a corner or is there some way out. How are
>the rest of you OOP programmers dealing with cases like this?

You are obviously reading these all in one place, so you must be doing
*something* with them.  Maybe just "handling" them -- which would suggest
that the base class should have a virtual handle() method, which is
implemented for each subclass to do whatever needs doing for that type of
object.  There may not be any other commonality -- if there isn't, don't try
to force it where it doesn't exist.
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: WHERE CAN ONE BUY AN ELEGANT AND EFFICIENT CLASS LIBRARY?
Date: 8 Nov 92 18:02:21 GMT
Article-I.D.: alice.24115
Organization: AT&T Bell Laboratories, Murray Hill NJ



mbersohn@alchemy.chem.utoronto.ca (M. Bersohn @ University of Toronto Chemistry Department) writes

 > One person
 > discussing this library pointed out that USL is a subsidiary of AT&T
 > where the inventor, Bjarne Stroustrup, and his colleagues work.

Small correction: I work at AT&T Bell Labs as I have done for all the
time I have worked on C++. Some ``C++ old-timers,'' notably Jonathan
Shopiro, works for USL now, but many are still at AT&T Bell Labs (as ever).
 
(this is not a comment on library design or quality).
Newsgroups: comp.lang.c++
From: miro@netcom.com (Miro Systems)
Subject: stream method zapeof ???
Keywords: stream zap eof
Organization: Miro Systems, Inc.
Distribution: usa
Date: Tue, 10 Nov 1992 14:22:46 GMT

I do not have access to AT&T's stream library, only g++'s.
In InterViews there is a stream method:
	 int zapeof(char*)
Gnu's g++ library does not have this method.
Could some kind soul please tell me what zapeof is suppose to do so that
I can write a work around.

Thanks

Richard Emberson
rme@miro.com


Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Multiple Header Files Problem
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.20 $
Organization: Trumphurst Ltd.
Date: Thu, 5 Nov 1992 12:56:00 +0000

In article <1992Nov03.133949.21465@rs6000.bham.ac.uk> pickerig@eee.bham.ac.uk (Mr. G. Pickering) writes:
> Koh Thong Hwee (gthkoh@ntuix.ntu.ac.sg) wrote:
> : The above class declarations gave problem as each declaration cannot be 
> : completed because of the other.  Before class A is declared, it takes a
> : pointer to class B.  But class B cannot be declared because it takes a
> : pointer to class A (I have need to know its parent object).  There must
> : be an obvious way out of this, however I just cannot see it...
> : 
> 
> Rather than putting just "A*" and "B*" use "class A*" and "class B*"
> instead. This tells the compiler that A and B are classes and it
> resolves them later.
There are compilers that won't recognise this syntax correctly. A more 
portable solution is to make a separate forward declaration of class B 
before declaring class A, thus ...

class B;		// Forward declare 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};
};

-- 
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: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: member test?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 13 Nov 1992 21:29:23 GMT

In article <1992Nov10.070124.5763@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
>In article <EB.92Nov9085335@ascent.ascent.com> eb@ascent.com (Ed Barton) writes:
>>In article <1992Nov6.081658.29693@bernina.ethz.ch> haechler@bernina.ethz.ch (Stefan Haechler) writes:
>>
>>   How can I know which dynamic type has a variable ?
>> ...
>> ...
>>The software-design answer is that you shouldn't have to know the
>>answer to this question, and that there may be something wrong with
>>the design if you need to ask it.  If you know only that something is
>>a pointer-to-A, you should be using only the methods and virtual
>>functions that are part of the interface defined by class A.
>> ...
>
>Come on, there are many fully reasonable and legitimate situations
>in which one needs to know this.  And C++ is almost the only OOPL
>I know of in which you cannot ask the dynamic type of an object.
>

	In the single address-space standalone program model
on which C++ is characterised it is never necessary to ask for
the dynamic object type. That is, in a domestic program,
one which creates all its objects itself, the program
knows the type of the objects at construction time and is simply
badly designed if the type information is lost when it is needed.

	A typical case, a list of objects of various types is often
raised. It illustrates in my opinion a need for C++ to have better
facilities for genericity such as tagged pointers, rather than
unconstrained type testing. (See my tagged pointer proposal).

	The problem with asking an object its type IMHO is
that one often deliberately loses this information.
That purpose would be defeated if the information could be arbitrarily
got back. In particular, if I have an Abstract Class A, and I have
various implementations of A, so I construct A objects of various
kinds, then I return pointers to A objects, I do NOT want anyone
bypassing the Abstract Interface I have deliberately declared
to restrict access to my objects.


-- 
;----------------------------------------------------------------------
        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: kanze@us-es.sel.de (James Kanze)
Subject: Re: Debugging output
Organization: SEL
Date: 5 Nov 92 20:34:43

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

|> [Sorry if this is a re-post. The first one seemed to get lost.]

|> 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.

Example deleted.

|> Is there a preprocessor macro trick to remove the dbg << statements? (doubtful)

|> Can I somehow define the << member fns as empty inline functions so that the
|> compiler will effectively remove them (i.e. generate no code for such calls).
|> e.g. something like:

|> 	inline dbg_stream & operator << (char *c) 
|> 		{
|> 		    // do nothing
|> 		}
|> This doesn't work seem to work -- using g++ still generates code.

|> Is there a better method?  (e.g. making dbg a reference to an ostream?)

|> Thanks for any suggestions.  I'll summarize if there's sufficient response.

Why not the following:

	#ifdef DEBUG
	#define	TRACE( x )	do					\
		{							\
			 if ( traceFile )				\
				 *traceFile << x ;			\
		} while( 0 )
	#else
	#define	TRACE( x )
	#endif

You then simply write:

	TRACE( "Got here, i = " << i ) ;

Whenever you what your debug output.

Two notes:

1. Don't put the x in the macro expansion in parentheses.  (This is an
exception to the normal rule.)

2. Because of the if, you can toggle tracing on and off by setting
traceFile to NULL or to &cerr (or to any other file you want).

In fact, because of point 2, I generally like to leave the debug code
in, even in the delivered version.  (In this case, I'll usually check
that there is a specific environment variable set to a special value
before accepting any options/commands to turn it on.  No need for the
customer to get a surprise because he mistyped and option, and got the
debug option.)
--
James Kanze			GABI Software, Sarl.
email: kanze@us-es.sel.de	8 rue du Faisan
				67000 Strasbourg
				France



Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Multiple Header Files Problem
Organization: Rational
Date: Tue, 10 Nov 1992 01:37:04 GMT

A more interesting variation on this issue is the problem of "circular
inclusion".  Consider a source file: "a.h" which includes "b.h".
However, "b.h" includes "a.h".  This trivial example will fail to
compile.  Unless the compiler is very clever (I haven't seen one yet),
it will sit and spin until it exhauses some resouce (usually memory),
and then it will die a horrible death.  If it prints an error at all,
the error is nearly certain to have nothing to do with the circular
containment.

Now this may not seem to be a horrible problem.  But consider that, no
matter how many files are involved in the circularity, the malfunction
of the compiler will be the result.  This if "a.h" includes "b.h"
which includes "c.h" which includes "d.h" which includes "e.h" which
includes "a.h"; then the compiler will still hang up.

C++ programs are notorious for long and frenetically branching
inclusions.  If care is not taken to limit the number of #includes
placed in header files, the probability of encountering a circularity
increases with every new class that is created.  When a circularity
does occur, finding it can take a very long time.  Just realizing that
the problem is a circularity is a challenge.  Finding the sources of
the circularity is non-trivial.  And fixing it is not always that easy
either.

Thus, it is a good idea, if you are planning a major C++ effort, to
put some thought into designing the physical dependencies of your
source files.  Moreover, use forward declarations instead of #include
wherever possible.  And to that end, avoid inline functions in your
header files, if those inlines force you to use a #include rather than
a forward declartion.  Also, use references and pointers as opposed to
values in data members, member function arguments or return values; if
those values force you to use #includes rather than forward declarations.

--
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++
From: kanze@us-es.sel.de (James Kanze)
Subject: Re: yagh!(yet another hard g++ (problem))
Organization: SEL
Date: 13 Nov 92 20:17:03

In article <kilitzir.721570562@news.forth.gr>
kilitzir@antigone.csi.forth.gr (Xristos Kilitzirakis) writes:


|> Suppose the following program :
|> ----------------------

	[actual program deleted...]

|> -------------------------
|> 1.(compiled under g++ with unknown version).
|> Now, there's a compiler error in line "base x2 = f2()" - YET the 
|> statement "x = f2();" IS CORRECT!Any comments ?

This is just another GNU bug.  If you use g++ any length of time,
you'll get used to them.

G++ has definite problems when it comes to generating default copy
constructors, at least in derived classes.  The work-around is always
to provide your own copy constructor for derived classes.  (At least,
it worked for me.  The context where I saw this bug was considerably
different.)

Oh, well, you can always console yourself with the thought that you
got what you paid for.

|> 2.What do you expect for the program to write ???
|> answer --> bbb bbb !
|> Is that also correct ???

Actually, since there were three calls to the "show" routine, I'd
expect "bbb bbb bbb".

(BTW, you forgot to declare the return type void of the "show"
routines.)
--
James Kanze			GABI Software, Sarl.
email: kanze@us-es.sel.de	8 rue du Faisan
				67000 Strasbourg
				France
From: kevinc@hpcc01.corp.hp.com (Kevin Collins)
Date: Thu, 5 Nov 1992 19:24:08 GMT
Subject: Re: Inheritance & operator overloading
Organization: the HP Corporate notes server
Newsgroups: comp.lang.c++

The answer was provided by Steve Vinoski :

The correct call is :

Block<Type>::operator[](i);

Thanks Steve.

Newsgroups: comp.lang.c++
From: pj@sam.wpd.sgi.com (Paul Jackson)
Subject: Re: Making qsort type-safe
Reply-To: pj@sgi.com
Organization: Silicon Graphics, Research & Development
Date: Thu, 5 Nov 1992 05:08:14 GMT

In article <1992Nov5.004640.24689@netcom.com>, mdr@netcom.com (Marc D. Rossner) writes:
|> In article <1992Nov4.162131.10289@cs.brown.edu>, sdm@cs.brown.edu (Scott Meyers) writes:
|> [[ Deleted: example template wrapper for qsort ]]
|> 
|> Heesh, this principle of "not reinventing the wheel" can be taken to
|> extremes.  It's really not THAT much effort to just write a templatized
|> qsort for C++ directly (Lippman, 2nd ed. has it on page 194, in about 15 lines
|> of code).

A similar qsort() is on page 94++ of Hansen's "The C++ Answer
Book."  Hansen then spends another six pages and a few hundred
lines of code improving it, to be more "industrial strength."
The qsort in the libc nearest to me at the moment has 209 source
lines, including comments.

This is not a religious issue to me -- sometimes I reuse,
sometimes reimplement.  But in this case the trade offs are very
clear - use the libc qsort, perhaps with the nifty wrapper Scott
suggested.  Thanks Scott.

-- 

				I won't rest till it's the best ...
				Software Production Engineer
				Paul Jackson (pj@sgi.com), x1373
Newsgroups: comp.lang.c++
From: dunkle@src.dec.com (David William Dunkle)
Subject: Re: the deal with templates
Organization: DEC Systems Research Center
Date: Thu, 12 Nov 92 03:38:12 GMT

>From: matt@physics.berkeley.edu (Matt Austern)
>It certainly would be nice if compilers handled templates better than
>they do; I'm sure that compiler writers are working on that.  It would
>also be nice if I could get my hands on a compiler that supported
>exceptions...  

I'm a very biased, but the DEC C++ compiler supports both templates (reasonably
in most aspects IMHO) and exceptions. Its associated debugger, DECLadebug
also provides basic support for both features. For instance, you can say:

stop in foo<int>::bar

etc.

Its only available on DEC platforms at this time.

david
Newsgroups: comp.lang.c++
From: xjzhu@math.uwaterloo.ca (Xiaojun Zhu)
Subject: Summary: Dynamically allocate and de-allocate a 2-dim'l array.
Keywords: new, delete, dynamic array
Organization: University of Waterloo
Date: Fri, 13 Nov 1992 17:42:04 GMT

Object: 
         1. Giving thanks to all those who responded to my question
         2. Trying to give the answer.

Tip:
        When de-allocate an dynamically allocated array, use
        delete[] operator. (See <<C++ Programming Language>>,
        2nd Edition, P.98)

Code segment:

   0. Declaration:

      typedef int T;  

      int row, column;
      T **array;

   1. Allocation: 
                  // note: row and column should have assigned values
                  // at this stage

      array=new T*[row];
      for(int i=0; i<row; i++)
      {
         array[i]=new T[column];
      }
       
   2. Deallocation:
                   // note: several of you have pointed out to me that
                   // the order is not important, anyway, I figured
                   // to stick to the reverse order.
      for(i=row-1; i>=0; i++) 
      {
          delete[] array[i];
      }
      delete[] array;
From: graphics@foggia.ATC.Olivetti.Com (Franco Pallavicini)
Newsgroups: comp.lang.c++
Subject: HELP NIHCL!!!!
Summary: Porting NIHCL
Date: 12 Nov 92 17:31:25 GMT
Reply-To: carlabo@xdml1
Organization: Olivetti ATC; Cupertino CA, USA

Hi, 
has anyone of you tried to port Process Classes of NIHCL 3.0
on a i386 with UNIX SystemV R4.0 and AT&T C++ 3.0.1??
I have a lot of problems in doing this and I have absolutely need
to compile these classes!!!!!!!!

         Thanks in advance........

                     Carla 
-----------------------------------------------------------
Carla Bonci(OLIVETTI-Italia) 
Newsgroups: comp.lang.c++
From: rosenber@aton.abo.fi (Robin Rosenberg INF)
Subject: templates within templates
Organization: Abo Akademi University, Finland
Distribution: comp
Date: Wed, 11 Nov 1992 21:51:58 GMT


I tried using templates like this:

    Ref<Node<T>> obj;

I tried Borland C++ (3.0) and g++ (2.1) and neither accepts the
syntax. If I change this to

    typedef Node<T> Node_T;
    Ref<Node_T> obj;

then it is accepted.

So the questions are:
    Is it legal to use a template as class argument for a template?
    If yes; which compilers accept it ?
    Any ideas of how to avoid the problem besides using typedefs?

----
    Robin Rosenberg


Newsgroups: comp.lang.c++
From: greg@qualcom.qualcomm.com (Greg Noel)
Subject: Can this be done with iostreams?
Organization: Qualcomm, Inc., San Diego, CA
Date: Thu, 12 Nov 1992 02:14:15 GMT

Here's a fragment of code that I would like to convert to use iostreams.
The idea is that it inserts some stuff onto the output stream, copies the
information from the calling location, and then regains control so that
it can finish up.

	void
	Class::Err(char *msg, ... )
	{
		va_list ap;
		printf("Line %d of `%s': ", linenumber, filename);
		va_start(ap, msg);
		vprintf(msg, ap);
		putc('\n', stdout);
		va_end(ap);
		++errorcount;
	}

I'd like the result to look more like C++, perhaps something like:
	Class Input; char *str; int i;
	Input.Err() << "found bad input: " << str << " and " << i;

Failing that, is there some way using iostreams to simulate the original?

There was a thread a bit ago about controlling debugging output that has
a similar flavor.  If this can be done, perhaps a similar technique can
be used for that sort of thing.

Tks,
-- 
-- Greg Noel, Unix Guru         greg@qualcomm.com  or  greg@noel.cts.com
From: ameesh@lsil.com (Ameesh Desai)
Newsgroups: comp.lang.c++
Subject: Re: Linking C++ and C
Date: 13 Nov 92 21:18:54 GMT
Reply-To: ameesh@lsil.com
Organization: LSI Logic Corporation

In article 22547@cucs5.cs.cuhk.hk, hclam@cuse1.se.cuhk.hk (LAM Ho Cheong) writes:
>I got a problem of linking C & C++ programs using the Turbo C++ for
>Windows on PC. I'm going to link some C source codes and some C++ 
>source codes. I need to invoke certain C-like functions defined in a C++
>codes in a C codes. However, the linker replies me that no such functions
>have been declared. That means the functions defined in the C++ codes are
>not accessable from the C codes. Can anyone give me some advice?
>
>test1.cpp                          test2.c
>....                                main()
>void f(void)                       {
>{                                     ...
>    printf("Hello, World\n");         f();
>}                                     ...
>....                                }
>
>linker error: "function _f is not declared in module "test2.c""!
>
>It's natural because I'm using some more advanced stuff (C++) by a less 
>advanced stuff (C). But, I need to solve this ...
>
>I'll appreciate any advice sent to me at hclam@se.cuhk.hk
>
>Thanks in advance.


Use extern "C" linkage specification for defining f() in test1.cpp


Ameesh
---
______________________________     o__            
| _   /|     Ameesh Desai     \    ,>/_                              
| \`O.o'     LSI Logic Corp.   \__(_)`(_)_              email: ameesh@lsil.com
| =(_|_)=    MS E192, 1501 McCarthy Blvd. \             fax  : (408) 433-6802
|____U_______Milpitas, CA 95035____________\____________voice: (408) 433-4097