HDTenEightyP/NetNews huggingface dataset:
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: Confusion on :: and protected (Simple?)
Date: 21 Nov 92 14:27:30 GMT
Article-I.D.: alice.24266
Distribution: na
Organization: AT&T Bell Laboratories, Murray Hill NJ



rmartin@thor.Rational.COM (Bob Martin @ Rational) writes
 
 > mike@sdd.comsat.com (Mike Stennett) writes:
 > 
 > |I tried to compile with both DEC's cxx 1.0 and GNU's g++ 2.2.2 but got 
 > |the following errors:
 > 
 > |[39] cxx test.C
 > |test.C:24: error: In this statement, "foo::print" is not accessible.
 > |Compilation terminated with errors.
 > |[40] g++ test.C
 > |test.C: In function `int  static joe::something (int)':
 > |test.C:24: method `int  static foo::print (int)' is protected
 > 
 > |class foo 
 > |{
 > |protected:
 > |	static int print(const int y) { cout << y << endl; return 1;}
 > |};
 > 
 > |class  joe : public foo
 > |{
 > |public:
 > |   static int something(int z);
 > |};
 > 
 > |int joe::something(int z)
 > |{
 > |    foo::print(5);
 >      ^^^^^^^^^^^^^^^    This is the line with the error.
 > |}
 > 
 > ARM 11.5 (p253) says that member functions of derived classes can only
 > access protected members of base classes "through a pointer to,
 > reference to, or object of the derived class (or any class derived
 > from that class). 

Actually, the ARM specifically says NONSTATIC member. That example is
perfectly legal, so he seems to have found bugs in those compilers.
On cfront derivatives - and I suspect most C++ compilers - this works
as written. 

 > However, you can do this:
 > 
 >     this->foo::print(5); 
 > 
 > This is allowable since you are accessing foo::print through a pointer
 > to a joe (this).  Wierd huh?

Very, had the first explanation been true. Fortunately it wasn't.

Actually, because joe::something was static there is no `this' pointer
to use for qualification so ``this->foo::print(5)'' would be an error.

 > E&S try to justify this in the last paragraph of page 254.  

No. The discussion in 11.5 relates to something completely different.

	- BJarne
From: njs@planet.bt.co.uk
Newsgroups: comp.lang.c++
Subject: Re: comp.lang.c++
Date: 20 Nov 92 09:41:37 GMT
Organization: DNM42, BT Labs, Martlesham Heath, Ipswich, UK.
Originator: njs@andromeda


In article <1354@datmuc.UUCP>, vincent@datmuc.UUCP (vincent) writes:
|> >mat@mole-end.matawan.nj.us writes:
|> >|(Howard Pinsley) writes:
|> >|
|> >|> (Roger Haaheim) writes:
|> >|> : (John MAX Skaller) writes:
|> >|
|> >|> : > 	It might be appropriate to have a comp.newuser.c++
|> >|> :                                           ^^^^^^^^^^^^^^^^
|> >|> Why split it up?  If newuser-type ...
|> >|> ...  Let's stay together.
|> >|
|> >|As much as I want to encourage and help new people, I also need ...
|> 
|> >|At the very least, I would like to see `environment' stuff (how to compile,
|> > ....
|> >comp.lang.c++.pedantry or some such.  (comp.unix.wizards might be
|> >the model to follow, but perhaps with a less stringent meaning
|> >of "wizard".)
|> 
|> Well to start how about stoping all cross posting between this group
|> and comp.std.c++.
|> 

With all of this discussion, and a message I posted earlier, I have to say that this newsgroup is too cluttered.  I would actually like to help people solve their c++ problems, but after wading through 50+ messaages a day I don't have time to give more than a perfunctory glance to most of the questions asked.

My employer doesn't pay for me to do this, so the less time I have to spend trawling through messages that don't interest me the more pleased I will be, and the more time I would have to actually help someone.

The ideas presented below - or some close form of them - have my definite vote.

Nathan

|> I Also vote for a hierachy (if someone invents one)
|> 
|> i.e. 
|> 	comp. lang. c++.  std	  (discusion on standard (old comp.std.c++)
|> 			. advocay (discusion on new isues)
|> 			. problems (bugs, code, problems)
|> 			. tools    (tools ..., porting,)
|> 			. source... 
|> 			. don't_know_anmore_idea. bye.bye
|> 
|> ciao vincent@datmuc.dat.de
Newsgroups: comp.lang.c++
From: swillden@news.ccutah.edu (Shawn Willden)
Subject: Re: question on REFERENCES
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Wed, 18 Nov 92 00:38:03 GMT

kestes@nswc-wo.nswc.navy.mil (Kent Estes) writes:
: Hello netters,  
: 
: I am working on a function that references objects via id.  Upon finding
: an object, it returns a reference to that object.  My question is :
: if the object is not found, what is the best way to handle this.  If 
: I were returning pointers to objects, all I would have to do is
: return NULL.

So return a pointer.  There is no way to return a NULL reference (which
is good, if you have a reference you *know* that it refers to something).

If there really is a good reason why you need to return a reference 
instead of a pointer you can declare a special object of the return
type that is always to be returned in case of error and then compare
the address of the returned object with the address of the error 
object (or overload operator== and play games with that).  Usually,
though, you're better off just returning a pointer.

: 
: tnx kl.
: 
: reply via email not encouraged.
: 

--
Shawn Willden
swillden@icarus.weber.edu
From: kilitzir@antigone.csi.forth.gr (Xristos Kilitzirakis)
Newsgroups: comp.lang.c++
Subject: virtual functions need virtual destructors ?
Date: 23 Nov 1992 16:30:01 +0200
Organization: Institute of Computer Science, FORTH Hellas
NNTP-Posting-Host: antigone.csi.forth.gr


Why do virtual functions need virtual destructors ?

Hope to be easy question.



Answers & comments to 
kilitzir@csi.forth.gr
kilitzir@csd.uch.gr
From: matt@centerline.com (Matt Landau)
Newsgroups: comp.lang.c++
Subject: Re: Multiple Inheritance - Necessary?
Date: 20 Nov 1992 20:55:38 GMT
Organization: CenterLine Software, Inc.
NNTP-Posting-Host: 140.239.1.32
Keywords: c++ inheritance

In <By17An.4uH@usenet.ucs.indiana.edu> ezachris@iroquois.ucs.indiana.edu writes:
>A friend of mine who programs in Objective-C argues that multiple  
>inheritance is unnecessary and complicated. 
>
>My Objective-C friend would make a new object "Pencil-with-eraser" that  
>would declare two objects inside it.
>
>     PENCIL-WITH-ERASER
>        Eraser TheEraser(...);
>        Pencil ThePencil(...);
>
>I think this sounds like hogwash. What do you think?

There are basically two ways you can combine the features of existing 
classes:  composition and inheritance.  Your friend's example above is 
an example where combining classes by composition works perfectly well, 
as long as you don't mind the overhead of having to reimplement many 
member functions of both Pencil and Eraser in your new composed class, 
delegating them back to the component parts.

There are other uses of MI for which composition just doesn't provide
the right kind of abstraction.  Consider a class "Collection" that lets
you insert, remove, and search for elements.  Objects that are part of
a collection must have certain attributes that comprise "collectability";
in C++ these attributes are often expressed as virtual member functions
used by the Collection class itself when manipulating members of the
collection.  

One approach to building such a system involves declaring an abstract 
base class which we might call Collectable, whose purpose is to declare 
the required virtual functions.  In fact, it would declare that as pure 
virtuals, so that derived classes are forced to provide an implementation 
for each of them.

To create a collection of pencils, one would want a class that combined 
the attributes of a pencil with the characteristic of collectability; in
C++, one could express this using multiple inheritance:

	class CollectablePencil : public Pencil, public Collectable
	{
	  public:
		CollectablePencil(args) : Pencil(args) { }
		virtual ~CollectablePencil(void);

		... implement Collectable's pure virtuals ...
	};

Now CollectablePencil can be used in any context where Pencil can be
used, *and* can become an element of a Collection.  Similarly, to build
a herd of elephants, one might start with:

	class Elephant : public Pachyderm, public Collectable 
	{
		...
	};

I'm not saying this is the BEST way to deal with collections, but absent
templates (which most compilers are just starting to support), it is an
adequate way, and it's used right now by a number of widely available class
libraries.  It also happens to be a technique that really *requires* MI,
and cannot be done with composition instead.

Personally, I find C++'s version of multiple inheritance overcomplicated,
confusing, and extremely fragile - basically more trouble than it's worth.
In my own programming, I try not to use it for anything *except* this sort
of attribute-based mixins.
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Calling pure virtual functions in base class constructor
Organization: TauMetric Corporation
Date: Fri, 20 Nov 1992 18:41:42 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

|In article <721505557snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk writes:
|>
|>Sorry about the length of this posting, but I really would like to 
|>understand the reasons for all this :-)

|	I suspect it is a quirk. To ban or not to ban a body for
|a pure virtual? Bjarne chose to allow them. I now see and accept that
|apart from some unrelated meaning for the body, some 'default' behaviour
|or, better, 'core' behaviour might well be a good use.

Consider this:  An abstract base class may have a pure virtual
destructor.  The destructor for that base class will be called when
a derived object is destroyed.  Therefore, you must provide a
definition for the pure virtual destructor.

The alternative would have been for the language to forbid pure virtual
destructors, or to have special rules for them.  It seems simpler to
allow a definition of a pure virtual function.  It cannot cause any
difficulties, and is necessary or desirable in some cases.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: pete@borland.com (Pete Becker)
Subject: Re: Operator -> cannot return non-class types?
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Tue, 17 Nov 1992 16:58:41 GMT

In article <1992Nov17.131437.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
>
>The _real_ question is not _does_ the restriction exist but _why_ does
>it exist? One clealy couldn't _use_ an operator->() returning anything else.
>BUT there can be good reason for a template class to have an operator->()
>that would only be usable for some values of the template parameter.
>
>template <class T> PtrClass { T* operator->();};
>
>I now fully support the original poster's assertion that this restriction
>should be lifted now that the language has templates.

	I must have missed something, because I don't see the connection
between the use of operator->() and templates.  Yes, you ought to be able to
use operator->() in a template.  The fact that there are types for which
such use would be illegal doesn't seem particularly important, unless, of
course, you attempt to instantiate the template for one of those types, in 
which case you have a programming error which the compiler ought to 
diagnose.
	Is the claim here that the possibility that the template could be used
incorrectly makes the template definition illegal?  If so, get yourself a
different compiler.
	-- Pete


Newsgroups: comp.lang.c++
From: hansen@pegasus.att.com (Tony L. Hansen)
Subject: Re: Making qsort type-safe
Organization: AT&T
Date: Mon, 16 Nov 1992 15:45:33 GMT
Summary: examples of unsafeness
Keywords: sorting, templates, qsort

< From: mdr@netcom.com (Marc D. Rossner)
< In article <1992Nov12.194207.19040@cbnewsk.cb.att.com>, hansen@pegasus.att.com (Tony L. Hansen) writes:
<< [ .. describes a safe qsort]
<< Is that the end of the story, though? No, of course not, because just
<< swapping the bits around may not be sufficient to swap a[0] and a[1]. They
<< may truly have to be swapped using assignments, and qsort provides no way to
<< do that.

< Can you think of a good example of this?  I realize that COPYING an
< objects bits may be insufficient for making a conceptually independent
< copy, but I can't think why swapping the bits of two objects would not
< leave the two objects physically and conceptually swapped.

Two examples come to mind, both related:

    o	An object consists of an outer object with a pointer to an inner
	object. The inner object also contains a pointer back to the outer
	object. Swapping the bits of the outer object won't get the inner
	objects updated properly.

    o	An external registry of a pointer and some information about the
	object is maintained about for each object, and doing an assignment
	will update that external registery. 

Defining a safe and efficient sort function is hard, as there are tradeoffs
which must be made. Some tradeoffs are appropriate in some cases and not in
others. The example of swapping bits is one tradeoff. There may be times
that swapping bits is just fine; other times it's disastrous. Some times a
third algorithm is more appropriate. The example in the first bullet item
above could probably be handled by swapping the bits and then updating the
inner object's pointer, but only a swap<T>() function could know that.
qsort<T>() cannot know apriori how to handle any given type. On a related
note, the comparison function doesn't necessarily have to provide a total
ordering of two elements, and using operator<() would be sufficient.
Similarly, just using the less-than relationship, provided by some other
function, would often be sufficient. This probably argues for a set of
related functions which provide various options for the different tradeoffs.

					Tony Hansen
			    hansen@pegasus.att.com, tony@attmail.com
				att!pegasus!hansen, attmail!tony
From: sb@next.neuro.emory.edu (Stephen O. Berger)
Newsgroups: comp.lang.c++
Subject: Template classes and overloaded binary operators on differing types
Date: 19 Nov 1992 18:38:44 GMT
Organization: Emory University, Dept of Math and CS
Reply-To: sb@next.neuro.emory.edu
NNTP-Posting-Host: next.neuro.emory.edu



Hi,

  Can someone please comment on the following problem and suggest the
"best" way to solve it.

   Say I have a template class that implements a VECTOR type and binary
 operators like addition and subtraction. All of the binary operators are  
currently implemented as template friend functions which accept two  
vectors of the same type. For example, I have this :


  VECTOR<int> ivec1(3),ivec2(3),ivec3(3);  // 3 is vector size

  ivec3 = ivec1 + ivec2;   

  My question is, how can I extend this so that I can add vectors of  
differing types ?  e.g.,

	VECTOR<int> ivec1(3);
        VECTOR<double> dvec1(3),dvec2(3);

        dvec2 = ivec1 + dvec1;

 What is a good way to implement this ?


 Steve Berger (sb@onripx.neuro.emory.edu)
Xref: sparky comp.lang.c++:16360 comp.std.c++:1573
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: something nasty report
Date: 16 Nov 92 15:45:57 GMT
Article-I.D.: unx.BxtFsM.4Iv
Organization: SAS Institute Inc.
Originator: sasghm@theseus.unx.sas.com


In article <5798@npg-sd.SanDiegoCA.NCR.COM>, rns@npg-sd.SanDiegoCA.NCR.COM (Rick Schubert) writes:
|> In <BxIp1L.M37@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:
|> 
|> >When a compiler dies with an internal error, causes an access
|> >violation, etc. it is *always* a bug.
|> 
|> Not *always*: if the internal error is caused by an error in the program
|> being compiled, it is merely a very user-unfriendly error message (I

Nonsense.  It is a symptom of an oversight on the part of the compiler
writer to handle less than ideal programs.  It is a flaw in the
compiler.  (I'm sure we all have these flaws in our compilers, but
they *are* flaws.  It is our job to eliminate them -- or at least
to minimize them.)

(Actually, the correct answer is along the lines of:  Not *always*.
Such an internal error *could* be caused by a bug in the operating
system -- in which case it is not the fault of the compiler.  But
this case certainly is pretty rare.)

|> consider "segmentation violation -- core dumped" to be the ultimate
|> diagnostic).
|> 
|> -- Rick Schubert (rick.schubert@SanDiegoCA.NCR.COM)

You must use a lot of UNIX compilers -- maybe even free ones.
-- 
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
Newsgroups: comp.lang.c++
From: rik@nella9.cc.monash.edu.au (Rik Harris)
Subject: template problem (g++)
Keywords: bug? g++ template operator
Reply-To: rik.harris@fcit.monash.edu.au
Organization: Monash University, Melb., Australia.
Date: Wed, 18 Nov 1992 05:38:19 GMT

I'm having a problem with templates, using g++ 2.3.1.  It occurs when a
function template argument is a base class, and a template function
not being generated when using a derived class (ARM terminology p345).
In the program below, I believe it should generate a template for
operator<< for the A<int> type, as B is derived from A<int>, but it
doesn't seem to.  I get the error:
ld: Undefined symbol
   ___ls__FR7ostreamRt1A1Zi


Am I expecting too much from C++, or is this a problem with g++ 2.3.1?
I have a friend with Borland C++ (a version with templates, not sure
which one) and he was able to compile this code.  If it is
unreasonable for C++ to automatically generate a template for operator<<,
is there a way I can coerce it to do so?

// simplified example...don't look too hard at it's usefulness :-)
#include	<stream.h>

template<class T>
class A
{
  T	a;
public:
  void set(T b) { a=b; }
  friend ostream& operator  << (ostream& s, A<T>& x);
};

template<class T>
ostream& operator << (ostream& s, A<T>& x)
{
  return s << "template: (" << x.a << ")\n";
}

// it compiles with this line uncommented
//ostream& operator << (ostream&s, A<int>& x) { return s; }

class B : public A<int>
{
  int	a;
public:
  void set(int i) { a=i; }
};

main()
{
  B	b;

  b.set(3);
  cout << b;
}


thanks for any help,
rik.
--
Rik Harris - rik.harris@fcit.monash.edu.au
+61 3 571-2895 (AH & ans.mach) +61 3 573-2679 (BH)
Faculty of Computing and Information Technology,
Caulfield Campus, Monash University, Australia
Newsgroups: comp.lang.c++
From: davidc@brahms.udel.edu (David Casper)
Subject: BC/C++ For Sale
Followup-To: davidc@brahms.udel.edu
Keywords: sale, BC/C++
Organization: University of Delaware
Date: Thu, 19 Nov 1992 23:57:40 GMT

FOR SALE:  BC/C++ v3.1

I purchased the full BC/C++ v3.0 about 1 month before v3.1 release...
so Borland sold me v3.1 for $3X.XX   They sent all v3.1 disks 
and one (1) v3.1 manual...  when I called and asked why I received
only one (1) v3.1 manual, when I had 8 or 10 (complete, but I never
counted) manuals for v3.0, they told me that the only one (1) manual
had been changed for the new release...


My point...I wish to sell (and transfer all formal registration) for
my copy of Borland C/C++ v3.1 (with all manuals, disks, etc as
described above) for $90.00 U.S. dollars...

If you are interested...please send email to "davidc@brahms.udel.edu"
or call (voice) at (302) 837-1313 and leave message.

FYI, the disks have only been used for one installation, the manuals
are barely touched, and even the box is in good shape...I purchased
the program last May and, during this past summer, I decided to
spend all of my time with my guitar, not with my computer... :-)


-- 
David W. Casper
davidc@brahms.udel.edu
From: andy@federation.gatech.edu (Andy Register)
Newsgroups: comp.lang.c++
Subject: Re: Does anyone understand this quirk?
Date: 17 Nov 92 13:55:26 GMT
Organization: CERL-EE, Georgia Institue of Technology


Nah, it does what I would expect.  The constructor for B
first creates an A.  When the constructor for A is called
it really doesn't know anything about B, yet.

Try replacing your B ctor with,
         B () : A() { id(); }
and watch what happens.

Toodles
Andy
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: BC++ Container Class Problem
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 20 Nov 1992 13:52:25 GMT

In article <1992Nov16.014419.27027@ntuix.ntu.ac.sg> gthkoh@ntuix.ntu.ac.sg (Koh Thong Hwee) writes:
>
>In particular, I would like to know how to use the link list to store
>disparate objects.  I can use the indirect storage method of storing their
>pointers instead.  However I need to declare the type T for the link list
>template class and how do I declare it for storing the different pointer types
>to the many different kinds of objects? 
>

	The best way to do this is with tagged pointers ... but thats
only a proposal of mine, so here's roughly how to emulate this facility.

	Suppose you want to but pointers to A,B and C objects in the list.
(Or an array, or other container). Well, you cant, you can only put objects
of a single type in a container.

	struct ABC {
		enum {A_t, B_t, C_t} tag;
		union {
			A* a;
			B* b;
			C* c;
		};
		ABC(A* aa) {a=aa; tag=A_t;}
		ABC(B* bb) {b=bb; tag=B_t;}
		ABC(C* cc) {c=cc; tag=C_t;}
	};

Now put ABC objects in the list. Use them like this:

	ABC abc;
	...
	switch(abc.tag)
	{
	case A_t: a->print(); ...
	case B_t: b->print(); ...
	case C_t: c->print(); ...
	}

This mechanism would be completely automated using tagged pointers:

	[A,B,C] *abc;
	abc->print();

The method does NOT require any casts, it is 'type-safe' by not secure
in that you might select the wrong union member. However using casts
is far worse, you might cast to anything. Tagged pointers, however
are completely secure (since the tag checking code is compiler generated).



-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: kanze@us-es.sel.de (James Kanze)
Newsgroups: comp.lang.c++
Subject: Re: packing/unpacking unsigned in char ?
Date: 19 Nov 92 00:06:57 GMT
Organization: SEL

In article <1992Nov15.225151.7502@imada.ou.dk> adelt@imada.ou.dk (Adel
Shavandi) writes:

|> I need some suggestions for an effective and correct way to
|> pack/unpack unsigneds in [0,127] in chars and communicate
|> them to another process.  

|> What i do myself is as the following code:


|> // child process:
|> 	// ...
|> 	unsigned num1;
|> 	// ...
|> 	// num1 is in [0,127] now
|> 	printf("%c",num1); // later is rediercted to parent by pipe mech.
|> 	// ...


|> // parent process:
|> 	// ...
|> 	unsigned num2;
|> 	char ch;
|> 	int n=read (fd,&ch,1);
|> 	if (n>0)
|> 		num2=(unsigned) ch;
|> 	// ...


|> Now i know this may be wrong since sometimes i receive some wrong
|> numbers. Any ideas/suggestions ?

|> But what is interesting is that the wrong numbers are very similiar
|> each time. Am i confronting with pitfalls ?! 

You don't say what OS you're using.

On most non-Unix systems (MS-DOS, for example), there is a distinction
between binary files and text files.  In such cases, stdout (which
printf uses) is normally opened as a *text* file.  Independantly of
this, I'm not sure what the implications would be of using printf on a
binary file.

As an example of the difference, in a text file, MS-DOS will convert
the character '\n' (0x0a) to a two character sequence 0x0d,0x0a.

So the correct solution is to open a file (don't use stdout) for
binary output (fopen( <filename> , "wb" )), and output to it, with
either fwrite or putc.  (On some systems, it's possible to change the
mode of stdout, but this is non-portable.)
--
James Kanze			GABI Software, Sarl.
email: kanze@us-es.sel.de	8 rue du Faisan
				67000 Strasbourg
				France