HDTenEightyP/NetNews huggingface dataset:
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for named loops.
Date: 26 Aug 92 20:54:19 GMT

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

|After many postings extolling the evils of "break", "return" and other
|"non-structured" exits from blocks, Bob Martin writes in article
|<rmartin.714749390@thor>:

|   In a real application, when confronted with memory outage, I would
|   throw an exception, call assert, or just plain exit.

|What is an exception exception other than an exit from a block? How is
|that going to leave your "pre- and postconditions" intact?

Exceptions do not return to the invoking block, they return to another
block which is declared to catch the exception.

|Altogether, I find Bob's arguments against "break" unconvincing. There
|is nothing wrong with using "break", exceptions, or even the
|occasional "goto" in C++, since C++ has mechanisms (destructors) that
|can be used to take care of cleanup jobs when a block is exited from
|anywhere; simply use them.

And I disagree, in part.  Yes, use exceptions and exits where
necessary.  But avoid break and continue where possible, and avoid
goto altogether.  



--
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: potts@itl.itd.umich.edu (Paul Potts)
Subject: Re: GOTO, was: Tiny proposal for na
Organization: Instructional Technology Laboratory, University of Michigan
Date: Thu, 3 Sep 1992 17:51:18 GMT

In article <rmartin.715526582@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>potts@itl.itd.umich.edu (Paul Potts) writes:
>
>|I use "goto" sparingly as well, and agree that it can be very useful in
>|cases, and even make code *more* readable. BASICally <grin> I use it 
>|only to exit from loops where adding additional conditions to the loop
>|would make the code much more obscure and slow, or to skip down past a
>|piece of code to the end of the loop under some circumstances. 
>
>|To make GOTO more readable, NEVER go backwards in your code, only
>|forwards; use only one GOTO in a block, and comment explicitly. If GOTO
>|is used only under certain conditions, the argument against writing
>|spaghetti code really doesn't apply.
>
>Paul, though you rail against the proscription of goto, you have
>simply replaced it with several proscriptions and warnings of your own
>making.  You tell us NEVER to do some things, and to "skip down" in
>"some circumstances" and "use only one" in others.  
>
>I am sure that there are others who might disagree with your "one goto
>per block" rule.  Others may disagree with your "NEVER go backwards"
>rule.
>

Look again at what I wrote. I never used the word "rule" in my post.
I said "To make GOTO more readable." These are clearly my suggestions.
I find uses for GOTO. I find that these guidelines help, and these are
the situations in which I feel that using GOTO doesn't make my code
less readable or more difficult to maintain.

>
>You don't have to make up your own rules.  Some other guys, who have
>thought about it alot, have put together a pretty well thought through
>set of rules.  

Guys like... You? Ooh, could you teach me?

This is more-than-vaguely insulting. I am perfectly familiar with the
tenets of structured programming. It looks like our writer is assuming
that my ".edu" domain means that I am an untutored student just beginning
to learn programming. This simply isn't the case.

>So, why invent your own?

My own what? I haven't written any rules here.
My own guidelines, suggestions, occasional method of coding,
my own code? Isn't that what programming *is*? I study guidelines, books,
C++ Report, Journal of Object-Oriented Programming, class libraries,
other programmer's code, and take what I find useful from these sources. 
I strive to write readable and maintainable code, and I am now working to
develop my skills as a C++ programmer. That's why I read this group. None
of these activities preclude the occasional use of GOTO. Into the kill file...
-- 
"...remove protective cap. Hold atomizer with thumb at base and nozzle 
between first and second fingers. Without tilting head, insert nozzle into 
nostril. Fully depress rim with a firm, even stroke and sniff deeply."
-advice for presidential candidates from Paul Potts - potts@itl.itd.umich.edu
From: howells@bird (Timothy P. Howells)
Subject: run time type checking
Organization: Research Computer Facility, The MITRE Corporation, Bedford MA
Date: Wed, 2 Sep 1992 13:34:18 GMT

  How are things progressing with run time type checking?  Is this
still projected to become part of the language?  If so are there any
references regarding the particular system that might be implemented?
Any idea on the time frame?

Replies via email would be appreciated.

Thanks,
Tim Howells, howells@linus.mitre.org
Xref: sparky comp.lang.c++:13083 gnu.g++.help:1168
From: schiebel@cs.wvu.wvnet.edu (Darrell Schiebel)
Newsgroups: comp.lang.c++,gnu.gcc,gnu.g++.help
Subject: Explicit Calls to Destructors (SunCC=ok, gcc=not)
Keywords: destructors
Date: 31 Aug 92 12:46:44 GMT
Followup-To: comp.lang.c++
Organization: WVU Statistics and Computer Science


	In the Sun (SC1.0 w/ cfront 2.1 (I think)), an explicit call
	to a class' destructor from within a one of the class' member
	functions works:

	void Tess::cleanup(Bool abort) {
	  Tess::~Tess();
        }

	However, in gcc-2.2.2 this does not work, and gives the error:

test.cc: In method `void  Tess::cleanup (enum Bool)':
test.cc:28: destructor specification error

	Other nonworking variations:

	this->~Tess();			AND
	(*this).~Tess();		WITH THE ERROR MESSAGE:

test.cc: In method `void  Tess::cleanup (enum Bool)':
test.cc:30: address of `this' not available

	and finally:

	~Tess();			WITH:

test.cc: In method `void  Tess::cleanup (enum Bool)':
test.cc:30: invalid functional cast

	Is there some way to get around this in gcc? Its exactly what
	I want to do; I don't want to force users of my class to call
	parent ``cleanup'' functions, in children. Explicit calls to
	destructors is permitted, ARM p.278, sec 12.4.

						
						thanks,
						Darrell Schiebel
						(schiebel@a.cs.wvu.wvnet.edu)
From: combee@prism.gatech.EDU (Ben Combee)
Newsgroups: comp.lang.c++
Subject: Re: BC 3.1 TV Running slow ?
Date: 27 Aug 92 12:07:57 GMT
Organization: Satellite of Love, Gizmonic Institute

On the specific problem of 3.1 TV being slower than 3.0's TV:

1) The memory allocation routines (and the whole library) were compiled
   with debugging.  If you recompile it using the option -DNDEBUG to
   define the macro NDEBUG, there will be a large jump in speed.  The
   debug version calls heapcheck () after every allocation and deallocation.

2) This version also defaults to TScreen::checkSnow == True.  By setting this
   variable to False you will get another jump in speed, as writes to the
   screen will not have to wait for the refresh.
-- 
Benjamin L. Combee                 |  -===-
Internet: combee@prism.gatech.edu  | =   ___  "Home of the Big G Burger" 
1991-1992 joint enrollee           | -     =    -- MST3K, Comedy Central
C, Modula-2, C++ resource          |  -===-
From: kotula@nano.cs.umn.edu (Jeff Kotula)
Newsgroups: comp.lang.c++
Subject: Re: Return value for the constructors.
Date: 24 Aug 92 00:23:57 GMT
Distribution: usa
Organization: University of Minnesota

In <matt.714407976@centerline.com> matt@centerline.com (Matt Landau) writes:

>The fact that both of these approaches leave you with the potential for
>using an incompletely initialized object (the very thing constructors in
>C++ were supposed to prevent!) points to a basic shortcoming in most of
>the current implementations of the language.  

Do any languages handle this cleanly?  None leap to mind...

>The underlying point is that without a decent exception system, there 
>is **NO** good way to deal with the problem of constructor failures.  
>There are several different not-so-good ways to choose from; which one 
>you choose depends on the nature of the system you're writing.

>Even *with* a decent exception system, the problem doesn't just go away.
>Exceptions provide a mechanism and a framework within which one can deal
>with this problem (as well as many other problems).  The design skills
>and engineering discipline needed to use exceptions both correctly and 
>robustly are still not to be underestimated.

Absolutely.  The approach you've outlined is what I've been using and it
seems to work pretty well.  You're final point is important because I've
found that programmers dislike dealing with error situations and tend
to simply ignore them.  All the discussions elsewhere on how to improve
software quality are a bit premature until we can overcome this tendency.

Another aspect of this problem hasn't been discussed at all: what about
operator overloading?  Unless no operator functions can fail (probably
unlikely in anything more complicated that a numerical type) you can't
really use operator overloading and check for errors.

One way you could is to (as has been mentioned) have a status code (a bit
will generally not be enough information to recover from an error) in the
object and *propogate* errors back to the final result-object of the
expression.  This is Ugly.  Are programmers going to check the status of
an object resulting from an expression when 50%(?) of all malloc or new
calls are not verified?

Anyway, the language that solves this problem elegantly and robustly is
probably a long way off, so I think we need to come up with useful
techniques and programming practices rather than rely on a new feature in
a language that follows a tradition of ignoring the problem.

2 cents.

object
--
-------------------------------------------------------------------------------
jeff                            |     "Dismiss whatever insults your own soul."
kotula@cs.umn.edu               |      		Walt Whitman
-------------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: pete@genghis.borland.com (Pete Becker)
Subject: Re: Callbacks - C++ needs an extension?
Originator: pete@genghis.borland.com
Keywords: callback event eventdriven extension
Organization: Borland International
Date: Sat, 29 Aug 1992 16:13:56 GMT

In article <1992Aug28.165108.17479@isy.liu.se> svan@isy.liu.se writes:
>Hi guys!
>
>Maybe some of you have, like me, done some windowprogramming in
>C++. There are a lot of toolkits to choose from, but whatever
>you choose, wether it is a C++-package like TNT or a C-package
>like xview, you'll probably stumble upon the notion of call-
>backs.
>
>Callbacks are essencially a functionpointer you deliver to 
>the windowing toolkit when creating a widget, for instance 
>a button. This function is then supposed to be called when
>the user have taken some action, like pressing the button.
>
>Their existance is motified by the nature of event-driven
>programming and that it is most unpractical to have to edit
>sourcecode in the toolkit when you want a special function in
>your source to be called.
>
>Most often a button is connected to some sort of other
>object, like a window, and it is most often the window that
>knows how to response when the button is pressed.
>
>The problem is that it seems impossible in C++ to implement
>a callback strategy which calls this window-object directly...
>

	The problem is not in C++ but in libraries that constrain callback
functions to look like ordinary C functions.  Such libraries are old 
technology, and making newer techniques work will always require a certain
amount of work.
	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.
	-- Pete
From: macdonal@westford.ccur.com (Steve MacDonald)
Newsgroups: comp.lang.c++
Subject: Turbo C++ vs. Gnu C++
Date: 25 Aug 92 16:52:24 GMT
Article-I.D.: westford.1992Aug25.165224.27556
Distribution: usa
Organization: Concurrent Computer Corp.  Westford, MA

I have a question regarding the following code. This compiles fine with the 
Gnu C++ compiler, but when I compile this on the latest version of Turbo C++
on a p.c., I get an error. I'll flag the line to the right of where it appears.

#include <stream.h>
#include <string.h>
#include <new.h>
#define endl "\n"

			//Example3_8
int classcount;		//Accessing an array of class pointers.

class Test{
public:
	Test() {
             print(word = "NO INITIALIZER SUPPLIED");
	     count = ++classcount;
	     }

	Test(char *mess ="HELLO") 
		{
	     print(word = mess);
	     count = ++classcount;
	     }

	Test(char *mess1, char *mess2){
		print(word = mess2);
		count = ++classcount;
              }

	Test(Test &clone){
		print("I'm a clone class");
		count = ++classcount;
		word = clone.word;
		}

	~Test() {
	      print ("GoodBye");
	      classcount--;
	      }

	void print(char *mess){
		cout<<mess<<endl;
		}

	void print() {
		cout<<word<<endl;
		}

	int getcount(void){
		return count;
		}

protected:
	char *word;
	int count;
};

main(){

Test *classptrarray[10];

for(int i = 0; i < 10; i++)
	classptrarray[i] = new Test; ***TURBO C++ yields the following error
					message:
					Error c:\tc\examples.cpp 58: Ambiguity
					between 'Test::Test()' and 'Test::
					Test(char near*)' in function main()

int a;
for(int x = 0; x < 10; x++){
	a = classptrarray[x] -> getcount();

	//a = (*(classptrarray + x)) -> getcount();
	//Alternate pointer syntax

		cout<<a<<endl;
}

//delete [10] classptrarray;
//Generates a runtime error: "null pointer assignment"
//new "mem" for 10 classes not deleted.

//delete classptrarray;
//Same error as above and "new" mem not deleted

//This is the correct way to delete 
for(i = 0; i < 10; i++){
  a = classptrarray[i] -> getcount();
  delete classptrarray[i];
  cout<<a<<endl;
 }
}


Again, when I compile and run this in the Gnu environment, no problems. What is
wrong with this picture?

					Regards,
					Steve
Newsgroups: comp.lang.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: GOTO, was: Tiny proposal for na
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Wed, 2 Sep 92 21:53:23 GMT

I find this whole discussion of GOTO in comp.lang.c++ somewhat
quaint.  Perhaps it should be moved to comp.lang.c. 

If we've learned anything in the past 20 years, it is that
that the way you write your code within a function is much
less important than the way you structure your functions and
types. The distinctive features of C++ (member functions,
inheritance, ...) are concerned with global structure and
not the local structure of functions.   

   -- Jerry Schwarz

Newsgroups: comp.lang.c++
From: igrdb@informatik.tu-chemnitz.de (Ingo Gringer)
Subject: Combine c and c++ possible?
Summary: How?
Organization: tu-chemnitz
Date: Wed, 26 Aug 1992 13:33:36 GMT

Hi everywhere,

Please be indulgent if that's just another nonsense question!

I try to connect two applications which are programmed in c++
and otherwise in c. Now I want to combine these programs, but
there is an hump: they need their own libraries and the c-
application is not compiled through the c++. It fails with the 
error, that a function used in the special c-library is not
declared. Thats correct but doesn't irritate the c-compiler.
I dont know where he obtains his informations. One lib contains
finally the needed function. 

Is it possible to link the object files produced by c++ or c 
together? Trying this generates permamently an error that my
function I wrote in the c-programm are not defined. But 
I told the c++ - part everything with my headerfiles. 

What is wrong? Why doesn't it works?

Any hints would be very much appreciated.

Please responds by email.
Ingo
From: sam1969@dcs.qmw.ac.uk (SOURESAFIL)
Newsgroups: comp.lang.c++
Subject: SmallTalk to C++
Keywords: Conversion
Date: 4 Sep 92 16:06:15 GMT
Organization: Computer Science Dept, QMW, University of London


I am very interested to design a protocol and a set of rules to convert 
classes in SmallTalk to C++.

There are number of problems like emulating the garbage collection, block 
objects, etc...

However, I feel the problem is within our grasp and doable. I am aware of a 
conversion from SmallTalk to Objective-C, although, I have no idea about its 
sucess or failure.


Any comments or references would be greatly appreciated.


Ramin
*****
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 28 Aug 92 23:28:26 GMT
	<1992Aug26.130335.26725@hemlock.cray.com>
	<MATT.92Aug26122422@physics16.berkeley.edu> <rmartin.714929724@thor>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: rmartin@thor.Rational.COM's message of 27 Aug 92 15:35:24 GMT

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

   Goto has never been a "good" way to implement FSMs.  Nested
   switch/case statements which use a State variable and transition codes
   are more traditional, easier to maintain, and do not use goto.

That depends on your application. For the inner loop of a GC, an FSM
implemented with "goto" might be significantly faster than an FSM
implemented with state variables and transition codes.

					Thomas.
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Destruction of temporaries
Date: 29 Aug 92 15:17:52 GMT

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

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

|> It is in these cases where I would be perfectly happy if the compiler
|> issued a warning, or even an error.

|Which cases?  I don't know how to write a compiler smart enough to
|distinguish the innocent cases from the guilty ones.  Surely you're
|not suggesting a warning every time you call a function that returns
|a pointer!
|-- 

No, I want a warning every time a temporary gets converted into a
pointer.  

In your example:  Given String::operator char*(); 
                    and String String::operator+(const String&);  : 

String a,b;
char* c = a+b;

An implicit conversion to char* takes place on a temporary.  A warning
should be possible.  

Clearly there are cases where the compiler could be thwarted:

String a,b,s;
char* c = <some_condition> ? a+b : s;

A simplistic compiler might not be able to see this, but it is
detectable.


String& f(String& x) {return x;}

String a,b;
char* c = f(a+b);


The above is more of a problem, becuase in order to provide the
necessary warning, the compiler must warn whenever a reference to a
temporary is taken.  This would generate warnings even when there was
no danger.  But that's what warnings are all about.

What have I forgotten?  Do temporaries present dangers for any context
in which they are not converted to pointers or references?  Are there
any such contexts where the operand of such a conversion cannot be
determined to be a temporary?

--
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: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Pointer to member function as parameter
Keywords: pointer, member function
Organization: Computer Science, University of Melbourne, Australia
Date: Mon, 31 Aug 1992 19:20:20 GMT

bhickey@bambam.uwaterloo.ca (Bruce Hickey) writes:

>Hi,
>
>I am attempting to pass a pointer to a member function as an argument to
>a function. Neither Stroustrup (2nd Ed) or Lippman (2nd Ed) cover this
>subject directly, to my knowledge. 
>
>I am trying to create a pointer to a member function as well as use that 
>pointer to call the function. The problem arises when I try to pass this 
>pointer as a paramter to a function. There appears to be no reason why this 
>is not possible. 
[...]

>#include <iostream.h>
>
>class mine {
>public:
>    double func( int );
>};
>
>double mine::func( int var1 ) 
>{ 
>    cerr << var1 << "\n"; 
>    return 0.1;
>}
>
>// This function wants a pointer to a member function.
>void freefunc( double (mine::*f)(int) ) 
>{ 
>    cerr << "calling func\n";
>    (*f)(2);			// How do I call the function?
>}

Try the following instead:

// This function wants a pointer to a member function, and a pointer to
// the object that we are going to call the member function for
void freefunc( mine *object, double (mine::*f)(int) ) 
{ 
    cerr << "calling func\n";
    (object->*f)(2);			// call the function
}

>int main()
>{
>mine test;		
>
>double (mine::*pf)(int) = &mine::func;
>
>(test.*pf)(5); 		// Call the member function through pointer
>
>freefunc(test.*pf); 	// Attempt to pass pointer to function

Try one of the following here:

freefunc(&test,&mine::func); 	// pass pointer to function (directly)
freefunc(&test,pf); 		// pass pointer to function (via variable pf)

>
>}
-- 
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: steve@taumet.com (Steve Clamage)
Subject: Re: Novice Questions
Organization: TauMetric Corporation
Date: Thu, 3 Sep 1992 16:33:37 GMT

nikki@trmphrst.demon.co.uk (Nikki Locke) writes:


>I HATE it when people do that ! (:-)

>NULL is a POINTER which is guaranteed not to point to any valid location. 
>It may or may not have the bit pattern all zeroes.

>'\0' (ASCII NUL) is the CHARACTER which is used to terminate strings.

>Please do not confuse the novice by using NULL to mean NUL.

I HATE it when people do that ! (:-)

Neither C nor C++ is required to use the ASCII character set.

A literal string in C and C++ will always be terminated by an
implicit null character, meaning a character having zero value.
In source code, this may be represented as '\0' (type char).

This need have nothing to do with ASCII, although the ASCII character
set happens to have a member of zero value which is called NUL
when writing about the character set.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: noye@bcrka378.bnr.ca (Janet Noye)
Subject: 3.0 for sun/sparc or apollo??
Reply-To: noye@bcrka378.bnr.ca (Janet Noye)
Organization: Bell-Northern Research, Ottawa, Canada
Date: Tue, 1 Sep 1992 20:42:22 GMT

Does anyone know of any 3.0 compilers for the sun/sparc's or the Apollo's?
Yeah I realize that asking about the Apollo is just opening myself up to 
disappointment but I had to ask -);

Thanks for your help!
Janet

-------------------------------------------------------------------------------
Janet Noye : email : noye@bnr.ca                mail  : Dept. 5E22
             phone : (613) 763-5985             Bell-Northern Research Ltd.
             fax   : (613) 765-4845             P.O. Box 3511, Station C
                                                Ottawa, Ontario K1Y 4H7
                                                Canada
-------------------------------------------------------------------------------


Newsgroups: comp.lang.c++