HDTenEightyP/NetNews huggingface dataset:
From: Bob Hathaway <objsys@netcom.com>
Subject: Vtbl and Ptr to Member Questions
Keywords: vtables, PM, Pointer to Member
Organization: Object Systems
Date: Wed, 6 Jan 1993 03:33:29 GMT

Hello,

I have two C++ questions I would most appreciate an expert response to.
First, (this looked wrong the first time I looked at it and it still does),
on pg 235 of the ARM, Virtual Base Classes with Virtual Functions, shouldn't
MW and BMW's vtbl look like:

  &BW::f  | delta(BW)	- 0
  &MW::g  | 0		- 0
  &BMW::h | 0		- 0
  &W::k   | delta(W)	- 0

The rest look Ok, but was the above table in the ARM a typo?

Also, can a pointer to member (function) of any class be declared and if
not (for lack of typechecking), whats the best (or least implementation
dependent) workaround?  I'd like to avoid approaches such as those involving
declarations and casting to functions with void * as the first parameter;
but even establishing that this approach is as good as any other would be
helpful, I think.

Thanks,
bob
objsys@netcom.com
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: Preventing inheritance
Date: 11 Jan 93 15:21:16 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: TIN [version 1.1 + PL8]

Howard Ferguson (hlf@nic.cerf.net) wrote:

: If I create a class which I am supplying to other users, how do I
: make sure that they do not inherit from it ever. I could overload new
: and check the size of the object that is being allocated, but there
: are two catchs. The first minor one is that this is a run-time check,
: and it would be far preferable to catch this sort of thing at compile
: time. More seriously, they could over-ride the new operator and by-pass
: the check.

If your objects are always heap-based, you can prevent inheritance by
making the destructor private:

class X { public:
    static X* create() { return new X(); }
    static void destroy(X* it) { delete it; }
private:
    X() { /*...*/ }
    ~X() { /*...*/ }
};
-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: euamts@eua.ericsson.se (Mats Henricson)
Subject: Re: Private vs. Protected
Reply-To: euamts@eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Tue, 12 Jan 1993 15:54:29 GMT

In article 90218@ncratl.AtlantaGA.NCR.COM, vkessler@ncratl.AtlantaGA.NCR.COM (Vance Kessler) writes:
#I would like to get your feelings as to when to use private versus when to use
#protected.
#
#I generally make instance variables protected to give direct access to
#sub-classes.  But, I am thinking that it might make maintenance easier to make
#them private and always access them through protected access functions.
#
#I would appreciate your opinions on this.
#
#Vance Kessler
#vkessler@ncratl.atlantaga.ncr.com

Our public domain coding standard recommends the second approach, i.e. make
data private and let subclasses access them through protected access functions.

Mats Henricson
Ellemtel Telecom Systems Labs
Stockholm
Sweden

Newsgroups: comp.lang.c++
From: girod@kilohp.kiloapo.ts.tele.nokia.fi (Marc Girod)
Subject: Re: Static global initialization outside of main() legal?
Reply-To: marc.girod@ntc.nokia.com
Organization: /user/girod/.organization
Date: Mon, 4 Jan 1993 10:23:11 GMT

wlee@sales.GBA.NYU.EDU (Wai-Shing Lee) writes:
wlee> I want to initialize a static global at run-time but I don't want to
wlee> have to have a programmer using my modules to have to call some init() funciton
wlee> at the begining of thier main().

This is a problem I have met already. I find it most recommendable to
find a way to insure that needed static data is transparently
initialised before use, without any explicit call of the user. This
should definitely be well (better!) supported by the language.

>>>>> On Thu, 31 Dec 1992 19:11:23 GMT, nagle@netcom.com (John Nagle) said:
John>        You're working in a very messy area of C++.  The order in which
John> things happen during static initialization isn't the same in different
John> compilers.  The language rules arein section r3.4 of "The C++ Programming
John> Language, Second Edition", and you should read them if you want to do this
John> sort of thing.

Things are not so bad as John states! The most important is
guaranteed: that "the initialisation [...] in a translation unit is
done before the first use of any function or object defined in that
translation unit". There remains the "pathologic" case of mutual
dependencies, dealt with in the annotation part of the ARM for 3.4,
... and the treatment of "virtual constructors" through the
declaration of meta-class objects, the precise class of which should
be kept unknown to the rest of the world...

John>        In most implementations, static initializers are run before
John> "main" is called. 

But not in all, as unfortunately allowed by the language (e.g. g++).

John>                    For initializers that don't call functions, this
John> is enough to get the static variables initialized properly.  But
John> initializers that call functions can create serious problems, especially
John> if the functions have side effects, are in a different compilation unit
John> (file), or depend on other static variables being initialized.  The order
John> in which things get initialized varies from compiler to compiler and
John> sometimes from compile to compile, so you can't depend on this at all.

Well, there is no surprise: you should not rely on such order, but if
you may "force" it explicitly, e.g. with the technique of "nifty
counters" described in the ARM (among others).
--
+-----------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications       Phone: +358-0-511 7703          |
| TL4E - P.O. Box 12                            Fax: +358-0-511 7432          |
| SF-02611 Espoo 61 - Finland              Internet: marc.girod@ntc.nokia.com |
|    X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc     |
+-----------------------------------------------------------------------------+
Newsgroups: comp.lang.c++
From: jonesa@syma.sussex.ac.uk (A Jones)
Subject: Dyad M++ Re-compilation?
Organization: University of Sussex
X-Newsreader: Tin 1.1 PL5
Date: Tue, 5 Jan 1993 13:49:38 GMT

Maybe this is more suited to comp.law.misc ..

I've been using the M++ matrix class library for research towards my PhD
and would have to say that it is very good. However my PC has only 16M
of RAM and I need to work with ~100M data structures. The library source
code came with Zortech C++ and I'm wondering if anybody has any leads as
to the legality of re-compiling the source for a SPARC clone for
personal use. If so has anybody got a make file to accomplish this?
Or the address of Dyad?

Thanks in advance,
						Gareth.
-- 
* A. Gareth Jones			* JANET:			*
* Postgraduate Pigeonholes, ENGG 3,	* jonesa@uk.ac.sussex.syma	*
* Sussex University, Brighton,		* INTERNET:			*
* E. Sussex, England, BN1 9QT.		* jonesa@syma.sussex.ac.uk	*
Xref: sparky comp.lang.c++:19041 comp.object:4768
From: cshaver@informix.com (Craig Shaver)
Newsgroups: comp.lang.c++,comp.object
Subject: Re: Pros and cons of C++
Date: 12 Jan 93 20:14:49 GMT
Organization: Informix Software, Inc.

In article <PwR9wB3w165w@wozzle.linet.org> alane@wozzle.linet.org (J. Alan Eldridge) writes:
>sailer@hpuerca.atl.hp.com (Lee Sailer) writes:
>
>> 3.  There is an Obj-C front end for Borland C.
>
>(serious questions) Where? From whom? (couldn't resist) Why?

Me too!  Please Post!

>
>alane@wozzle.linet.org (J. Alan Eldridge)
>Fido: The University of Walamaloo 1:272/38.473


-- 
Craig Shaver  (cshaver@informix.com for now) (415)390-0654 (415)926-6407
Productivity Group POB 60458 Sunnyvale, CA  94088
Newsgroups: comp.lang.c++
From: hansen@pico.cs.umn.edu (David Hansen)
Subject: Re: How to prevent local instances, but allow "new"
Organization: University of Minnesota
Date: Thu, 7 Jan 1993 01:44:34 GMT

In article <726348154snx@trmphrst.demon.co.uk>, nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
[...]
|> 
|> Leave the constructors public. Make the DESTRUCTOR private. Provide an
|> inline member function ... 
|> 
|> 	void destroy() { delete this; }
|> 
|> Users have to call destroy instead of delete, but they won't be able to
|> create automatic, static or extern objects of the class.

This is the approach I took.  However...

When I first started reading this group, there was a discussion about whether 
"delete this" would be legal in the future.  The general consensus (from what
I read) was "probably not."  Is there still a question about this?  The above
seems to me a good argument for keeping it legal.

					-=Dave
From: tk@dcs.ed.ac.uk (Tommy Kelly)
Newsgroups: cs.questions,comp.lang.c++
Subject: Re: Dynamic Multidimensional Array Allocation in C++
Date: 5 Jan 93 01:02:14 GMT
Reply-To: tk@dcs.ed.ac.uk (Tommy Kelly)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U

In article <C0C68I.MA7@dcs.ed.ac.uk> tk@dcs.ed.ac.uk (Tommy Kelly) writes:
>How do I implement a dynamically configurable two dimensional array in C++?
>
>For one dimension its easy, but doing:
>
>my_type *my_type_var = new my_type[a][b];

What I'm doing at the moment is explicitly creating a vector of vectors like:

	My_type **my_type_var = new My_type*[a];
	for(int i=0; i<b; i++) {
    	  my_type_var[i] = new My_type[b];
	}

I can then access the array my_type_var[a][b] as normal.
But it seems kinda inelegant.  Maybe I expect too much from C++...

tk
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: About class template names
Date: 7 Jan 93 16:01:42 GMT
Article-I.D.: alice.24568
Organization: AT&T Bell Laboratories, Murray Hill NJ



arthur@solomon.technet.sg (Arthur Sombrito) writes

 > Hi,
 > 
 > According to the ARM, a class template name must be unique in a program
 > and may not be declared to refer to any other template, class, function,
 > object, value, or type in the same scope.
 > 
 > Does this mean that a name previously used as a class template name
 > can't be reused in another scope? For example:
 > 
 >    template <class T> class U {};
 >    enum U {};    // This should be an error. I am wondering why GNU
                 // and Borland accepted this.

They shouldn't accept it. 

 >    f() {
 >      union U {}; // So is this an error?
 >    }

No. That's OK. U is not in the global scope and hides the global U within f().
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Callbacks in C++
Organization: Rational
Date: Sun, 10 Jan 1993 14:58:27 GMT

hlf@nic.cerf.net (Howard Ferguson) writes:

>The FAQ for this group describes how to put wrapper functions around 
>member functions so they can be called as callbacks from X libraries
>and the like. But if I am writting a c++ class library, surley I should
>be able to provide a cleaner mechanism to my customers. Is there
>a standard way of doing this???

If you are designing a class library, you don't generally want to
provide callbacks to your users.  Instead, you want to provide them
with interfaces that they can use to receive information from you.
These interfaces are abstract classes.  Pure virtual functions are
declared which allow information to be passed from your class library
to user objects derived from the abstract classes.  The users can
implement the derivatives of the pure virtuals as they see fit.


--
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++
From: mhopper@emperor.gatech.edu (Michael A. Hopper)
Newsgroups: comp.lang.c++
Subject: template problems
Date: 5 Jan 93 03:34:02 GMT
Organization: Computer Engineering Research Lab, Georgia Tech.
Originator: mhopper@emperor

I'm not sure if this is the right newsgroup, but...

I have a template which contains two constant member functions, one
which is inline, the other is defined separately from the declaration,
as shown below.  The inline function works fine, but the other function
causes a compiler error when defined as a const.  The error occurs with
gcc (g++) 2.2.2 but the code works fine with Borland C++ 3.1.  The error
states that the function `print' does not belong to the class
`template<whatever>'.

Has anyone ran into this problem before?  Is there a list of gcc bugs
floating around that informs us of such bugs?  Do I need a gcc upgrade?

The code of interest is below:

template<class T>
class Fifo
{
  public:
	// ...
	void print(int indent=0) const;		// causes error.

	unsigned int size(void) const { return (msize); }  // okay here.

  protected:
	unsigned int	msize;
	T		*entries;
};

/********************************************************/
template<class T>
void
Fifo<T>::print(int indent=0) const
{
cout << "size = " << msize << endl;
}


Also, when using default arguments, gcc requires both the function
declaration and definition to specify the default value, while
Borland C++ causes and error if the definition includes the default 
value.  Which way is the standard?

-Mike

-- 
| mhopper@cerl.gatech.edu |   ' ) ) ) o  /_       ' )  /   ROLL TIDE !!!
| Office: CRB 388         |    / / / /  /\_) __    /__/______   _   __  __
| Phone: (404) 894-9111   |   / / (_/\_/  \_/_/_  /  / (_) /_)_/_)_/_/_/ (_
| Home:  (404) 723-1718   | ALABAMA: 1993 Nat'l Champs    /   / how Sweet it is!
Newsgroups: comp.lang.c++
From: pf@bilbo.bio.purdue.edu (Paul Furbacher)
Subject: Re: Reusability will come true bringing by OOP?
Followup-To: comp.lang.c++
Organization: Purdue University
Date: Tue, 12 Jan 1993 17:29:31 GMT

In article <1993Jan12.042140.27051@sparc4.ncu.edu.tw>,
oper7@ee05.ncu.edu.tw (Anthony Shih Hao Lee) wrote:
[..]

> Think about this if you are a TVISION programmers:
> if Borland does not release TVision source code, do you really trust
> the quality of that package?

If I'm not mistaken, the source code for both OWL and 
TV comes with Borland C++&Application Frameworks.  It is
now available with the Borland Pascal 7.0 package.

As far as reusability of code or extensibility of object libraries
is concerned, much of what is written and promised is simply
an expression of the *ideal* situation.  Ideally, well-written
and documented object libraries should allow complete 
extensibility without having to resort to hacking the source code
of the original object library.  That is the ideal.  But few
software authors are capable of anticipating all the possible
extensions which their objects may undergo in real life.
Therefore, there is always something missing or wrong in the 
foundation classes/objects which requires the source code to
be hacked because inheritance cannot straighten out the problem.

TV is good but not perfect.  What are the impressions of
OWL users -- could you live without the source code?  I doubt it.
TurboPower has provided source code with their libraries from 
day one, even though their libraries are of excellent quality.
They are also extremely well commented and therefore a good 
learning tool.

In five years time, some other new programming paradigm   
will come along and again promise to make unnecessary the
distribution of source code with the new-fangled library.
Yeah, right.

pf
From: pellinor@cs.mcgill.ca (Michael CHOWET)
Newsgroups: comp.lang.c++
Subject: Any good intro's to OOP?
Summary: Looking for titles to get into OOP...
Date: 8 Jan 93 18:55:08 GMT
Distribution: na
Organization: SOCS - McGill University, Montreal, Canada


Hello.

  I've been programming for a while, but I've never gotten around to objects 
and never had a need for OOP. Until now, that is. I was wondering if there
are any decent publications that can get someone started on OOP. Both printed
materials such as books and articles, or some available somewhere via FTP (as
expected, this one's preferred if only for expediency) would be appreciated.
In guiding your choices, I like to think of myself as a fairly strong plain
vanilla ANSI C programmer (don't we all? :), with his roots in Pascal.

  I see that there was a newbie thread in here just recently, so I ask you
to please save bandwidth and mail responses to me directly at:
pellinor@cs.mcgill.ca. As well, I ask you to please save the wear and tear
on the /var/spool partition and only respond to this letter in the first
week of its existence.

	a T d H v A a N n K c S e

|          Michael Chowet, U3        |     I've an image in my pocket        |
| Computer Science Undergrad Program |         of some dark demon            |
|      McGill, Montreal, Canada      |  that temptation brought to life...   |
|_____ pellinor@cs.mcgill.ca ________+________  - Melissa Etheridge _________|
-- 
|          Michael Chowet, U3        |     I've an image in my pocket        |
| Computer Science Undergrad Program |         of some dark demon            |
|      McGill, Montreal, Canada      |  that temptation brought to life...   |
|_____ pellinor@cs.mcgill.ca ________+________  - Melissa Etheridge _________|
From: dodd@dodd.UUCP (Mike Dodd)
Newsgroups: comp.lang.c++
Subject: Re: Borland C++ compiler products ?
Date: 6 Jan 93 18:32:22 GMT
 <7522@tivoli.UUCP>
Reply-To: dodd!dodd@seq.uncwil.edu
Organization: Not
X-Newsreader: Arn V1.00 beta rel2

I think DDJ does a nice job of explaining why BC++ Debugger runs under DOS.
Apparently it has a lot to do with the way Windows 'multitasks'.  A step
through the code and an unanswered message causes windows to freeze.  The
'true' windows debuggers are according to the article (and I am paraphrasing
at best) are a little buggy themselves because of the way they have to handle
things.  I am happy with the debugger Borland gave us.  It is a heck of alot
better than codeview, and a text based debugger (though boxy) runs better and
when debugging my own buggy code I don't need a buggy debugger. :-)

			    -Mike

+-----------------------------------------------------------------------+
|   Michael E. Dodd		Internet:  dodd!dodd@seq.uncwil.edu     |
|   219 Pershing Court		Voice:     919/799-9453                 |
|   Wilmington, N.C. 28412	(Answering Machine on between 4-10PM)   |
+-----------------------------------------------------------------------+
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: why `int X: :X()' ?
Date: 7 Jan 93 15:53:50 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: TIN [version 1.1 + PL8]

Matt Wette (mwette@csi.jpl.nasa.gov) wrote:

: Why are constructor and destructor functions usually declared to return
: ints when the usage typically warrents a `void' declaration.

The "default int" rule does not apply to constructors and destructors.
You can't return an "int" from those functions.  You can't explicitly
mark them as procedures (void) either.

I'd say that "default void" (as for constructors and destructors)
makes more sense than "default int".  Having no default type at all
makes the most sense, avoiding compiler and programmer confusion.

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.pascal
From: ctaylor@cs.uiuc.edu (Conrad Taylor)
Subject: An article by Jean G. Vaucher "Pretty-Printing of Trees"...?
Organization: University of Illinois at Urbana-Champaign
Date: Wed, 6 Jan 1993 05:46:14 GMT

         Yes, I have obtained an article in the "Software - Practice and 
Experience" for the pretty printing of trees and was wondering would any- 
body have an e-mail address for the above named author?  I think there
might be a small mistake in the code but I would like to speak with the author
in regards to this before I jump to any conclusions.  So, if anyones knows
his e-mail address, I would be very grateful.  Well, thanks in advance to all
that reply to this post.

-Con

ps:  My e-mail is ctaylor@silver.lcs.mit.edu or
     taylor1@jupiter.eecs.uic.edu.


Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: feedback wanted on appropriate OOPL
Organization: Rational
Date: Mon, 11 Jan 1993 23:33:06 GMT

tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

|In article <rmartin.726674455@thor> rmartin@thor.Rational.COM (Bob Martin) writes:

|   A language can have a significant impact, however, on quality,
|   run-time efficiency and coding efficiency.  C++ will certainly catch
|   more programmer errors than stalk [Smalltalk], [...]

|It is only true to say that _at compile time_, C++ will catch more
|programmer errors than Smalltalk.

|If you take into account both compile time and runtime, Smalltalk will
|catch more "programmer errors" than C++: not only will Smalltalk catch
|all type errors, but also bad pointers, overflows, and array bounds
|violations, errors that go undetected in most C++ implementations and
|are not mandated to be detected by the C++ definition.

Deferring error detection to runtime is risky, since the error may be
encountered several months after its release.  Also, there are several
C++ development environments that catch runtime errors just as nicely
as stalk does.  So, I don't accept that runtime error detection is
either an advantage or the exclusive domain of stalk.


--
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: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Restatement and clarification of "static inheritance" question
Keywords: inheritance
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 8 Jan 1993 17:44:34 GMT

In article <1993Jan8.154446.17174@dayfac.cdc.com> pault@dayfac.cdc.com (Paul Thompson;DAYFAC-ITS;) writes:
>First off, thanks to all those who responded to my question and my
>apologies for not being clear. I probably should have chosen a different
>phrasing of the problem and certainly should have explained it better!
>First to answer the replies received so far and I will clarify.

	You missed mine?
> 
>WHAT I AM INTERESTED IN IS THE FUNCTIONALITY OF "COUNTING ONE'S
>OWN INSTATIATIONS", NOT COUNTING THE TOTALITY OF ALL INSTATIATIONS OF
>CLASS A. 

	class A {
		int & counter;
	public:
		A(int& c) : counter(c) {++counter;}
		~A() { --counter; }
	};

	class B : public virtual A {
		static int counter;
	public:
		B() : A(counter) { ... }
	};

	int B::counter=0;

Without templates. Exercise: Prove it works! Prove you cannot
get away without declaring and defining the counter in
each class manually.

There are a number of possible ways that might fix this using templates.
You would have to do something like:

	class B : public virtual A<B> { ...

which seems dubious. Then the template class A<T> could create
the int A<T>::counter automagically. Dont know if this
works.

-- 
;----------------------------------------------------------------------
        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: Morten Irgens <morten.irgens@si.no>
Subject: where to find a good class string?
X-Useragent: Nuntius v1.1.1d5
Date: Mon, 11 Jan 1993 13:50:59 GMT
X-Xxdate: Mon, 11 Jan 93 14:53:24 GMT
Organization: Senter for Industriforskning


Newsgroups: comp.lang.c++