HDTenEightyP/NetNews huggingface dataset:
From: rmartin@willing.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: Call by reference using * and &
Date: 15 Apr 92 00:06:01 GMT
Followup-To: comp.lang.c++

lam@saifr00.cfsat.honeywell.com (Josh Lam) writes:

>In C++, call by reference can be accomplished using pointers (like in C) or
>by reference (&).  Question:  What are some advantages of using references
>over pointers (or vice versa)

The form:

	void f(TYPE&);

is prefered over the form:

	void f(TYPE*);

There are several good reasons for this.  First, from the caller's
point of view there is no difference between

	void f(const TYPE&);

and
 
	void f(const TYPE);

Thus, the designer of the function can choose whether a call-by-value
or a call-by-reference paradigm is used.   Thus, if TYPE were a huge
structure, call by reference could be used to speed up the call.  If
TYPE were a primitive, or very small struct, pass by value might be
more appropriate.  The function designer can decide, and the client
never needs to know.

Secondly, the forms:
	
	void f(TYPE*);
	void f(TYPE&);

are not semantically equivalent.  They both represent the
pass-by-value paradigm, but the pointer form allows the argument to be
zero, whereas the reference form does not.  The reference form
*guarantees* that a real object is being refered to.

Both forms are useful, but should be used at the appropriate times.
When the pointer form is used, the called function should always
assume that the argument can be zero.  When using the reference form,
the called function should never check for zero.  

--
+---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting         |
| rmartin@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering    |
|     (Uncle Bob.)     |-RRR--C----M--M--M-| OOA/OOD/OOP Training      |
+----------------------+-R--R--CCC-M-----M-| Product Design & Devel.   |
From: easchwei@eos.ncsu.edu (ERIC ARNOLD SCHWEITZ)
Newsgroups: comp.lang.c++
Subject: A really good way to do this is?
Date: 8 Apr 92 00:44:46 GMT
Organization: NCSU Project Eos

Hi, I am having a problem seeing how to do the follwoing in C++
and was wondering if anyone out there has done it and/or has
some good thoughts on the subject.

The problem at hand is I'd like to be able to define a general
class which I can inherit from that has a the following property:
each time a member function is called a hidden member function,
eg. an access function, is called and when the member function
exits a `deaccess' function is called.  This is similar to, but not
really the same, as the constructor/destructor pair for an
object, but I wish for it to happen on each access.

For a trivial (un-real) example, suppose I have a ``locking'' class
that is free to be moved around memory, but when I access an object
I wish it to be frozen someplace.  (This isn't thought out, so please
don't pay a lot of attention to this example.)

Anyhow, if I do a ``obj.spill_guts();'' call I'd like the object
to fix its location in memory, do whatever it was supposed to do,
and then free itself to walk around memory again.  There seem to
be some simple approaches, such as forcing the user to call an
``access'' and ``de-access'' function before and after each call.
Yuck!  Or forcing each member function to do this -- equally
yucky -- especially with inheritance.

So does anybody have any good thoughts on an approach to hide
these special access functions?  Thanks in advance.
Newsgroups: comp.lang.c++
From: jmb@fid.morgan.com (Jeff Birnbaum)
Subject: C++ name mangling and dynamic loading
Organization: Morgan Stanley & Co., New York, NY
Date: Fri, 10 Apr 1992 15:25:59 GMT

The question: does anyone know how to dynamically load C++ code or more 
precisely I need to know how to do name mangling. The following example 
should help explain better.

What I have: class, function name, args, return type - i.e. prototype

What I want: the mangled name that is stored in the object file.

I have an interpreter running that needs the address of the routine, but 
I can only provide it the prototype - the mangled name allows it to get 
the address.

In 'C' this is trivial - each function name just has a leading underscore.

If I had a mangler routine then I believe that the dynamic load would be 
just as trivial, but I cannot such a utility.

I'm running Sun C++ 2.1 on a SPARCstation.

-- 
Jeffrey M. Birnbaum             \     Morgan Stanley & Co., Inc.
jmb@fid.morgan.com               \    1251 Avenue of the Americas
Fixed Income Research Department  \   New York, NY  10020 USA
(212) 703-7219                     \
Newsgroups: comp.lang.c++
From: jyelon@dante.cs.uiuc.edu (Josh Yelon)
Subject: Can any MSDOS C compiler handle big files?
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Fri, 10 Apr 1992 04:37:30 GMT

Is there any MSDOS C compiler that doesn't say "error: code segment
too large" when you give it a big source file? 

<FLAME ON>

This is absurd behavior for a compiler. Code segments and other
machine-specific details are the compiler's job --- That's what I use
a compiler for! "Code segment too large" is nothing but a glorified
compiler bug.

Oh, Don't tell me to chop the C code up into pieces. The C code is
program generator output - any changes to it would get overwritten
the next time I changed the _real_ source.

<FLAME OFF>

Newsgroups: comp.lang.c++
From: ejs@borland.com (Eric Swenson)
Subject: Re: Borland support
Organization: Borland International
Date: Tue, 14 Apr 1992 18:51:58 GMT

In article <1992Apr14.141744.18290@bmerh2.bnr.ca> ACOLES@BNR.CA writes:
>I`ve been trying for the past 3 days to get borland technical support.
>All I get is being on hold for 1/2+ an hour...long distance.
>
>Does anyone know if Borland supports their products on Compuserve, email or
>FAX besides the dreaded telephone?

Borland tech support is provided on Compuserve, BIX, and Genie.  You can
send bug reports via Internet mail at bugs@borland.com, but don't expect
a response -- the reports go directly to our QA department.  
-- Eric
From: john@iesd.auc.dk (John Nikolajsen)
Newsgroups: comp.lang.c++
Subject: Reverse engineering
Date: 30 Mar 92 11:36:30 GMT
Distribution: eunet
Organization: Mathematics and Computer Science, Aalborg University


We are two students from Aalborg University, Denmark, who are working
on our Master Thesis. We are currently making a research on reverse
engineering of C++ source code.  

The primary objective of the research is to find the limits for
reverse engineering from C++ source code to a design notation. We are 
especially interested in how run-time binding can be reverse
engineered into a design notation e.g. virtual functions in C++. 

Are there any ideas on the limits for reverse engineering and how
run-time binding can be expressed in a design notation?

We are also interested in a C++ software (source code) for reverse
engineering. The software should use encapsulation, inheritance, and
polymorphism. The size of the C++ software should be held between 1
and 5 KLOC. 

Please respond by e-mail or by post.

Frank Kjaersgaard and John Nikolajsen.
______________________________________

e-mail: john@iesd.auc.dk

Address: Aalborg University,
         Frederik Bajers vej 7, E2-107,
         9220 Aalborg, Denmark.
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: question re this and new
Organization: TauMetric Corporation
Date: Wed, 8 Apr 1992 16:49:46 GMT

alan@elroy.jpl.nasa.gov (Alan S. Mazer) writes:

>If I have a virtual base class (with multiple inheritance) shouldn't the 
>value of "this" in the constructor of a derived class be the same value
>eventually returned by "new"?  It's not ("new" returns something 8 bytes
>greater than "this" was in the constructor) and I'm not sure why.

The "this" pointer has the value of the current object.  In a constructor
(or other member function) for a class X object, "this" must point to
the "X" portion of a possibly larger object.  Simple example:`
	class X {
	    int i;
	public:
	    int get();
	};
	X::int get() { return i; }
Function X::get() returns this->X::i, the int typically at offset 0 from
the start of the X object.  No matter whether an X object stands by
itself or is a member of another object, or is a base class of another
object, there is only X::get() in the program.  Therefore, this->X::i must
be found in some consistent way.

Now suppose we have
	class Y { int j; foo(); ... };
	class Z : public Y, public X { ... };
	Z z;
	... z.get() ...
	... z.foo() ...
When we call z.get(), it invokes X::get().
When we call z.foo(), it invokes Y::foo().
Each of the base class member functions must get a "this" pointer which
points to the appropriate sub-object.  It cannot be the case that X::get()
and Y::foo() get the same value for "this", since neither sub-object is
zero size.

The same is true of constructors.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: gs4t@helga2.acc.Virginia.EDU (Gnanasekaran Swaminathan)
Subject: Re: question about class member access rules, A CLARIFICATION
Reply-To: gs4t@helga2.acc.Virginia.EDU (Gnanasekaran Swaminathan)
Organization: University of Virginia
Distribution: na
Date: Fri, 3 Apr 1992 18:51:02 GMT

hira@walkman2.bellcore.com writes:
|>      class B {
|>          protected:
|>              int i;
|>          public:
|>              void foo();
|>      };
|> 
|>      class D : public B {
|>          public:
|>              void bar();
|>      };
|> 
|>      void B::foo()
|>      {
|>          B b;
|> 
|>          i = 1;    // o.k.; i is protected member of B and i == this->i
|>          b.i = 1;  // LEGAL, eventhough b.i != this->i
|>      }
|> 
|>      void D::bar()
|>      {
|>          B b;
|> 
|>          i = 1;   // o.k., as i is an inherited protected member and
|>                   // i == this->i
|>          b.i = 1; // ILLEGAL; i is protected but b.i != this->i
|>      }
|> 
|> 
|> Why is the second assignment in B::foo legal when the second assignment 
|> in D::bar is not? Both g++ and cfront flag the latter as an error, but 
|> do not complain about the former.
|> 
|> If the rule simply says "any member function of a class can access 
|> the protected members of its base classes" then the second assignment in 
|> D::bar should also be legal.
|> 
|> If the rule also requires that the object whose protected members are
|> being accessed should be same as `*this' then the second assignment in
|> B::foo should also be considered illegal!

Instead the ARM sec 11.4 p253 rules,
	"A friend or a member function of derived class can
	 access a protected nonstatic member of one of its base
	 classes only through a pointer to, reference to, or
	 object of the derived class (or any class derived from
	 that class)."
Hence,
	void	D::bar() {
		B b;
		D d;
		i = 1; 	  // ok. this->i
		d.i = 1;  // ok. access through an object of
			  // the derived class
		b.i = 1;  // error. access through an object of
			  // D's base class.
	}


-Sekar

		
Newsgroups: comp.lang.c++
From: mcgrant@isl.stanford.edu (Michael C. Grant)
Subject: Re: Gunnar Teege's Emacs C++ class browser
Organization: Information Systems Laboratory, Stanford University
	<1992Apr10.163700.11699@csqx.cs.rhbnc.ac.uk>
Date: 10 Apr 92 18:19:31


Someone said:
   Try using the machine ftp.informatik.tu-muenchen.de
   The file has been updated to version two so you require
   /pub/GNU/emacs/contrib/c++-browse-2.tar.Z
   Andrew

But, kappa.rice.edu:/pub,
     oskgate0.mei.co.jp:/tmp_mnt/public/mnt0/gnu,
and  reseq.regent.e-technik.tu-muenchen.de:/informatik.public/GNU/emacs/contrib

also have the file, so there's very little reason to cross the ocean
for the file.

(This is thanks to xarchie 1.3).

Mike

Newsgroups: comp.lang.c++
From: jim@.SanDiego.NCR.COM (Jim Ruehlin)
Subject: Re: Borland's design decisions
Reply-To: jim@cheers.SanDiego.NCR.COM (Jim Ruehlin)
Organization: NCR Corporation, Rancho Bernardo
Date: Mon, 6 Apr 1992 17:33:29 GMT

In article <1992Apr2.131624.245@pictel.com> boba@pictel.com (Bob Alexander) writes:
>Secondly, Borland extended C++ with dynamic dispatch virtual tables.  Why?
>Why not just just create virtual member functions like WMLButtonDown that
>always receive a particular message and that the user can override?  What
>do DDVTs add that is so worthwhile as to justify a non-standard extension
>to C++?

It might be because you can receive custom messages with DDVTs.  This includes
your own buttons, menu items, window messages, etc.  If they just had
virtual member functions defined for every possible window/menu/button message
the classes would have a lot of overhead in the virtual function table.  You
would also be limited to regular messages, without the ability to create
your own.

Jim Ruehlin

Newsgroups: comp.lang.c++
From: boba@pictel.com (Bob Alexander)
Subject: Re: Borland's design decisions
Organization: PictureTel Corporation
Date: Thu, 9 Apr 1992 12:37:16 GMT

pete@borland.com (Pete Becker) writes:
>>In the class libraries, they have a doubly-linked list object.  They have
>>member functions that delete from either end of the list, but it seems
>>there's no way to remove an item from the middle of the list.
>>
>	The function detach() will do what you want.

You're right, but it's not quite what I had in mind.  detach() searches
through the list from the beginning to find the object you want to
remove: a potentially time consuming task.  Also, there's still no way
to add to the middle of a doubly-linked list.

What would be nice is an add and detach function that took an iterator as
an argument and used it to insert or detach an object anywhere in the list.

>>Secondly, Borland extended C++ with dynamic dispatch virtual tables.  Why?
>
>	Since there are 64K possible Windows messages, any class that could
>handle them all would have a rather large vtable.

Several people gave this answer, and it sounds like a pretty good reason.
But now I'm curious: how do other class libraries for Windows handle this?
Microsoft's MFCs don't rely on compiler extensions (I think.)  There's
also a product called zApp that doesn't rely on compiler extensions.

     Bob Alexander                                     boba@pictel.com
     -----------------------------------------------------------------
     Organizations don't have opinions; people do.  The above opinions
     do not reflect those of the directors, stockholders, managers, or
     other employees of PictureTel.

Newsgroups: comp.lang.c++
From: sch@mitre.org (Stu Schaffner)
Subject: Re: overloading [] for bitvectors?
Organization: MITRE Corp.
Date: Mon, 13 Apr 1992 17:33:29 GMT

In article <Garym.0bo0@qube.OCUnix.On.Ca>, Garym@qube.OCUnix.On.Ca (Garym) writes:
> 
> What I want to do is pure syntactic sugar, but it would be very nice
> and a noble gesture of implementation hiding.  I have a bit-array class
> to store large lists of bit values in a compact form, and in a nutshell
> what I would like are statements like the following:
> 
>      bitvector[17] = TRUE;
>      if (bitvector[3]) do_something();
> 
> The rvalue side seems easy, as I can overload [] to compute the byte
> index and the mask and shift-right values to reduce the proper byte to
> the corresponding bit value to return.  What this would do on an
> lvalue is anyone's guess.
> 
> For the lvalue, there doesn't appear to be a solution: my C++
> reference, Schildt's Complete Reference, only explains overloading [] to
> produce a reference value, which would work for bytes and structures
> but obviously would not work at the bit level.
> 

It's a bit complex for the implementer, but there is a way that gives a
clean interface to the user. See pp 50-52 of Coplien's book, "Advanced
C++, Programming Styles and Idioms", Addison Wesley 1992, ISBN 0-201-54855-0

Stu Schaffner, not speaking for the MITRE Corp.
sch@mitre.org
From: shite@sinkhole.unf.edu (Stephen Hite)
Newsgroups: comp.lang.c++
Subject: Re: Is this a FLAW in C++ ??
Keywords: C++ FLAW VIRTUAL VARIABLES
Date: 16 Apr 92 12:57:39 GMT
Organization: University of North Florida, Jacksonville


   All languages are flawed. ;-)  Seriously, I think you should take
a look at:

       "Advanced C++ : Programming Styles and Idioms" 
       by James Coplien

I believe your question of "virtual data members" is answered in
the C++ FAQ.  It can be found at sun.soe.clarkson.edu in the /pub/C++
hierarchy.

P.S. Dr. Cline has created an execllent C++ FAQ that could turn into a
     book if he's not careful. ;-) 


Steve Hite
shite@sinkhole.unf.edu
From: jtc@cayenne.gain.com (J.T. Conklin)
Newsgroups: comp.lang.c++
Subject: Who do you contact to order a cfront source licence?
Date: 9 Apr 92 01:06:57 GMT
Organization: Gain Technology, Inc., Palo Alto, CA

I've seen this asked and answered many times before, perhaps it should
be included in the FAQ (I just ftp'd the latest version and it didn't
contain the answer).

Please mail me a contact for ordering a source licence for cfront.

Thanks,

        --jtc
--
J.T. Conklin	Quality Assurance Engineer
		GAIN Technology, Inc.
		Palo Alto, California
Newsgroups: comp.lang.c++
From: minard@qucis.queensu.ca (Brian Minard)
Subject: Borland C++ Virtual Tables
Keywords: C++, Virtual Tables
Organization: Computing & Information Science, Queen's University at Kingston
Distribution: na
Date: Thu, 16 Apr 1992 16:44:58 GMT


I'd be interested in hearing from anyone with experience using 
Borland's virtual table compiler options.

My problem is that all of the methods for the classes used in a
function seem to be included in the compiled code for that function.

The options (-V, -Vs, -V0 and -V1), documented in version 2.0 prevent
the inline expansion of functions, instead storing them in global 
virtual tables.

Is there any way to allow inline expansion while preventing the unused 
methods from being included in the compiled functions?

Are there any reasons why the methods should *not* be stored in
global tables?

Thanks.

Newsgroups: comp.lang.c++
From: dfoster@jarthur.claremont.edu (Derek R. Foster)
Subject: Re: Problems w/Borland & new
Keywords: borland
Organization: Harvey Mudd College, Claremont, CA 91711
Date: Sat, 11 Apr 1992 02:52:19 GMT

In article <52496@ncratl.AtlantaGA.NCR.COM> vkessler@ncratl.AtlantaGA.NCR.COM (Vance Kessler) writes:
>I am having problems with Borland and memory allocation.  I am using the
>text based Borland 3.0 compiler.  The problem is that sometimes my program
>will have about 340K free and do a new on an object that is about
>20 bytes in size.  After the new I have 16 BYTES of memory left.  It does
>not always do this, I can add some code and it will go away for awhile.
>But after some time (and some code changes) the problem comes back.  When 
>the problem comes back, it is generally in a different place.  But the 
>problem is consistently reproduceable until I recompile.
>
>If anyone has had similar problems, or knows how to fix this please let me
>know.  I would really like to know if my code is to blame or the compiler.

What are you using to detect how much memory you have left? Are you using
the 'coreleft()' function? If so, you may not be aware that it does not
actually report the allocable space left, but merely the upper (lower?)
limit of the memory reserved for the heap. Memory under that limit may
be a patchwork quilt of allocated an unallocated blocks of memory which
will not enter into the total returned by coreleft(). For instance, if
you execute something like:

void * space[100];
printf("core0 = %d\n",coreleft());
for (i=0; i<100; i++)
  space[i]=malloc(SOME_NUMBER);
printf("core1 = %d\n",coreleft());
for (i=0; i<99; i++)
  free(space[i]);
printf("core2 = %d\n",coreleft());
free(space[99]);
printf("core3 = %d\n",coreleft());

you may (depending on what your memory looks like) get exactly the same
numbers for core0 and core 3, and for core1 and core2, even though
at core2, much less memory is really allocated at core2 than at core1.

If you want to get an accurate picture of how much memory you really
have available to allocate, use the 'heapwalk' function, and the examples
given in the library reference manual, to construct a function to add up
the size of all of the unallocated blocks of memory in the heap. You
can also use the Borland heap routines to check out the integrity of
your heap, to see if it has been corrupted by a stray pointer for instance.

Of course, an unitialized pointer which trashes the routines themselves
is always a possibility.

Good luck!

Derek Riippa Foster
Newsgroups: comp.lang.c++
From: melissag@iplmail.orl.mmc.com (Melissa Garber)
Subject: g++ compiler
Organization: Martin Marietta
Date: Fri, 10 Apr 1992 14:25:05 GMT

Sorry, in my previous post:

I'm having trouble compiling a simple program with a call to 'getch'.
I include 'curses.h', and link with the 'curses' library.
The program compiles, but croaks out a 'Segmentation Fault' when it is run.
Got any ideas?

I forgot to say the problem occurs with g++ -- works fine with gcc.

*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*

Melissa Garber                               Image Processing Lab
melissa-garber@orl.mmc.com                   Martin Marietta Electronic Systems
Phone: (407) 356-8745                        Orlando, Florida
Fax:   (407) 356-8944

 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
From: kcl@cbnewsh.cb.att.com (kuo-cheng.li)
Newsgroups: comp.lang.c++
Subject: Re: AT&T Class Library with MPW??
Date: 13 Apr 92 21:36:52 GMT
Organization: AT&T

In article <1992Apr11.020844.28227@ux1.cso.uiuc.edu>, mlanett@void.ncsa.uiuc.edu (Mark Lanett) writes:
> martin@cicada.volvo.se (Martin Borjesson) writes:
> 
> >Anyway, have anyone successfully used AT&T Class Library on the
> >Apple Macintosh with MPW??? 
> 
> What *is* the AT&T Class Library?
> -- 

I think the C++ Class Library here means USL (UNIX System Laboratories,
a subsidiary of AT&T) C++ Standard Library and/or USL C++ Standard Components.

The Standard Library includes iostream, task and complex components
which are delivered with USL cfront, but it is also available as a 
separate product.

The Standard Components is a collection of efficient, general-purpose
software components which include Args, Array_alg, Bits, Block, Fsm, 
G2++, Graph, Graph_alg, ipcstream, List, Map, Objection, Path, Pool,
Regex, Set, Stopwatch, String, Strstream, Symbol and Time.

For more information, contact your local USL sales office, or call
1-800-828-UNIX (8649).
From: rr2b+@andrew.cmu.edu (Robert Andrew Ryan)
Newsgroups: comp.lang.c++
Subject: Re: C++ as a 1st programming language ?
Date: 15 Apr 92 15:13:37 GMT
	<1992Apr15.135716.25812@udel.edu>
Organization: School of Computer Science, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.lang.c++: 15-Apr-92 Re: C++ as a 1st
programmin.. Mark C. Carroll@hercules (1541)

> In article <1992Apr14.202824.14288@colorado.edu>
> wilde@tigger.Colorado.EDU (Nick Wilde) writes:
> >
> >Greetings - How would you rate C++ as a language to 
> >*teach* programming in, from the beginning ?
> >

> Frankly, I think it would be a very poor choice.

I would say that it depends on whether or not you expect they will
eventually need or want to know C++.

I recently graduated in CS, but one of the worst faults I found with the
curriculum was that C was completely missing.  There were NO classes in
C, then in our Operating Systems class we were expected to be reasonably
fluent in it.  (True C++ is not C, but I think it is analogous now to C
then.)

If C++ is going to be used later I would say that it should be used in
the intro.  You don't need to dwell on all the features/misfeatures of
the language, focus on the concepts.  Let the students and the TA's deal
with the features/misfeatures.  They may hate you for it, but it's
probably the best way if they are going to have to do it eventually.  I
would much rather see them learn it in an intro course where they have
relatively more time than when they have 3 weeks to write an OS kernel
(or only the networking part :-)

-Rob Ryan
Newsgroups: comp.lang.c++