HDTenEightyP/NetNews huggingface dataset:
Subject: Re: Need help implementic data structures of generic objects
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Trumphurst Ltd.
Date: Tue, 15 Dec 1992 20:29:18 +0000

In article <1992Dec13.002551.778@informix.com> cshaver@informix.com (Craig Shaver) writes:
> Another tech weenie C++ bigot speaks out against Object Oriented Programming
> methodology in general!  (no :')

No, the various C++ programmers who have replied to your rantings have 
merely stated that C++ is not the best language to implement a particular 
design, viz. heterogeneous collections.

> This group seems to be biased against inheritance techniques in all cases.

No, this group merely states that heterogeneous collections (and certain 
other things) are difficult to implement in statically typed languages 
like C++, because they are incompatible with static typing.

> Matthew is going through the physics department of berserkeley, so I have
> to assume we are dealing with a person of intelligence.  That is unless
> the night janitor has an interest in C++ class libraries.

No-one was insulting Matthew's intelligence. I take it you are the night 
janitor at Informix :-) [ Sorry, couldn't resist. I'm sure you are highly 
intelligent really, it is just that your postings do not make it obvious ].

> It is obvious to me that you have a virtual function in the base class for 
> all functions that you need to use when dealing with 'Objects'.

This is the major problem with such systems - you end up with hundreds of 
virtual functions in the base Object, most of which will not be used 
(indeed, have no meaning) in a particular derived class. It can work, but 
it is not elegant C++.

> If you use a function on a class that is only restricted to a certain
> sub-tree of your inheritance structure, then you know what you are using,
> ergo, you should have used that type instead of 'Object'.

Correct. That is what everyone else is saying too.

> So if you insist on making something more complicated than is needed and
> you do not use good sense and good software engineering practices; it may come
> back to haunt you.  

Precisely what everyone else is saying. Deriving everything from Object 
_is_ making things too complicated.

And as for inheritance, in C++ it is for expressing an "is-a" 
relationship. Templates are for expressing genericity.

[ Remind me to avoid the first few versions of any C++ class libraries 
that Informix come up with. Or was your disclaimer missing :-]

-- 
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: alexism@ngc.com (Alexis Mermet)
Subject: Re: Operator "new" - how to catch array-allocation?
Organization: Network General Corporation
Date: Wed, 16 Dec 1992 19:29:17 GMT

Here is a simple C++ program which overides the global new and delete 
operators:

I would have expected that A * a = new A(5) calls the overloaded new
operator, just as delete [] a should call the overloaded delete operator.

I tried on Borland C++ 3.1 and Microsoft c 7.0 and 
*** THE RESULTS ARE DIFFERENT ***
This is not argue who has the best C++, I just want to understand what is 
done right, and what is done wrong.


Borland:
~~~~~~~
A* a = new A[5]
The overloaded global new operator is ***not*** called

delete [] a;
The overloaded global delete operator ***is*** called.

=> makes quite a mess since the pointer received by the operator delete
is not exactly what was given on the delete [] line. Somehow an extra field is
hidden ( to know the size of the array I suppose ).

Even worse: if you use the new syntax with extra parameters like:
A *a = new (__FILE__,__LINE__) A[5];
and you have an operator new ( char* file, int line, size_t size ) then
this operator new gets called. But the pointer it returns is returned as is to
the application  ( with no offset added to hide the size field ) then when
the application calls delete [] a, the operator deletes gets called with a 
pointer that has been 'corrected' by the compiler to include this hidden 
field. Therefore, delete screw the whole thing up!

In those conditions it is not possible to implement any reliable memory
allocation tracking mechanism. There is even no way inside the delete
operator to know whether this if for an array or a standard delete. Therefore
there is no workaround.


Microsoft:
~~~~~~~~~
The overloaded global new and delete operator are both called.

=> new returns an address. The program gets this address plus an offset 
( for a hidden field possibly like the size of the array ). Then when delete[]
is called with this same address, delete gets called with the address minus 
the offset, so deletes gets the same address as the one returned by new.

Seems the right way to do it for me.


QUESTION:
--------
Who or What is right ?


------------------------------>> Test sample <<------------------------

#include <stdio.h>
#include <malloc.h>

int cstr = 0;
int dstr = 0;
int allocated = 0;
int freed = 0;

void * operator new ( size_t size );
void operator delete ( void * ptr );

class A {
	public:
		A();
        ~A();
};

A::A()
{
	cstr++;
}

A::~A()
{
	dstr++;
}

void * operator new ( size_t size )
{
	allocated ++;
	void * ptr = malloc( size );
	printf("In new, about to return ptr 0x%lx\n",(unsigned long)ptr);
	return ptr;
}

void operator delete ( void * ptr )
{
	freed ++;
	printf("In delete to free 0x%lx\n",(unsigned long)ptr);
	free(ptr);
}

int main()
{
	A *pa = new A[5];
	printf("About to free address:0x%lx\n",(unsigned long)pa);
	delete [] pa;
	printf("cstr:%d   dstr:%d\n",cstr,dstr);
    printf("alloc:%d  free:%d\n",allocated,freed);
	return 0;
}


-- 
Alexis MERMET-GRANDFILLES		Voice: 415-617-2943
Software Engineer. R&D    		Fax:   415-321-0855
Network General Corp.
From: njs@planet.bt.co.uk
Newsgroups: comp.lang.c++
Subject: Re: Survey: File Extension
Date: 16 Dec 92 09:55:31 GMT
Organization: DNM42, BT Labs, Martlesham Heath, Ipswich, UK.
Originator: njs@andromeda


In article <78146@hydra.gatech.EDU>, andy@federation.gatech.edu (Andy Register) writes:
|> In article <1gb1h0INNle2@tsavo.hks.com> webb@hks.com writes:
|>  >I have a survey question for you all:
|>  >
|>  >	What extension do you believe is correct for C++ source code?
|>  >	Is a clear majority winner emerging?  The contenders are: .C, .c
|>  >	and .cxx. 
|> 
|> don't forget .cpp for all us borland users.
|> 
|> Toodles
|> Andy

Also .cc .

Nathan
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: IS C++ a language for the "average programmer"
Date: 15 Dec 92 13:32:15 GMT
Article-I.D.: alice.24411
Organization: AT&T Bell Laboratories, Murray Hill NJ



jimad@microsoft.com (Jim Adcock @ Microsoft Corporation) writes

 > C++ is not a goal in itself, but rather a tool to be used in
 > achieving other, meaningful, goals.

Well said and a point well worth remembering. Programming languages are
(just?) tools for writing programs and should not be the major interest
for the vast majority of programmers.
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Survey: File Extension
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 12 Dec 1992 16:20:23 GMT

andy@federation.gatech.edu (Andy Register) writes:

>In article <1gb1h0INNle2@tsavo.hks.com> webb@hks.com writes:
> >I have a survey question for you all:
> >
> >	What extension do you believe is correct for C++ source code?
> >	Is a clear majority winner emerging?  The contenders are: .C, .c
> >	and .cxx. 
>
>don't forget .cpp for all us borland users.

Another contender is .cc.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c++
From: marc@meadow.uucp (Marc Riehm)
Subject: overloading operator new
Reply-To: marc@meadow.UUCP (Marc Riehm)
Organization: Amdahl Canada Ltd., Software Development Center
Date: Fri, 18 Dec 92 12:56:56 GMT

I want to be able to take control of memory management in c++, and I've run
into a problem with overloading operator new.  I have c++ classes which
provide memory "pool" management: these act as a layer over malloc().  What I
want to do is to be able to specify which pool to allocate from when I
instantiate an object of another class.

Thus, say I had class MyObject -- I want to be able to instantiate instances
of this class in some manner like...
MyObject *myObj1 = new MyObject(bigHeap)   where bigHeap is a memory pool,  or
MyObject *myObj2 = new MyObject(altHeap)  etc.
The store for myObj1 would come from bigHeap, and that for myObj2 from altHeap.

My Turbo C++ 2.0 manual (the only C++ documentation I have available :( )
says that the first argument of MyObject::new must be a size_t.  i.e. we
overload new via a method which looks like...
void *MyObject::new(size_t)
They imply that there can be other arguments to MyObject::new.  Could anyone
tell me whether or not this is true and, if it is, how to declare the method
and how to use MyObject::new?  Are there any side effects on the constructor?

-- 
Marc Riehm      Amdahl Canada Ltd., Software Development Center
                2000 Argentia Road, Plaza 2, Suite 300
                Mississauga, Ont.   L5N 1V8
marc@meadow.UUCP
Newsgroups: comp.lang.c++
From: hansen@deci.cs.umn.edu (David Hansen)
Subject: Re: Is this a compiler bug?
Organization: University of Minnesota
Date: Fri, 11 Dec 1992 19:30:23 GMT

In article <KANZE.92Dec11165414@slsvdnt.us-es.sel.de>, kanze@us-es.sel.de (James Kanze) writes:
[..]
|> 
|> If your compiler accepts this code, then it is broken.  (I am
|> supposing that NULL is defined as either 0 or 0L; however, in this
|> case, nothing changes if it is defined as (void*)0.)  "fptr" and the
|> results of "(fptr = bar())" are both pointers to member functions, and
|> *not* pointers.  There is no implicit (nor explicit) cast from a
|> pointer to member function to an int, a long, or a pointer, so it is
|> not legal to compare a pointer to member function to NULL.

Ummm, I don't think so.  The ARM on p. 158 describes a possible implementation
of pointers to member functions, and it explicitly describes a decision
"To allow the representation of a null pointer to member to be 0..."

Furthermore, on p. 161, the initialization of a pointer to member function
to zero is given, thus:

   int (D::*pmf0)() = 0;

which kind of implies the conversion of 0 to a pointer to member function
does, indeed, exist.

|> 
|> There is *no* special value for pointers to members, the equivalent to
|> NULL for pointers.  So if there are cases where "bar()" cannot return
|> a legal value, some other arrangements must be made for it to return a
|> status.

There is no equivalent to void* for pointers to members -- see p. 70.
Is this, perhaps, where the confusion might lie?

					-=Dave
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Virtual base classes
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Trumphurst Ltd.
Date: Tue, 15 Dec 1992 20:11:32 +0000

In article <445@genie.UUCP> roger@genie.UUCP (Roger H. Scott) writes:
> In article <1992Dec8.192759.24081@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
> >In article <rmartin.723768537@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
> >| ... There is nothing that can be done with private inheritance that cannot
> >| be done, just as simply, with containment.
> >
> >Except for redefining virtual functions and accessing protected members.
> 
> If Kludge is a non-public subclass [derived class] of WellFormed then there
> isn't much point in talking about Kludge redefining WellFormed's virtual
> functions since you can't use a Kludge in a place where a WellFormed is
> expected (i.e., who would ever have hold of a Kludge and send it one of
> WellFormed'd messages [call one of WellFormed'd virtual functions], other than
> a member function of Kludge?).

Imagine that WellFormed's constructor adds all WellFormeds to some 
Collection of WellFormeds. Notice that all Kludges will also be added to 
this collection. Now imagine some calling some virtual function for all 
WellFormeds in the Collection.

-- 
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: btarbox@world.std.com (Brian J Tarbox)
Subject: compiler error reporting
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 18 Dec 1992 03:11:19 GMT

Why are c++ compilers so bad about reporting errors?
Long ago most c compilers would unhelpfully say only
"syntax error" to most errors.  They have progressed
to now giving very help error messages.  Most c++
compilers (especially on workstations) still give
terrible errors.

For example, in a class I had the following private
variable declared:  "Process process"  i.e. 'process'
is a 'Process'.  I accidentally passed 'Process' to
a routine and got 30 errors, none of which where
within 10 lines of the incorrect line.

Second example.  I forward declare a class and then 
try to call one of its public functions.  I get a
'no matching signature for member function bla' error.
Having written a few compilers I KNOW the compiler knows
it hasn't seen the real class definition, and it also
KNOWS (in the previous example) that a class name is not
allowed as a parameter.  While the latest esoteric features
are nice, I'd sure like to see the 'feature' of decent
error reporting.

Brian Tarbox
Been There - Done That Software

Newsgroups: comp.lang.c++
From: cmick@silver.ucs.indiana.edu (Baldy)
Subject: A simple question.  Please help.
Organization: Indiana University
Date: Sat, 19 Dec 1992 08:17:28 GMT

     This is propably a simple problem.  But I'm trying to write an invoice
type program for a friend.  I know how to read and write to a file but how
do you say save an invoice number, or a debit, credit amount, and then add
something to it.  I know how you get stuff from a file, but only character
by character, not integers that I can add + 1 to.
     If this makes sense, please help.

Thanks.
-- 
Later,
	Craig
cmick@silver.ucs.indiana.edu
cmick@acoma.ucs.indiana.edu
Newsgroups: comp.lang.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: inlining friend functions
Date: Wed, 16 Dec 1992 13:01:56 GMT
Organization: University of Birmingham

In article <1992Dec15.182858.22555@aruba.uucp>, sandys@aruba.UUCP (Sandy Schindler) writes:
> I would like to inline some friend functions for a class, without placing
> the method definitions inside the class declaration.  Such as:
   [example deleted]
> BUT, when I try to compile this with Borland's C++ 3.1, I get the error
> message 
>   Error inl.hh, line xx: Storage class 'inline' is not allowed here 
> Borland will not allow the inline keyword to used on a friend function 
> inside a class declaration, no matter where the definition happens.

I never put inline in the class definition when declaring friends. Simply
putting inline in the function definition is sufficient. As far as I know
Borland is right and the inline storage class should only appear in a
function definition and not in a friend declaration that is not also acting
as the definition.
 
> Is this a mere compiler bug on Borland's part, or is this the first 
> appearance of a standard restriction?  I hope not.  With the volume of 
> code we're working on, omitting the inline keyword from the headers is not 
> an option.

Wow that must be a lot of code! Assuming you do a global search/replace of
"friend inline" with "friend" in *.h and it takes 1 second to answer each
prompt in the time it took to write this posting you could have done
several hundred.
-- 
    \\   ( )    No Bullshit!     |  Email: B.A.McCauley@bham.ac.uk   
 .  _\\__[oo        from         |  Voice: +44 21 471 3789 (home)
.__/  \\ /\@    /~)  /~[   /\/[  |    Fax: +44 21 625 2175 (work)
.  l___\\      /~~) /~~[  /   [  |  Snail: 197 Harborne Lane,
 # ll  l\\    ~~~~ ~   ~ ~    ~  |         Birmingham, B29 6SS, UK
###LL  LL\\   (Brian McCauley)   |   ICBM: 52.5N 1.9W
From: gordie@kaleida.com (Gordie Freedman)
Newsgroups: comp.lang.c++
Subject: Re: How to call C++ functions in a C progr
Date: 18 Dec 1992 23:25:57 GMT
Organization: Happy hacker bait and tackle shop
Distribution: world
Reply-To: gordie@kaleida.com
NNTP-Posting-Host: moon.kaleida.com

The best way to do this is have a wrapper function in the C++ code that
the C function can call. Of course, this is not optimum performance, so
hopefully things are encapsulated such that the calls from C to C++ are 
infrequent, and frequent calls are within the same language.

By declaring foo1 and foo2 extern "C", the names do not get mangled. Note that if
they are called from other C++ code in another file, that file must declare the
references to foo1 and foo2 as extern "C" also.

Make sure you link with the c++ linker, it is also recommended that you compile
main with a c++ compiler, to make sure that global constructors get called/etc.

-----------foo.C-----------------
// This is C++ code
extern "C" int foo1 (int, int);
extern "C" int foo2 (int, int);

int bar (int x, int y)
{
	int someInt;
	// do some fancy C++ stuff
	return someInt;
}

int foo1 (int x, int y)
{	
	return bar (x, y);
}

int foo2 (int x, int y)
{
	int z;
	// Do some fancy C++ stuff
	return z;
}
---------test.c-----------------

/* This is C code */
extern int foo1 (int, int);
extern int foo2 (int, int);

void
test (void)
{
	/* stuff ... */
	a = foo1 (1, 2);
	/* More stuff */
	a = foo2 (10, 20);
}

---
Gordie Freedman: gordie@kaleida.com Sigs are for kids
From: jh@first.gmd.de (Joerg Heuer)
Newsgroups: comp.lang.c++
Subject: Re: & of inline functions
Date: 17 Dec 92 10:13:52 GMT

x9999bvj@maple.circa.ufl.edu writes:


>What is the official method for handling taking the address of an inline
>function?  For example, if you do this:

What exactly do You mean? Your example seems correct and Stroustrup
defines: "It is possible to take the address of an inline function..."
(The C++ Programming Language, 2nd Ed., p.138)

So what's Your problem? Does Your compiler don't like it? This problem
got to be handled by the compiler, anyhow, since virtual functions can
also be defined 'inline'.

J"org.
--
Joerg Heuer                   | INTERNET: jh@first.gmd.de
GMD-FIRST an der TUB          | UUCP:     jh@gmdtub.uucp
Rudower Chaussee 5, Geb. 13.7 |
D-1199 Berlin Adlershof, FRG  | Tel/Fax:  +49 30 6704 - 5819/5610
From: matt@physics.berkeley.edu (Matt Austern)
Newsgroups: comp.lang.c++
Subject: Re: Survey: File Extension
Date: 13 Dec 92 09:10:12 GMT
	<1992Dec12.014834.926@netcom.com>
	<WARSAW.92Dec12174801@anthem.nlm.nih.gov>
Reply-To: matt@physics.berkeley.edu
Organization: Lawrence Berkeley Laboratory (Theoretical Physics Group)
NNTP-Posting-Host: physics.berkeley.edu
In-reply-to: warsaw@nlm.nih.gov's message of 12 Dec 92 22:48:01 GMT

In article <WARSAW.92Dec12174801@anthem.nlm.nih.gov> warsaw@nlm.nih.gov (Barry A. Warsaw) writes:

> More important is consistancy within your project and compilers/tools
> ought to be configurable to use just about any extension: .cc .cxx
> .cpp .C whatever...

This is only possible for certain operating systems.  Two of the three
operating systems that I use on a regular basis are case-insensitive,
so .C isn't much of an option.  

But yes, I agree with these sentiments; this choice should be made by
users, not compilers.
--
Matthew Austern                   Just keep yelling until you attract a
(510) 644-2618                    crowd, then a constituency, a movement, a
austern@lbl.bitnet                faction, an army!  If you don't have any
matt@physics.berkeley.edu         solutions, become a part of the problem!
From: oper7@MBOX.ee.ncu.edu.tw (Lee. shih-hao)
Newsgroups: comp.lang.c++
Subject: TVISION: how to replace text field for a TStaticText?
Keywords: TVision, BC++, TStaticText
Date: 15 Dec 92 05:38:24 GMT
Organization: Dep. of EECS, National Central University, Chungli, Taiwan, R.O.C.
X-Newsreader: TIN [version 1.1 PL6]

Hi, BC++ programmers:

Is there any feature for such purpose: After displaying a TStaticText onto
desktop, application dynamically change the text of that class? and
redraw it so that it can show the most recent change?

Thanks for your helps
tony
--
>>> Anthony Li <Li3, Shih4 Hao2><Li:fruit's Name><Shih:Scholar><Hao:Hero>   <<<
<<< Institute of CSEE, National Central Univ, Chungli, Taoyuan, Taiwan, ROC >>>
>>> Internet:	oper7@mbox.ee.ncu.edu.tw	 oper2@ncuee.ncu.edu.tw	    >>>
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: static members in derived classes
Date: 11 Dec 92 21:55:49 GMT
Organization: Microsoft Corporation

In article <Bz20Gt.29x@cs.uiuc.edu> pjl@cs.uiuc.edu (Paul Lucas) writes:
|>We don't understand this behavior of C++. Can anyone explain to us.
|
|******>	What's to understand?  That's the way it is.  What you're describing
|	are "class instance varaibles" in Smalltalk; C++ has no equivalent.

The equivalent in C++ is to provide one or more virtual functions that
give access to the class-specific information.  It's certainly true
that C++ provides no built-in support for class instance behaviors --
you have to write the code yourself.  At least until runtime type identification
is adopted.  Then at least some of the common requirements will be built-in.

Newsgroups: comp.lang.c++
From: pete@borland.com (Pete Becker)
Subject: Re: static members of templates
Originator: pete@genghis.borland.com
Organization: Borland International
Distribution: comp
Date: Tue, 15 Dec 1992 17:33:41 GMT

In article <CBT.92Dec15101117@hobbes.inesc.pt> cbt@hobbes.inesc.pt (Conceicao Batista Tavares) writes:
>
>I want to have a static member of a template
>
>Example:
>
>        class A {
>                int a;
>        };
>
>        template<T> class exemple {
>          static int elem;
>        };
>
>For the definition of the static member I have to do this?
>
>        int exemple<A>::elem;
>

	template <class T> int example<T>::elem;

	-- Pete



Newsgroups: comp.lang.c++
From: jdp@polstra.uucp (John Polstra)
Subject: Re: Initialization {} of Aggregates with Static Members
Organization: Polstra & Co., Inc., Seattle, WA
Date: Tue, 15 Dec 1992 16:52:56 GMT

In article <1992Dec15.094709.5566@eua.ericsson.se> euamts@eua.ericsson.se writes:
> class testbase 
> {
>    public:
>       int y;               // If I remove this line...
> };
> 
> class test : public testbase 
> {
>    public:
>       int myVal;
>       const test* myNext;
> };
> 
> const test t1 = {7,1,0};      // If I remove "7,"
>
> [Remainder of program and description of symptoms deleted]

I don't think the above is legal.  ARM section 8.4.1 says that
curly-brace initialization may be used for *aggregates*, and that an
*aggregate* (by definition) has no base classes.  Your class "test" has a
base class, thus it is not an aggregate, thus it may not be initialized
using curly braces.

At least, that's my reading of the ARM.
-- 
   John Polstra                              polstra!jdp@uunet.uu.net
   John D. Polstra & Co., Inc.                  ...!uunet!polstra!jdp
   Seattle, Washington USA   Phone (206) 932-6482, FAX (206) 935-1262
   "Self-knowledge is always bad news."                 -- John Barth
From: westes@smurf.sti.com (Will Estes)
Newsgroups: comp.lang.c++
Subject: Looking For C++ Course Slides Via Anon FTP
Date: 19 Dec 1992 13:04:56 -0800
Organization: Mail Group
NNTP-Posting-Host: smurf.sti.com

I'm wondering if anyone out there has developed a C++ course for
experienced C programmers that they have put onto an anon ftp server.
Ideally, I'm looking for a Postscript file that will print out maybe
30-60 pages worth of class slides.  I've had luck finding course
materials for other subjects, and I'm hoping that someone out there has
put together something for C++.  Any anon ftp references are
appreciated.  I will use this material is for personal education only.

-- 
Will Estes		Internet: westes@netcom.com