HDTenEightyP/NetNews huggingface dataset:
From: steve@taumet.com (Steve Clamage)
Subject: Re: I Borland C++/Win 3.1 Broken??? Help!
Organization: TauMetric Corporation
Date: Wed, 2 Sep 1992 16:49:49 GMT

David.Haigh@bbs.actrix.gen.nz writes:

>The following member function compiles without error, using Turbo C++
>for Windows 3.0.

>virtual int yield( volatile BOOL & continueYield = TRUE);

>BOOL : typedef for int
>TRUE : #define 1

>However, using Borland C++ for Windows 3.1, the following errors are generated:

>* Reference initialised with 'int', needs lvalue of type int.
>* Type mismatch in default value for parameter 'continueYield'.

It looks like Borland fixed a compiler bug in the later release.

You cannot initialize a non-const referernce with a constant.
TRUE is a literal (constant) integer, and may be passed only to a
a const reference.  If a function has a non-const reference parameter,
it is allowed to change the passed-in value.  You can't change a
literal constant, which is why it is illegal.

Either pass in a variable initialized to TRUE, or declare the function
parameter to be a const reference.  If it does not change the value of
its actual argument, it should be declared const anyway.  If it does
change its actual argument, you can't pass it a literal.

This is legal, assuming you really want 'volatile' as well:
    virtual int yield( const volatile BOOL & continueYield = TRUE);
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Destruction of temporaries
Date: 29 Aug 92 21:53:26 GMT
Article-I.D.: alice.23590
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

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

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

All that will do is cause library authors to write little classes
that contain pointers to suppress warnings.  Or maybe they'll use
explicit member function calls instead of implicit conversions.

It's hard to make things foolproof because the fools are so clever.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: rad2r@uvacs.cs.Virginia.EDU (Robert DeLine)
Subject: Destructors and exit()
Organization: University of Virginia Computer Science Department
Date: Thu, 3 Sep 1992 22:03:01 GMT


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.  This doesn't
surprise me too much, but is this correct?  Does the ARM mention what should
happen when exit() is called?  What if the program is ended due to an uncaught
exception?  If destructors _are_ called when leaving via an uncaught exception,
perhaps this is a better way than calling exit() to leave from deep inside a
program?

Thanks.


-- 
Rob DeLine
Computer Science, University of Virginia
deline@Virginia.EDU
From: twbrown@PE-Nelson.COM (Tom W. Brown)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 2 Sep 92 20:12:24 GMT
Organization: PE-Nelson

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 :-)
How about:

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


----------------------------------------------------------------------------
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
----------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: psrc@pegasus.att.com (Paul S.R. Chisholm)
Subject: Re: a few rookie questions about testing for CLASSS membership.
Reply-To: psrc@pegasus.att.com (Paul S.R. Chisholm)
Organization: AT&T Bell Laboratories
Distribution: na
Date: Thu, 27 Aug 1992 00:54:22 GMT

In article <1992Aug25.204448.15682@cs.wisc.edu> you write:
>I'm a relative rookie to C++, though not to OOP (due to many moons of
>programming in Objective-C).

It shows.

>1. I have a pointer p to some object. How do I test if p is a member
>of the CLASS a.

There's no way in C++ to do this.  Such run-time information isn't
generated by the compiler.  (You can put it in yourself, if you want
to, but not trivially.)

>2. Is there a way to test if p, which is a pointer to an object, can
>test if p can execute method m?

See previous answer.

>Bill Roth, University of Wisconsin Computer Sciences Dept.
>Internet: roth@cs.wisc.edu. BITNET: ROTH@WISCPSL. HEPNET: PSL::ROTH

Paul S. R. Chisholm, AT&T Bell Laboratories/EasyLink Services,
att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Destruction of temporaries
Date: 28 Aug 92 19:07:06 GMT
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

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!
-- 
				--Andrew Koenig
				  ark@europa.att.com
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: disp.h for BC/C++ Yes/No? Where...Al Stevens...*.hpp?
Date: 25 Aug 92 22:14:29 GMT
Reply-To: jamshid@emx.utexas.edu
Followup-To: comp.os.msdos.programmer
Organization: The University of Texas at Austin; Austin, Texas

Followups have been redirected to comp.os.msdos.programmer.

In article <Bt9J3M.CHL@news.udel.edu> davidc@brahms.udel.edu (David Casper) writes:
>Is there a "disp.h" for DOS|BC/C++ ???

No, I think it's a Zortech (now Symantec) header file.  It's probably
their screen functions so you may be able to do what you want with
Borland's <conio.h> functions.  If you have TC++/BC++ 3.0+ take a look
at their <constrea.h> class constream.

>Is there a "stream.hpp" ???

It's Zortech's C++ streams header.  Instead use the standard
<iostream.h> header.  Note, your code was probably compiled with the
older version of C++ streams (Zortech didn't support "C++ 2.0 streams"
until their 3.0) so you may need to do some code changes.  See
Stroustrup's _C++ Prog.Lang. 2nd Ed_ or Lippman's _C++ Primer 2nd Ed_
to learn about modern streams.

>What does "*.hpp" stand for ???

Some C++ programmers use this extension instead of ".h" for their
header files.  See the c.l.c++ FAQ (ftp sun.soe.clarkson.edu,
pub/C++/FAQ).  I just use ".h" since there's not much reason to use a
different extension (you don't 'make' .h files) and I think most C++
programmers do also.  ANSI C++ will probably use ".h" for any standard
C++ headers they introduce (confirmation?).

>What is Dr. Dobbs ???

_Dr. Dobb's Journal_ published by M&T.  Very good, not too serious,
general programming magazine leaning towards C (some C++) and PC
programming.  I subscribe to it because I really like the
personalities and policies of the editor and columnists.  You should
be able to find it at any bookstore (B.Dalton) in the computer mag
section.  All DDJ code is available in the DDJMAG directory at Simtel.
See the comp.os.msdos.programmer FAQ if you don't know about Simtel.

>What/which publication(s) does Al Stevens write for ???

For at least DDJ.  He's writing the free D-Flat user-interface library
(supports MS-DOS character mode now) and soon to be writing about the
C++ version D-Flat++.  Haven't really looked at it, though.  Anyone
know if he or others are planning on porting it to other GUIs?  That
would be great.

Jamshid Afshar
jamshid@emx.utexas.edu
Newsgroups: comp.lang.c++
From: dowdell@unixg.ubc.ca (David J. Dowdell)
Subject: Dyad M++: Information, opinions requested.
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Tue, 1 Sep 1992 00:34:40 GMT

If you are an experienced programmer in C++, and have experience with
Dyad's M++ class libraries for numerical analysis, could you please help me
out by answering some, or all of my questions below.(E-mail, please)  
I am not an experienced C or C++ programmer, but I would like to use C++ to
simulate a fairly complex dynamic system, and then analyze the results. 

      -What modules do you use?
      -Have you had any problems with M++?  
      -Are there any bugs that you know of?  
      -Is it necessary to have the source code modules?
      -Is the documentation good? adequate?
      -Is there anything obviously missing from the package?
      -Finally, are there any alternatives to M++ that you would
       more highly recommend?

Any comments you have would be greatly appreciated.
Thanks in advance.

----
Dave
dowdell@unixg.ubc.ca
From: David.Haigh@bbs.actrix.gen.nz
Newsgroups: comp.lang.c++
Subject: BC 3.1 lost "strtod" !?
Date: 3 Sep 92 22:00:28 GMT
Organization: Actrix Information Exchange

I was recently compiling some 'old' BC 3.0 / TCW code with the new BCW
3.1 and up came the following message:

--> Undefined symbol '_strtod' in module ....

Now, I thought this was my coding, but the same problem occurred when
I attempted to run the small sample on how to use the function,
supplied in the Borland Help.

The old and new stdlib.h files look to not include any difs likely to
cause this.

Comments??? Has anyone else seen this before?

-- 
----------------------------------------------------------------------
"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: srinivas@lgc.com (Manapragada Srinivas)
Subject: Overloading in the presence of ellipsis
Organization: Landmark Graphics Corporation
Date: Thu, 27 Aug 1992 16:48:55 GMT


Hi,

	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); }


	The CC 2.0 on sun complains about finding an exact match for 'foo' and
	aborts.

	g++2.2.2 on the other hand doesn't complain even with the -Wall flag,
	and on running the executable prints out
	
			"non ellipsis version"

	which is the behaviour I would expect.


	Unfortunately, ARM (page 326) explicitly states that this is an error.

	The problem I am having is that the g++ behaviour is what I am looking
	for, does anyone know what the ANSI committee adopted?

Thanks in advance,
Srinivas
--
Yonder, beyond the event horizon!
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: risky inline
Date: 27 Aug 1992 18:54:42 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu
Keywords: inline, safe programming

In article <1992Aug27.142700@uni-paderborn.de> trachos@uni-paderborn.de (Konstantin Trachos) writes:
>Inline-expansion is surely more effective than #defines, but it isn't
>less risky than that.

Inline expansion is FAR less risky than macros, because type-checking is
done and because the parsing is the same as if it were a regular function.
However, inline functions have file scope only (I would say they are
static, but unfortunately Stroustrup gave that word one too many
meanings).  For this reason you must never do what your example does,
which I abbreviate:

>// Interface C.hxx -----------------------------
>   class C{
>          int c();
>   };
>
>// Code C.cxx ----------------------------------
>   #include "C.hxx"
>   inline int C::c() {return 1;}// !

You've basically put a lie in your C.hxx file: you've told users of
that file that someone will supply a global C::c(), but C.cxx supplies
only a local C::c().

The solution is that if you put a declaration of a function in a header
file, you must supply a global definition somewhere (it can't be inline).
If you want an inline function, it must be in the header file. With some
compilers there are ways around this, but if your code is to run under
several compilers, you need to follow this rule.

But to claim on the basis of this one little gotcha that inline functions
are not any less risky than macros is to lose all sense of proportion.
It's evident that you didn't understand the rule about the local scope
about inline functions.



--
Joe Buck	jbuck@ohm.berkeley.edu
From: kers@hplb.hpl.hp.com (Chris Dollin)
Newsgroups: comp.lang.c++
Subject: Re: Re: GOTO, was: Tiny proposal for named loops.
Date: 27 Aug 92 11:56:06 GMT
Organization: Hewlett-Packard Laboratories, Bristol, UK.

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

--

Regards,    | ``Wandering minstrels are fogging my brain    | Judy Tzuke
Kers.       | And weird intellectuals are doing the same.'' | Higher & Higher
Newsgroups: comp.lang.c++
From: eric@tfs.com (Eric Smith)
Subject: Re: Destruction of temporaries
Organization: TFS
Date: Wed, 2 Sep 1992 22:34:51 GMT

In article <1992Sep2.192339.2774@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>	h( ostrstream() ) ;
>
>but not 
>
>	h ( ostrstream() << "contents" << ends ) ;


Wrong.  Both calls are with a temporary.  Both should be equally illegal.

You should construct the stream object, give it a name, and use it as
above.  Then neither of the above will be temporaries.

e.g.  h ( mystream << "contents" << ends ) ;
returns a reference to mystream, which is not a temporary.
(And each subexpression returns a reference to mystream, so
there are no temporaries involved.)

A temporary is an object constructed for a single expression.  Calling a
function with that expression is ok only if the function does not assume
the object will still exist after the function returns.
From: doug@foxtrot.ccmrc.ucsb.edu (Douglas Scott)
Newsgroups: comp.lang.c++
Subject: Re: Replacing NeXT cc with gcc-2.2.2
Date: 1 Sep 92 18:19:59 GMT
Reply-To: doug@foxtrot.ccmrc.ucsb.edu
Distribution: usa

In article <1992Sep1.003306.15284@fcom.cc.utah.edu> swillden@news.ccutah.edu  
(Shawn Willden) writes:
] jbuck@forney.berkeley.edu (Joe Buck) writes:
[large portion deleted]
] : >5)	Is 2.2.2 compatible with the NeXT gdb or would I have to get gdb-4.6 as
] : >well?
] : 
] : I recommend getting gdb-4.6 if you're going to use g++.  It has greatly
] : improved facilities for finding member functions, including command
] : completion (where you type part of the name and prototype of an overloaded
] : member function and it completes it or lists the possibilities).  I don't
] : know what version of gdb NeXT provides; if it predates 4.0 you'll need
] : to upgrade.
] : 
] : --
] : Joe Buck	jbuck@ohm.berkeley.edu
] 
] Thanks, Joe.

Sorry Joe and Shawn--this is not the case.  You cannot build any of the Gnu gdb  
versions on the NeXT.  There is no support for them.  The version on the NeXT  
under 2.1 is old (something like version 1.3) and only provides rudimentary  
information (like backtraces) for programs compiled under gcc/g++.
--
Douglas Scott                              (805)893-8352
Center for Computer Music Research and Composition
University of California, Santa Barbara
Internet: (NeXTMail ok)   <doug@foxtrot.ccmrc.ucsb.edu>
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Destruction of temporaries
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Thu, 3 Sep 92 02:08:51 GMT

In article <1992Sep2.223451.24804@tfs.com>, eric@tfs.com (Eric Smith) writes:
|> In article <1992Sep2.192339.2774@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
|> >	h( ostrstream() ) ;
|> >
|> >but not 
|> >
|> >	h ( ostrstream() << "contents" << ends ) ;
|> 
|> 
|> Wrong.  Both calls are with a temporary.  Both should be equally illegal.

I didn't specify h in the original.  I assumed it was obvious
that it would be a function that didn't retain or return it's 
ostrstream& argument.  So I thought h(ostream()) would be ok.
Recall that the argument passing is defined to be equivalent
to initialization so if I can't do the function call, then I
can't do

	ostrstream& o = ostrstream() ;

either.


Perhaps Eric will reconsider his comments in that light.  

  -- Jerry Schwarz








Newsgroups: comp.lang.c++
From: tannerrj@cnsvax.uwec.edu (Power = 486 + HST Dual Standard)
Subject: <stdio.h> and <iostream.h>
Organization: University of Wisconsin Eau Claire - Power Users
News-Software: VAX/VMS VNEWS 1.41    
Date: Tue, 1 Sep 1992 20:47:00 GMT
X-Posted-From: cnsvax.uwec.edu
X-Posted-Through: sol.ctr.columbia.edu

I am trying to put a text windowing environment on a C++ program
that I have created. The text windowing environment is DFLAT from 
DDJ magazine. The problem is DFLAT is ANSI C using stdio.h and
my program is a C++ program with iostream.h. I have read that there
are potential dangers in mixing the two. Any suggestions? Thanks.

Newsgroups: comp.lang.c++
From: matt@centerline.com (Matt Landau)
Subject: Re: constructor call during initialization of same class
Organization: CenterLine Software, Inc.
Date: Sun, 23 Aug 1992 21:34:02 GMT

In <1992Aug23.154530.1131@taumet.com> steve@taumet.com (Steve Clamage) writes:
>I am guessing that you want to share some code by having several
>constructors call a "basic" constructor.  You can't do that with
>a construcutor.  You can write an initialization function which all
>constructors call.  

Yes, you can, but it's not quite the same semantically.  In particular,
using initalization functions means you cannot initialize data members
that are references, and you cannot initialize data members that are
instances of classes by using their copy constructors.  (You end up
using their assignment operators instead if assign to them in your 
shared initialization member function.)

More properly, of course you CAN initialize references and perform copy
construction of data members that are instances, but you have to do it
by using the usual data member initialization syntax, and you have to
do it explicitly in every overloading of the constructor.  Where there
are a large number of such data members, or when the class design is
very fluid (early in the design, for instance), it's very easy to miss
one or two of these.

I think THAT is the problem the original poster was trying to address;
it's a problem that being able to call alternate overloadings of your
own constructor would address.  Are there any ways to deal with it in
the language as currently defined?
Newsgroups: comp.lang.c++,comp.lang.c
From: kendall@centerline.com (Sam Kendall)
Subject: Tags++ (etags/ctags for C and C++) posted to comp.sources.misc
Organization: CenterLine Software, Inc.
Date: Fri, 28 Aug 1992 16:37:14 GMT

   The basic idea of etags and ctags is to allow someone using a text
editor (Emacs and vi, respectively) on a source program to ask the
editor for the definition of a function, type, or other named entity.
The editor then positions itself at the appropriate source file and
line.

   Tags++ is an enhanced version of etags and tags.el (for use with GNU
Emacs Version 18) and ctags (for use with vi).  The enhancements support
C++, and they support C better than the standard etags, tags.el, and
ctags.

   This should work on all Unix(tm of AT&T) systems.  It may work on VMS
(with VMS GNU Emacs), but that has not been tested; please let me know
if you have tried it on VMS, successfully or unsuccessfully.

   Tags++ has not changed significantly in several years and is robust.


Advantages of Tags++
--------------------

   The major advantage of tags++ over the standard version in Emacs
Version 18 is support for C++.  For example, given this program:

	class A {
		int i;
	public:
		A() { i = 5; }
		int get_i();
	};

	int A::get_i() { return i; }

you can find the tags "A", "A::A", or "A::get_i".  Caveat: if you are
using ctags and vi, you must supply the "-T" switch when you run ctags
to get this to happen.

   Even for C, tags++ finds more stuff (such as macro constants and
structure tags) than other versions.

   In Emacs, you get name completion in the minibuffer (on all
identifiers in the program).  See the man page for an example of why
this is useful.  Note that the visit-tags-table operation is slow
because it is building an alist for name completion.

   Also in Emacs, M-. finds exact matches first; then M-, (or C-U M-.)
finds other exact matches, followed by successively less exact matches.
For example, suppose you type M-. f RET, and your sources contain
functions "efface", "f_internal", "foo", and "f" in that order.  The
standard tags facility will find these in that order -- frustrating if
you just wanted "f".  Tags++ will find "f" first (exact match), then
"f_internal" (word match), then "efface" and "foo" (inexact matches).


Compatibility
-------------

   Tags++ is forward- and backward-compatible with the standard versions
of etags and tags.el (for Emacs Version 18) and ctags.  In other words,
if some people at a site are using the standard tags facility and others
are using tags++, no one will notice -- except that tags++ users will be
unhappy with the sparse tags files produced by the standard etags or
ctags.

   Tags++ almost certainly works with Epoch, although we haven't tried.
Tags++ -- along with all other Emacs Version 18 tags programs -- is
probably incompatible with the upcoming Emacs Version 19.


For More Info
-------------

   See the README file and man page including in the posting.


----
Sam Kendall
CenterLine Software, Inc. (formerly Saber Software)
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: How to hack c++ into doing late binding ?
Summary: Decency and Mach 3
Organization: :
Date: Tue, 1 Sep 1992 09:16:41 GMT

In article <TMB.92Aug31191017@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
> In article <1992Aug13.151003.15231@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
 
>    What you need to do 'dynamic linkage' is a decent operating system.
>    Windows and OS/2 do exactly what you want. I do it, it
>    works superbly. So your problem is that Unix is a brain dead
>    operating system :-) 
  ...
> It's easy to claim to "standardize" lots of features (Windows, OS/2)
> if you only have one system running on only one hardware platform...

And to get out of that one-platform problem, you have to go back to
being an operating system rather than simply a graphical user shell.
IBM recently announced that their next OS/2 will be based on the Mach
`microkernel.'  I believe that a `version 3' appeared in the article,
which was in last week's Computerworld.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++