HDTenEightyP/NetNews huggingface dataset:
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Destruction of temporaries
Date: 2 Sep 92 14:38:24 GMT

ark@alice.att.com (Andrew Koenig) writes:

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

|> These strategies should not supress the warnings.  ANY time an address
|> or reference to a temporary is taken, whether is is via implicit
|> conversion, or as the argument of a member function, a warning should
|> be issued.  No exceptions.

|> This will flag every instance where a long lived alias to a temporary
|> could be created.

|No, it will flag some instances.  For example:

|	struct A {
|		A& foo();
|	};

|	A a();

|	main()
|	{
|		A& b = a().foo();
|	}

|Should this give a warning or not? 

It should, because the temporary created by 'a()' must be converted to
a pointer in order to be used in the method call as 'this'.  And, of
course, this means that every time you invoke a method on a temporary,
you will get a warning.

Issuing warnings every time a method is invoked on a temporary is very
ugly.  #pragmas for selectively supressing such warnings are a
solution, but not a very satisfying one.  Still, it is when a pointer
or reference to a temporary is taken, that the risk of a long lived
alias is created; and a warning about that risk seems appropriate.

In the absence of GC, or some other foolproof mechanisms for
eliminating the risk of long lived aliases to temporaries, I think
warnings are the only practical answer.  But I must admit, it's not a
very good answer.  It's just better than silence.



--
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: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 27 Aug 92 16:04:45 GMT

hosken@spss.com (Bill Hosken) writes:

>Clear thinking helps to write good code, gotos whether or not.


This is sort of like saying:  "I am an expert driver, my clarity of
driving skills entitles me to ignore certain stop signs, when I know
(by virtue of my great skill) that there is no cross traffic.

You see, I am such a good driver, that the legal alcohol limit does
not apply to me.  Nor do speed limits, detour signs, or even
the need to use headlights at night."

Now, this diatribe might sound absurd, but for some individuals it   
might me 100% correct.  There may be individuals whose driving skills
are so sharp and accurate that they can drive drunk, 20 mph over the
limit, in the dark, with no headlights, ignoring stopsigns, with no
ill effects at all.

But I'd be damned (or more probably roadkill) if I took their word for
it.

So we have rules.  These rules protect us average types from the guys
who think they are "real good drivers".  When some guy blows a stop
sign, it doesn't matter to me, one whit, if he is the greatest driver
in the world, I will still applaud the cop who pulls him over.

-------------------

In software engineering, we have rules, but no cops.  (And I don't
want any cops either).  So "real good programmers" sometimes feel that
the rules don't apply to them.  We average types suffer at their hands.


--
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: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.c++
Subject: Re: named loops
Date: 29 Aug 92 17:09:36 GMT
	<1992Aug21.143653.10805@alias.com> <1992Aug22.171535.29638@taumet.com>
	<BEVAN.92Aug23144650@tiger.cs.man.ac.uk>
	<1992Aug24.161012.2835@taumet.com>
Organization: Department of Computer Science, University of Manchester
In-reply-to: steve@taumet.com's message of 24 Aug 92 16:10:12 GMT

In article <1992Aug24.161012.2835@taumet.com> steve@taumet.com (Steve Clamage) writes:
   As Bjarne Stroustrup has pointed out many times, there are lots of
   proposals for lots of nice features to be added to C++.  Any one
   feature considered alone might be easy to implement, break no existing
   code, and provide some convenience for some number of programmers.
   If all such were adopted, the language would become so complicated
   that the language and its compilers would collapse under their own
   own weight.  (Some might say this has already happened :-) .)

This "some" does.


   Second (a bit of nit-picking), the current "break" does not require a
   label, whereas "goto" does.  The proposed change adds a label to
   the main code and thus also to the "break".  This seems to me quite
   similar syntactically to the "goto", as shown in the example above.
   The difference is the location of the label and whether there is a
   colon following it.  For better diagnostics in the presence of syntax
   errors and for consistency, it could be argued that the loop label
   should have a colon anyway.

I'm not sure what point the above was trying to make.  Anyway, 
given that keyword overloading is the norm in C, I'm suprised there
even is a "break" statement.  In true minimalist style, I would have
expected to have "goto" with no label to mean "exit this block".
Of course this doesn't handle "continue", but then I've never found a
use for it, so it can go the way of "entry".

bevan

PS I don't take C++ seriously, so don't take this article seriously either.
Newsgroups: comp.lang.c++
From: he@bourbon.ee.tulane.edu (Chuang He)
Subject: malloc or new in C++
Nntp-Posting-Host-[nntpd-21487]: bourbon
Organization: E.E. Dept., Tulane University, New Orleans, LA
Distribution: usa
Date: Mon, 31 Aug 1992 19:44:26 GMT


I have written a program by using C++. The compiler is Sun C++ 2.1. I find a
very interesting thing. I find two structure pointer set by malloc or new have
the same address. That means if I change the content of one pointer pointing to
will also change the other's. But these two pointers are unrelated. I don't know
why. Does this mean that I use too much new or malloc that no more memory I can 
use? Could anyone tell me about how many memories can one program use, I mean
use by new or malloc. My machine is Sparcsation-SLC. The system is SunOS 4.1.1.
It would be appreciated that someone can tell me the reason and the solution.


Please send me an email. I do not read this newsgroup quite often.

he@bourbon.ee.tulane.edu


-Chuang
From: dsf@cray.com (Dan Frankowski)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 26 Aug 92 18:03:35 GMT
Organization: Cray Research, Inc.

In article <6800007@tisdec.tis.tandy.com> kevinl@tisdec.tis.tandy.com writes:

>	For experienced programmers, the goto is a legitamite tactic.
>There may not be any cases where a goto is absolutly necessary (I've
>heard that there are some, but I have yet to see any), ..

I thought that one of the triumphs of the Structured Programming camp
was an honest-to-goodness proof that any code using gotos could be
replaced by structured constructs and state variables.  I can imagine
some such proof by construction from arbitrary code with a goto.

>	I agree that programs are generally easier to understand and
>debug when there are no goto statements, but, if well documented
>gotos are just another structured technique.

If one-entry-one-exit is part of a structured programming, then the
goto is not "just another structured technique."  Note that I did not
say gotos have no uses.  (I haven't made up my mind yet.  Maybe this
thread will help me decide.  :-) However, they're not structured
programming, as defined by the debate in computer science fifteen-odd
years ago.

DISCLAIMER: This ain't official Cray business.

-- 
Dan Frankowski            Dan.Frankowski@cray.com     (612) 683-5099
Newsgroups: comp.lang.c++
From: zpvy0a@hou.amoco.com (Prasad Yalamanchi WWNV x4269 9.125)
Subject: Turbo C++, function prototypes
Reply-To: zpvy0a@hou.amoco.com
Organization: Amoco
Date: Mon, 31 Aug 1992 18:17:55 GMT

I am trying to compile a program on Turbo C++, 3.0 . It gives me the following

error.

main () , function prototype missing.

Do i need to put in the 'main' function's prototype. 

void main();

was still giving me errors.  Could someone help.

Newsgroups: comp.lang.c++
From: mittle@watson.ibm.com (Josh Mittleman)
Subject: Re: Overloading in the presence of ellipsis
Date: Thu, 27 Aug 1992 17:43:35 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center

srinivas@lgc.com (Manapragada Srinivas) writes:

> 	If I overload a function in the following way
> 
> 		foo( int ) { cout << "non ellipsis version" << endl; }
> 
> 		foo( int ... ) { cout << "ellipsis version" << endl; }
> 
> 		main() { foo(1); }

Then you are out of luck: foo(1) matches both versions exactly.  
foo(int, ...) exactly matches any call of foo where the first argument is
an int: It is "int followed by any number of arguments," not "int followed
by one or more arguments".

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
From: euamts@eua.ericsson.se (Mats Henricson)
Newsgroups: comp.lang.c++
Subject: Re: Numerical Recipes in C++?
Date: 1 Sep 92 12:47:16 GMT
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden

ajayshah@almaak.usc.edu (Ajay Shah) writes:

>In <SINAI.92Aug11105913@biltong.sono.uucp> sinai@sono.uucp (Julian &) writes:
>>application I'm working on. So I trotted out the venerable "Numerical
>>Recipes in C" bible and quickly realized that their algorithms could
>>do with an object-oriented facelift. So here's the question:

>NR in C++ is due within a few months.

This pisses me off considerbly!! I had my local computer bookstore
call Cambridge University Press to ask them if they had a C++ version
coming up, and they replied NO. So, I bought the C-version. Now I have
to put up even more cash when the new version comes, and I tell you,
the book isn't cheap...

I suppose I just encountered normal business behaviour...

Mats Henricson
Ellemtel
Stockholm
Sweden
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: risky inline
Keywords: inline, safe programming
Date: 27 Aug 92 17:19:33 GMT
Organization: AT&T Bell Laboratories, Murray Hill NJ



trachos@uni-paderborn.de (Konstantin Trachos @ Uni-GH Paderborn, Germany) writes

 > Maybe this topic is well known, but I realy want to know the reason, 
 > inline has been introduced for.

	example of how to trick cfront into inconsistent use
	of a member function by declaring inconsistent inline
	functions in different files

 > I think, that a safe compiler requires safe Language-rules,
 > not only carefull Programmers.

Actually, what you found was a compiler error. The example you gave
was illegal according to the language rules, but hard to test for.
It is not legal to have two different definitions of a function.
From: hwrvo@kato.lahabra.chevron.com (W.R. Volz)
Newsgroups: comp.lang.c++
Subject: backwards casting for lackof better term
Date: 26 Aug 92 00:45:18 GMT
Organization: Chevron Oil Field Research Company

Another simple question from someone who's simple:

Let's say I have a class A. And from that class I inherit and make
three other classes, say AA, AB and AC. Now I can have a pointer
to any of these classes: A *a ==> can point to any of the four classes.
Assume that I have a routine that creates one of the three derived classes at
random and returns it. So I might have

A *a[10];
for(int i=0;i<10;i++)
 a[i] = ____________ CreateAAorABorAC(i);

The question: what does CreateAAorAborAC return, or, what does the function
protptype looklike? A * CreateAAorABorAC(int) or what.

And inside of the function, what does it look like:

A * CreateAAorABorAC(int i)
{
A * ret;
if(i % 3 == 0)
 ret = (A *) new AA;
else if(i % 3 == 1)
 ret = (A *) new AB;
else if(i % 3 == 2)
 ret = (A *) new AC;
return ret;
}

Is anything lost by casting the new object  back to A, or is the new object  
still one of the derived classes. Is this a problem unique to c++, due to 
strong static type checking? Can this function be written so that it is 
independant of any new classes that might be created from A, or, what 
happens if I create a new class AD.  If all the derived classes handle 
their initializations, can this routine be written so that it is 
independant of new classes that might be created later, like AD?

C++ allows classes to have a branching structure, can the branches come
back together to form a single class? So if I have a base class X, and
derive three more XA, XB, and XC, can I then merge the three classes
back into one? Can inheritance be used to do this? So that XX : XA,XB,XC.
After all XA and XB and XC are all different kinds of X and so is XX.

Any insights here would be quote helpful in getting over the learning hump
for c++ (It feels like a programming version of Mount Everest).

Thanks, in advance.

-- 

======================
Bill Volz
Chevron Oil Field Research Co.
Exploration Research/Geophysics Division.
P.O. Box 446, La Habra, CA 90633-0446
Phone: (310) 694-9340
From: checker@acf5.NYU.EDU (checker)
Newsgroups: comp.lang.c++
Subject: Re: Callbacks - C++ needs an extension?
Keywords: callback event eventdriven extension
Date: 29 Aug 92 19:26:35 GMT
Organization: New York University

pete@genghis.borland.com (Pete Becker) writes:
>	The most straightforward solution is to work with the library and
>provide a callback function that examines the message being sent and forwards
>it to the appropriate recipient.

I hope by straightforward you don't mean most secure, easiest to debug,
or even easiest to maintain.  There is a simple way of doing blind
callbacks in a typesafe manner using an intermediary class and a pure
virtual function:

class callback
{
public:
	virtual void CallBack( void ) = 0;
};

This is the interface class.  An object that needs to call another
object back takes a reference to one of these:

class button
{
public:
	button( callback &CalledWhenPushed, etc. );
};

Now, any object that wants to instantiate a button and be called back
simply derives from callback:

class my_callback :
	public callback
{
public:
	my_callback( my_class &Instance, void (my_class::*pToCall)( void ) );
	void CallBack( void );
private:
	my_class &Instance;
	void (my_class::*pToCall)( void );
};

This concrete callback class takes a reference to an instance of the guy
who wants to be called back, and a pointer to one of his member
functions.  The class obviously stores that information inside itself:

my_callback::my_callback( my_class &I, void (my_class::*p)( void ) ) :
	Instance(I), pToCall(p)
{
}

The CallBack function simply calls the member function:

void my_callback::CallBack( void )
{
	(Instance.*pToCall)();
}

Now, inside my_class I would do this to instantiate a my_callback:

my_callback MyCB(*this,&my_class::MyFunction);

then I'd pass this object to the button using the standard conversion:

button MyButton(MyCB,...);

That's it.  button knows absolutely nothing about who it is calling.
The method uses the virtual call mechanism so it is completely type
safe.  There is no run time switching on message types, etc, and the
method is easily extended using templates and/or nested classes.

This technique is a typical use of the abstract interface/concrete
implementation idea.  All of the grungy details are in the derived
class, so the folks using the base don't have to know about them.

Chris
Newsgroups: comp.lang.c++
From: jetherid@gucis.cit.gu.edu.au (Jason Etheridge)
Subject: File I/O using C++ (write/read objects...)
Organization: Griffith University, Brisbane, Australia.
Date: Wed, 26 Aug 92 02:32:55 GMT

I am having real problems reading and writing objects to a file.  A text
I have uses

	out.write((unsigned char*) &object, sizeof(OBJECT))

where out is an fstream that allows writing to the file it is open for,
and object is an object of class OBJECT.

It writes the object, seemingly with no problems, but when I try and read
it back in the resulting object has been garbled, it's attributes changed
with the occasional garbage character.

Strangely enough, if I try this with an object with no functions, it
works perfectly.

Can anyone suggest a good way of writing and reading objects to a file
that really works?

(I am using the Borland C++ 3.0 compiler)
Newsgroups: comp.lang.c++
From: dsf@cray.com (Dan Frankowski)
Subject: Re: help?? is their a method for solving dynamic allocation problemes in c++
Organization: Cray Research, Inc.
Date: 27 Aug 92 09:29:38 CDT

In article <78304@ut-emx.uucp> jamshid@emx.utexas.edu writes:
>In article <1992Aug19.203838.20501@bmw.mayo.edu> staniszewski@mayo.edu writes
>[in lines annoyingly over 79 chars long]:

>>The problem I am looking at is to trackdown where my dynamic memory
>>problems are using new and delete..

>Why is overloading the global operator new() awkward?  And COMMA
>global delete can be overloaded.  See any good, modern, C++ book like
>Stroustrup's _C++ Prog. Lang. 2nd Ed_ or Lippman's _C++ Primer 2nd Ed_
>for more information.  A code example is appended.  Just add your
>debugging alloc package and stir.

>Jamshid Afshar
>jamshid@emx.utexas.edu

I'm not sure, but doesn't the code need (at least) the corrections below?

>#include <new.h>
>#include "debugging_alloc.h" // defines debugging_malloc() & debugging_free()
>

extern (*_new_handler)();  // Is this only for cfront?
                           // Will it work even on cfront?

>void* operator new(size_t size) {

    void *p;

>   size = size ? size : 1;    // new(0) must return unique object pointer
>   while ( (p = debugging_malloc(size)) == 0 && _new_handler != 0)
>      _new_handler();
>   return p;
>}
>
>void operator delete(void* p) {
>   if (p)   // ignore "delete 0;"
>      debugging_free(p);
>}

Also, my question is, will this cover the global new and delete?  It's
not an overloading.  A function may be overloaded only with different
signatures-- that is, if the parameter lists are different.  In this
case, you are trying to define the same function with the same
parameter list.  I've been trying to get it to work under g++ 1.37 and
cfront 3.0.1, and it hangs in both cases.  Should this work?  Why?

(I want to assume global new and delete cannot be replaced-- or if
they can, that it will not show up as __nw__FUi() under cfront 3.0.1
name mangling.)

Dan

DISCLAIMER: This ain't official Cray business.
-- 
Dan Frankowski            Dan.Frankowski@cray.com     (612) 683-5099
From: twbrown@PE-Nelson.COM (Tom W. Brown)
Newsgroups: comp.lang.c++
Subject: Re: Callbacks - C++ needs an extension?
Date: 1 Sep 92 20:21:24 GMT
Followup-To: comp.lang.c++
Distribution: comp
Organization: PE-Nelson

In article <DAVIDM.92Aug31105639@consilium.com>, davidm@consilium.com (David S. Masterson) writes:
|> >>>>> On 29 Aug 92 19:26:35 GMT, checker@acf5.NYU.EDU (checker) said:
|> 
|> > There is a simple way of doing blind callbacks in a typesafe manner using an
|> > intermediary class and a pure virtual function:
|> 

[ example omitted ]

|> 3.  Given a windowing system based on C, its likely that the information
|> coming from the windowing system will not be C++ object oriented (ie. it won't
|> follow a C++ inheritance model).  How do you convert?

Most windowing systems provide for some type of closure to be supplied.  In
the specific case of Xt programming, one provides an untyped pointer along
with the address of a normal C callback function.  This can be relatively
type-safe if done as follows:

   void button_callback(Widget, button_class*, XtPointer);
   .
   .
   .
   button_class* a_button = new button_class("OK");  // hypothetical UI object

   XtAddCallback(button_widget,                      // This would usually
                 XmNactivate,                        // be done in the
                (XtCallbackProc) button_callback,    // constructor for the
                (XtPointer) a_button);               // button_class
   .
   .
   .

   void button_callback(Widget, button_class* button, XtPointer)
   {
      button->push_function();  // dispatch to our C++ hierarchy
   }

   .
   .
   .

So, a single, global, non-member function receives all callbacks for all
button objects, but since the object pointer was tied to each callback as
closure for the callback, this one function is able to dispatch to the
appropriate object member function.  For MS Windows one could stuff the
"this" pointer in the extra bytes that can be made available on a window
basis.

I don't believe there's a way to avoid this kind of indirection when the
underlying system making the callback knows nothing about C++, a "this"
pointer, or the difference between member and non-member functions.

Note, there was a posting in comp.windows.x (and possibly this group also)
regarding how to fit C++ in with Xt/Motif programming.


----------------------------------------------------------------------------
Tom Brown               |  "Strange women, lying in ponds, distributing
PE Nelson Systems       |   swords is no basis for a system of government."
twbrown@pe-nelson.com   |                    Monty Python and the Holy Grail
----------------------------------------------------------------------------
From: michaelh@cc.usu.edu
Newsgroups: comp.lang.c++
Subject: BC 3.1 file redirection?
Date: 1 Sep 92 15:50:01 MDT
Organization: Utah State University

Can anyone help me on this problem:

I am trying to use Borlandc 3.1 on a novell network and I wish to have
the three files BC3.1 makes go to each of the users personal hard disks.

Is there a SET command or something in the install I have missed?



Thanks in advance for the help

Michael Harper
From: Lee_Robert_Willis@cup.portal.com
Newsgroups: comp.lang.c++
Subject: class browser engine for C++?
Date: Mon, 31 Aug 92 16:00:26 PDT
Organization: The Portal System (TM)
Distribution: world

I'm looking for a C++ equivalent of Ada's DIANA

DIANA is a standard way of representing the parsed-syntax tree of a set
of Ada modules.  

A compiler that supports DIANA compiles Ada code into the DIANA format,
and writes this information to its compilation library database.
An end-user can query this database thru the DIANA API to find out
anything language-related to the code.  e.g. one could lookup type 'A',
and find out what kind of type it was, in what module it was declared,
which modules make use of it, etc.

I'd like to see the same thing for C++.

Given a utility which could parse C++ files and create such a database,
the routines to access it could act as the database engine to a
class-browser (among other things).

If the interface to the C++ database is standardized, then one could
write different class-browsers for different environments, (e.g. a CURSES
interface, an X interface, a Whatever-windowing-system interface, etc.)
and people could pick the class-browser which best suits their needs.

So, does such a thing currently exist? (probably not)  

If not, where would be a good starting point to build such a thing?  Any
ideas?

--
Lee      Lee_Robert_Willis@cup.portal.com
From: Neal.Sanche@ttlg.UUCP (Neal Sanche)
Sender: postmaster@ttlg.UUCP
Newsgroups: comp.lang.c++
Subject: Running BC++ 3.1 under O
Date: 02 Sep 92  12:50:06 mst

SP> How do you run Borland's C++ 3.1 under OS/2. I can't get it to run. All
SP> it says is that BC encountered some problem.  I would like to used both
SP> th IDE version and the command line version as I have to use make file
SP> to get the project to run.

From what I recall you have to set the dos settings to run DPMI. There is
a specific setting to do this, however I don't have OS/2 installed right
now, so I can't be more specific, sorry.

-Neal

 * OLX 2.1 TD * Earth: Mostly harmless.

 * Origin: Paradigm BBS: A programmer's paradise. (42:100/11)