HDTenEightyP/NetNews huggingface dataset:
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: New C++ type: boole
Organization: Texas Instruments Inc
Date: Thu, 30 Jul 1992 16:33:38 GMT

In <1992Jul29.193723.15092@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

>In article <1992Jul27.135243.28686@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>|NO!  Do *NOT* make this warning mandatory.  Some of us prefer to write
>|code like this on purpose.  

>"Mandatory warnings" in a language standard is an oxymoron.  From the 
>context of the *language* either something is illegal and therefore cannot
>be legally done, or something is legal and therefore can be legally done.
>IE either its an error or its not.  "Warnings" then, are not part of the
>language, but rather are part of an implementation -- typically they represent
>an area of the language where the implementors of a compiler disagree with
>the specifiers of the language, in effect a warning says: "you can do this
>if you insist, but *we* think its stupid!"

But are there not places where the language can be REQUIRED to issue a
warning?  Hence, a "mandatory warning"; which is just what I don't
want it to do.

>|The only 'advantage' I can see to a 'real' boolean type is if you can
>|guarantee me that it will only take up one bit and the compiler is
>|bright enough to store them all off in some bit array someplace to
>|save space.  Otherwise, I guess I fail to see any pressing need for
>|this.

>I don't see this as being a very plausible feature of a 'boole' or whatever
>you want to call them.  A byte is already the smallest addressable unit of
>storage.  The reason for this is simply in most hardware a byte is the smallest
>addressible unit of storage.  Implementations could be required to implement
>a non-native pointer that gives bitwise addressibility, but such a pointer
>would be incompatible with native pointers [in much the same way the
>"pointers" to member are incompatible with native pointers]

I agree, which is why I don't see the point of a separate 'bool' type.
What does it get me that I don't already have?  Type checking on
parameters that are intended to be of type 'bool'?  BFD.

I'd still rather have genuine 'subrange types', at which point I could
make my own 'bool' if I wanted it, by specifying 'bool' to be a
subrange type on the range [0..1].

-- 
"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: mike@meiko.com (Mike Stok)
Newsgroups: comp.lang.c++
Subject: Re: Coding Standards - Request for ammo
Date: 23 Jul 92 12:31:20 GMT
Organization: Meiko Scientific Corp.

In article <1992Jul16.081820.984@cbfsb.cb.att.com> nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:
>A while ago I read an item explaining quite well  why
>coding standards were usualy bad and in particular why
>C coding standards are inappropriate for C++. Could
>someone please mail me the item or tell me where I can
>find it.
>
>I would also like to hear of any documentary discussion
>of coding standards.
>
>I would also like to receive/hear of any coding standards
>which sensible and not to onerous for creative geniuses
>like myself!! since it might be easier to change our 
>standards as a whole than change bits here and there
>provided that the replacement had some sort of authority.
>
>Nick Hounsome

Ellemtel, a Swedish telecomms company, put their Programming in C++
Rules and Reccommendations up for grabs by anon. ftp.  I got them and
was impressed by the clarity and general level of common sense
displayed - enough control & structure to be useful without stifling
creativity.

I can't remember the ftp address, but the addresses
erik.nyquist@eua.ericsson.se and mats.henricson@eua.ericsson.se are in
the introduction...

Mike
--
The "usual disclaimers" apply.    | ... many were weak and confused, succumbing
Mike Stok                         | to drink or drugs whenever possible ...
mike@meiko.com                    |
Meiko tel: (617) 890 7676         |                          Hunter S. Thompson
From: shimizu@adacidea.adac.co.jp (Keisuke Shimizu)
Newsgroups: comp.lang.c++
Subject: Introduction to C++
Keywords: MEMBER_FUNCTION_POINTERS
Date: 23 Jul 92 03:01:05 GMT
Reply-To: shimizu@adacidea.adac.co.jp (Keisuke Shimizu)
Organization: Advanced Data Controls, Corp.

Dear friends,

    I am new to c++. I would appreciate for any pointer to a gentle,
complete introduction to c++ book.

    Thanks in advance.
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Renew? And MOVE constructor/destructor.
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 28 Jul 1992 18:16:14 GMT

In article <THOTH.92Jul25110048@wave.cis.ufl.edu> thoth@wave.cis.ufl.edu (Robert Forsman) writes:
>
>  Why not have ANOTHER special method (in addition to copy
>construction, deletion and assignment) which is only called when an
>object is being MOVED from one memory location to another?  (please
>note that I am not overjoyed at the idea of another special operator.
>I merely expect that the default will work fine for everything I do.)

	Very interesting idea.

	Assignment is like destroy destination followed by copy.
	Move would be like then destroying the source.

	Apart from 'renew', where and how would it be used?


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: cok@sunshine.Kodak.COM (David Cok)
Newsgroups: comp.lang.c++
Subject: Re: downcast
Keywords: downcast, covariant return types
Date: 24 Jul 92 19:39:52 GMT
Organization: Eastman Kodak Co., Rochester, NY

>In article <dpg.711421775@extro.ucc.su.OZ.AU>, dpg@extro.ucc.su.OZ.AU (D P Gilbert) writes:
>
>> ...
>> This posting is canvassing ideas about downcasts and if the "covariant
>> return type on virtual functions" approved by the ISO C++ committee can
>> be used to make them a wee bit safer. Consider:

When I look at the downcasts that I currently need to do, nearly all of them
will be unnecessary after support for covariant return types is implemented.

David Cok
From: alex@bilver.uucp
Newsgroups: comp.lang.c++
Date: 17 Jul 92 19:16 MDT
Subject: Re: More operator silliness (was: |
Nf-ID: #R:1992Jul15.042239.26033@unixland.:2073232881:1992Jul17.151650.19661@bilver.uu:-1379043339:001:706
Nf-From: bilver.uucp!alex    Jul 17 19:16:00 1992


scott@unixland.natick.ma.us (Scott Evernden) writes:
>Another opportunity to request my ROTATE operators:
>	newbits = bits :) 7;
>	newpels = pels (: 3;
>Might help with some graphics code, and would otherwise be nice to
>access these usually available but inaccessible machine instructions.

Not to mention the fact that any source code making extensive use of these
operators would appear quite "friendly", what with those smileys all over
the place.

   :)


-- 
 _ |__  Alex Matulich
 /(+__>  Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817
//| \     UUCP:  alex@bilver.uucp   {peora|ge-dab|uunet!tous}!bilver!alex
///__)     Internet:  alex@bilver.oau.org | alex%bilver@peora.sdc.ccur.com

Newsgroups: comp.lang.c++
From: victor@watson.ibm.com (Victor Miller)
Subject: signals and exceptions
Date: Mon, 27 Jul 1992 13:54:15 GMT
Reply-To: victor@watson.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM, T.J. Watson Research Center

With the advent of the C++ exception handling mechanism, it would seem
logical that for those systems (like Unix) that have signal handlers,
that there would be a standard way of turning these into C++
exceptions -- that is have them act like a throw of something standard
had been done.  Have any implementations of C++ done this (or are any
planning to do this)?
--
			Victor S. Miller
			Internet: victor@watson.ibm.com
			IBM, TJ Watson Research Center
Newsgroups: comp.lang.c++
From: potts@itl.itd.umich.edu (Paul Potts)
Subject: Debugger for C++ DOS apps sought
Organization: Instructional Technology Laboratory, University of Michigan
Date: Mon, 27 Jul 1992 18:30:00 GMT

I'm looking for recommendations for a good debugger for Borland C++ 3.0/3.1
applications. I realize this isn't the ideal group for such a posting, but I've
gotten no replies on the other DOS programming groups.

I'm looking for something that works a little better than Borland's Turbo
Debugger or the IDE Debugger. Ideally, I would like to be able to look at
the call chain of a method (fully), examine objects together with their
instance variables, double-click on pointers and have them open up into the
objects they point to, etc. I've seen ads for MultiScope for debugging C++
apps, but it doesn't seem to be shipping yet.

Thanks for any help...
-- 
..though I respect that a lot, I'd be fired if that were my job, after 
killing Jason off and countless screaming argonauts... (They Might Be Giants)
Paul R. Potts, Software Designer --- potts@itl.itd.umich.edu <--- me!
Xref: sparky comp.lang.c++:11714 comp.std.c++:986
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: tagged unions, an alternative to RTTI (Re: run-time type checking)
Date: 29 Jul 92 16:53:22 GMT
	<1992Jul25.172045.24675@ucc.su.OZ.AU> <BryL9q.K5I@watcgl.waterloo.edu>
	<1992Jul28.183746.24287@ucc.su.OZ.AU>
Reply-To: tmb@idiap.ch
Followup-To: comp.lang.c++
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: maxtal@extro.ucc.su.OZ.AU's message of 28 Jul 92 18:37:46 GMT

In article <1992Jul28.183746.24287@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

   >Consider the classic "List" class and "ListNode" class.
   >ListNode is a base class, and assume there are two flavors
   >of derived node.  We write a List that contains a mix of
   >these nodes out to a file; now we want to read the List back
   >in and reconstruct it.
   >
   >Can it be done without resorting to an isA() member function,
   >some member data to identify node type, and possibly some
   >casting/conversion?

	   a) without some type information, it cant be done.
	   b) without casting it can (and should :-) be done

	   union hetero {
		   type1 *p1;
		   type2 *p2;
	   };


   And the list is homogeneous--all the elements are of type 'hetero'.

It would, in fact, be nice if C++ had a tagged union type, like Pascal
or SML. Something along the lines of:

union hetero int {
case 1: type1 *p1;
case 2: type2 *p2;
};

int f(hetero h) {
	switch(h) {
	case 1: return h.p1->foo();
	case 2: return h.p2->bar();
	}
}

void g(hetero &h) {
	// set the tag of "h" to "1" and the value of p1 to NULL
	h.p1 = 0;	
}

The members of tagged unions should usually only be used inside a
switch statement (note that switching on a tagged union is a new
construct, distinct from switching on an integral type).  Updates of
one of the members would automatically update the type tag.  There are
probably some additional syntactic and semantic issues to be resolved.

I think such a facility would be very useful and have some advantages
over RTTI:

 * works for any collection of types (objects don't have to have
   virtual function tables, etc.)

 * the compiler can warn about type cases that the programmer
   has forgotten to handle in his "switch" statement

 * tagged unions would allow objects with constructors/destructors
   in unions

 * easy to implement and explain

					Thomas.
From: fzjaffe@othello.ucdavis.edu (Rory Jaffe)
Newsgroups: comp.lang.c++
Subject: establishing a registration/database class for program defaults
Date: 31 Jul 92 20:34:30 GMT
Organization: University of California, Davis

I want to have a class that maintains a defaults file for a program.
This class would also have a database with class tags and default
information read from the file. Objects that wanted to read/write
defaults would refer to this class. Each class that used defaults would
have their own methods to send defaults to, and extract them from, the
database field that contained the default information. The acquired
default info would be in static data members so that changing it would
propagate amongst all class instances.

This is not quite like persistent objects, where the database class
would create objects corresponding to the stored information.

My questions:

1. How do you avoid collisions between class tags in the database? (2
classes with the same tag).

2. How do you ensure that classes wanting to access the defaults class
find it?

3. How should classes that use the database and thus read/write to the
default field develop their read/write functions? --e.g. overload a
function, or inherit and modify something from the database class?







I expect that this is a common enough need that someone has good
experience with the issues involved.
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Distribution: world
Subject: Re: Q: static members and private constructors
X-Mailer: cppnews $Revision: 1.10 $
Organization: Trumphurst Ltd.
Date: Mon, 27 Jul 1992 21:31:17 +0000


In article <YDD5OTF@hp832.informatik.hu-berlin.de> loewis@informatik.hu-berlin.de (M.v.Loewis) writes:

> 
> In the following program, it is not possible to create static (class)
> instances of a class with only private constructors. I suppose it is
> a general compiler error:
> 
> class B;
> class A{
> friend class B;
> A(int);
> int i;
> };
> 
> A::A(int){}
> 
> class B{
> static A m;
> public:
> int func();
> };
> 
> int B::func()
> {
>  return m.i;
> };
> 
> A B::m(1);
> 
> The problem is the last statement: I think it should be possible to create
> the m member of B somehow, since B is a friend of A, but all compilers I 
> tried complained about sth:
> BC: A::A(int) is not accessible in function _STCON_()
> g++: In function _GLOBAL_$I$__1Ai(): ...invalid initializer to constructor
> 	for type A
> CC: sorry, not implemented: static member B::m of class A with constructor
> ...
> So, is there a way out of this problem?
I seem to remeber coming across a similar problem in another compiler - I 
changed the syntax to something like ...
A B::m = 1;
and it worked. I have no idea whether this is applicable to your 
situation, but it is worth trying.
---
Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
trmphrst.demon.co.uk is NOT connected with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Renew?
Date: 30 Jul 92 17:28:24 GMT
Organization: Microsoft Corporation

In article <23347@alice.att.com> ark@alice.UUCP () writes:
|If renew guarantees to the user that the copy constructor and
|destructor will be called for each object moved, that greatly
|ameliorates the situation.  It is then sufficient for the user to
|get those two functions right, or make them private (which would
|prohibit renew on objects of that class).

Not sufficient, also the programmer has to make sure not to have
any interior pointers to objects in the array.  Because C++ *still* wouldn't
have support for "move"able objects.  What it would have then would be 
support for constructing a new array of objects based on a previous 
array of objects which are destroyed in the process.

For C++ to allow programmers to "move" objects would require language
support for identifying pointers at runtime, and "patching" those pointers
and/or refs to refer to objects' new locations.  This is a good idea IMHO, 
and is necessary for effective GC and OODB.  The central problem then becomes
the inability to support the historic "C" hack of casting pointers to/from
ints.  This problem and others lead to the idea that such an approach would
require a Modula-3-like split of the C++ programming world into "safe" 
verses "unsafe" parts.
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.lang.c++
Subject: Re: Power operator! for C++
Date: 20 Jul 92 17:49:10 GMT
Reply-To: bright@nazgul.UUCP (Walter Bright)
Organization: Zortech, Seattle

In article <1992Jul15.033910.5300@actrix.gen.nz> Bruce.Hoult@bbs.actrix.gen.nz writes:
/In article <820@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
/> Zortech C/C++ is the only compiler so far that has stable and robust behavior
/> regarding NANs and infinities. All the library functions dealing with floating
/> point now have defined behavior with all the different IEEE special cases.
/> The compiler itself can handle NANs, such as:
/> 	static double d = NAN;
/Zortech is great, Walter (on the PC anyway), but what's wrong with
/this from MPW C++?
/
/#include <iostream.h>
/void main(){
/	cout << "3/0 gives " << 3.0/0.0 << ", 0/0 gives " << 0.0/0.0;
/};
/buildprogram test >dev:null
/test 
/3/0 gives INF, 0/0 gives NAN(004)

There is nothing at all wrong with it. It is simply not enough. 0.0/0.0 as
a substitute for NAN has the non-portable deficiency of how the compiler handles
exceptions when constant folding. NCEG defines all these behaviors, and
offers things like isnan(double), and a long list of other things.
Lots of compiler printf's cannot handle NANs, for instance, check out C7's
library reference on what happens if you pass a NAN for a double:
	digit.#NANrandom-digits
(I am not kidding...) Some printf's will hang or crash if you pass NAN
or INFINITY.

I'd rather program NAN than 0.0/0.0, and likewise for INFINITY.
All the library functions should be able to handle these special values.

Some of what NCEG does is simply to nail down the behavior instead of leaving
it undefined like ANSI C does.
From: weeks@hpscit.sc.hp.com (Greg Weeks)
Date: Wed, 22 Jul 1992 21:03:30 GMT
Subject: iteration without iterators (and a question)
Organization: Hewlett-Packard, Santa Clara, CA
Newsgroups: comp.lang.c++

This note is divided into two (brief) independent parts.  The first part
describes a simple iteration protocol.  The second part asks for help in
implementing it.  (Readers who just want to be helpful can skip to the
second part.)

THE ITERATION PROTOCOL

Let `col' be a collection that holds items of type `Item'.  Here is a
very simple iteration protocol:

    for (Item *pi = col.first(); pi; pi = col.next(pi)) {
	...
	//  `pi' is the address of an item in the collection.
    }

Only two member functions are used by the iteration.  No separate iterator
class is needed.  The iteration code fits nicely into a `for' statement.
And users can set the item at the current location by assigning to `*pi'.

However, to implement `next', you have to:

    1.  Get the "node" that holds the item at address `pi'.
    2.  Get the next node.
    3.	Get the address of the item in the next node.

Steps 2 and 3 are easy.  But step 1 is hard.

HOW TO IMPLEMENT?

The problem is:

    Given the address of a class object member variable, find the address
    of the class object.

In C, this would be easy.  Just make the member variable the first member
of the structure.  Then a pointer to the first member may simply be cast to
a pointer to the structure.  But I don't think this works in C++ for a
couple of reasons.

First, I don't think the first member of a class is guaranteed to be at the
same physical address as the class object.

But suppose that it is.  Now suppose that the collection class is a
template parameterized by the node class.  What happens if someone derives
a new node class and uses that to build the collection class?  It now seems
likely the the item member will no longer be at the same physical address
as the new node object.  That's the second reason.

This discussion is leaning in the direction of messy
implementation-dependent considerations.  Is there some nice way to avoid
this?

Greg Weeks
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Question: How to get fd from cin?
Organization: TauMetric Corporation
Date: Mon, 27 Jul 1992 18:08:01 GMT

gordie@duts.ccc.amdahl.com (Gordon Freedman) writes:

>How do I get the integer fd for cin (or any iostream for that matter)? I want
>to use it for XtAddInput and/or select system call.

An iostream will only have an fd if its streambuf is some sort of filebuf.

You get the streambuf* from the rdbuf() member of the ios base class.
You need an unsafe downcast to filebuf* of the streambuf*, and you
can then use the fd() member function of the filebuf.  Example:

#include <fstream.h>	// includes <iostream.h>
main()
{
    cout <<
	 ((filebuf*)(cerr.rdbuf()))->fd() // get the fd for cerr
//        ^^^^^^^^^^ unsafe downcast
	 << "\n";
    return 0;
}

If the streambuf is not really a filebuf, this will produce poor results.

Please also note that an integer file descriptor is a Unix-like notion,
and may not be supported on all systems.  That is, a given implementation
might not have the fd() function, or it might not return anything useful.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++,comp.std.c++
From: rons@hardy.u.washington.edu (Ronald Schoenberg)
Newsgroups: comp.lang.c++
Subject: Re: Power Operator vs NANs
Date: 21 Jul 92 20:46:39 GMT
Organization: University of Washington, Seattle

In article <TMB.92Jul21152204@arolla.idiap.ch> tmb@idiap.ch writes:
>In article <850@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
>
>   C++ has abandoned ones-complement hardware and 6-char linkers, that C
>   was unwilling to leave behind. Maybe it is time to leave behind non-IEEE
>   floating point too.
>
>C++ does not specify how integer arithmetic is to be performed on the
>machine. And, personally, I don't think it's time to leave behind
>non-IEEE floating point.
>
  [elision]
>
>There is a nice middle road. You can use functional/macro syntax
>(isnan(x), isinf(x), ...) to denote standardized IEEE floating point
>operations. Such notation is straighforward, simple, and easy to
>implement even in existing compilers. Via the usual "#define foo(x)
>__foo(x)" trick, you can get macro semantics (i.e., you don't get the
>feature unless you #include the header file) with the efficiency and
>flexibility of a language extension.
>
>   For instance, only Zortech's compiler correctly (IEEE 754) implements
>   == and != (others set the exception bits incorrectly if one operand
>   is a NAN). Do you really want to do isequal(a,b) instead of a==b?
>
>I would want neither. The behavior of operator== on NaN's should be
>left undefined. If you care to know whether operator== is operating on
>a NaN, you should simply test beforehand:
>
>	if(isnan(x)||isnan(y)) { ... }
>	else if(x==y) { ... }
>
>Sadly, this is a losing battle. NCEG seems to be determined to go down
>this route of adding lots of IEEE specific, complicated, useless
>operators, and the C++ language is likely to follow suite.
>
>				Thomas.

I'm not sure I understand - why is better to leave the effect of NaN's
on operator == undefined?  Why do you see NCEG as losing battle? 
What do you really have against adding features that would benefit
people like me who are doing numerics programming?  Your note seems to
assume that I would know why "it's not time to leave behind non-IEEE
floating point.  What exactly do non-numerics programmers have to lose
with IEEE floating point?  Maybe Walter Bright could tell us what the
reaction is to Zortech C++.  Is there a deluge of criticism from
non-numerics programmers?  Or maybe they aren't even aware of (and
don't care about) the NCEG extensions.  And maybe the numerics