HDTenEightyP/NetNews huggingface dataset:
From: mbrinn@bbn.com (Marshall Brinn)
Newsgroups: comp.lang.c++
Subject: C++ 3.1 vs. 3.0 vs. 2.2 ....
Date: 22 Jul 1992 13:19:57 GMT
Organization: BBN Systems and Technologies
NNTP-Posting-Host: bbn.com

Could anyone give (or point me to ) a brief description of the language 
differences between the different recent revisions of C++. That is, what 
does a 3.1 compiler provide that a 3.0 compiler doesn't? 3.0 vs. 2.2? 

Thanks.

Marshall Brinn
------------------------------------
mbrinn@bbn.com
BBN Systems and Technologies
(617)-873-2717
Newsgroups: comp.lang.c++
From: maceache@fox.nstn.ns.ca (Tim Maceachern)
Subject: Astronomy program converted to c++
Summary: Want info on astronomy program converted to c++
Keywords: astronomy, program, conversion
Organization: NSTN Network Operations Centre, Nova Scotia, Canada
Date: Mon, 27 Jul 1992 15:17:42 GMT

Sorry for this vague request, but I'm working on a series of models of
physical processes (sedimentation) and am running up against the usual 
problems with endless expansion of programs -- lack of modularity, 
lack of maintainability, etc.  I had read in New Scientist, I believe,
that a much larger Astronomy program, written in Fortran, was to be
ported to an OOP language, probably c++, for the same reasons.  Can
anyone point to rationale or description of this program?

*******************************************************************
*         Tim MacEachern         * Tim_MacEachern@hawk.nstn.ns.ca *
*     Software Kinetics Ltd.     *  or maceache@hawk.nstn.ns.ca   *
* Dartmouth, Nova Scotia, Canada *                                *
*           Opinions expressed are the author's only              *
*******************************************************************
From: jml@taco.visus.com (Jim Large)
Newsgroups: comp.lang.c++
Subject: Re: Efficient 64-bit integer arithmetic
Date: 27 Jul 92 21:30:12 GMT
Organization: Visual Understanding Systems, Pgh PA

In article <1992Jul25.145049.15951@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU  
(John MAX Skaller) writes:
> [...] To get the carry, do 16 bit operations with 32 bit
> result, the high 16 bits are the carry.

But wait!  Do 32 bit operations and use some simple logic to get the carry.
Below are some examples (from long before ANSI or c++, sorry).  Please note
that although I've defined these ops using UNSIGNED longs, most work on either
signed or unsigned.

/*
 * function:    double_inc
 * purpose:     Add 1 to a double integer.
 * inputs:
 *   dst        (unsigned long *) ptr to an array of two longs, LSW first.
 *
 * outputs:
 *   *dst     -- 64 bit value is incremented.
 *
 * returns:     (void)
 */
void double_inc(dst)
  unsigned long *dst;

  /*double_inc*/ {
    (*dst) += 1;
    if ( (*dst) != 0 ) return;
    dst++;
    (*dst) += 1;
  /*double_inc*/ }



/*
 * function:    double_neg
 * purpose:     Compute the 2's complement of a double long by first computing
 *		 its 1's complement, and then adding one to it.
 * inputs:
 *   dst        (unsigned long *) ptr to an array of two longs, LSW first.
 *
 * outputs:
 *   *dst	-- 2's comp of 64 bit value stored
 *
 * returns:     (void)
 */
void double_neg(dst)
  unsigned long * dst;

  /*double_neg*/ {
    (*dst) = ~(*dst);
    (*(dst+1)) = ~(*(dst+1));
    double_inc(dst);
  /*double_neg*/ }



/*
 * function:    double_add
 * purpose:     Adds two "double long" integers
 *
 * inputs:
 *   dst        (unsigned long *) ptr to an array of two longs, LSW first.
 *   src        (unsigned long *) ptr to an array of two longs, LSW first.
 *
 * outputs:
 *  *dst        -- overwritten with result.
 */
double_add(dst,src)
  unsigned long *dst,*src;

  /*double_add*/ {
    int carry = 0;
    register unsigned long tmp;

    tmp = (*dst) + (*src);
    if ( tmp < (*dst) || tmp < (*src) ) carry = 1;
    *dst++ = tmp;
    src++;

    tmp = (*dst) + (*src);
    if ( carry ) tmp += 1;
    *dst = tmp;

  /*double_add*/ }


----------------+------------------+------------------------------------
     |\ /|      |  Jim Large       |  Visual Understanding Systems, Inc.
     | V |      |  jml@visus.com   |  2100 Wharton St.                  
   \_|   |__    |  (412)488-3600   |  Pittsburgh, PA  15203             
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: boolean (was: Re: typedef vs enum)
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 22 Jul 1992 05:17:53 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>	While we're talking of a boolean type (which has two
>values equivalent to 0 and 1), how about a ZERO type?
>
>	Type ZERO only has ONE value---0 of course.

We ALREADY have a type with only one value -- "void".

>	What use is it, you ask?
>
>	Plenty. 0 is very important.
>
>	How often have you wanted to allow assignment
>or initialisation of a class to 0 (but not any other value?)
>
>	For example, if p is a pointer, you can write
>
>	p=0; // null pointer
>
>But if it is a *smart* pointer, you would have to declare
>assignment of say int->smart, and give a run-time error
>if the int was non-zero.

If you want a constructor which could only take one possible value value, you
should use the void type. There *is* a problem in that C++ does not allow named
constructors, and so you have to use the default constructor. One workaround is
the following:

	class Zero {
	   public: operator int() const { return 0; }
	} zero;

	class smart {
	   private: void *p;
	   public: smart(Zero z) : p(z) {}
	   ...
	};

Then you can just use smart(zero) instead of smart(0).
[Alternatively you can just use class Zero {}, but you tend to get spurious
warnings from the compiler because variables of class Zero are never used]
--
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: mat@uunet.uu.net!mole-end
Subject: Re: Novice? question: Designing for multiple inheritance w/ templates
Summary: Problem Domain/Solution Domain
Organization: :
Date: Sat, 25 Jul 1992 06:55:23 GMT

In article <1992Jul23.175814.15356@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> In article <1992Jul21.131054.20622@mole-end> mat@mole-end writes:
> >In article <1992Jul20.152931.8037@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> >> In article <1992Jul19.233851.15525@mole-end> mat@mole-end writes:
> >> 
> >> >...  From what I can tell, virtual inheritance is principally useful
> >> >for importing what might be called `object representation behavior,'
> >> >e.g. printability, special allocation and deallocation, etc.--things
> >> >that are related to the representation OF the object, rather than to
> >> >what the object itself represents.

> >> 	Quite the opposite I find. Its prinicple use is in 
> >> deriving new abstractions from old. 
> >> ...

> >> 	A new optimisation technique (like caching) can be
> >> hooked in, on an object by object basis, at construction time.

> >This is exactly what I was saying.  The thing added by Virtual MI is added
> >not for the sake of what the class represents, but for the sake of the
> >class representation.  ...

> >Or do I misunderstand you completely?
 
> 	Maybe I misunderstand. 
 
> 	IMHO: ALMOST ALL derivation should be public, and ALMOST ALL
> public derivation should be virtual. Inheritance of an abstract
> base class should be virtual and public even more often than almost
> all :-).
 
> 	When using mixins, the abstractions are derived, using
> MI, from each other. They're the "problem domain" stuff aren't they?

No, the examples you give are especially solution-domain.  They come from
programming technology and express programming-type concepts applied to
programmed objects.

Problem-domain stuff includes most of the examples in the popular OO
texts, things that are expressed as `is-a' or `is-a-kind-of-a,' e.g.
`A hardcover book is a kind of a book' (derive hardcover book from
book), `A salaried employee is a kind of employee,' (derive salaried
employee from employee), `A gravel road is a kind of road,' (derive
gravel road from road).

Is it possible to program with mixins for the problem domain?  Yes, it is.
Is the result malleable?  I suspect not.  I haven't examined any large
model built that way, so I'm not sure.  I rather suspect that some of the
inheritance links that get built that way should be `part-of' links
(bi-directional `has-a' links between objects collaborating to implement
the functionality of the object representing the `whole').

This is drifting off into abstract talk; we are better off with examples
and with class-relationship or object-relationship diagrams before us.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: sandy@garfield.cs.mun.ca (Sandy Walsh)
Subject: Any ZINC users out there?
Organization: CS Dept., Memorial University of Newfoundland
Date: Thu, 30 Jul 1992 23:44:10 GMT

If you have used or are using the ZINC Interface Library, I want to talk
to you. I am using it for a large project, and have some subtle questions
for other users. These are not C++ questions (I have a good grasp of that)
but more along the lines of tricks to make life with ZINC easier 
(and use less ram so I don't need overlays!) ...

Thanx in advance,

---
Sandy Walsh - Memorial University of Newfoundland - CS Dept 

I've been carving you, to see what form you take. 
You were hiding in ivory, I just wanted to free your shape.
	- The Tragically Hip 	(sandy@garfield.cs.mun.ca)
From: marke@cpg.trs.reuter.com (Mark Ellis)
Newsgroups: comp.lang.c++
Subject: g++ & gdb compatibility
Date: 27 Jul 92 18:01:47 GMT
Distribution: usa

Simple question:
Does gdb support g++?  If so, what version gdb is req'd?

Thanks,

--
Mark Ellis
Reuters, 1400 Kensington Rd., Oak Brook, IL  60521
marke@cpg.trs.reuter.com
uunet!richsun!marke
Newsgroups: comp.lang.c++
From: mat@uunet.uu.net!mole-end
Subject: Re: const on pass by value
Summary: Const Correctness: A Good Thing
Organization: :
Date: Sat, 25 Jul 1992 07:15:59 GMT

In article <1992Jul24.151010.11969@PacBell.COM>, pjcondi@lepton (Paul Condie) writes:
> Should pass by value arguments be declared as "const" for
> good coding style?  Or is that nit picking?
 
> For example:
 
> void foo (const int a);
> or
> void foo (int a);

It's not nitpicking.  It's part of something called const correctness.
Your program has it or doesn't.  Programs that have it are almost immune
to a certain large family of errors.

You can't have const correctness selectively.  You have it everywhere
or nowhere.

Have it everywhere.  And if you are writing a library or writing utilities,
be sure to have it there.

Read about overloading on  const --and on overloading on `trailing const.'
You'll need them.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Xref: sparky comp.lang.c++:11628 comp.editors:1830
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Having this=0, class-name::main() and tasking in c++
Date: 26 Jul 92 14:48:20 GMT
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ

In article <1DDA4ACFA5BF800C41@ursula.lucas.lu.se> KOSU_MATSB@ROUTH.KOSUFY.LU.SE writes:

> Question #1:	Having a 0 "this" pointer. Standard?

No.  ARM page 176:

	The effect of calling a nonstatic member function of a class X
	for something that is not an object of class X is undefined.

	For example,

		((X*)0)->f();
	
	is not guaranteed to work.  In particular, this will not work for
	virtual functions on any implementation since the information
	needed to find the appropriate virtual function for an object
	of type X is not found at location 0.  Even for nonvirtual
	functions, one should expect this trick to fail eventually...


> Question #2:	class_name::main() & coroutines/threads/tasks in C[++]

> 	a; Im M2 each implementation module have a part 
> 	initializing the module. A similar opportunity to 
> 	initialize a class would be a very powerful tool.

Static data members do quite a bit of what you want.
However, there are problems in getting things to happen in
the right order.  This particular issue has been under discussion
in the standards committee for quite some time, with little progress.

> 	b; The M2 coroutine/task concept is VERY powerful when
> 	making asynchonic programs. Are there any plans to 
> 	incorporate this in C++/C?

Many C++ implementations provide a task facility as a class library.
However, there are a number of different models for how to do tasking
and none of them is clearly so far better than the others for C++
that it has seemed appropriate to include it directly in the language.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++,comp.std.c++
From: jrobie@netmbx.netmbx.de (Jonathan Robie)
Subject: Downcasting and mortal sin (was run-time type checking)
Organization: netmbx, Berlin, Germany
Date: Mon, 27 Jul 1992 08:50:51 GMT

glw@io.uswest.com (Glenn Williams) writes:

>>(John MAX Skaller) writes:

>>class Animal {
>>	int mate(Animal&);
>>};
>>class Dog : Animal {
>>	int mate (Animal&);
>>};

>>We REALLY want Dog::mate(Dog&), but we can't have it.

I'm confused.  I have two animals, and I place them in a cage.
Who knows where these animals come from or what kind they are--
my classes may not have produced them.

Now the program needs to decide if these animals should mate.
I assume that the program will follow the general biological rule
and restrict mating activity to animals of the same type.

I think that we need virtual functions to do this right.  Otherwise
a dog accessed with an Animal pointer will mate any other animal,
but you can't even ask the dog if he wants to mate with anything
other than a dog if you access it with the Dog pointer.

I would think that the program should let the dog decide if this
other animal is the kind he likes.  The mating function might also
be virtual since different animals have different habits--you can't
expect dogs to practice safe sex, for instance.  So the mate() function
for a dog must be Dog::mate().

This seems to need a down cast.

So does any procedure that would attempt to determine if one animal
is the same kind as another.



Jonathan

===========================================================================

Jonathan Robie		jrobie@netmbx.UUCP
Arnold-Zweig-Str. 44	jrobie@netmbx.in-berlin.de
O-1100 Berlin		
Deutschland		Phone:  +37 (2) 472 04 19  (Home, East Berlin)
				+49 (30) 342 30 66 (Work, West Berlin)


-- 
Jonathan

===========================================================================
Organization: University of Illinois at Chicago
Date: Friday, 31 Jul 1992 11:48:59 CDT
From: Henry Young <U23379@uicvm.uic.edu>
Newsgroups: comp.lang.c++
Subject: Is concurrency available in bc++ 3.1 ? msc++?

  I currently have version 2.0 of BC++ but I am debating buying 3.1
I would like to know if they have implemented spawning a separate task that
runs concurrently.   They have such a function documented in 2.0 with the
note that it isn't currently available.  If not, does the latest version of
MSC++ have it?    I would really prefer to not have to set up timer interrupts,
with each process having an interrupt handler..... ;>

              Thanks,
                    - Henry -
From: terryk@terminus.gatech.edu (Terry Kane)
Subject: Re: Probs using GNU and the Libs :-(
Organization: Georgia Tech College of Computing
Date: Fri, 24 Jul 1992 13:58:23 GMT

Oliver.Otto@f2006.n241.z2.fidonet.org (Oliver Otto) writes:
>I am using the GNU C++ compiler under OS/2 and have lot's of trouble with
>the libaries. Some days ago when I start installing GNU C++ all went fine
>but know I always get this message

>D:SPRACHE\GCC\g++include-/_G_config.h:72: warning: unknown escape
>sequence'\S'

This is a symptom that comes from the mild brain deficiency of swapping
between forward and back slash for pathnames.

I found that removing the debug switch from the cc cmd line (in the make.ini
supplied by Kai Uwe-Rommel for dmake & emx gcc) eliminated the problem.

Remove this, and the (erroneous) debugging source file info won't be
generated.  That's not a problem anyway, since gdb has not been ported
for this compiler!  This bug was probably not found since gdb ain't
there.

If you need gdb, suffer the pain :-), and use emx gcc for os/2 2.0.
(The pain is using a non-native program loader, name=?run?
e.g. "c:\> run myprog", although you can bind the loader into
a final executable.)

-------------------------------------------------------------------
Terry Kane (terryk@cc.gatech.edu)
-------------------------------------------------------------------
I am a .sig file virus. Copy me into your signature file please.
Newsgroups: comp.lang.c++
From: jonas@beppe.ericsson.se (Jonas Nygren)
Subject: Re: iteration without iterators (and a questio
Reply-To: jonas@beppe.ericsson.se
Organization: Ericsson Telecom AB
Date: Thu, 23 Jul 1992 07:15:35 GMT

In article 46960006@hpscit.sc.hp.com, weeks@hpscit.sc.hp.com (Greg Weeks) writes:
>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.
>    }
.
.
.
>>This discussion is leaning in the direction of messy
>implementation-dependent considerations.  Is there some nice way to avoid
>this?
>
>Greg Weeks


One solution might be to let the class describing col define its own data
structure, cursor, and then let Item contain one such data member. 
On each call to first and next col will update pi's cursor. This solution
requires that pi is given as an argument to first in the above example.

/jonas
From: weh@abasin.dr.att.com (William E. Hopkins)
Newsgroups: comp.lang.c++
Subject: reference to C++ assertion macro package?
Keywords: C++, assertions, precondition, postcondition, invariants
Date: 23 Jul 92 20:12:09 GMT
Organization: AT&T Bell Laboratories

I can't recall the reference to an article I read that described a macro
package that provided assertions for C++ in the flavor of what is in
Eiffel (can I write ``Eiffel'' in this newsgroup, or should I use
``*ffel'', ``eye-full'', ``I fell'', or some other appropriate code?).

My recollection is that the package was called A++.  I thought I saw it in
some C++ Conference proceedings, but it isn't in the ones I have here.
I also couldn't find it via a rather broad-based electronic search.

I would also appreciate any pointer for obtaining the package itself.

	Thanks in advance!

			Bill Hopkins
Newsgroups: comp.lang.c++,comp.std.c++
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Newsgroups: comp.lang.c++
Subject: Re: strdup() Was: Re: Renew?
Date: 31 Jul 92 14:11:49 GMT
Reply-To: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Organization: Bell-Northern Research, Ottawa, Canada

In article <9221219.25266@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU
(Fergus James HENDERSON) writes:
> hansen@pegasus.att.com (Tony L. Hansen) writes:
> 
> >By the way, at least one person has posted a poor version of strdup() which
> >didn't check the return value of new. Here's my contribution. As you can
> >see, it is a very straightforward function:
> >
> >    #include <string.h>
> >    char *nstrdup(const char *s)
> >    {
> >	if (!s) s = "";
> 	^^^^^^^^^^^^^^^
> >	char *ret = new char[strlen(s) + 1];
> >	if (ret) strcpy(ret, s);
> >	return ret;
> >    }
> 
> If you ask me, the check for ``if (!s) s = "";'' is a really bad idea.
> If the program passes you a NULL pointer, then you do NOT want to silently
> correct it, you want to let the programmer know that an error has occured.

This is a matter of whether or not you consider this to be an error.
In C, it was annoying that realloc did not treat NULL as a request for
malloc.  It is personal preference whether this should be allowed in realloc 
or handled in a higher-level macro.  Similarly, if free(s) did nothing if
s was NULL, it would have saved a lot of bugs due to people forgetting to do
if (s) free(s).

This case is slightly different, because there is more than one obvious
way to handle 0 legally:  return 0 or return a pointer to "".  Personally,
I don't consider the gain made by treating 0 input as an error to be worth
the pain.  Anyone who wants to write robust code will use your less efficient
form.  And anyway, the strcpy(ret,s) instead of memcpy(ret,s,len) is a far
more expensive coding luxury.  (Set len = strlen(s) + 1 before the new).

Stuart

: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
Newsgroups: comp.lang.c++
From: nagle@netcom.com (John Nagle)
Subject: Re: New C++ type: boole
Date: Mon, 27 Jul 92 17:58:04 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

      The notion that new reserved words should be added to C++ by 
beginning them with a digit seem flawed.  Admittedly this avoids
clashes with existing names.  But it suggests a move in a strongly
undesirable direction.  Will the next new reserved word begin with
a digit too? 

      It also may break programs which process C and C++ source text
(formatters and such) because it changes the syntax of the basic
lexical token.

      "true" and "false" are the way to go.  Compatability of old 
programs can be handled by a simple trick.  Compilers should
consider any form which defines "true" or "false" as a constant
and effectively gives "true" a value of 1 or "false" a value of 0 to
be a warning-only error.  

      Thus, a program which has

	#define true 1

      or

	const char true = 1;

will be automatically converted to the use of "boole" constants, because
the old declarations will be ignored, with a warning.  Uses of "true"
and "false" in the program in integer contexts will be automatically
upgraded to "int", so the program will compile and function as before.

      Thus, "true" and "false" are fixed values, not redefinable.
Unusual definitions of "true" and "false", such as

	const char false = -1;

should be considered illegal redefinitions of a reserved word.  Such
usage is rare in C/C++, since it's incompatible with the usual operators.

       This approach will get "boole" into the language without pain, and
without introucing strange symbols for the boolean operators.

					John Nagle
Newsgroups: comp.lang.c++
From: mittle@watson.ibm.com (Josh Mittleman)
Subject: Re: Conversion operators and typedef names
Date: Tue, 21 Jul 1992 18:51:37 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center
Keywords: Microsoft C++ new error bug


> class MyTime {
>   ...
>   operator time_t(void);   // Does this make you queasy?
>   ...
> };

No; why do you think it should?

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
Newsgroups: comp.lang.c++