HDTenEightyP/NetNews huggingface dataset:
From: pete@genghis.borland.com (Pete Becker)
Subject: Re: GOTO, was: Tiny proposal for na
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Thu, 3 Sep 1992 17:05:35 GMT

In article <600@lax.lax.pe-nelson.com> twbrown@PE-Nelson.COM (Tom W. Brown) writes:
>In article <1992Sep2.155510.4274@genghis.borland.com>, pete@genghis.borland.com (Pete Becker) writes:
>|> 
>|> C++ version:
>|> 
>|> void foo()
>|> {
>|> 	ifstream input( "foo" );
>|> 	DataObject data;
>|> 	if( data.doStuff( input ) == ERROR )
>|> 		return;
>|> 	data.doMoreStuff();
>|> }
>|> 
>|> 	Let the compiler do the work...
>|> 	-- Pete
>
>Tsk, tsk, tsk... You put a return in the middle of the function :-)

	Yes, and quite deliberately.

>How about:
>
>   void foo()
>   {
>      ifstream input("foo");
>      DataObject data;
>      if (data.doStuff(input) != ERROR)
>         data.doMoreStuff();
>   }
>

	I use a return in the middle of a function whenever processing within
that function has terminated.  This is usually because of an error, but it
is sometimes because a very simple case has been identified and handled.  If
instead of data.doMoreStuff() there had been 30 lines of code, it's much 
clearer to me to have the conditional return followed by that code, rather
than adding a block and indenting everything.
	-- Pete
 
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 10:56:27 CDT

In article <1992Aug27.092938.6768@hemlock.cray.com> dsf@cray.com (Dan Frankowski) writes:
>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? ..
>> [code deleted]

>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?

Sorry for the bandwidth.  I answered my own question (at least on a
cfront-based compiler), and can't get the newsreader to cancel my
article.

Answer#1: It will indeed "cover" global new and delete.  If the
reference to new is resolved in the source code, the linker will
never look for an external definition.

Answer#2: Hanging had something to do with using stream I/O in new.
I used the default new, modified so the first line was

cout << "new: Allocating " << size << " bytes.\n";

If one of the ostream::operator<<()s somehow called new, that would
explain it..

>(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.)

I can't assume any of that.  The user can replace new and delete,
and they will cover the original functions.

-- 
Dan Frankowski            Dan.Frankowski@cray.com     (612) 683-5099
Newsgroups: comp.lang.c++
From: rgp@mpd.tandem.com (Ramon Pantin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 27 Aug 92 03:36:40 GMT
Organization: Tandem Computers, Micro-Products Division

In article <rmartin.714863091@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>kevinl@tisdec.tis.tandy.com writes:
>
>|	I have to paritally disagree.  Everytime you add a flag variable,
>|you are doubling the number of states for your program.  The more states,
>|the more possible paths, and the more paths, the more possible unforseen
>|errors (if the paths are not anticipated and tested--something that is
>|very hard to do).
>
>No, the influence of state variables which control loops is limitted
>to the loop condition, and possibly to tests at the completion of the
>loop.  Thus, the "doubling" does not occur.

It is well known that to rewrite code that uses breaks, continues,
mid-function returns and gotos (in the most general case) you have to
either:
	- Add state variables to the head of loops and additional tests
	  of these variables within the bodies of the loops; or
	- State variables only tested at the head of the loops and
	  code duplication.

So you either duplicate code (as you did in the example a couple of
postings ago) or you have to add additional tests within the loops
(which I showed in my "structured" version of the original C example).

So your wins are:
	- Code duplication, difficult to maintain (in one of your
	  previous posts you din't even seem to agree that code
	  duplication was difficult to maintain!); or
	- A complexity explosion in your code (number of code paths +
	  tests and sets of state variables).

From my informal counts in this thread it seems that most people are
perfectly happy with break, continue and mid-function returns.  Some
group of people avoid gotos as a rule of thumb but wouldn't mind using
them if required, some of these have not used a goto in the last 10 years.
A smaller group (only you?) avoid all of these contructs completely.

In any case Bob, nobody is suddenly going to have a religious experience
right here and convert themselves to the other camp, so if you don't see
more followups on this subject it is not because of that, but because this
subject has already been beaten to death and at least I've got tired of it.

Ramon Pantin
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Turbo C++, function prototypes
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 2 Sep 1992 19:13:23 GMT

steve@taumet.com (Steve Clamage) writes:

>If you write, for example,
>	void main(){ }
>The compiler is obligated to diagnose an error in C and C++.

Are you sure? I've just tested three supposably ANSI-compliant C compilers
and NONE of them diagnose an error (or even a warning!). 

The compilers were
	gcc -ansi -pedantic -Wall	version 2.2.2 for mips-sgi-irix
	cc -ansi -pedantic -fullwarn	"MIPS ucode C compiler" on an sgi-irix
	tcc -P- -A -w			Turbo C++ 1.00 (C compiler, not C++)

I also tested three C++ compilers, and got one error and one warning.

	g++ -ansi -pedantic -Wall	version 2.2.2 for mips-sgi-irix
		Warning: return type for main changed to integer type
	CC -ansi +p +w 			Cfront 2.0, using the above cc
		(No diagnostic)
	tcc -P+ -A -w			Turbo C++ 1.00 (C++ compiler)
		Error test.c 1: main must have a return type of int

-- 
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:  dolgov@inpbox.inp.nsk.su (Yuri V. Dolgov)
Subject: Please help ! How to use "strstream" ?
Reply-To: dolgov@inpbox.inp.nsk.su
Organization: Budker Institute of Nuclear Physics SD RAS
Date: Fri,  4 Sep 92 17:33:29 +0700 


Hi, folks !

Please send me any examples with "strstream" (especially "ostrstream" with
dynamic memory allocation).

Thanx in advance,

-------------------------------------------------------------------------------
Yuri Dolgov                               Internet: dolgov@inp.nsk.su
Programmer                                Phone:    +7(3832)359 147
Budker Institute of Nuclear Physics       Novosibirsk, Russia.
-------------------------------------------------------------------------------
-- 
-------------------------------------------------------------------------------
Yuri Dolgov                               Internet: dolgov@inp.nsk.su
Programmer                                Phone:    +7(3832)359 147
Budker Institute of Nuclear Physics       Novosibirsk, Russia.


Newsgroups: comp.lang.c++
From: kboyle@csfb1.fir.fbc.com (Kevin T. Boyle)
Subject: C++ Grammar 
Reply-To: uunet!csfb1!kboyle
Organization: First Boston Corporation
Date: Thu, 3 Sep 1992 13:23:27 GMT



		I am interested in writing a syntax parser for C++ and
	I wonder if anyone has a YACC compatible grammar that they
	could supply me.  Your help would be very appreciated.
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Destructors and exit()
Organization: TauMetric Corporation
Date: Fri, 4 Sep 1992 16:02:54 GMT

rad2r@uvacs.cs.Virginia.EDU (Robert DeLine) writes:

>Sorry for this novice question, but when I call exit() from a program compiled
>using g++ 2.1, the destructors for my objects don't get called.

ARM, p21:
"Destructors for initialized static objects are called when returning
from main() and when calling exit()."

Perhaps the bug is fixed in a later version of g++.


>What if the program is ended due to an uncaught exception?

See the ARM, p 364-5.  You can set up your own handlers for
unexpected and/or uncaught exceptions, but the default handling
winds up calling abort(); abort() does not invoke static
destructors.

If you have uncaught or unexpected exceptions, the default assumption
is that things have gone so far wrong that attempting to clean up will
only make things worse.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: adk@Warren.MENTORG.COM (Ajay Kamdar)
Subject: Re: Destruction of temporaries
Organization: Mentor Graphics Corp. - IC Group
Date: Tue, 1 Sep 1992 15:48:28 GMT

In article <rmartin.715356168@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>adk@Warren.MENTORG.COM (Ajay Kamdar) writes:
>

  - example where implicit conversion of a temporary to char* is ok deleted -

>|I wouldn't want the compiler to issue warnings in such a case, irrespective
>|of whether operator char*() was called on a temporary or not.
>
>Then, you should cajole your compiler vender into supplying you with a
>compiler which provides you with the type of #pragma control that lets
>you supress the warnings on a function by function basis.
>
>

Development teams do not necessarily use the same compiler on different
platforms. pragmas are not necessarily portable across compilers, and hence
could be a problem if a product has to be supported on multiple platforms.

Are you advocating this generation of warnings as an optional "quality of
implementation" feature of compliers, or as a language standard? If it
is the former, it makes sense for the compiler to also provide means to
turn off the warnings via pragmas or command line switches. It might be
that you need to cajole your compiler vendor into supplying you with a
compiler which provides these warnings.

But if it is a language standard that you are advocating, then depending
upon pragmas (which are implementation dependent by definition) to silence
warnings from code which is perfectly ok seems inappropriate to me. If the
standard specifies the generation of warnings, it had better make sure that
it enables the compilers to generate warnings only for the problematic
cases and not for good code.

Warning about conversion of a temporary to pointer or reference is a nice
goal to shoot for, but that needs the language to be enhanced to enable
the compilers to do a good job of it. 

- Ajay

-- 
I speak for none but myself.

Ajay Kamdar                               Email : ajay_kamdar@mentorg.com
Mentor Graphics, IC Group (Warren, NJ)    Phone : (908) 580-0102
From: acanter@sdcc3.ucsd.edu (Adriaan Canter)
Newsgroups: comp.lang.c++
Subject: C++ Memory Management
Keywords: Memory, Heap, new, delete
Date: 4 Sep 92 14:18:26 GMT
Distribution: ca


Hello, I've noticed that Borland Turbo C++ (v 1.0) will actually reserve 16
bytes when the "new" function is used to allocate space for a 2 byte
integer, i.e. the following code:

int * intptr;
intptr = new int;

will allocate 16 bytes, as measured using the "coreleft()" function,
under the small memory model. A subsequent second allocation of this type will
fit the second integer into the first 16 byte space allocated, but a third call
will block off an additional 16 bytes, and so on, so that 4 two-byte integers
will take up 32 bytes of space, for example. I guess this happens because some
space is reserved to point to the next location in the heap, although the
amount seems excessive. This is pretty wasteful of course, if I want to
dynamically allocate alot of structures. Is there anyway I can control how
much memory is actually reserved when the "new" function is called? Do the
newer versions of C++ have some memory managment classes (as I've over-heard)
that can fix this? Or do I have to finagle my own scheme, overloading the
"new" and "delete" operators. Forgive me if this is a dumb question, but my
manuals don't say very much about it. Thank you.

                                        Adriaan Canter
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: Object What is an OODBMS?
Summary: Quick Trick Brick Stack
	 (Or the difference between What Is and What It Is Made Of
Organization: :
Date: Wed, 26 Aug 1992 01:03:49 GMT

In article <JONAS.92Aug22123325@ipcsun5.his.se>, jonas@ipcsun5.his.se (Jonas Mellin) writes:
> In article <BEVAN.92Aug12152127@jaguar.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
 
>    In article <RCZ5NS@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
>       ... we frequently want to use code or data that ... exist in another
>	class.  ... if we have a ... LinkedList we might ... use this when
>	implementing our stack.  ... we might say that a Stack is a LinkedList
>	which also has the push() and pop() functions.  We can do this
>	directly using ... inheritence:

> 	  class Stack : public LinkedList
> 	   ...
 
>    Is this generally considered good use/example of inheritance?  I
>    don't think a "Stack is a LinkedList" at all, rather a LinkedList is
>    a possible implementation of a Stack.  I'd therefore use ... a
>    template ...
 
> I too prefer the view of this that Bevan has, but who is to say that
> Stack cannot be a LinkedList?

This is the difference between modelling the problem and modelling the
solution.  In general, we _do_ need different tools for modelling

	A) Real-world entities and processes
	B) Mathematical entities and processes (mathematical entities
		have no lifetime; math can describe time but it itself
		exists out of time)
	C) Algorithmic entities and the various loosely set-theoretic
		notions that undergird many them

And we must be careful not to confuse implementation tricks with the
modelling of the `world' in question.

			First, I'll make a quick trick brick stack.
			Then I'll make a quick trick block stack.
			You can make a quick trick chick stack.
			You can make a quick trick clock stack.
						(_Fox in Socks_, Dr. Seuss)

The tricks are great for getting a fast implementation, but a fast
implementation isn't necessarily the one you want for the long term.
They may be good for prototypers, but they may not be so good for the
`real product'.  The real product has to survive many people working on
it, and that probably means that it has to be written with an eye
towards communication.  (Of course, if you are a prototyper, the
prototype _is_ your Real Product ...)

			...
			Clocks on fox tick.  Clocks on Knox tock.
			Six sick bricks tick.  Six sick chicks tock.
			Please sir, I don't like this trick sir.
			My tongue isn't quick or slick sir.
			I get all those ticks and clocks, sir,
				mixed up with the chicks and tocks sir.
						(ibid.)
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
From: nagle@netcom.com (John Nagle)
Newsgroups: comp.lang.c++
Subject: Comparison chart of C++ dialects?
Summary: Does such a chart exist?
Keywords: chart C++ dialects
Date: 2 Sep 92 18:26:14 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


      Does anyone have a chart that shows, side by side, the differences
between the various dialects of C++?  I'd like to see at least Object C,
Objective C, C++ per Strostrup's first book, C++ per the current AT&T
based products, and C++ per Strostrup's second book.  Oh, and the GNU
product.  

					John Nagle
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for named loops.
Date: 28 Aug 92 12:26:58 GMT

kers@hplb.hpl.hp.com (Chris Dollin) writes:

|In article ... rgp@mpd.tandem.com (Ramon Pantin) writes:

|   It is well known that to rewrite code that uses breaks, continues,
|   mid-function returns and gotos (in the most general case) you have to
|   either:
|	   - Add state variables to the head of loops and additional tests
|	     of these variables within the bodies of the loops; or
|	   - State variables only tested at the head of the loops and
|	     code duplication.

|Isn't one (non-boolean) state variable enough? [Hint: call it ``PC''. When you
|are enlightened, you will realise that just because it's *possible* to cast
|your code in an obsessively structured fashion doesn't mean you *should*.]

In fact, one BOOLEAN variable is sufficient, since all we are trying
to do is decide when to terminate a loop.  However, in many cases it
is advisable to use more than one boolean variable so that after the
loop exits, you can find out why.

Unfortunately the PC is not a very good state variable.  The state of
the program often cannot be determined from the PC.  However,
structured programming uses the PC as a state variable more than non
structured programming, since more of the significant program states
are separated into individual pathways of their own.

Although it is possible to obsessively ignore the lessons of the past,
it doesn't mean that you *should*.



--
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: mcgrant@rascals.stanford.edu (Michael C. Grant)
Subject: Re: complex classes and temporary destruction.
Organization: Information Systems Laboratory, Stanford University
Date: 26 Aug 92 23:24:10


Oh, and that reminds me, if I can't do

complex a,b,c,d;
...
a = b + c*d

when the ANSI committee finally settles on some temporary destruction
standard, then I'm going to be really ticked.

Michael C. Grant

Newsgroups: comp.lang.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Destruction of temporaries
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Wed, 2 Sep 92 19:23:39 GMT

In article <1992Sep2.042030.488@frumious.uucp>, pat@frumious.uucp (Patrick Smith) writes:
|> 
|> So I think it would be a better idea for the programmer to identify
|> those functions which can't be called with temporaries as arguments,
|> instead of those which can.  As, for example, in Eric Smith's
|> proposal upon which I commented in another posting.

Several people have expressed opinions that seem to suggest that
there are some functions that should be called with temporaries
and some that shouldn't.  I don't have the same intuition.

In particular, I'm assuming that they would designate that the
first argument of all my insertors as not usable with temporaries.

   ostream& operator<<(ostream& out, MyType& mytype) ;

But the description of these is clear.  They return their first
argument.  Except that they have a side effect on out they are
identity functions.  So if I have a function, h that accepts
an ostrstream& I can call

	h( ostrstream() ) ;

but not 

	h ( ostrstream() << "contents" << ends ) ;

This doesn't make much sense to me.  It is one of the
reasons I am strongly opposed to "earliest possible" destruction
of temporaries.

  -- Jerry Schwarz
From: mi@starlab.UUCP (Michael Hoennig)
Newsgroups: comp.lang.c++
Subject: using this in initializer list generates warning
Summary: should it be allowed to use this befor *this is initialized?
Keywords: this,initialization,base-class pointer
Date: 3 Sep 92 06:39:29 GMT
Organization: StarDivision GmbH, D-2000 Hamburg, Germany

In article <23598@alice.att.com> ark@alice.UUCP () writes:

>The unfortunate reality is that I have seen a number of development
>projects that have an inflexible rule -- no warnings allowed!  That is,
>they will not allow their people to ship any code that generates warnings.

In this context we have a problem with the Microsoft C++ 7.0. We too
should not ship sourch wich generates warnings (but exceptions are
allowed - it's not a strikt rule). But in the following situation 
the MSC7.0 comiler generates a warning: this used befor initialization.

class Window;
class Button: public Window ...

class Dialog: public Window
{
	Button aBtn;
	... some more stuff
public:
	Dialog( Window *pParent ):
		Window( pParent ),
		aBtn( this )				// here comes up the warning
	{...}
	...
};

Although I use this as a Window* and the *(Window*)this is already
initialized - the warning comes up. What can we do? To set the parent
after construction is a bad idea it makes code awful and we must
create the Windows on the level of GUI later too because
there are GUI where the parent can't be canged (OLIT, Motif).

Adios
-- 
Michael Hoennig                                  FAX:   +49 40 23 646 550
StarDivision GmbH                                Phone: +49 40 23 646 500
Sachsenfeld 4                                    uucp: ...!unido!starlab!mi
D-W-2000 Hamburg 1                               domain: mi@starlab.uucp
From: garyp@manutius.UUCP (Gary Powell)
Newsgroups: comp.lang.c++
Subject: Legal uses of goto
Date: 3 Sep 92 14:56:37 GMT
Reply-To: garyp@manutius.UUCP (Gary Powell)
Distribution: na
Organization: Aldus Corporation, Seattle WA

IMHO Besides optimizing critical loops there is one other area where
goto's are useful, add clarity, and ease maintiance.  Error trapping.
Until I get a fully implemented try,catch scheme I plan on using goto's to avoid
over nesting when I check the state of the result of a function and wish
to exit the fn on an error condition. These goto's only go forward and only
with the express intention of cleaning up and returning from the fn.

This is my concession to having only one return in a fn, being religious about
checking the return state of a fn, and not wishing to read the guts of the
fn in a 30 character column on the right side of the page. Note, I try to use
descriptive labels so a casual reader understands where and why the goto is
being used.

eg:
--------------------------------------------
// Sample code

enum iResult { OK, ERROR};
extern iResult gn(char *&);
extern iResult hn(char *&);

iResult fn(int *arg)
{
    iResult result = OK;
    char *g;
    char *h;

    if ( arg == 0 )
    {
	result = ERROR;
	goto Exit;
    }

    result = gn(g);  // Some other routine which allocates memory.
    if ( result == 0)
	goto Exit;

    result = hn(h);  // Some other routine which allocates memory.
    if ( result == 0)
	goto Free_gn;

    // More routines called each allocating memory or doing some
    // other task which requires cleanup before the fn returns.
    // If you do this 20 times in a fn the indentation and nested {}'s
    // make it almost unreadable without the goto's.

    delete h;
Free_gn:
    delete g;
Exit:
    return (iResult);
}


Gary Powell ------------+ Internet:     garyp@aldus.com
c/o Aldus Corporation   | uunet:        manutius!garyp@uunet.uu.net
411 1st Ave South       | uucp:         camco!manutius!garyp
Seattle, WA 98104  USA  | Voice:        (206) 622-5500