HDTenEightyP/NetNews huggingface dataset:
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Quest: Multiple Virtual functions with same name
Organization: Rational
Date: Sat, 7 Nov 1992 00:42:23 GMT

rct@fulcrum.co.uk (Richard Taylor) writes:

|In article <1992Oct30.182516.20463@hplabsz.hpl.hp.com> kalra@PROBLEM_WITH_INEWS_GATEWAY_FILE (Deven Kalra) writes:
|>
|>I have a question about having multiple virtual functions with same names.
|>
|>I have a base class as
|>
|>class BaseClass{
|>
|>
|>    virtual render (Sphere &s);
|>    virtual render (Rect   &r);
|>}
|>
|>and a derived class
|>
|>class DerivedClass:public BaseClass{
|>	virtual render (Sphere &s);
|>}
|>
|>I get compiler warnings as:
|>
|>	render function hides base function

This is to be expected, members in derived classes "hide" members in
base classes that have the same name.  See "ARM 13.1"

|>
|>Is it documented behavior? Why does not 
|>    render(Sphere &s) in DerivedClass
|>
|>replace 
|>    render(Sphere &s) in BaseClass

It does.  But it also hides BaseClass::render(Rect&)

|>
|>but 
|>    render(Rect &r) be taken from the BaseClass.

Because it is hidden.  The ARM justifies this with a reasonably
compelling argument.

|>
|>
|>Why should the above create a warning. Is there an alternative way
|>to achieve the above functionality of replacing only some of the functions
|>of a BaseClass that are named the same.
|>

Yes,  You can add DerivedClass::render(Rect& r)
{BaseClass::render(r);}


|Isn't the problem that you have made *both* render (Sphere &s) functions
|virtual? That means the base virtual function will *never* be used. Maybe
|you meant:

|class DerivedClass:public BaseClass{
|       /*virtual*/ render (Sphere &s);

No, virtualness has nothing to do with it.  The functions would have
been hidden regardless of whether they were virtual or not.  In the
example, it would appear that the functions ought to be virtual.


--
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: reindorf@us-es.sel.de (Charles Reindorf)
Subject: Re: Using 64k objects
Organization: SEL-Alcatel Line Transmission Systems Dept. US/ES
Date: Tue, 10 Nov 92 10:27:46 GMT

In article <BxH4p6.8Bn@research.canon.oz.au>, colin@cole.research.canon.oz.au (Colin Pickup) writes:
|> In article <1992Nov4.011604.5884@piccolo.cit.cornell.edu>  
|> sl14@crux3.cit.cornell.edu (Stephen Lee) writes:
|> > [ etc ]
|> 
|> Borland is one of the few C/C++ compilers that handles arrays bigger that  
|> 64K. To do it either use the huge memory model for the whole program or  
|> just make the pointers to the arrays huge (read the manuals on how to do  
|> this). The second option will give better run-time performance.

Is it not the case that the "huge" memory model does not imply huge pointers by default?
According to my understanding of the "huge" memory model, the only difference between it and
large memory models is that a separate data area is allocated for statics, string literals,
e.t.c. per translation unit rather than for the entire program. The "huge" as applies to
memory models versus the "huge" as applies to pointers would seem to have a subtle difference
here. If you wish to allocate and manipulate huge arrays, I believe you have to explicitly
use "huge" pointers.
 
|> NOTE : you can not use new to allocate arrays bigger than 64K. The size  
|> parameter for new is a unsigned, i.e. 16 bits. You must use hugealloc and  
|> hugefree (again look in the manual for these functions).
|> Colin Pickup
|> 


All opinions above are my own etc.

-- Charles Reindorf
Newsgroups: comp.lang.c++
From: hansen@deci.cs.umn.edu (David M. Hansen)
Subject: Re: Debugging output
Organization: University of Minnesota
Date: Fri, 6 Nov 1992 13:50:17 GMT

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
space replaces each comment..." _before_ preprocessing directives are 
executed.  The annotation recognizes that C preprocessors, unless adapted
for use with C++, will not recognize the // comment form, but it also makes
it clear that is is inappropriate behavior.

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

   #define MAX_WIDGETS   12    // maximum number of widgets available to the user

   Widget user_widgets[MAX_WIDGETS];

will not parse appropriately, leading to non-sequiter error messages.

					-=Dave
From: davidn@csource.oz.au (david nugent)
Newsgroups: comp.lang.c++
Subject: overloading operator<<
Date: 14 Nov 92 00:46:28 GMT
Reply-To: davidn@csource.oz.au
Organization: Unique Computing Pty Ltd, Melbourne, Australia

I'm looking for some assistance, or even hints, on how to achieve
something with iostreams. In particular, I want to overload the <<
operator to work in a particular way.

Here's an example:

I've derived a class from the 'struct tm' in <time.h>, similar to
this:

  #include <time.h>

  class ptm : public tm
  {

  public:

    typedef ostream& (ptm::*ptmf)(ostream& os);  // Saves the ugly syntax

    // .. usual constructors, etc...

    short format (short _f);	     // Set formatting attributes
    short format (void) const;	     // Return formatting attributes

    ostream& date (ostream& os);       // These print various parts
    ostream& time (ostream& os);       // or combinations
    ostream& datime (ostream& os);
    ostream& year (ostream& os);
    ostream& month (ostream& os);
    ostream& day (ostream& os);
    ostream& hour (ostream& os);
    ostream& minute (ostream& os);
    ostream& second (ostream& os);

    friend ostream& operator<< (ostream& os, ptmf _f);

  private:

     short _tmfmt;		     // Time/date (default) format

  };


The idea is to set particular flags and have the date format changed
according to things such as locale, preferences or whatever..

What I'd _like_ to achieve would be something like:

  ptm t = <initialiser>;

  cout << "The date is:" << t.date << '\n'
       << "The time is: " << t.time << endl;

So, what I thought I'd do is to overload the << operator to accept a
pointer to a function.	I tried this:

  inline ostream&
  operator<< (ostream& os, ptm::ptmf _f)
  {
	_f (os);
	return os;
  }

where ptmf (pointer-to-member-function) is typedef'ed as above the
class definition.

Now, gcc 2.2.2 _refuses_ to compile this, claiming that it is allowing
illegal access outside of a class.  Well, I guess that's true, but it
is defined as a friend function after all.  MSC/C++ compiles this just
fine, but in calling the ptmf, it doesn't pass 'this', with all sorts
of strange and unpredictable results.

I tried a second solution, which involved having operator<< as a member
function, but there seems to be no way that I can pass more than one
argument to a bitwise operator (being the ostream reference and the
function to call). Perhaps I just can't get the syntax right on it,
but a search from one end of the ARM to the other didn't help either...

Any helpful comments would be appreciated.  I'm probably missing something
obvious.


david


--
davidn@csource.oz.au 3:632/348@fidonet 58:4100/1@intlnet 199:4242/5@rainbownet
Unique Computing P/L / Communications+LAN Specialists / Public Access USENET
Newsgroups: comp.lang.c++
From: ort@netcom.com (David Oertel)
Subject: Re: Debugging output
Summary: re: debugging output
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 10 Nov 1992 19:18:48 GMT




> Someone please correct me if I'm wrong, but I thought the arguments to
> an inline function still had to be evaluated, even if they aren't used
> in the body.  So if you write

> void debug(ostream& expr) { 
> #ifdef DEBUG
>   if (debug_flag) expr << endl;
> #endif
> }

> debug(cout << "foo: " << foo);

> wouldn't the compiler still have to arrange to do the output anyway as
> part of argument evaluation, even when DEBUG is not defined?  I
> thought it's not supposed to matter to the result whether a function
> is inline or not.

> Or maybe I misunderstood the suggestion?

Ed,
	Your question is good, and I hope some compiler jock gives us the 
	answer.  What I had in mind, however, was something like:

	void debug(ostream& out, String& desc, int val){
	#ifdef DEBUG
		out << desc << val;
	#endif
	}

	debug(cout, "foo: ", foo);

	I don't know whether either version generates code for DEBUG not 
	defined.  Thinking naively about how macros are typically implemented,
	I would suspect not.

	ort@netcom.com
--
From: deanp@peg.pegasus.oz.au
Newsgroups: comp.lang.c++
Date: 11 Nov 92 21:47 EST
Subject: Re: C++ on Mac
Nf-ID: #R:lflsntINNhp2@jethro.corp.sun.com:-606914223:peg:497700003:000:320
Nf-From: peg.pegasus.oz.au!deanp    Nov 11 21:47:00 1992


regarding MPW C++,

you are crazy not to buy the E.T.O CD subscription if you can afford it.
looots of useful online documentation about writing programs for the mac.
not all specifically for c++, but since the compiler is the same as AT&T
releases, you get the AT&T library documentation on the CD as well...

dean :)


Newsgroups: comp.lang.c++,comp.std.c++
From: dan@BofA.COM (Dan Brockman)
Subject: something nasty
Organization: Bank of America, Capital Products, RMTG #5906
Date: Thu, 5 Nov 92 17:13:17 GMT


I received several responses via email to my posting
re the "something nasty" bug .  Thanks to all.  I will
post a summary of the responses and the cure adopted
next week when the deadline crush is off.  
Problem solved for now.  Thanks all.  DanB

-- 
 --------------------------------------------------------------
 Daniel Brockman             tel 415-953-0406, fax 415-622-2892
 Bank of America, Dept 5906, 555 Calif St
 San Francisco 94104 USA    email uunet!odinba!dan dan@BofA.COM
Xref: sparky comp.lang.c++:16276 comp.std.c++:1564
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: The fate of my exponentiation operator proposal
Date: 14 Nov 92 06:54:23 GMT
Article-I.D.: alice.24185
Organization: AT&T Bell Laboratories, Murray Hill NJ



hf@telematik.informatik.uni-karlsruhe.de (Harald Fuchs @ Karlsruhe University, Germany) writes

 > Hey, since the predecessor of C++, ``C with Classes'', didn't provide
 > operator overloading _except_ for operator=, this might have been the
 > way the language evolved. Maybe someone from AT&T can comment on this?

The story is of course somewhat longer than this, but yes, operator overloading
and overloading in general in C++ started with overloading of assignment and
initialization.
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: static data members of private types impossible?
Organization: TauMetric Corporation
Date: Fri, 13 Nov 1992 18:30:31 GMT

johnh@tt.com (John Hasselkus) writes:

|How do you define a static data member of a private type?  For example:

|class A {
|  private:
|    enum FOO {
|      FOO_1,
|      FOO_2
|    };
|    static FOO foo;
|};

|A::FOO A::foo;	// <- Compiler won't let you use private types out here


You can't have a static member of a private type.  Some compilers
allow it, but the ARM is clear that it is illegal.  You can have a
private static member, but its type must accessible at file scope.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: dan@BofA.com (Dan Brockman)
Subject: Re: Criticisms Wanted
Organization: Bank of America, Capital Products, RMTG #5906
Date: Fri, 13 Nov 92 06:08:23 GMT

In article <1992Nov11.175117.15325@bcrka451.bnr.ca> sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:
>
>The real question is *why* does the user have to look into the inner workings of
>the class?  Surely not to discover the inner workings, but to discover behavioural
>characteristics of the class.  Will these be clear from looking inside the class?
>Does the user enjoy poking his nose around where he doesn't belong?
>

Reading source code is hardly a crime.  He could be trying to fix the damned
bug his benighted colleague wrote into the program.  He could be trying to 
find the damned bug.  He could be looking for a good example of how to 
perform some deft programming trick.  He could be making an enhancement.
You are right to ask *why*, though.  It is a good question to ask.  But 
do you intend to prohibit the reading of source code?  That is, *why not*
look into the inner workings, even if you do not have to?
-- 
 --------------------------------------------------------------
 Daniel Brockman             tel 415-953-0406, fax 415-622-2892
 Bank of America, Dept 5906, 555 Calif St
 San Francisco 94104 USA    email uunet!odinba!dan dan@BofA.COM
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: Multiple Header Files Problem
Date: 11 Nov 92 12:59:26 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

walduck@mpr.ca (Andrew Walduck) 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
: >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.
: 
: Why not just wrap your headers in:
: 
: #ifndef someUniqueIdentiferPerFile_inc
: #define someUniqueIdentiferPerFile_inc
: 
: #include <someotherfile.h>
: 
: // grotty code goes here...
: #endif

(I'm sure Bob is aware of this idiom)

You still get problems with circularities, although you do not
cause the compiler to loop forever:

// a.hh
#ifndef A_HH
#define A_HH
#include "b.hh"
// code for "a", needs stuff in "b.hh"
#endif

// b.hh
#ifndef B_HH
#define B_HH
#include "a.hh"
// code for "b", needs stuff in "a.hh"
#endif

// main.cc
#include "a.hh"

Problem is that a.hh gets #included, #includes b.hh, which tries to
#include a.hh.  This will fail, since b.hh will not see all declarations
in a.hh (A_HH is already defined).

In general, circular #includes is a clear indication that you should
revise your source file structure.  Sometimes it is possible to factor out
a common header file, which both a.hh and b.hh #includes.  If a.hh and b.hh
represent collaborating classes, then it is sometimes useful to create a
new "broker" class that forwards request between the classes.  As Bob said,
using forward declarations instead of $includes helps too.

B.T.W., you should regularly analyze your #include dependencies not only
to find circularities, but also for the sake of cleaning up unnecessary
#includes.  If you define the #include patterns during design, you can
also compare that with what is actually there in the source code.
The following trivial AWK script is a start:

#!/bin/awk -f
#
# includes - AWK script that analyses C/C++ source files
#            Generates output of the form
#
#            prog.c Includes "interface.h"
#            prog.c Includes <stdio.h>
#            interface.h Includes <string.h>
#
/^[     ]*#include/ {
                print FILENAME, "Includes", substr( $2, 2, length($2)-2 )
   ^^^^^
   this is a space and a TAB

Feed it to your favorite graphical layout tool (:-), or use a nice
environment that provides #include graphs.

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Newsgroups: comp.lang.c++
Subject: Re: Squares and Rectangles (Re: Const Inheritance)
Date: 11 Nov 92 11:42:30 GMT
Reply-To: nikki@trmphrst.demon.co.uk
Organization: Trumphurst Ltd.
X-Mailer: cppnews $Revision: 1.20 $

In article <1992Nov4.165028.1273@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
> From a mathematical point of view, there is no question about the
> relationship that should hold. Every rectangle IS-A polygon, with
> four sides and four right angles. Every square IS-A rectangle with
> four equal sides. If we are using classes Rectangle and Square to
> model these mathematical concepts (and, say, displaying them on screen),
> then there certainly are common operations we want to carry out.
> For example, we would probably like to draw them, move them, intersect
> them, .... 
I have been trying to avoid the temptation to get into this discussion, 
but I have finally succumbed :-)

The common operations (between Rectangle and Square) you mention also 
apply to other Shapes. I have seen no example so far of an operation
common to a Square and a Rectangle which is not also common to any Shape
(or, at least, to some set of shapes which contains Rectangles, Squares 
and others).

I think our problem here is that we have two separate meanings of "is-a".
In the geometrical sense, any particular Square "is-a" Rectangle. But, 
geometrically, the shape of any given object is fixed, so setWidth() and
setHeight() methods do not make sense geometrically. If you make all 
objects of fixed size and shape, then a Square is-indeed-a Rectangle.

If you consider the problem from the point of view of a topologist, a 
Square, a Rectangle and a Circle are indistinguishable !

-- 
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: Calling pure virtual functions in base class constructor
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 10 Nov 1992 01:06:26 GMT

In article <720990361snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk writes:
>In article <miLRVB10w165w@csource.oz.au> david@csource.oz.au writes:
>> I'm somewhat puzzled as to why the current rule on calling pure virtual
>> functions from a base class does not simply prohibit them from being
>> there (ie. by a compiler error) rather than defining the results as
>> being 'undefined'. (ARM sec 12.7)
>The reason is that it is quite legal to have a definition of a pure 
>virtual function, thus ...
>
>class A
>  {
>    // ...
>      ~A() { purefunc(); }
>      virtual void purefunc() = 0;
>  };
>
>void A::purefunc()
>{
>  cout << "You called a pure virtual function !\n";
>}
>
>This facility might be useful when you want your abstract base class to 
>provide some kind of default behaviour, but you want to force derived 
>classes to add additional behaviour (or, at least, hint strongly :-).

	Not quite. It does not supply 'default behaviour', but 
is called in two by a statically, i.e. like

	A::purefunc(); // from inside a member
	a.purefunc(); // from outside the object

>
>Actually, it occurrs to me that it should be possible to do this yourself,
>without adding to code size (probably) - just declare your virtual 
>functions ...
>
>class A
>  {
>    // ...
>      ~A() { purefunc(); }
>      virtual void purefunc() = 0;
>  };
>
>inline void A::purefunc() { assert(0); }

	No, this cannot work. The body of a pure virtual cannot be
called though a pointer or reference, only from a 'value'. Had
the pure specifier not been included, the body would have been
called virtually during construction of the A base only.
>
>Pure virtual functions can only be called explicitly, under circumstances 
>where the actual type can be deduced at compile time, which are the 
>conditions allowing inline virtuals to be expanded inline. Then again, I 
>could be wrong.

	IMHO you are wrong. It is not a matter of deduction, the programmer
must explicitly override the virtual call mechanism.  Virtual calls
(indirections via the vtble) can be replaced by direct calls only
in code outside the object where the compiler can deduce the actual
object type, this cannot ever be the case inside a member function
as far as I can see (because no member can know what the most derived
object is).

-- 
;----------------------------------------------------------------------
        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: david@lpi.liant.com (David Michaels)
Subject: Re: LPI C++ bug
Keywords: bug, fix, work-around, support, update
Reply-To: mj@lpi.liant.com	
Organization: Liant Software Corporation, Framingham MA	
Date: Fri, 13 Nov 1992 16:08:46 GMT

In article <1992Nov12.112734.11920@aie.nl>, hansb@aie.nl (Hans Bayle) writes:

> This is a bug report for Liant LPI C++, version 01.00.08 for Interactive
> Unix 386/ix.
> When using the debug option, (-g with lpicxx, or -deb with lpi++) the
> calling of methods in objects in which a virtual method is defined will
> result in executing the wrong methods, or causing a segmentation fault (when
> run in Codewatch as well as run stand alone)
> Without the debug option, the code will run correctly. Unfortunately,
> the debug option is needed for the source level debugger Codewatch.
> So most C++ code will not run when compiled for Codewatch :(
> I isolated the bug in the shar archive beneath.

This bug has been fixed in version 1.1 of LPI-C++ which has just been released
for i386/i486 UNIX SVR3 (SCO & Interactive).  We regret that most of your C++
code does not seem to run when compiled for CodeWatch.  As a work-around, try
using the -defvft compiler option.  For bug reports and update information,
please contact Liant directly:

        USA
        ---
        Liant Software Corporation
        959 Concord Street
        Framingham, Massachusetts 01701-4613
        Tel:     (508) 872-8700
        Fax:     (508) 626-2221
        Support: (508) 875-2294
   -->  Email:    support@lpi.liant.com

        UK
        --
        Liant Software Limited
        2 Caxton Street
        London SW1H 0QE
        United Kingdom
        Tel:     +44-(0)71-799-2434
	Fax:     +44-(0)71-799-2552

	Germany
	-------
	Oakland Group GmbH
	Alt-Moabit 91 B
	W-1000 Berlin 21
	Germany
	Tel:     +49 (0)30-391-5045
	Fax:     +49-(0)30-393-4398

Thank-you.

+------------------------------------------------------------+
| David Michaels              |  Email:  david@lpi.liant.com |
| Liant Software Corporation  |  Phone:  (508) 872-8700      |
+------------------------------------------------------------+
Newsgroups: comp.lang.c++