HDTenEightyP/NetNews huggingface dataset:
From: crash@ckctpa.UUCP (Frank "Crash" Edwards)
Subject: Re: BC++ 3.0 TDW and Windows 3.1
Date: Thu, 8 Oct 1992 01:59:03 GMT
Reply-To: crash%ckctpa@tct.com (Frank "Crash" Edwards)
Organization: Edwards & Edwards Consulting

mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>In article <tpenttin.718029822@majakka.uku.fi> tpenttin@majakka.uku.fi (Tommi Penttinen) writes:
>>"Can't load WINDEBUG.DLL". That's what my TDW tells me when I try to debug
>>anything.. And I'v put WINDEBUG.DLL on the dos command path as told in a
>>readme file on the distribution disk. So, what's the problem? Doesn't
>>BC++ 3.0's Turbo Debugger for Windows work with Windows 3.1?
>
>No, it doesn't.  There was at one time a patch for this, but now the
>suggested fix is to update your compiler suite to the current version.
>
>[I don't know if Borland is still providing the patch to 3.0 users or
>not -- I never got the patch; I merely waited for the new release.]

I got the file TD386.DLL off of their bbs (14.4 V.32bis) and installed
it as described in the README.  As of three or four days ago it was
still there.  The BBS number is 408-439-9096, 1200/2400/9600/19.2K.

>Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

-- 
Frank "Crash" Edwards            Perceptual Technologies, Inc.
Fax:  813/786-6526               [Our office is moving; watch this space
Home: 813/786-3675               for the new phone number.]
Newsgroups: comp.lang.c++
From: dcb@slsvitt (David Binderman 3841)
Subject: Nested classes & Inheritance
Organization: SEL-Alcatel LTS Dept. US/ES
X-Newsreader: Tin 1.1 PL4
Date: Fri, 9 Oct 92 11:37:31 GMT

Hello there,

Given the following code

class A {
public:
     class B { };
};

class C : public A {
    class D {
        B y;
    };
};

Then does the declaration of y require A::B or only B ?
Or, is B accessable from D directly ?

The ARM, Stroustrup 2 & Lippmann 2 didn't help in this case.

Regards
--
David C Binderman     Dept US/ESI, Bau 60, SEL-Alcatel AG, Lorenz Strasse 10,
D-7000 Stuttgart 40, Germany      dcb@us-es.sel.de   Tel: +49 711 821 3841
If you lie to the compiler, it will get its revenge
From: pete@genghis.borland.com (Pete Becker)
Newsgroups: comp.lang.c++
Subject: Re: Const and Reference
Date: 9 Oct 92 17:50:08 GMT
Article-I.D.: genghis.1992Oct9.175008.9517
Organization: Borland International
Originator: pete@genghis.borland.com

In article <1992Oct9.034720.832@debbie.cc.nctu.edu.tw> c7821027@csie.nctu.edu.tw (Shih-Hao Liu) writes:
>
>Sorry, I have make some mistake in posting this question.
>The prog should be modified as following.
>

	That makes much more sense!

>: #include <stdio.h>
>: main()
>: {
>:     char a = '-';
>:     const char &b = a;
>: 
>      a = '+';
>      printf("%c\n", b);
>: }
>: 
>: What output should we excepted?
>: The CC compiler on Sun yield '+', but gcc give a '-'. Which correct?
>: 
>: Shih-Hao Liu
>: c7821027@csie.nctu.edu.tw
>: 
>: 

	'b' is a reference to a const char, which means that you cannot use
'b' to modify the char that it refers to.  It does not say that this char
will never be modified.
	On page 154 the ARM describes this situation:

	If the initializer for a reference to type T is an lvalue of type
	T ..., the reference will refer to the initializer.  Otherwise, if
	and only if the reference is to a const an object of type T will be
	created and initialized with the initializer.

	Since 'a' is an lvalue, the first sentence applies, and assigning to
'a' changes the value that you see when you access 'b'.
Newsgroups: comp.lang.c++
From: adk@Warren.MENTORG.COM (Ajay Kamdar)
Subject: Re: Proposal: Preconditions and PostConditions in C++
Organization: Mentor Graphics Corp. -- IC Group
Date: Tue, 13 Oct 1992 16:37:55 GMT

In article <1992Oct12.135729.9116@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:

>
>What is one real example where private bases give you an advantage over
>including a member object?

One real example where private bases have an advantage over including a
member object is when the class you are using for implementation has
protected data/member functions which you need to access. Including a
member object won't work.

Consider the following code fragment:

  class A {
  protected:
    int  d_i;
  };

  class B : private A {
  public:
    void setVal(int i) {d_i = i;}    // OK. Can access protected member.
  };

  class C {
  private:
	A  d_a;
  public:
    void setVal(int i) {d_a.d_i = i;}// Not OK. Cannot access protected member.
  };


- 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: donb@cco.caltech.edu (Don Brotemarkle)
Newsgroups: comp.lang.c++
Subject: Why Hybrids appear so Pure
Date: 16 Oct 1992 18:41:35 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: alumni.caltech.edu

In some ways it pays to get older..

I have been around Object Programming since 1980 (Simula), 
and have gotten especially deep into it since 1985(MacApp) and 
1987(C++).  I am now able to calmly design class heirarchies 
and overload operators with a lot less religious fervor than 
five or six years ago.  

But I just recently learned something.

Systems that descend spiritually from SmallTalk, (like
the Macintosh and MS Windows), are built on hybrid object
languages (Object Pascal, C++) .  Yet they continue to behave
and to present the appearance of "pure" or that they are at
runtime dynamically interpreting events.

When you look into it, there is always a big case statement 
(or equivalent service provided by the system) to handle the
OS events and to pass them on in terms of the hybrid language's
member functions.

I finally found a statement of what is going on in Lippmann's
"The C++ primer" (recommended) where it was slipped
inconspicously in at the end of a chapter on object programming.
These systems (Mac and Windows) have allowed the metaphor of 
object programming (encapsulation,inheritance) to emerge beyond 
just being a software engineering methodology into being a
model for the user's perception of the system.

In other words, SmallTalk allowed the user to have the same view
of the programming structures as the programmer.  And this was
a success.  The Macintosh kept this through a hybrid approach.
But if you're beginning a project in  C++ where there isn't 
a "native" user interface strategy in place, there needs to 
be an effort made to consider the user's metaphor (view) when 
designing your objects.

SmallTalk, in short, succeeded based on a good trick: every
application is really just an inspector of some high-level object.
If I write a new system, I have to respect that same trick. 

Well, anyway, this settled a nagging confusion for me about
the user-level appearance and behavior of "pure" versus hybrid
object systems.

Don Brotemarkle, donb@alumni.caltech.edu
From: ANDREW@odin.uniras.dk (Leif Andrew Rump, Software Engineer, UNIRAS A/S)
Newsgroups: comp.lang.c++
Subject: Does somebody have a list of known bugs/limitations in GNU C++
Date: 7 Oct 1992 04:51:57 -0500
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

I've run into quite a few problems in GNU C++ v2.2.2!
Do anybody out there have a list of known bugs and
limitations in GNU C++ they could mail me?


Andrew

Leif Andrew Rump, UNIRAS A/S, 376, Gladsaxevej, DK-2860 Soeborg, Denmark
UUCP: andrew@odin.uniras.dk, Phone: +45 31 67 22 88, Fax: +45 31 67 60 45

Plan:
begin 644 plan
M5&AI<R!S<&%C92!I<R!U;FEN=&5N=&EO;F%L;'D@8F5E;B!L969T(&)L86YK
K+BXN"@H)"0D)"4%N9')E=PHH0V]P>7)I9VAT("AC*2!$;W5G(#$Y.3(I"FYK
 
end


Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Only 'public' stuff in .h file?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sun, 11 Oct 1992 13:01:38 GMT

In article <1atb5oINN6d0@hpsdlss3.sdd.hp.com> mark@sdd.hp.com (Mark Overton) writes:
>I'm really hoping that C++ will let me totally hide all implementation
>info from the "user" of a class.  This means the .h file for the class
>must contain solely the public interface, and not contain any private
>members (which would be in the .cpp file).
>
>Is such separation of public and private members possible?

	Yes, almost. The way to do it is have an abstract class,
which has only the public interface. Of course, to actually construct
concrete objects, this doesn't work, but its the best possible
at the moment.
>
>I'm afraid the answer is 'no' because such separation would require that the
>layout of memory for a source file be decided at link-time instead of at
>compile-time (the compiler wouldn't know how much space to allocate for
>private instance-variables).

	I used a version of Modula II that could do this properly.
It use the 'old' computed size of the object, taken from the
implementation and silently stuck into the pre-compiled
interface. If it turned out you'd changed it, the module was
compiled again.

	However in C++ there is a more serious problem in this
regard, and that is that private (and protected) routines
are considered for matching, and if one of these is best match
you get an access error. Private routines are still visible,
even if not accessible.
>
>So it seems to me that 60's compiler+linker technology has trapped us into
>a serious violation of the principle of information-hiding.  I don't want
>to force all the users of my container class to recompile their files just
>because I added a private variable, or switched from binary trees to
>skip-lists.
>
>Please tell me I'm wrong!
>

	I agree, despite the justification for private members being
considered visible but inaccessible given in the ARM. The problem 
can be particularly nasty with private constructors with one argument,
since these are inaccessible automatic conversions as well.
(This can be fixed by adding a dummy argument)

	It should at least be possible to have private member
functions which are not declared in the interface---static
functions do not suffice as helpers.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: virtual base classes
Keywords: virtual
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 14 Oct 1992 11:56:12 GMT

In article <1992Oct9.112319.16876@cs.nott.ac.uk> gas@spitfire.xtel.co.uk (Alan Shepherd) writes:

>class foo2: public virtual Object {...
>Object* oneFoo2 = new foo2();
>aFoo2 = (foo2) oneFoo2;

	This should read

	aFoo2 =(foo2*) oneFoo2;

>
>gcc complains like so:
>cannot cast up from virtual baseclass `Object'

	Strange that it says it cannot cast up. What you are trying
to do is called *downcasting* in my books. Dont. Downcasting
from a virtual base is illegal. Downcasting from non-virtual
bases is problematic :-)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: hartzman@kilroy.Jpl.Nasa.Gov (Les Hartzman)
Subject: Object instance inside of a static member function?
Followup-To: hartzman@kilroy.jpl.nasa.gov
Keywords: static member function, object instance
Organization: Jet Propulsion Laboratory, Pasadena, CA
Distribution: na
Date: Sat, 10 Oct 1992 03:16:12 GMT

I am new to C++, so please bear with.

I have a class A that has a static member function in it.  With in the static
member function I try to create an instance of another class, B.  B is not
contained within A; the closest they get is the same header file.  The static
member function is also a declared private in A, but I don't believe this
should matter, since its only called from within A.

The error I keep getting is from the linker complaining about an unresolved
external.  I know it is the attempted creation of the B class object, since the
error goes away when I comment out the declaration of the B object.

Any help would be greatly appreciated.  Thanks.  Please email responses.

Les



-- 
Les Hartzman                hartzman@kilroy.jpl.nasa.gov
Jet Propulsion Laboratory   M/S 238-528    (818) 354-5964
4800 Oak Grove Dr., Pasadena,  CA.  91109
Newsgroups: comp.lang.c++,comp.std.c++
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: NULLing a pointer
Date: Thu, 15 Oct 1992 20:31:19 GMT
Organization: Security APL, Inc.

In article <WARSAW.92Oct15103415@anthem.nlm.nih.gov> warsaw@nlm.nih.gov (Barry A. Warsaw) writes:
>On a related topic, I've always wondered why operator delete was
>required to take a void* as its first arg and not void*&.  I
>understand why a deleted ptr is not nulled by default (and agree with
>the reasoning), but I should be able to add that functionality to my
>classes if I'm willing to incur any associated costs.  With
>delete(void*), I can't even do it.

Because there is no guarantee that the pointer being deleted has the same
bit format as a void *.  If you try,

class Foo {...};
Foo *p;
void *& rP = p;

you should get an error message from your compiler; the types are not the
same.  But this is exactly the assignment implicit in calling operator
delete(void *&);
From: Tarasov.Eugene@f1.n100.z60.wlink.nl (Tarasov Eugene)
Newsgroups: comp.lang.c++
Subject: Help: C++ and C grammar required
Date: Tue, 13 Oct 1992 05:15:07 -0100

Organization: Institute of Informatics Systems, Novosibirsk

Help!
   I need BNF description of C++, ANSI C, and KR C as well. Where can I
get it from, or at least yacc definitions?
   GNU C++ yacc definitions  unacceptable  beacuse  they  contact  with
BISON too much and too closely.
   Is there pure context-free C++ grammar at all?

Thanks,
  Eugene Tarasov
  sem@isi.itfs.nsk.su
From: mxb8@po.CWRU.Edu (Matthew Bakaitis)
Newsgroups: comp.lang.c++
Subject: Extended Mem use on IBM clones using C/C++
Date: 9 Oct 1992 03:47:44 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
Reply-To: mxb8@po.CWRU.Edu (Matthew Bakaitis)
NNTP-Posting-Host: thor.ins.cwru.edu


-Sorry about the initial (no subject) post.  I reposted to try to 
keep the subject line relevant...provided this works...

	Currently, I'm using an IBM clone with 8 meg of extended memory
to do some statistical analysis for some (boring) classes...I decided to
try to use a big sample size, but naturally ran into a problem with making
my arrays larger than allowed than the Turbo C++ 1.0 compiler I'm using.
	I tried to use the command _OvrInitEms and _OvrInitExt given in
the library reference manuals, but I couldn't get either of them to work.

So, two things:

1)  Are there any books out there that are specifically aimed at programming
	in C/C++ that deal with using this memory?
2)  Are the library functions given in the Borland manuals not the thing to
	use?  Are there better PD libraries to use?  etc.

	Notes:
	I am a decent programmer, but it is not my true vocation it seems.
I am competent in programming in T-C++ for an IBM, but that's about the
limit of it.  I _am_ pretty good at this little niche, however.
	I am crossposting this to a few groups, so take note.  The post
is to rec.games.programmer thanks to a note I read about a PBM game that
had four million planets in it.  I figured that equaled either an incredible
amount of disk access (that I would like to avoid) or some hefty memory
use...

Thanks,
Matt
-- 
Matt Bakaitis
mxb8@po.cwru.edu
From: cshaver@informix.com (Craig Shaver)
Newsgroups: comp.lang.c++
Subject: Re: streams
Date: 13 Oct 92 22:55:52 GMT
Organization: Informix Software, Inc.

In article <1992Oct13.155518.22845@rs6000.bham.ac.uk> pickerig@dns0.bham.ac.uk (Mr. G. Pickering) writes:
>My first reaction is to use FILE functions rather than streams, unless
>you have a good reason to use streams. This is just the way I do things,
>feel free to flame me for this.

Praise the lord for a breath of fresh air -- streams are hard to use!

>
>In this case you wouldn't have the problem, you would just pass the
>file pointer to whichever service functions that need access to the
>file.
>
>You can still do:
>
>  FILE* input_file;
>  if (input_flag)
>  {
>    input_file = stdin;
>  }
>  else
>  {
>    input_file = fopen("in_file","r");
>  }
>
>  if (input != NULL)
>  {
>    // do some stuff
>  }
>
>Ok, so it's not C++, but I subscribe to the school of
>thought that "if it works reliably...use it".  

And I can use simple printf and scanf too?  Huh, Huh?
-- 
Craig Shaver  (cshaver@informix.com for now) (415)390-0654 (415)926-6407
Productivity Group POB 60458 Sunnyvale, CA  94088
From: Peter.Bray@f1.n100.z60.wlink.nl (Peter Bray)
Newsgroups: comp.lang.c++
Subject: Warnings in AT&T C++ v3.01b / Templates
Date: Tue, 13 Oct 1992 02:37:33 -0100

Organization: Application Specific Computer Design, The University of Newcastle


Greetings,

	I'm having a problem with AT&T C++ v3.01b ( SunOS4.1.2 ), the
following warning is being generated for the code below I have stripped the
code slightly to help show the problem. This warning along with others is also
generated for the standard include file <iostream.h>.

	Any help, would be greatly appreciated, as this warning seems to be the
cause of another small error, I'm experiencing. I'll be only to happy to post a
summary of the responses.

Peter

------------------------------------------------------------------------------
Peter Bray: Application Specific Computer Design      Phone : (049) 21 5963
	    Dept. Electrical & Computer Engineering   Fax   : (049) 60 1712
	    University of Newcastle                   Email : InterNet/AARNet
	    Callaghan NSW 2308  AUSTRALIA         pbray@ascod.newcastle.edu.au
------------------------------------------------------------------------------

[ascod] 1 > CC  +w +p -g Problem.C
CC  +g +w +p Problem.C:
"Problem.C", line 16: warning: copy constructors should take a const  Integer& not a  Integer&
cc  -L/usr/att/lib   -g Problem.c -lC
[ascod] 2 > cat Problem.C
//
// Required typedef for portability
//
typedef int		Integer;		// 32 bit   signed

const	Null = 0;

template <class Type>
class ListItem
{
public:
	ListItem	( const ListItem<Type>& li );

	ListItem	( const Type& i,
			  ListItem<Type>* Next = Null,
			  ListItem<Type>* Prev = Null );
	// This constructor causes the problem.

	~ListItem	( void );

private:
	Type		theData;
	ListItem*	previous;
	ListItem*	next;
};

int main( void )
{

	ListItem<Integer> CausesWarning( 1 );

	return 0;
}

// The implementation ( not required, included for completeness )
template< class Type >
ListItem<Type>::ListItem ( const ListItem<Type>& li )
	: theData( li.theData ), previous( li.previous ), next( li.next )
{
}

template< class Type >
ListItem<Type>::ListItem ( const Type& i, ListItem<Type>* Next, ListItem<Type>* Prev )
	: theData( i ), previous( Prev ), next( Next )
{
}

template< class Type >
ListItem<Type>::~ListItem ( void )
{
}

// Thanks in Advance :-)
From: ren@function.mps.ohio-state.edu (Liming Ren)
Newsgroups: comp.lang.c++
Subject: help about fstream needed!
Date: 10 Oct 1992 23:32:55 -0400
Organization: Department of Mathematics, The Ohio State University
Distribution: world
NNTP-Posting-Host: function.mps.ohio-state.edu

I write a short prgram to define a class X and try to write it to a file.
I get error messages when  I complile it. Could somebody nice to tell me what 
is wrong and how to correct it?



#include<iostream.h>
#include<fstream.h>
#include<stdio.h>
class X{
  friend write(fstream, X&, streampos);
 private:
  int aa;
 public:
  X(){aa=1;};
  int get(){return aa;};
};

write(fstream st, X& a, streampos p)
{
  st.seekg(p, ios::beg);
  st<<a.aa;
  return 0;
}
  
main()
{
  X b;
  fstream file;
  file.open("out",ios::out);
  write(file,  b, 2L);
  file.close();
}               //here is line 27.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^



"test.c", line 27: error:  fstream::fstream() cannot access ios::ios(): private  member
"test.c", line 27: error:  fstreambase::fstreambase() cannot access ios::ios(): private  member
"test.c", line 27: error:  filebuf::filebuf() cannot access streambuf::streambuf(): private  member
"test.c", line 27: error:  iostream::iostream() cannot access ios::ios(): pios::ios(): private  member
"test.c", line 27: error:  ostream::ostream() cannot access ios::ios(): private  member
Compilation failed




						Liming Ren
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: virtual base classes
Keywords: virtual
Date: 9 Oct 92 19:10:22 GMT
Article-I.D.: alice.23851
Organization: AT&T Bell Laboratories, Murray Hill NJ



 gas@spitfire.xtel.co.uk (Alan Shepherd @ X-Tel Services Ltd.) writes

 > I have a base class 'Object' (very original...) which has a number of
 > derived virtual classes.  
 > 
 > e.g. 
 > 
 > class foo: public virtual Object {...
 > 
 > class foo2: public virtual Object {...
 > 
 > When I try a statement of the following form:
 > 
 > Object* oneFoo2 = new foo2();
 > 
 > aFoo2 = (foo2) oneFoo2;
 > 
 > gcc complains like so:
 > 
 > cannot cast up from virtual baseclass `Object'
 > 
 > Can anyone explain (by email preferably) what is going wrong ?  Is it
 > a feature of C++, or just something I'm doing wrong with the virtual
 > keyword ?  I have hunted around Stroustrup's 2nd of "The C++
 > Programming Language" to no avail.

Well, Assuming you meant `(foo2*)oneFoo2' the problem is that casting
from a virtual base to a derived class is not allowed (sec 5.4 of the
manual ``Explicit Type Conversion'' pg 501 of my 2nd edition).

The fundamental reason for the restriction is that there might be two
foo2s derived from Object and keeping track of such derivations at
run time was not considered to be worth while.

For example:

	class X : public foo2 { ... };
	class Y : public foo2 { ... };
	class Z : public X, public Y { ... }; // Z has two foo2s

	Y* py = new Z;
	Object* p = py;
	foo2* pfoo = (foo2*)p;	// which foo2?

If you want to ``get back'' to a derived class from a virtual base
you need a virtual function:

	class VB { public: virtual void f(); };
	class D1 : public virtual VB { public: void f(); };
	class D2 : public virtual VB { public: void f(); };

	void g()
	{
		VB* p = new D1;
		p->f();	// invoke D1::f

		p = new D2;
		p->f();	// invoke D2::f
	}
From: Arlie.Davis@f1.n100.z60.wlink.nl (Arlie Davis)
Newsgroups: comp.lang.c++
Subject: virtual destructors
Date: Tue, 13 Oct 1992 05:24:14 -0100

Organization: University of Louisville

In <1992Oct12.235515.4506@netcom.com> nagle@netcom.com (John Nagle) writes:

>        It's not your fault.  The language is badly designed in this area.
> Destructors should always be virtual, and it should be an error (at least
> a warning) to declare one that isn't.

So, I must penalize every class, no matter how simple, with a vtable pointer?
Perhaps that would go over better as: "... and it should be an error/warning to
derive from a class that does not have a virtual destructor."

I like that FAQ's advice: If it has any virtual methods, it should have a 
virtual destructor.

-- 
lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null

Newsgroups: comp.lang.c++