HDTenEightyP/NetNews huggingface dataset:
From: swillden@news.ccutah.edu (Shawn Willden)
Subject: Re: Multiple Header Files Problem
Reply-To: swillden@icarus.weber.edu
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Wed, 11 Nov 92 01:57:47 GMT

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
: 
: |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. 
: 
: However, using the #ifndef convention does not solve all the problems
: related to inclusion, nor obviate the need to make judicious use of
: forward declarations.  #ifndef, while it *does* keep the contents of a
: header file from being compiled more than once, does not keep the
: header file from being *read* more than once.  Thus, if care is not
: taken, compile times can grow quite long.
: 
: Moreover, some compilers limit the number of files that they will
: include, or at least the depth of the inclusions.  
: 
: 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.

While I agree with that it is a good idea to choose your #included
files carefully, the above-metioned problems are also easily avoided
by simply wrapping each inclusion in its own #ifndef...#endif pair.
Like:

#ifndef SOMEFILE_H
#include "somefile.h"
#endif

That way, if somefile.h has already been included once, the compiler
won't even have to read it again.  If this technique is always used
the #ifndef..#endif pairs are not even needed in the included file,
though I always use them, just in case someone else makes a mistake
(something I'm sure *I* would never do :-)

: --
: 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++

--
Shawn Willden
swillden@icarus.weber.edu
From: brw@aber.ac.uk (Benjamin Roy Whittle)
Newsgroups: comp.lang.c++
Subject: template question
Date: 9 Nov 92 12:14:52 GMT
Organization: University of Wales, Aberystwyth


    If I write the following

template<class T>
class stack { /* public interface stuff push pop etc*/};

but I want to say that the class T should have a function copy available
for objects of that class, so that the function can be used in the
implementation of the stack.

How do I do it please?

email appreciated.

ben

brw@aber.ac.uk
Newsgroups: comp.lang.c++
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Debugging output
Organization: University of Illinois at Urbana-Champaign
Date: Thu, 5 Nov 1992 16:11:14 GMT

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

>*****>	This has nothing to do with <<.

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

****>	That only works if you have a C++-ignorant preprocessor, i.e., so
	it won't strip the // comment.  This is one instance, among others,
	why I would like to keep cpp //-ignorant; you can do all sorts of
	hokey stuff that way.

>	// ...

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

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

>*****>	See above.

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

>*****>	Unnecessary; see above.
>-- 
>	- Paul J. Lucas				University of Illinois	
>	  AT&T Bell Laboratories		at Urbana-Champaign
>	  Naperville, IL			pjl@cs.uiuc.edu
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: Help! BC3.0 link problem
Date: Fri, 6 Nov 1992 18:17:20 GMT
Organization: University of Birmingham

In article <1992Nov5.125313.19675@alf.uib.no>, s026@brems.ii.uib.no (Paal K Holmberg) writes:
> exception 13: general protection fault at 0B1F:A3AF error code 0000
> then it writes the contents of the registers, and then
> error code 0000 limit=INVL segment#
> 
> handled exeception 000D at 0b1f a3af ErrCode 0000

Borland 3.0 does this a lot - the only solution is to upgrade to 3.1 but
they won't let you have it for free :-(

    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)          
 .  _\\__[oo  ============
.__/  \\ /\@
.  l___\\     E-mail: B.A.McCauley@bham.ac.uk
 # ll  l\\ 
###LL  LL\\
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Newsgroups: comp.lang.c++
Subject: Re: c++ & c+++
Date: 8 Nov 92 23:59:40 GMT
Organization: University of Birmingham

In article <1992Nov8.222637.5773@nmsu.edu>, willittl@spock.NMSU.Edu (William  Little) writes:
> 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.
Get the ARM (Annotated reference manual) I've never seen it but
everyone else sears by it! (I use "The C++ Prog.Lang.Edn.2" also by
the man himself which is probably not quite as good).

> class::variable
> class::function()
The :: operator is used to refer to something inside a class without
refering to any object of the class. In this case your probably thinking of
static members which are just ordinary global functions or variables that
happen to be owned by the class. class:: might just as well be class_ for
most purposes (a simplistic way of looking at things and one I would not
recomend to anyone but a C convert (I learnt C the odd way by leaning C++
then being told what I _couldn't_ do))
Because static members belong to the class they behave like members wrt
privacy.

>   [Class declaration with some inline and some out-of-line member fns]

> 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.
For big member functions one puts only the prototype in the class declaration
(and hence in the header file) with the definition in a source file.
For trivial member functions one gives the whole definition and the compiler
will attempt to compile them inline (and optimize them out) when appropriate.
> 
> What do the ::'s do??
Let's you refer to a member of a class while you're lexical outside the
class. Thus sice funtions3's prototype was inside the class definition
it didn't need a prefix (although it's not strictly wrong to give it one)
but function3's definition needs its full name including the class name
part.

What I've said here is a gross simplification of the full story. If you
think the :: is confusing now just wait till you start playing with nested
classes, derived classes and virtual base classes ;->
-- 
    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)
 .  _\\__[oo 
.__/  \\ /\@  E-mail: B.A.McCauley@bham.ac.uk
.  l___\\        Fax: +44 21 625 2175
 # ll  l\\     Snail: 197 Harborne Lane, Birmingham, B29 6SS, UK
###LL  LL\\     ICBM: 52.5N 1.9W
 
Newsgroups: comp.lang.c++
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Debugging output
Organization: University of Illinois at Urbana-Champaign
Date: Thu, 5 Nov 1992 16:01:20 GMT

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

*****>	This has nothing to do with <<.

>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'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 allows the flexibility of having debugging "togglable"
	during development, presumeably by a command-line option, but
	can be compiled-out in the final version.

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

*****>	See above.

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

*****>	Unnecessary; see above.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: nadeau@JSP.UMontreal.CA (Nadeau Jean-Claude)
Subject: Re: Bus error
Organization: Universite de Montreal
Date: Wed, 11 Nov 1992 18:39:09 GMT

In article <BxJ1nK.B0y@acsu.buffalo.edu> yli@acsu.buffalo.edu (Yanhong Li) writes:
>#include <iostream.h>
>
>class T {
> public:
> int i;
> void foo() {cout <<"foooo\n";}
>};
>
>void main(){
>T *tt[3][5];
>
>tt[2][3]->i=1;
>}
	Well, another C (NOT C++) pitfall.  You've declare "tt" as an array
	of array of POINTER to T.  So there is memory for 15 pointers not
	for 15 objects of type T.  You'll have to reserve memory for those
	objects and INITIALIZE the pointers to the addresses of those blocks
	of memory.  Or declare "tt" like that (If it's possible):

		T tt[3][5];

	It's better to learn C before trying to use C++ ;-)

	A not so joking idea. ;-)
-- 
Jean-Claude Nadeau, ing.	<nadeau@ERE.UMontreal.CA>
Services informatiques		Tel. (514) 343-6111,ext 5234
Universite de Montreal		Fax  (514) 343-2155
Newsgroups: comp.lang.c++
From: hm@cs.brown.edu (Harry Mamaysky)
Subject: yacc and C++
Organization: Somewhere East or Somewhere West
Date: Mon, 9 Nov 1992 01:38:42 GMT

Howdy C++ faithful,

I have a slight problem. I am trying to use a YACC generated parser in
a C++ system I have. This leads to the problem of getting YACC to know
about my C++ objects and such. Of course, I can't include C++ header
files YACC (or can I?). SO I have a wrapper program whose routines are
called by YACC. I turn before I call yyparse() I set a global variable
to point to the object which is making the call. Then the wrapper
routines use this global pointer top call the correspondiong class
methods in my C++ code. So far so good.

BUT, the compiler I am using ( v.3.0.1 AT&T C++ ) translates C++ code
into C code and in so doing tacks on type specifier codes to the end
of my routines. SO, for example, a routine called foo becomes
_foo__FP5 in the symbol table of the object file which results from
the code. Unfortunately, this same function foo, which is called by
the YACC generated parser, is _foo is\n the corresponding symbol
table. So, the linker gets screwed in the head and does not know what
to do. I have to actually look up the routine names in the object file
from the C++ program which acts as a wrapper and tack on the weird
endings to the correspondings routines which are defined in the YACC
file. Not pretty.

Also, yyparse() is called by C++ code. So, the C++ translator makes
yyparse() into yyparse__Fv() in its symbol table. This means that I
have to call yyparse by its new name in the actual y.tab.c file.
Again, not pretty.

Although, the method I described works (so you can use it too if a
better one does not exist), it is incredibly ugly and hack-like. 

So, does any one have a better way of using YACC with C++?

Does a better way exist?

Does a (free) YACC like tool exist for C++? If so, where?

Please respond either by email or to comp.lang.c++. If any one out
there has a nicer solution, I am most eager to hear about it.

Harry.

hm@cs.brown.edu
Newsgroups: comp.lang.c++
From: adelt@imada.ou.dk (Adel Shavandi)
Subject: dbxtool ...
Summary: dbxtool ...
Keywords: dbxtool ...
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Fri, 13 Nov 1992 15:39:02 GMT


I have a program written in C++ and compiled with option -g. Now i call
the dbxtool for sun's C++ compiler version 2.1 released on 1 March 1991.
When the debugger is ready, i type 'debug myprog'. The debugger starts
reading the symbolic information and while doing so, suddenly it exits
without any messages! I have no idea of my program being wrong or the
Sun's C++ debugger. 


I will really appraciate any hints helping me to find out what is wrong
or how i can find out what is wrong.



				Thanks in advance,

					Ade'l


+++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ What happens when there is a bug in a debugger ?!!! + 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: Making qsort type-safe
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Thu, 5 Nov 1992 16:00:48 GMT

The library version of qsort on some machines behaves abysmally if many
objects compare equal.  On more than one UNIX workstation I have seen qsort
take more than 3/4 of an *hour* to sort a large list into two buckets,
whereas an appropriately adjusted qsort takes 1/4 *second*.  (Yes I know 
that qsort seems like a silly way to do what could be a single pass
operation, but why should "sort" be applicable to only some kinds of sorts?)

The code that is in Lipmann is not good enough if you do a lot of sorting
of large arrays.  It has none of the standard modifications to handle
equal elements efficiently, to use minimal stack, etc.  It is there to
show the essence of qsort and how this would be handled with templates,
for instructional purposes (or perhaps for use in simple applications).

If you are sorting large arrays (or more generally, collections), you are
better off sorting pointers.  This way you only swap pointers, not objects.
[Also, you can then keep several sort orders for the same collection, if you
want.]

If you might be sorting collections that are huge and will require paging
or that have other I/O implications, you may want to use a different sort
algorithm.  Is it wise to make the sorting algorithm visible outside of 
the class?  (e.g. by using the name "qsort")

So about this not re-inventing the wheel business:  be careful what you reuse.
Make sure it satisfies your requirements.  The blanket statements made by
previous posters about reusing qsort because it is there are oversimplifying
things, IMO.

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: kanze@us-es.sel.de (James Kanze)
Subject: Re: how to initilize an array inside of a class??
Organization: SEL
Date: 13 Nov 92 19:34:46

In article <BxL3t2.FKG@ns1.nodak.edu> cooper@plains.NoDak.edu (Jeff
Cooper) writes:

|> I have a bit of a problem that I can't really see an elegant solution
|> for and I hope someone can point me in the right direction.  I have
|> a class that looks something like this:

|> class Y : public X
|> {
|>     public:
|>         int some_ints[3000];
|>         Y();
|>         ...
|> };

|> Now what I'd need to do is initilize the array 'some_ints' with some
|> preset values...normally one would do it like:

|> int some_ints[3000] = { 1, 6, 34, 3, ... ,0 };

|> But my compiler complains about that, saying that I can't initialize
|> class members there.  The only other way I can think of doing it is
|> to do something like:

|> Y::Y()
|> {
|>     some_ints[0] = 1;
|>     some_ints[1] = 6;
|>     ...
|>     some_ints[2999] = 0;
|> }

|> Is this my only other option??  If it is, it's not really all that bad
|> as this code is being generated by another program, so I won't have to
|> type in 3000 entries like that, but I was hoping for a more elegant
|> solution...Would there be a performance hit doing it that way, I kinda
|> think so as the first one is done at compile time, while the other is
|> done at run-time, correct??

|> Any Ideas?

First, note that there is a slight difference in declaring an array
outside of a class, and declaring one inside the class.  The array
declared (and initialized) outside the class defines a single instance
of a variable, so a single initialization is in order.  The array
declared inside the class does not define an instance of a variable;
the array will be instantiated once for every instance of the class.

So, the first question is: do you always want to initialize it in the
same manner.  And if so, do you ever change it later.

If the answer to the latter question is false, then maybe what you
want is a static class member; that is, a member common to all
instances of the class.  In this case, the solution is easy:

	class Y
	{
	public :
		static int someInts[ 3000 ] ;
	} ;

and in one (and only one) source file:

	int		Y::someInts[ 3000 ] = { 1 , 6 , ... , 0 } ;

If you really need for each instance of the class to contain its own
array member, which is always initialized with the same values, then
my own solution would be to declare a private static member with the
initial values, and use "memcpy" to copy it into the dynamic member.
This is, of course, basically just doing what you suggested in another
way, but I find it more readable.
--
James Kanze			GABI Software, Sarl.
email: kanze@us-es.sel.de	8 rue du Faisan
				67000 Strasbourg
				France
Newsgroups: comp.lang.c++
From: rkinder@iat.holonet.net (Robert J. Kinder)
Subject: Re: Need Yacc & Lex retargeted to C++
Organization: HoloNet (BBS: 510-704-1058)
Date: Wed, 11 Nov 1992 03:31:36 GMT

You might also look into a product called YACC++ by Compiler Systems (I
think that's the company?).  Call or send e-mail and I'll look up the
phone number for you.  It is very nice and much simpler than MKS YACC/Lex.
-- 
// rkinder@holonet.net            International Software Solutions, Inc.  -
// Robert J. Kinder, Jr.                             Boca Raton, Florida  -
//                                                        1-800-788-4774  -
//                    "No thanks!  I have a radio."
Newsgroups: comp.lang.c++,comp.std.c++
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: Sat, 7 Nov 1992 15:46:13 GMT

In article <klamer.720475994@mi.el.utwente.nl> klamer@mi.el.utwente.nl (Klamer Schutte) writes:
>In <1992Oct30.113234.15010@daimi.aau.dk> sabroe@daimi.aau.dk (Morten Sabroe Mortensen) writes:
>
>>        Lately I've coded a lot of small libraries in C++, and been
>>thinking, why it's not possible to hide private parts, -it doesn't 

>The compiler does not know what the data layout will be of the object.
>So the best he can do, is make a reference to the actual data.
>
>This means that the actual class will be just a pointer to the real data:

	No, when USING the interface the compiler doesnt need to 
know about the private parts, it needs to know only the size of
the object to allocate storage for it.

	This can be done using external reference to the size,
or as I have seen done in a Modula compiler in which the
implementation has been compiler, the compiler looks up the
last size, uses that, and if it gets changed automatically
recompiles the module. This requires environment support that
C++ doesnt have though, but it can be done---without pointers.


-- 
;----------------------------------------------------------------------
        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: gthkoh@ntuix.ntu.ac.sg (Koh Thong Hwee)
Subject: Re: Multiple Header Files Problem
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 5 Nov 1992 04:36:46 GMT

Lance W. Bledsoe (lwb@cs.utexas.edu) wrote:
: In article <1992Nov03.133949.21465@rs6000.bham.ac.uk> pickerig@eee.bham.ac.uk (Mr. G. Pickering) writes:
: 
: class B;	// add this line
: 
: 
: >: 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};
: >: };
: -- 
: +------------------------------------------------------------------------+
: |  Lance W. Bledsoe        lwb@im4u.cs.utexas.edu        (512) 258-0112  |
: |  Avalon Technical Services, Inc.            Contract Software Engineer |
: +------------------------------------------------------------------------+


Thanx to Guy and Lance for the tips.  I really needed the pointer...


TH Koh