HDTenEightyP/NetNews huggingface dataset:
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: Explicit Calls to Destructors (SunCC=ok, gcc=not)
Summary: use "this->~T()" ("this->T::~T() to workaround gcc bug)
Keywords: destructors
Date: 4 Sep 92 19:31:23 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

In article <gnusenet2234@h.cs.wvu.wvnet.edu> schiebel@cs.wvu.wvnet.edu (Darrell Schiebel) writes:
>	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();
>        }

That's not the correct way to call a dtor.  It probably doesn't work
under later versions of cfront.

>	However, in gcc-2.2.2 this does not work ...
>
>	Other nonworking variations:
>
>	this->~Tess();			AND
>	(*this).~Tess();		WITH THE ERROR MESSAGE: ...

Both of these are correct -- you've encountered a gcc-2.2.2 bug.
Btw, it is also legal (since the ARM) to explicitly destroy built-in
types (it's a no-op, of course).  This makes it easier to instantiate
templates which explicitly destroy their objects with built-in types.
Note, BC++ 3.0 didn't implement this feature, and BC++ 3.1 only allows
one form of the syntax:

	int i;
	int* p = &i;
	i.~int();  // correct, but BC++ error
	p->~int();  // correct, but BC++ error
	i.int::~int();  // correct, but BC++ error
	p->int::~int();  // correct and BC++ allows

The difference between:
	p->~T();
and
	p->T::~T();
is that the second overrides the "virtualness" of the dtor (if it is
virtual).  You should therefore almost always use the first form.  Besides,
it's less characters and not any slower if ~T() isn't virtual.

>	and finally:
>
>	~Tess();			WITH:

You must explicitly use a "." or "->" whenever calling the dtor, even
from within a member function.  'this' is not assumed.  The above
tries to create a temporary Tess and call it's unary ~ operator (see
ARM 12.4).

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

I think someone said "this->Tess::~Tess()" works under gcc.  Just
remember that this will not call the destructor of derived class
(I'm assuming ~Tess() is declared virtual).

Jamshid Afshar
jamshid@emx.utexas.edu
From: ivan@cwi.nl (Ivan Herman)
Newsgroups: comp.lang.c++
Subject: Looking for a general threads package on UNIX
Date: 2 Sep 92 07:55:54 GMT
Organization: CWI, Amsterdam

Sorry if this question has been asked before.


In view of a large scale European research programme, we are looking for
a (possibly PD) lightweight process (thread) package on UNIX. The idea
is to have a package which would allow us to run within a "traditional"
UNIX process a large number of lightweight processes. We are especially
looking for packages which are as environment-independent as possible,
and which would be reasonably easy to install on a new hardware/software
environment.

More specific requirements are:

   - The package should be usable from C (or should be a language
     extension of C);
   - the scheduler for lightweight processes should be preemptive;
   - it should be possible to start several hundreds
     of lightweight processes
   - there should be facilities to ensure that system calls,
     especially I/O, would not block the whole UNIX process; only
     the caller lightweight process should be internally suspended.


It is a real plus for us if:

   - The package should be usable from C++ as well (if not, we can
     always try to adapt it).
   - There is a mechanism which ensures that, from a programmer's point
     on view, there would be no difference between sending a message from
     one lightweight process to another within the same UNIX address space and
     between making a (hidden) RPC call to another object on another
     UNIX process.

We know that the terminology in this respect is not fully established and,
for some, lightweight packages and threads are different sort of animals.
No flames please.

We do have information and/or experience with AT&T's Concurrent C/C++,
Brown University's Thread Package and of Waterloo University uSystem and
uC++. We are looking however for more complete information.

We would prefer to receive answers by email, because I do not read all
the newsgroups addressed by this message. I am happy to post a overview
if anything of interest pops up. Thank you in advance.

Ivan Herman
             Centre for Mathematics & Computer Sciences (CWI),
             Kruislaan 413, 1098 SJ Amsterdam, The Netherlands.
             Email:ivan@cwi.nl, Tel: +31-20-592.4163
Newsgroups: comp.lang.c++
Newsgroups: comp.lang.c++
Subject: Re: BC 3.1 lost "strtod" !?
From: David.Haigh@bbs.actrix.gen.nz
Date: Thu, 3 Sep 1992 22:22:33 GMT
Organization: Actrix Information Exchange

Well, no sooner had I posted my request for help, when it dawned on me
that perhaps I was at fault - in not linking the maths emulation library...

And, that solved it! Oh for the days of Turbo C 2.0 and its SPECIFIC
error messages.

(excuse me while I go and kick myself - repeatedly).

-- 
----------------------------------------------------------------------
"If I understand you correctly", said the student, after the professor  
had explained the big-bang theory of the creation of the universe, 
"first there was nothing and then it exploded." - Johan van Os.
Newsgroups: comp.lang.c++
From: tpurves@sygnus.uucp (Timothy Purves)
Subject: Re: BC++ 3.1 and 386 code generation
Organization: None
Date: Sat, 29 Aug 1992 00:40:46 GMT

In article <36863@uflorida.cis.ufl.edu> asher@qtp.ufl.edu (Robert L. Asher) writes:
>
>Recently a friend of mine purchased the BC++ 3.1 upgrade and I thought I might
>be interested as well.  But I had some doubts and wanted to know about the
>speed improvements and wheather 386/486 code generation had been added.  He
>indicated that it had and so did the blurb from Borland I got via e-mail.  So I
>had some programs which are fairly cpu intensive.  We compiled them and made
>some tests.  3.1 does not seem to make 386 code for me.  I compiled using
>bcc -Ot -3 -f287 code.cpp
>and the execution file then ran slower than the 3.0 version of the code
>compiled with the same options except a -2 used.  This was suspicous in itself.
>Then I tried running the code on a 286 machine and it did.  What's going on
>here?  Did we miss something?
>
>Thanks for any help / info.
>Robert
>
>-- 
>Robert L. Asher          | 
>Department of Chemistry  | 
>University of Florida    | 
>asher@qtp.ufl.edu        | 

As I understand borland's 386 code generation. is just for Long int's, nothing
else.

-- 

tpurves@sygnus (Timothy Purves)
Newsgroups: comp.lang.c++

In article ... matt@physics16.berkeley.edu (Matt Austern) writes:

   The classic situation where gotos are generally believed to be useful
   is writing a finite-state machine.

Use mutually recursive procedures, and lean on your language designers and
compiler-writers until they're as efficient as the goto's would have been.
--

Regards,    | "If taking devious pains was a sign of laziness, he was quite
Kers.       | prepared to call Hazelton the laziest man alive." Blish (m-o-l)
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 29 Aug 92 16:24:46 GMT

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

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

Agreed.  And, as I have said before, if you have to break the rules to
meet therequirements, then break the rules.  If you absolutely need
the speed (and in a GC subsystem you certainly do), and if you can
gain that speed by using a few gotos, then use the gotos.  Use breaks
and continues and duplicated code and any other trick that will allow
you to eek the last nanosecond out of your algorithms.

But nanosecond preformance is not generally needed in most
applications.  And in those cases, (the general case) the payoff is
greater if you sacrifice a little efficiency for readability,
maintainability and resuability.




--
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: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: Proposal: auto T&
Date: 25 Aug 92 22:51:29 GMT
Organization: The University of Texas at Austin; Austin, Texas

In article <2A991ABB.477D@tct.com> chip@tct.com (Chip Salzenberg) writes:
>According to eric@tfs.com (Eric Smith):
>>The "auto" in the function return value type tells the compiler to allocate
>>the space for that automatic in the stack frame of the caller, instead of
>>the stack frame of the called function.
>
>There is prior art.  GCC and G++ already allow named return values ...

But is there current reason?  Can named return values let compilers do
anything that they cannot do with a little bit of optimization (ARM 12
Commentary)?

Jamshid Afshar
jamshid@emx.utexas.edu
Xref: sparky comp.lang.c++:13198 comp.lang.c:13111
From: prechelt@i41s14.ira.uka.de (Lutz Prechelt)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: named loops
Followup-To: comp.lang.c++
Date: 2 Sep 1992 14:24:33 GMT
Organization: University of Karlsruhe, FRG
Distribution: world
NNTP-Posting-Host: i41s14.ira.uka.de

Everybody interested in the issue of named loops should have a look
at the C-Refine preprocessor, which -- among other things -- solves
this problem: give a name to any block (e.g. a loop or loop body) and
jump out of that block with the "leave" statement. You can leave 
arbitrarily many ones at once.

C-Refine works for C and C++ and is available for anonymous ftp from
  iraun1.ira.uka.de [129.13.10.90]
  /pub/gnu/crefine.3.0.tar.Z
as
-rw-r--r--  1 ftp      XLINK       93217 Jul 15 10:06 crefine.3.0.tar.Z

C-Refine 3.0 also appeared as v02i013 to v02i19
on comp.sources.reviewed on 15 Jul 92

[The other thing that C-Refine does is letting you put just the name of the 
 block where the block belongs, instead of the block itself.
 The block is declared later below. 
 This mechanism allows for top-down decomposition inside functions, 
 which very much improves the readability of programs and eases writing
 them.]

  Lutz

Followup to comp.lang.c++
--
Lutz Prechelt   (email: prechelt@ira.uka.de)            | Whenever you 
Institut fuer Programmstrukturen und Datenorganisation  | complicate things,
Universitaet Karlsruhe;  D-7500 Karlsruhe 1;  Germany   | they get
(Voice: ++49/721/608-4317, FAX: ++49/721/694092)        | less simple.
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: GOTO, was: Tiny proposal for na
Summary: Empress of India
Organization: :
Date: Sun, 30 Aug 1992 08:35:14 GMT

In article <rmartin.714931485@thor>, rmartin@thor.Rational.COM (Bob Martin) writes:
> 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.
>  ...
> 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.

Bob, I haven't used a goto in at least eight years, except perhaps in
a toy program to prove that the compiler takes it.  I believe that once
in that time have toyed with the idea of using one in real code, but
found a good way without it.

Goto's may be like titles such as `Empress of India.'  There may
somewhere be a monarch who still is styled by that title, but nobody rules
India as an empire.  But I'll be fight for my goto, if need be, with my
fingernails against the omnidijkstratite juggernaut, and if someone wants
to call himself Emperor of the North Pole, he's got my permission.

Goto's are like the write-in vote.  I don't expect ever to want to vote
for Elmer Plumpudding, but I want that slot on the voting machine.  (I
realize that the courts in Hawaii have ruled otherwise, but since when
are the courts a democratic institution?)
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
From: shite@sinkhole.unf.edu (Stephen Hite)
Newsgroups: comp.lang.c++
Subject: Re: simple C++ X-windows lib? (help me not reinvent the wheel)
Date: 29 Aug 92 13:33:47 GMT
Organization: University of North Florida, Jacksonville

In article <YOUNG.92Aug17185056@cruiser.umd.edu> young@umd.edu (Neal Young) writes:
>
>I want to write some very simple X-windows C++ code:
>a few buttons, some interactive graphics (draw
>circles, bitmaps, text, get mouseclicks).
>
>I'm new to C++ and X-windows.
>If you've been through this already,
>maybe I can learn from your experience.
>

   If you want a challenge but don't want to revent the wheel, I suggest
you get the XV package and convert his user interface tools to C++
classes.  All of the routines are written in C using Xlib.  I'd do it
myself but I don't care for XV's licensing statement.

Steve Hite
shite@sinkhole.unf.edu
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Tiny proposal for named loops.
Date: 28 Aug 92 12:09:44 GMT

Ramon!  I thought you were tired of this thread.

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

|In article <rmartin.714863856@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
|>Again, I disagree.  I find this construct:
|>   while (error == NO && done == NO)
|>easier to understand than:
|>   ...

|(Don't mean to start another religious war :-)

|I find this verbose and hard to read:
|	while (error == NO && done == NO)


|What is wrong with good old C code as the goods meant it to be?
|	while (!error && !done)


|You don't believe in boolean expressions either?  :-)

In fact I often use the !error form.  Fortunately for the badwidth of
the net, I do not have a religious axe to grind here.  I used the (==
NO) form here becuase of a habbit I acquired while working for a
recent client.  I turns out that his definition of NO was not zero...




--
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: Destruction of temporaries
Date: 1 Sep 92 14:11:01 GMT

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

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

|> Ideed.  But I think the warning is still useful.

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

|Thus, giving a compiler warning for a construct is equivalent to
|banning it for those projects.

|Warnings had better be right almost all the time.

Thus, the #pragma argument.  Development environments which support a
policy of no warnings will make use of either #pragmas to supress
benign cases of the warning, or will fix the code so that aliases to
temporaries are not created.

It is a much larger problem, IMHO, to fail to report a condition which
could cause a crash.


--
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: rose@t524i5.telematik.informatik.uni-karlsruhe.de (Ortwin Rose)
Newsgroups: comp.lang.c++
Subject: Re: indent for C++
Date: 31 Aug 92 07:25:06
Organization: /usr/users/rose/.organization
NNTP-Posting-Host: t524i5.telematik.informatik.uni-karlsruhe.de
In-reply-to: bakowskr@wm-mercer.ca's message of Thu, 27 Aug 1992 19:57:39 GMT


There seem to be some problems with accessing the host I adviced as a source for
'indent++' from within the states. So here is the IP-address:

   ftp.th-darmstadt.de:/pub/programming/languages/C++/tools/indent-C++.6.5.tar.Z
   ^^^^^^^^^^^^^^^^^^^
      130.83.55.75

Hope that helps in accessing the system without any problems.
(by the way, Ron: host, path and file-name you specified in your message were
 NEARLY correct - please look at the capital 'C++'!).


Regards

-- O. Rose
   University of Karlsruhe
   Institute of Telematics

   rose@telematik.informatik.uni-karlsruhe.de
Newsgroups: comp.lang.c++
From: jonas@falcon.ericsson.se (Jonas Nygren)
Subject: template typedef
Followup-To: comp.lang.c++
Organization: Ericsson Telecom, Stockholm, Sweden
Date: Thu, 27 Aug 1992 13:21:28 GMT

I wonder if the following construct for templates and typedefs ever
have been considered. Would it be possible to add this to the
language.

template<class S, class T> X {};

template<class T> typedef X<Y,T> xy;

xy<Z> xyz; // equiv to X<Y,Z>

/jonas
From: taylor@foraker.tivoli.com (Eric Taylor)
Newsgroups: comp.lang.c++
Subject: where is template?
Date: 27 Aug 92 00:57:51 GMT
Organization: TIVOLI Systems, Inc.

My g++ compiler does not seem to recognize
templates.  Is this a short term non-feature?
It would be a shame not to have them.
Newsgroups: comp.lang.c++
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: GOTO, was: Tiny proposal for na
Organization: Texas Instruments Inc
Date: Wed, 26 Aug 1992 21:56:00 GMT

In <1992Aug26.130335.26725@hemlock.cray.com> dsf@cray.com (Dan Frankowski) writes:

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

The fact that you CAN do something is not necessarily adequate proof
that you SHOULD do something.  Yes, you can do anything you like with
'if-then' and 'while'.  Even structured programmers use other
constructs than those.  You should use what makes things clearest, and
yes, there are going to be times when 'goto' and 'break' make for
cleaner and more easily read code.

>>	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."  

I believe someone once wrote an article entitled something like
"Structured Programming Using Goto"; the same person who wrote
another article that started this whole mess that was entitled "Goto
Considered Harmful", if my memory has changed state randomly.  In a
nutshell, 'goto' isn't the problem; it's the 'come from' that kills
you when it comes to figuring out what is going on.  If you structure
things correctly and document them clearly, there are times when
'goto', 'break', AND multiple exits make good sense in making code
more easily read.

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

According to the guy who started that debate they are (if properly
used). 


-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c++
Subject: Re: backwards casting for lackof better term
Date: 26 Aug 1992 17:54:50 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <6370@lhdsy1.lahabra.chevron.com> hwrvo@kato.lahabra.chevron.com (W.R. Volz) writes:
>The question: what does CreateAAorAborAC return, or, what does the function
>protptype looklike? A * CreateAAorABorAC(int) or what.

Yes, that's it.

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

Unfortunately, no.  While the overall structure will stay the same, if you
add new derived classes you have to update CreateAAorABorAC to add entries
for them to to the switch statement.  Hopefully your actual application
uses a better name for the function than CreateAAorABorAC, so that you
won't need to change the function name as well!

Another way to implement it is with a dispatch table:

A*(*creator_table)[] = {
    AA::CreateA,
    AB::CreateA,
    AC::CreateA
};

const int creator_table_size = sizeof(creator_table) / sizeof(*creator_table);

A* CreateAAorABorAC (int type_index) {
    if (i < creator_table_size)
       return (creator_table[i].fn)();
    error(...);
}

class AA: public A {
    // ...
  public:
    static A* CreateA() {return (A*) new AA;}
}

// same for AB and AC

Now if you create an AD class, you just make sure that it has a CreateA
static member function and add it to the creator_table.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.c++