HDTenEightyP/NetNews huggingface dataset:
From: reindorf@us-es.sel.de (Charles Reindorf)
Subject: Re: Multiple Header Files Problem
Organization: SEL-Alcatel Line Transmission Systems Dept. US/ES
Date: Tue, 10 Nov 92 10:44:47 GMT

In article <rmartin.721359424@thor>, rmartin@thor.Rational.COM (Bob Martin) writes:
|> 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.
|> 
|> [ etc.]

It is usual, in header files, to structure them so :


| # ifndef <HeaderFileName>_h
| # define <HeaderFileName>_h
| 
| 
| ... body of include file ...
| 
| 
| # endif


Where of course <HeaderFileName> is some valid identifier based on the name of
the header file (and intended to be unique).

This prevents cyclic dependencies and has been in common practice for, well, ages.

N.B. It can give rise to other dependency problems, e.g.

Header File A.h:

|  # ifndef A_h
|  # define A_h
|  
|  # include <B.h>
|
|  class A
|  {  
|     public:
|      ... etc ...
|     private:
|     B *b;
|     ... etc ...
|  };
|  
|  # endif

Header File B.h:

|  # ifndef B_h
|  # define B_h
|
|  # include <A.h>
|
|  class B
|  { 
|     public:
|     A a_func();
|     ... etc ...
|  };
|
|  # endif

In which neither header file will scan, but then using forward declarations instead
of direct includes generally solves these problems.

All options are my own etc.

--- Charles Reindorf


Newsgroups: comp.lang.c++
From: ort@netcom.com (David Oertel)
Subject: Re: Debugging output
Summary: nested includes, when?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Wed, 11 Nov 1992 08:24:34 GMT



> From: rmartin@thor.Rational.COM (Bob Martin)
> So, take care when using #include in a header file.  Always be sure
> that you the #include is necessary, and that it cannot be replaced
> with a forward declaration.

	I needed header file includes for defining base class interfaces but
	used forward references for everything else.  Are there other 
	situations where header file includes are necessary?  Merely putting
	one dependent include file before another in the source file is
	considered equivalent to using a nested include in this question.

	Thanks in advance,
	ort@netcom.com

-- 
Newsgroups: comp.lang.c++
From: ded@aplcen.apl.jhu.edu (nod sivad)
Subject: Re: Just what is so great about streams?
Reply-To: ded@aplcen (nod sivad)
Organization: Johns Hopkins University
Date: Thu, 12 Nov 92 17:16:41 GMT

>This posting is a genuinely answer-seeking question,
>
>  what _is_ so great about streams?
>  

If you're a purist, you have to use streams to remain pure.

If you're a beginner with no knowledge of C, you should probably use 
streams since they offer superior type checking.

If you're already familiar with the printf() IO scheme, you can
ignore the purists.  They'll whine and complain
and overstate their position, but the fact is streams offer little
advantage over printf().  The real advantages of C++ lie elsewhere.

				me
Newsgroups: comp.lang.c++
From: bill@amber.csd.harris.com (Bill Leonard)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: PROPOSAL: Hidden private parts of classes
Date: 9 Nov 92 19:32:55 GMT
Distribution: ssd
Organization: Harris CSD, Ft. Lauderdale, FL
NNTP-Posting-Host: amber.ssd.csd.harris.com

In article <klamer.721303355@mi.el.utwente.nl>, klamer@mi.el.utwente.nl (Klamer Schutte) writes:
> 
> I doubt it. I can't see how a compiler can build a stack frame with
> auto variables, if the sizes of the elements on the stack frame are
> unknown. What can be done, is putting a pointer to the actual data in
> the stack frame, and allocate the data element itself on some heap
> (preferably a fast one, like alloca()). 
> 
> Otherwise the offsets of individual elements in the stack frame are unknown
> at compile time. These might be patched back at link time. (seems dirty
> to me). Allowing this you might loose some optimization opportunities.

Why do stack frames have to be fixed size?  Many languages, including Ada,
allow for automatic objects whose size is determined at runtime.  This is
not new technology, nor even all that hard.  In most implementations, the
compiler allocates a fixed-size part of the frame for its own use (like
register saving and such), plus all the known-sized automatic objects.  It
then computes the amount of space needed for variable-sized objects and
extends the stack frame by that amount.

In some languages, like Ada for instance, variable-sized objects can even
be declared in nested blocks and/or returned from functions!  This means
that the stack frame must grow and shrink as the function executes.  That
gets a little more complicated, but again, the technology is not new.

I think the clever thing to do for C++ would be to make the sizeof operator
be specifiable by the user, with arguments specified after the constructor
arguments, say.  For instance:

    Foo   * x = new Foo(/* constructor args */) (/* sizeof args */) ;

The built-in sizeof operator would automatically generate a function if the
size of the object is not known at compile-time.  This would necessitate,
of course, some way to indicate that you wanted to defer the complete
specification of the class in its declaration, and also some way to
complete that specification elsewhere.

As much as I would like to see this feature, though, I wouldn't argue for
its inclusion in the current standard.  Defer it until the next revision,
perhaps.  The standard has dragged on long enough -- it certainly has
enough in it to be useful (as evidenced by the large number of C++ users
already).

-- 
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.csd.harris.com
---------------------------------------------------------------------------
Prism: A place for light waves that commit minor refractions.
---------------------------------------------------------------------------
Newsgroups: comp.lang.c++,comp.lang.c,comp.os.msdos.programmer
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Poll : Microsoft support on the Internet
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
Followup-To: comp.lang.c++
X-Mailer: cppnews $Revision: 1.20 $
Organization: Trumphurst Ltd.
Date: Wed, 11 Nov 1992 12:18:09 +0000

In article <720997472snx@trmphrst.demon.co.uk> mscyes@trmphrst.demon.co.uk writes:
> I have been conducting a poll about whether readers would like Microsoft 
> to provide support for their languages (particularly C7/C++) on the Internet.
> 
> Responses so far :
> Yes : 
> No  :
Oops - I forgot to include the figures. As of today, they are ...

Yes : 187
No  : 6
-- 
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.
From: jep@cs.duke.edu (Jonathan E. Polito)
Newsgroups: comp.lang.c++
Subject: Class scope and class declarations
Date: 6 Nov 92 20:54:24 GMT
Distribution: comp
Organization: Duke University CS Dept., Durham, NC


Hello,
	I have a question that seems somewhat open to interpretation.
I have not been able to find a specific reference in the ARM, nor in
Lippman's C++ Primer.

It is clear that:
class X;

class Y {
public:
	Y();
private:
	class X* xptr;
};

class X {
public:
	int info;
};

Y::Y() {
	X tmp;
	tmp.info = 1;
}

will cause tmp to be defined as a class X (at file scope) object. What
if the first class X; forward declaration is deleted though? Is the
effect then that xptr in class Y is a pointer to a local class X that
is never defined? This is one interpretation though I have seen a
number of programs that rely on class X* to be a forward declaration
to a class defined later at file scope.

Thanks in advance,

Jon.
--
Jonathan Polito                                      DoD #x (K 100)
jep@cs.duke.edu                                  jpolito@encore.com 
              "You Don't Say...." --- Sylvia Plath
Newsgroups: comp.lang.c++,comp.lang.c,comp.os.msdos.programmer
From: simms@ux1.cso.uiuc.edu (dan simms)
Subject: Re: Poll : Microsoft support on the Internet
Organization: University of Illinois at Urbana
Date: Sun, 8 Nov 1992 22:03:59 GMT

nikki@trmphrst.demon.co.uk (Nikki Locke) writes:

>I have been conducting a poll about whether readers would like Microsoft 
>to provide support for their languages (particularly C7/C++) on the Internet.

>Responses so far :
>Yes : 
>No  :

>The poll will close in ten days, when I will forward the final figures to 
>Microsoft.

Regardless of what you (or even the whole internet) wants the internet is
not for profit making, even if it would make it easier for academia to get
support.  Microsoft providing customer support over the internet would 
_have_ to be a violation..   

						dan



Newsgroups: comp.lang.c++
From: dan@BofA.com (Dan Brockman)
Subject: Re: something nasty
Organization: Bank of America, Capital Products, RMTG #5906
Date: Fri, 13 Nov 92 05:08:29 GMT


I have received much correspondence of late regarding
error message "...bus error or something nasty...".  Many
have seen it, and each seems to have traced it to a different
specific problem.  No strong patterns.  Many suggested
"get another compiler".  
-- 
 --------------------------------------------------------------
 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
Newsgroups: comp.lang.c++,bnr.lang.c++
From: gschwarz@dcc.uchile.cl (Guillermo Schwarz Utrup (Coto))
Subject: Re: Criticisms wanted
Date: Thu, 05 Nov 1992 15:20:19 GMT
Organization: Universidad de Chile, Depto. de Ciencias de la Computacion
X-Newsreader: TIN [version 1.1 PL6]

D.S.Riches (dsr@bnr.co.uk) wrote:
: I'd like to know about other issues such as; is C++ easier to test than
: C, is it possible to determine which object is invoked before another
: object and so on.

  Each module (I mean each Class) is easier to test because it clearly
performs a task and it can be tested by any program only by declaring
an instance of that class. If the class works, the problem is not there.
If all classes works, there is no problem :-)

  That's theory, no software really works (refer to Murphy's laws), but
it seems to work more times than C modules do.

  Besides, with a C++ debugger you can realize which method call which class.
If you don't have one C++ debugger forget it, buy one first.

  Hope it helps.
Newsgroups: comp.lang.c++
From: hansen@hecto.cs.umn.edu (David M. Hansen)
Subject: Re: Debugging output
Organization: University of Minnesota
Distribution: usa
Date: Mon, 9 Nov 1992 23:51:12 GMT

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:
|> 
|> >In article <Bx9369.3zL@cs.uiuc.edu>, pjl@cs.uiuc.edu (Paul Lucas) writes:
|> >|> *****>	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 allows the flexibility of having debugging "togglable"
|> >|> 	during development, presumeably by a command-line option, but
|> >|> 	can be compiled-out in the final version.
|> >|> 
|> 
|> >I think it is a mistake to rely on what is essentially a bug in many C++
|> >compilers.  According to the ARM (section 16.1, page 370)  "...a single white

[ARM reference and example deleted]

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

True, the example is irrelevant.

True, you _always_ have to do everything carefully.

Perhaps you pointed out that it doesn't always work.  I didn't see it (mea culpa).
This is also irrelevant.

It is _still_ a mistake to rely on a bug.

					-=Dave


Newsgroups: comp.lang.c++
From: gkrishna@alt.uucp (Gopal-Krishnan)
Subject: RPCGEN/C++
Keywords: rpcgen c++ 
Organization: Unisys Corp, Camarillo, CA - 93010.
Date: Fri, 6 Nov 1992 19:26:00 GMT

>>In article <1992Oct8.131946.5836@cs.brown.edu> rbb@cs.brown.edu (Robert Baynes) writes:
>>   Does anyone know of something similar to rpcgen that would produce
>>   the client, server and xdr code in C++? 

> Brian M Kennedy replies:
>In the 1992 USENIX C++ Proceedings there is a paper Minnear,
>Muckelbauer, and Russo (Purdue U) titled "Integrating the Sun
>Microsystems XDR/RPC protocols into the C++ stream model" that
>presents a *very* nice looking approach to XDR/RPC.  The paper
>says:
>  The source for the new I/O stream library and the XDR/RPC
>  classes discussed in this paper is public available for 
>  free distribution.  Interested parties should contact 
>  the authors for more information.
>and gives the authors' email addresses:
>  {minnear|muckel|russo}@cs.purdue.edu
>HOWEVER, I have *repeatedly* tried to contact the authors to
>get the software and have not yet succeeded.  :-( :-{

  1. Did anybody succeed in getting this or some similar software?
  2. Can somebody give me pointers to getting the 1992 USENIX C++ proceedings.
  3. Do any of you have more info on rpcgen/C++.

 Pl reply by mail. If I get enough response I will summarize.

-----------------------------------------------------------------------
Gopal Krishnan          | internet: alt!gkrishna@uunet.UU.net
Unisys Corporation      | voice: 805-389-4446
Open Systems Group      | fax  : 805-389-4420
5155, Camino Ruiz       | Not being able to find *something* 
Camarillo, CA - 93012.  |  does not mean *something* does not exist.
-----------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: Multiple Header Files Problem
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Wed, 11 Nov 1992 14:16:58 GMT

In article <1992Nov11.015747.20842@fcom.cc.utah.edu> swillden@icarus.weber.edu writes:
>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
>: |It is usual, in header files, to structure them so :
>: 
>: || # ifndef <HeaderFileName>_h
>: || # define <HeaderFileName>_h
>: || ... body of include file ...
>: || # endif
>: 
>
>#ifndef SOMEFILE_H
>#include "somefile.h"
>#endif
>

...and others have mentioned _A_H and _a_h, a_inc.  I have also seen
HEADERFILENAME with no _H.  This lack of standard makes it difficult to
follow one poster's suggestion of wrapping the #include with a test
(but I see no real reason to do that anyway).  It also makes it difficult
when trying to test if a system include file has been included (which I
sometimes have to do due to platform differences):  every workstation
seems to have a different convention for wrapping their include files!

On the other hand, everyone has used

# ifndef

and nobody has used

# if !defined

Just curious:  I have always used #if defined and #if !defined, having
noted the ANSI recommendations even many years ago, and all of our C
compilers have always supported this.  Weren't #ifdef and #ifndef supposed to
go the way of the dodo (in new code, if not in compilers)?

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. :
From: dsr@bnr.co.uk (D.S.Riches)
Newsgroups: comp.lang.c++,bnr.lang.c++
Subject: Re: Criticisms wanted
Date: 11 Nov 1992 09:46:59 GMT
Organization: BNR Europe Ltd, London Road, Harlow, England.
Distribution: bnr
NNTP-Posting-Host: 128.199.202.51

In article <1992Nov8.065652.14784@bcars64a.bnr.ca> schow@bcarh2d8.bnr.ca (Stanley T.H. Chow) writes:
>In article <1992Nov5.191155.1078@bmers145.bnr.ca> fraserf@bmerh9a4 (Fraser Fulford) writes:
>>D.S.Riches (dsr@bnr.co.uk) wrote:
>>
>>: Now, I've seen many pro's for the use of C++ but not really any for the
>>: cons of C++.  What I'd like is a set of reasons why C++ shouldn't be
>>: used.  Preferably, I want ones which are just C++ specific and not ones
>>: that can also be applied to C as well.  There is no other language to
>>: be considered and so I'm not interested in suggestions for going to
>>: another language.
>
>If you will not consider any other language, what is the point?

Yeah ok, what I meant was that it was either C or C++ and not C or
Prolog (for instance) :-).  You win a gummy bear :-)


On a more worrying point.  I've only seen a couple of replies to my
original post and those were from T.H. Chow and fraser but they seem to
suggest that there have been other replies which I haven't seen in
good(?) old England here.

Is there an archive of bnr.lang.c++ anywhere?

Dave (felling lonely and isolated :-( )

   Dave Riches
   Email:  David.S.Riches@bnr.co.uk
   Smail:  BNR Europe Ltd, London Road,
           Harlow, Essex. CM17 9NA.  England
   Phone:  +44 (0)279-402496
   Fax:    +44 (0)279-451434
From: richieb@bony1.bony.com (Richard Bielak)
Newsgroups: comp.lang.c++
Subject: Re: Why Hybrids appear so Pure
Date: 6 Nov 92 13:14:30 GMT
Organization: multi-cellular

In article <1bn2d0INNn9v@gap.caltech.edu> donb@cco.caltech.edu (Don
Brotemarkle) writes:

[...]

>In other words, SmallTalk allowed the user to have the same view
>of the programming structures as the programmer.  And this was
>a success. 


I think you've got it backwards :-). Smalltalk allowed the
*programmer* to have the same view as the user, so that the program
could be constructed in terms of things the user understands.


...richie
-- 
* Richie Bielak   (212)-815-3072   |                                          *
* Internet:       richieb@bony.com | Rule #1: Don't sweat the small stuff.    *
* Bang {uupsi,uunet}!bony1!richieb | Rule #2: It's all small stuff.           *
*    - Strictly my opinions -      |                                          *
From: amb@Apple.COM (A. Michael Burbidge)
Newsgroups: comp.lang.c++
Subject: Sources for indent++?
Date: 9 Nov 92 20:07:41 GMT
Organization: Apple Computer Inc., Cupertino, CA

Are the sources for indent++ available by anonymous ftp from somewhere? If so,
where?

Thanks
Mike Burbidge

Newsgroups: comp.lang.c++
From: mbersohn@alchemy.chem.utoronto.ca (M. Bersohn)
Subject: WHERE CAN ONE BUY AN ELEGANT AND EFFICIENT CLASS LIBRARY?
Organization: University of Toronto Chemistry Department
Date: Fri, 6 Nov 1992 15:08:38 GMT

Very many kind people responded to this query.  Unfortunately I didn't
back up my system in time and lost the list of their names. A digest of
the replies follows:  
There were only two class libraries which had the support of more than
one person. Both of these were widely supported.
One is C++ Standard Components Release 3.0, sold by UNIX
System Laboratories, 190 River Road, Summit, N.J. 07901. One person
discussing this library pointed out that USL is a subsidiary of AT&T
where the inventor, Bjarne Stroustrup, and his colleagues work. He said
that the library had the strong influence of these experts. The other
product was Tool.h++, sold by Rogue Wave Products in Oregon somewhere.
Danw@roguewave.com is the email address of the salesperson.
The supporters of this product were quite as positive as those of C++
Standard Components.  There was universal agreement that C++ Standard
Components is difficult to buy since USL is not too approachable. As
one respondent said "They basically don't want to deal with
individuals". Egregious here and absolutely shocking to me is their
failure to advertise in the C++ report.

I made my personal decision to buy C++ Standard Components rather than
Tool.h++ for the following two reasons.
I. In technology the expertise of a real expert has a value to us far
exceeding that of somebody who is simply "pretty good".  I've learned
and relearned this lesson many times in many settings. Of course, with
PR etc. it's often difficult to determine who is the real expert.
Anyway I want to go with a system strongly influenced by the AT&T
experts.
II. The Rogue Wave salesman said that SUN bought their product and will
resell it. I remember very well that SUN didn't have ANSI C for a long
period of time; that's why I bought a different workstation. Their
reasoning seemed to be that most users didn't need or want ANSI C. My
impression is that SUN wants to have the most machines installed and
therefore they will head for the low end and buy the cheapest library
not necessarily the best. So I avoid, in principle, what SUN chooses.

The universe is not random. Surely any company which is selling C++
libraries and doesn't even advertise in the C++ REPORT won't be in that
business forever.
mbersohn@alchemy.chem.utoronto.ca
From: usoderberg@sysinno.se (Ulf Soderberg)
Newsgroups: comp.lang.c++
Subject: operator [][]
Date: 9 Nov 92 18:49:17 GMT
Reply-To: usoderberg@sysinno.se
Organization: System Innovation AB


In article <BxFt8r.2Kt@cs.columbia.edu> duanyang@cs.columbia.edu writes:

 > 
 > for multiple dimension array, is it possible to define 
 > an operator [][](say for two dimensions)? I try to define 
 > it as 
 > int & operator[][] (int, int);
 > 
 > which g++ complains about it. 
 > 
 > any idea or just sth is wrong with my try? 
 > 
 > 
 > -- 
 > Duanyang Guo             |     (212)939-7098(O),   663-8904(H)   
 > CS Dept, Columbia Univ.  |      Rm 625, CEPSR
 > New York,     NY 10027   |      Email:duanyang@cs.columbia.edu  
 > 
 > 

First define a vector of int's, then define a vector of vectors of int's.

Ex.
class Ivect {
	int *vec;

public:
    Ivec(int n)               { vec = new int[n]; }
	int &operator[](int idx)  { return vec[idx]; }
};

class Imat {
	Ivec **mat;

public:
	Imat(int m, int n)
    {
        mat = new (Ivec *)[m];
        for (int i = 0; i < m; i++)
            mat[i] = new Ivec(n);
    }

	Ivec &operator[](int idx)  { return *mat[idx]; }
};

Then I think it is possible to do like this:

    Imat m(4, 3);

    for (int i = 0; i < 4; i++)
        for (int j = 0; j < 3; j++)
            m[i][j] = 0;

-----------------------------------------------------------------------------
Ulf Soderberg                                 Telephone: +46 8 6300630
usoderberg@sysinno.se                               Fax: +46 8 6300639
                                                Address: System Innovation AB
                                                         Polygonvagen 53-55
                                                         PO.Box 7105
                                                         S183 07 Taby
                                                         SWEDEN
Newsgroups: comp.lang.c++