HDTenEightyP/NetNews huggingface dataset:
From: shirleyk@qualix.com (Shirley Kumamoto)
Subject: Re: C++ 3.0 for SPARCs?
Reply-To: shirleyk@qualix.com
Organization: QUALiX Group, Inc.
Date: Wed, 2 Sep 1992 23:10:31 GMT

In article 3272@noose.ecn.purdue.edu, kudva@ecn.purdue.edu (Gautham K. Kudva) writes:
> Hi,
> 	Our research group has recently started using C++.
> We do most of our development work on Sun SPARC workstations.
> So far we've been going with cfront 2.1, and we'd like to upgrade
> to C++ version 3. Our primary reason for upgrading is Template
> support. Does anyone have experience with any cfront compliant 
> C++ compilers with template support for Suns? In particular how 
> about USL C++ 3.0? Any comments or suggestions are greatly 
> appreciated. 
> 
> Please post or e-mail me at kudva@ecn.purdue.edu. If there's
> sufficient interest, I'll summarize.
> 
> Thanks much in advance,
> Gautham Kudva


The Qualix Group provides another commercial 3.0 cfront (from
Solbourne Computing) for SPARC stations.  Its a full function
version of the AT&T C++ Language System Release 3 and translates
into C source code.  If you would like more information,
let me know.

Regards,

Shirley Kumamoto
Product Manager
Qualix Group
1900 S. Norfolk St. Suite 224
San Mateo, CA 94403-1151
voice: (415) 572-0200
fax:   (415) 572-1300
email: shirleyk@qualix.com
From: cyberman@toz.buffalo.ny.us (Cyberman)
Newsgroups: comp.lang.c++
Subject: Re: malloc or new in c++
Date: 2 Sep 92 01:44:06 GMT
X-Maildoor: WaflineMail 1.00r


     -=> Chuang He spoke of "malloc or new in c++" <=-
    To All at 08-31-92  19:44
 CH> I have written a program by using C++. The compiler is Sun C++ 2.1. I
 CH> find a very interesting thing. I find two structure pointer set by
 CH> malloc or new have the same address. That means if I change the content
 CH> of one pointer pointing to will also change the other's. But these two
 CH> pointers are unrelated. I don't know why. Does this mean that I use to

 The FAQ states NOT to use malloc in C++ programs it's thier only
 for backwards compatibility [ie compile older files on a C++
 compilor].

 CH> much new or malloc that no more memory I can  use? Could anyone tell me
 CH> about how many memories can one program use, I mean use by new or
 CH> malloc. My machine is Sparcsation-SLC. The system is SunOS 4.1.1. It
 CH> would be appreciated that someone can tell me the reason and the
 CH> solution.

Yes use ALL new and delete statements and eliminate all malloc
and free function calls!  This will more than likely solve at
least 1 potential problem.

 CH> Please send me an email. I do not read this newsgroup quite often.

Sorry I can't do that with my current mail program.  I hate it
when that happens.

        Stephen Cyberman@Toz.Buffalo.NY.US
        Scripted at Tue  09-01-1992  00:24:50

... Initialise reality before use.
--- Blue Wave/QWK v2.10
From: pete@genghis.borland.com (Pete Becker)
Newsgroups: comp.lang.c++
Subject: Re: Generic types
Date: 28 Aug 92 16:39:46 GMT
Article-I.D.: genghis.1992Aug28.163946.497
Organization: Borland International
Originator: pete@genghis.borland.com

In article <l9scgqINNh7u@exodus.Eng.Sun.COM> obourdon@France.Sun.COM (Olivier Bourdon - Sun ICNC) writes:
>Let's assume I have two different types of objects (classes)
>//-------------------
>class complex {
>public:
>	int i,j;
>	...
>	void Print();
>};
>//--------------------
>class string
>public:
>	char *str;
>	...
>	void Print();
>};
>
>and I also have a double linked list
>//-----------------
>class list {
>	void *element;
>	list *next, *prev;
>	void Print();
>};
>
>then I woul like to do something like :
>void list::Print() {
>	while (this->next!=NULL)
>		this->elem->Print();
>		...
>}
>

	There are two (at least) ways to do this, depending on what this list
class is really supposed to do.  If each instance of a list will only hold one
of these types of objects, then the way to do it is with a template:

	class ListBase
	{
	protected:
	    void *element;
	    list *next, *prev;
	public:
	    void insert( void * );
	    virtual void Print() = 0;
	};

	template <class T> class List : public ListBase
	{
	public:
	    void insert( T *item ) { ListBase::insert( item ); }
	    void Print();
	};

	template <class T> void List<T>::Print()
	{
	ListBase *current = this;
	while( current != 0 )
	    {
	    cout << *(T *)(current->element) << endl;
	    current = current->next;
	    }
	}

(Although I'd probably put the iteration in the base class, and use a function
to actually print the element).
	Or, if this list is going to have to hold both types simultaneously,
then both types must be derived from a common base class:

	class ListElement
	{
	public:
	    void show();
	};
 
	class Complex : public ListElement
	{
	...
	};

	class String : public ListElement
	{
	...
	};

	Now the list class should hold pointers to ListElements rather than
pointers to void.
	--Pete
Newsgroups: comp.lang.c++
From: adk@Warren.MENTORG.COM (Ajay Kamdar)
Subject: Re: Destruction of temporaries
Organization: Mentor Graphics Corp. - IC Group
Date: Mon, 31 Aug 1992 16:29:15 GMT

In article <rmartin.715101472@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>ark@alice.att.com (Andrew Koenig) writes:
>|
>|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!
>|-- 
>
>No, I want a warning every time a temporary gets converted into a
>pointer.  
>
>In your example:  Given String::operator char*(); 
>                    and String String::operator+(const String&);  : 
>
>String a,b;
>char* c = a+b;
>
>An implicit conversion to char* takes place on a temporary.  A warning
>should be possible.  
>

But what if operator char* () is coded as follows:

String::operator char*()
{
    char *ncptr = new char[strlen(d_cptr) + 1];
      // d_cptr is the data member pointing to String's char* representation
    strcpy(ncptr, d_cptr);
	return ncptr;
      // reclamation of newed memory is somehow taken care of
}

I wouldn't want the compiler to issue warnings in such a case, irrespective
of whether operator char*() was called on a temporary or not.

- Ajay

-- 
I speak for none but myself.

Ajay Kamdar                               Email : ajay_kamdar@mentorg.com
Mentor Graphics, IC Group (Warren, NJ)    Phone : (908) 580-0102
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: Comparison chart of C++ dialects?
Date: 3 Sep 1992 00:20:26 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu
Keywords: chart C++ dialects

In article <9xkng3+.nagle@netcom.com> nagle@netcom.com (John Nagle) writes:
>      Does anyone have a chart that shows, side by side, the differences
>between the various dialects of C++?  I'd like to see at least Object C,
>Objective C, C++ per Strostrup's first book, C++ per the current AT&T
>based products, and C++ per Strostrup's second book.  Oh, and the GNU
>product.  

The first two are not dialects of C++ in any way.

The current AT&T based products (cfront 3.0 and later) are roughly the
ARM minus exceptions and plus a few bugs and minor unimplemented features;
roughly the same is true of Gnu C++ (alias g++).

The ARM also includes exceptions.

Stroustrup's first book didn't have multiple inheritance, didn't have
"protected", or overloading of operator new.  You had to use the
"overload" keyword to indicate that a function was overloaded.  There were
many other differences.


--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.lang.c++
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Is there a way to flag errors when an automatic array is returned
Date: 25 Aug 92 22:30:32 GMT
	<1992Aug25.135401.17891@bnr.ca>
Reply-To: tmb@idiap.ch
Followup-To: comp.lang.c++
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: holiday@bnr.ca's message of 25 Aug 92 13:54:01 GMT

In article <1992Aug25.135401.17891@bnr.ca> holiday@bnr.ca (Matthew Holiday) writes:

   I'm not sure that it would be possible to verify at compile time that a returned
   pointer isn't a pointer to a local variable.  It is possible to determine this at
   run time -- just check all returned pointers to verify that the address isn't
   within or below the stack frame about to be destroyed (you may also need to check
   that it's within the stack area, so that you don't accidentally trap on valid heap
   pointers, if the heap is below the stack in the address space, etc., etc.).  It's
   probably about as expensive as run-time array bounds checks, which aren't in C or 
   C++ either -- they don't fit the C/C++ design philosophy.

I suspect array bounds checks are not in C++ because they would be
virtually impossible to add in a backwards compatible fashion. At the
root of the problem is the fact that C "pointers" are used for
multiple purposes, including displaced arrays and locatives. In
languages that support them, array bounds checks can usually be
disabled locally or optimized away, so there is no great cost
associated with them (and they are _very_ useful). I suspect that in
the long run, emulating array bounds checks in C++ classes is going to
be less efficient than if C++ supported them as a built-in.

Checking against returning pointers to automatic variables, however,
is very difficult in most languages. The situation is not at all
analogous to array bounds checks. The reason is that you might also
"return" pointers by storing them inside other data structures that
you return, or even via global variables. The solution to this problem
adopted by most programming languages is to use a combination of
copying and garbage collection. Small data structures are allocated on
the stack and copied upon return, while large data structures are
allocated on the heap and cleaned up via a garbage collector if it
turns out that they are no longer needed after the function returns.

(Some modern language implementations have done away with the stack
altogether, allocating even "stack frames" on the heap; the jury is
still out on whether that is a good idea.)

					Thomas.
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 29 Aug 92 15:41:22 GMT

hosken@spss.com (Bill Hosken) writes:

>The rule "avoid goto" does not stop anyone from writing confusing
>code.  It probably makes some people think more about the code
>they write when seeking alternatives to the goto, but taken alone
>it does little good.  

I don't agree.  Taken alone, it forces your code to have a "known"
structure.  This doesn't mean that the code is "good code", it just
means that there are some basic rules that the reader/maintainer can
depend upon.  This have significant value.

>A better rule would be "Be prepared to give a clear and convincing
>argument that the code is correct". 

But what is "correct code"?  Code that works?  I can write code that
works, but is unmaintainable.  If all we want to produce is "code that
works", then the nightmares which have plagued us from the late
sixties on are sure to continue.

What we want is:

	Code that works.
	Code that is maintainable.
	Code that is reusable.
	
Each of these three aspects requires thought and effort on the part
of the designer.  Moreover, the easiest of the three tasks, is the
first.  Any high school comp-sci geek can cajole a bunch of program
statements into working.  But to write code which others can
understand and eaily alter, or which others can re-use in a different
context takes thought, planning and work.

Now, there are some rules which we have learned over the years which
help this process.  One of them is "don't use gotos", another is "use
single-entry, single-exit constructs".  If we follow these rules, then
we can concentrate on the job at hand, i.e. the correctness,
maintainability and reusability of our code.  But if we ignore those
rules, then we add more variables to the problem we are trying to
solve.  And if we break the rules, and provide justifications, then we
have expended effort in the wrong direction.

--
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: svan@isy.liu.se (Jonas Svanberg)
Newsgroups: comp.lang.c++
Subject: Re: Callbacks - C++ needs an extension?
Keywords: callback
Date: 30 Aug 92 18:02:48 GMT
Reply-To: svan@isy.liu.se
Organization: Linkoping University

I acknowledge checker@acf5.NYU.EDU (checker) for a nice solution
to the callbackproblem:

Every class that want to receive direct callbacks must declare an
own callback class which inherits from some sort of systemclass
CallBack or whatever. In this derived class one defines a new
constructor and overloads one memberfunction. These new member-
functions contain typinginformation about the receiver of the 
callback, so this will work and it is safe. 

This can be nicely done with templates I suppose, but it still
seems like hard work to me.

I have got another solution in comp.windows.open-look from 
imp@solbourne.com (Warner Losh):

> In OI, you can regstier a C or a C++ style callback.  Just an
> overloaded call.  For example,
>	OI_menu_cell *cellp;
>	MyClass	     *mcp;
>
>	// call ::foo when button activated.
>	cellp->change_action( &foo );
>
>	// call MyClass::bar when button activated
>	cellp->change_action( mcp, (OI_action_memfnp) &MyClass::bar );

My presumption is that the type OI_action_memfnp is a pointer-to-member-of-
-baseclass-of-MyClass. My question is:

Is it safe to make the call (obj->*membfun)() when both the obj* (of class
A) and the membfun* have been casted from respectively:
1. a pointer to a class derived from A and (the obj*)
2. a pointer to a member of a class derived from A (the memfun*)
?

Cast #1 above can be done implicitely of course, but #2 has to be
done explicitely if I have understood things correctely...

--------------------------------------------------------------
 Jonas Svanberg
 Department of Electrical Engineering
 Linkvping University
 S-581 83 Linkvping, Sweden             Email: svan@isy.liu.se
--------------------------------------------------------------
From: brennan@hal.com (Dave Brennan)
Newsgroups: comp.lang.c++
Subject: Why is cfront to stupid to compile this?
Date: 2 Sep 92 23:29:40 GMT
Organization: HaL Computer Systems, Austin, TX
NNTP-Posting-Host: yosemite.hal.com

Attempting to compile this with cfront 2.1.03 08/31/90 reports:

"foo.cc", line 8: error:  foo::operator delete() declared with 
          external linkage and called before defined as inline
Compilation failed

class foo
{
  static void operator delete (void *);
};


inline void
foo::operator delete (void *)
{
}

Why, why, why??  This is just plain stoopid.  Why does cfront think that
declaring a class results in an inline call to the destructor?  Other
compilers can handle this.  Who can I report cfront problems to anyhow?

--
Dave Brennan                                      HaL Computer Systems
brennan@hal.com                                         (512) 794-2855

Visit the Emacs Lisp Archive: archive.cis.ohio-state.edu:pub/gnu/emacs
From: daniel.edelson@goudurix.inria.fr (Daniel Edelson)
Newsgroups: comp.lang.c++
Subject: Re: risky inline
Keywords: inline, safe programming
Date: 28 Aug 92 08:34:50 GMT
Reply-To: Daniel R. Edelson <edelson@sor.inria.fr>
Organization: INRIA -- Institut National de Recherche en Informatique et Automatique -- Rocquencourt, France

In article <1992Aug27.142700@uni-paderborn.de>, trachos@uni-paderborn.de (Konstantin Trachos) writes:
|> 
|> Consider folowing example:
|> 
|> // Interface C.hxx -----------------------------
|>    class C{
|>           int a() {return 0;}	// OK
|>    inline int b() {return 0;}	// OK
|>           int c();		// ...
|> 	  int d();		// ...
|>    };
|> 
|> // Code C.cxx ----------------------------------
|>    #include "C.hxx"
|>    inline int C::c() {return 1;}// !
|>           int C::d() {return 0;}// OK
|> 
|> The Problem is, that #including C.hxxin your main file
|> will make the cfront handle the C::c() as a function-call
|> instead of expanding the code.
|> You can also build more .libs including code invoking C::c().
|> But the linker will fail, because he is going to miss c__1CFv.
|> 
|> I think, that a safe compiler requires safe Language-rules,
|> not only carefull Programmers.
|> 
|>                                       email: trachos@dat.uni-paderborn.de

According to the draft C++ Standard:
	``A name of file scope that is explicitly declared
	  inline is local to its translation unit.''
Therefore, C::c() has internal linkage, is local to its translation
unit, and is not available outside of C.cxx or any other
implementation file in which it is defined.

When using separate compilation, non-inline functions go
in implementation files, inline functions go in header files.

In this regard, the language rules are safe.

Daniel.Edelson@inria.fr

(Pardon me if I got the wording slightly wrong, I don't have the 
latest draft with me so I referred to the 14 May 1991 draft.)
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: istrstream
Date: 2 Sep 1992 01:13:43 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <1992Sep1.225259.1533@Warren.MENTORG.COM> adk@Warren.MENTORG.COM (Ajay Kamdar) writes:
>Why do istrstream constructors take a char* instead of a const char* ?
>This either stops me from reading a formatted input string (which I get
>as a const char*) as an istrstream, or compels me to cast away the const
>on the string when constructing the istrstream.

This annoys me too.  The reason appears to be that istrstream and
ostrstream are both derived from strstream, and it is the strstream
constructor that requires the "char *" argument.  Still, it would be nice
if this could be avoided.  I despise casting away const, and currently
this is the only place where I feel compelled to do it.  It still may 
not be safe, because of putback.

Depending on the implementation, I suppose that it is possible that
istream::putback(char) might modify the argument to the istrstream
constructor, which could cause trouble if you passed a string argument
and the code modified the string (possibly causing a bus error if the
string is in ROM).



--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: <stdio.h> and <iostream.h>
Organization: TauMetric Corporation
Date: Thu, 3 Sep 1992 17:00:37 GMT

jss@lucid.com (Jerry Schwarz) writes:

>The problems with mixing stdio and iostream is one of syncronization.
>That is since stdio and iostream are each doing their own buffering ...

>If you can arrange for flush to be called at appropriate points
>there is never any problem.

This is OK for output, but you will still have problems with input
(which was not the original question).  For example, this code will
produce bizarre results if input is from a file:

	int i, j;
	while( ... ) {
	    cin >> i;
	    scanf("%d", &j);
	    ...
	}

As Jerry and I both noted, you can call ios::sync_with_stdio() first
to allow mixing.  It is probably best to avoid mixing stdio and
iostream I/O on the same file.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: ciaranst@rossinc.com (ciaran storan)
Subject: C++ for Interactive Unix
Keywords: gcc interactive
Organization: Ross Systems, Inc.
Date: Mon, 31 Aug 1992 00:04:45 GMT


Can anybody tell me if they are using C++, gnu or any other flavour on
386 Unix, interactive preferably. Also any problems, implementation or
use.

Thanks

Ciaran



-- 
<.....................................................................>
<    A Day without laughter, is a day wasted!!. - Charlie Chaplin     >
<.....................................................................>

Newsgroups: comp.lang.c++
From: act@softserver.canberra.edu.au (Cyclops)
Subject: Re: Compuserv offer
Organization: University of Canberra
Date: Tue, 1 Sep 92 06:56:59 GMT

wai@csuvax1.csu.murdoch.edu.au (Julian Wai) writes:

>I've just received my BC++3.1 upgrade and with it an offer to Compuserv
>membership and use for $15.  Can anyone tell me what the rate/per minute to
>Compuserv is?  Is there similar offer in Australia?

A$0.60/min + $A4.00/month membership($14.00/month business/executive account)


-- 
Renrut Werdna			Probable-Possible, my black hen,
				She lays eggs in the Relative When.
				She doesn't lay eggs in the Positive Now
act@ss.canberra.edu.au		Because she's unable to postulate how
Newsgroups: comp.lang.c++
From: kotula@nano.cs.umn.edu (Jeff Kotula)
Subject: help needed w/ Borland C++
Keywords: borland
Organization: University of Minnesota
Date: Sun, 23 Aug 1992 21:36:57 GMT

Hi.  I'm new to Borland C++ and I'm trying to compile a pretty simple
Objectwindows program intended to get my feet wet with the event handling,
etc.  Unfortunately, I'm getting compile errors from \borlandc\classlib\
include\clstypes.h, at line 32.  I suspect I'm just not including something
correctly or something annoyingly trivial like that.

I'd appreciate any pointers...
(Thanks in advance)_
--
-------------------------------------------------------------------------------
jeff                            |     "Dismiss whatever insults your own soul."
kotula@cs.umn.edu               |      		Walt Whitman
-------------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: kotula@milli.cs.umn.edu (Jeff Kotula)
Subject: Desparate plead for help with ObjectWindows
Organization: University of Minnesota
Date: Wed, 2 Sep 1992 01:31:19 GMT


First, let me apologize for posting a question about a specific compiler.
Last time I did this someone, quite rightly, pointed to other venues for
such questions.  Unfortunately I lost that mail message (accidentally
deleted it, I mean), and I would appreciate it if that person could
send me the information again.

On to the problem...

Actually, I have several problems, but I'll start with the worst one.
I have a small ObjectWindows program that is loosely based off of the
example programs provided on owl/examples/steps.  I'm including owl.h.
My directory search path includes \borlandc\include, \borlandc\owl\include,
and \borland\classlib\include.  All this seems fine as far as I can tell,
yet when I compile, HWindow comes up undefined!

I'm guessing there is something different in my project file from the steps
project file.  However, I'm out of ideas.

Yes, I called Borland's support line, but this being for private use, I
can't afford to stay on hold to California (from Minnesota).  I would
give great praise and eternal servile gratitude to anyone who can help me
figure this out.

Thanks for your patience.

--
jeff               |     "We've got to make drastic changes to keep up with the
kotula@cs.umn.edu  |      competition.  That's why I've had these little note
		   |      pads made that say 'quality'."
		   |     "Isn't it spelled with a 'u'?"   --Dilbert
Newsgroups: comp.lang.c++