HDTenEightyP/NetNews huggingface dataset:
From: andrewm@uws.EDU.AU (Andrew Maclean)
Subject: BC++ OWL Screen Saver
Summary: Sample code for a more sophisticated screen saver.
Keywords: BC++ OWL Screen Saver
Organization: University of Western Sydney
Date: Thu, 3 Sep 1992 23:50:43 GMT


To save me re-inventing the wheel:
Has anyone got OWL code to share based on the example OWL screen
saver provided with Borland C++.  I really need the following:
A configuration dialog that actually saves the configuration to
the CONTROL.INI file.
A set of dialogs for password protection.
A help function.

Any help would be appreciated.



+-----------------------------------------------------------------------------+
| Andrew J. P. Maclean                          E-mail: a.maclean@uws.edu.au  |
| University Planner,                                     andrewm@uws.edu.au  |
| University of Western Sydney,                  Phone: +61 2 678 7848        |
| PO Box 1000, St. Marys, N.S.W. 2760,             Fax: +61 2 678 7804        |
| Australia.                                                                  |
+-----------------------------------------------------------------------------+
Newsgroups: comp.lang.c++
From: heilig@plains.NoDak.edu (Zachary Heilig)
Newsgroups: comp.lang.c++
Subject: delete this???
Date: 4 Sep 92 02:29:27 GMT
Article-I.D.: plains.20146
Organization: North Dakota Higher Education Computing Network


I saw the previous thread about calling the destructor in member functions,
and was wondering how legal the following code would be:

--foo.c--
class foo {
	int	*bar;
public:
		foo();
		~foo();
	void	remove( int = 1 );
}

foo::foo()
{
	bar = new int[100];
}

foo::~foo()
{
	remove( 0 );
}

void foo::remove( int call_destruct )
{
	if( bar ) delete bar;
	if( call_destruct ) delete this;
}
--end--

or, should I just call the destructor function?

any ideas?

-- 
    - Zach Heilig (heilig@plains.nodak.edu)

Ninety-Ninety Rule of Project Schedules:
	The first ninety percent of the task takes ninety percent of
	the time, and the last ten percent takes the other ninety
	percent.
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Handling of operator . pro
Date: 31 Aug 92 23:06:49 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: fjh@munta.cs.mu.OZ.AU's message of 12 Aug 92 13:32:47 GMT

In article <9222523.7061@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

   Compilers become more expensive, which discourages beginners, so the
   language becomes less popular. (This in turn leads to less resources
   being spent on compilers and tools for the language). Compilation
   becomes slower. Compilers occupy more disk space and take longer to
   install.  Also compilers become more error-prone; it is a lot easier to
   fix a bug in your work-around than to fix a bug in the compiler.

   [...]

   If the language becomes too complex, then "simply knowing the language"
   becomes a non-simple task. On the other hand if some feature has been
   coded using the facilities of a simple language, the maintainer can
   SEE how it works, by reading the code.

   The ideal is to have a language that is simple but powerful and extensible.
   This is the idea behind using standard library i/o functions rather than
   special builtins, overloading rathern than printf %-specifiers, etc.

In all this discussion, please keep in mind that much of the
complexity of C++ is due to its C heritage. It is quite possible to
design and implement languages that are simpler, more powerful, and as
efficient as C++ -- but they won't be backwards compatible with C.

					Thomas.
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Multiple Inheritance Problem
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 1 Sep 1992 01:37:06 GMT

don@surtsey.aero.org (Don C. Hancock) writes:

>I'm confused as to why the following results in what to me is the wrong
>virtual function being called.  I'm sure the problem is somehow caused
>by my casting the result of the function call from one base to the
>other (and somehow lying to the compiler), but I'm not sure how else to
>accomplish my task.

Yes, that is exactly what is causing the problem.
You can fix it by inserting an extra cast to (derived *) before
casting to (base2 *), ie.

	main() {
		base2 *bb2 = (base2 *)(derived *)fun();
		bb2->v2();	// prints der::v2 as desired
	}

BUT, I would strongly recommend *against* using these sort of casts.

Maybe you could explain in a bit more detail why you think that you
need to downcast from a (base *) to a (base2 *), and then we may
be able to give you an alternative solution :-)

-- 
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++,comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.tools,comp.windows.ms.programmer
From: pete@genghis.borland.com (Pete Becker)
Subject: Re: I Borland C++/Win 3.1 Broken??? Help!
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Wed, 2 Sep 1992 16:06:33 GMT

In article <1992Sep1.213224.7550@actrix.gen.nz> David.Haigh@bbs.actrix.gen.nz writes:
>Here's the situation:
>
>The following member function compiles without error, using Turbo C++
>for Windows 3.0.
>
>virtual int yield( volatile BOOL & continueYield = TRUE);
>
>BOOL : typedef for int
>TRUE : #define 1
>
>However, using Borland C++ for Windows 3.1, the following errors are generated:
>
>* Reference initialised with 'int', needs lvalue of type int.
>* Type mismatch in default value for parameter 'continueYield'.
>

	The second error is a result of the first, so don't worry about that
one.  The problem is that the code is trying to pass a constant object as a
reference parameter.  What happens in this case?

	int yield( int& b )
	{
	b = 0;
	}

	yield(1);

Newsgroups: comp.lang.c++
From: wright@epx.cis.umn.edu (Mark Wright)
Subject: New, farcoreleft() and BC++ 3.1
Summary: Does farcoreleft() give me the right number when I use 'new'?
Organization: University of Minnesota
Date: Wed, 2 Sep 1992 05:11:06 GMT

     In one of my C++ programs I just happened to put a farcoreleft() after
having deleted all my 'new'ed objects, and I get the same ammount of free
space as I had when those objects were still around.  Are my ~Object routines
faulty, or does farcoreleft() not work correctly with objects allocated with
'new'?  I'm compiling in the large memory model (oh, and using BC++ 3.1).

thanks,
Mark Wright
wright@epx.cis.umn.edu
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Turbo C++, function prototypes
Organization: TauMetric Corporation
Date: Thu, 3 Sep 1992 17:34:46 GMT

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

>steve@taumet.com (Steve Clamage) writes:

>>If you write, for example,
>>	void main(){ }
>>The compiler is obligated to diagnose an error in C and C++.

>Are you sure? I've just tested three supposably ANSI-compliant C compilers
>and NONE of them diagnose an error (or even a warning!). 

>I also tested three C++ compilers, and got one error and one warning.

I have to retreat from my earlier position.  The ANSI C standard 
requirement (2.1.2.2.1 and 2.1.2.2.3) is not in a "constraint" section,
so a diagnostic is not strictly required.  The result of defining
main() with a return type of void is therefore undefined -- an
"unconstrained error".

Many unconstrained errors are very difficult or even impossible to
detect, which is why the Standard differentiates them from
constraint violations.  The return type of main() is always detected!

A compiler may diagnose unconstrained errors, and I would expect a
compiler to diagnose this one, if only in "strict" mode.  (A
"warning" is a diagnostic, for example.)

For C++, the ARM does not address required diagnostics.  It does say
that main() returns a value to the environment; this would exclude a
definition with return type void.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Distribution: world
Subject: Re: Novice Questions
X-Mailer: cppnews $Revision: 1.14 $
Organization: Trumphurst Ltd.
Date: Fri, 4 Sep 1992 19:41:49 +0000


In article <1992Sep3.163337.13948@taumet.com> steve@taumet.com (Steve Clamage) writes:

> nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
> 
> 
> >I HATE it when people do that ! (:-)
> 
> >NULL is a POINTER which is guaranteed not to point to any valid location. 
> >It may or may not have the bit pattern all zeroes.
> 
> >'\0' (ASCII NUL) is the CHARACTER which is used to terminate strings.
> 
> >Please do not confuse the novice by using NULL to mean NUL.
> 
> I HATE it when people do that ! (:-)
> 
> Neither C nor C++ is required to use the ASCII character set.
You are quite correct. 

I merely assumed you used the word NULL because you had heard someone
pronounce the ASCII name of the '\0' character, and assumed they were
saying NULL.

> A literal string in C and C++ will always be terminated by an
> implicit null character, meaning a character having zero value.
> In source code, this may be represented as '\0' (type char).
Nevertheless, NULL has a specific meaning in C(++), and this meaning 
should not include "character '\0'", in my opinion, because it is liable 
to confuse.

> This need have nothing to do with ASCII, although the ASCII character
> set happens to have a member of zero value which is called NUL
> when writing about the character set.
Right.

I'm not going to get into an argument about this - if you choose to 
overload NULL to mean "character '\0'" as well as "a pointer which is 
guaranteed not to point to a valid address", that's your choice. I just 
don't happen to like it, that's all :-)

---
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 affiliated 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: mrs@kithrup.COM (Mike Stump)
Subject: Re: SOLVED: Template functions and g++  : -)
Reply-To: mrs@cygnus.com
Organization: Cygnus Support
Date: Wed, 02 Sep 1992 09:49:00 GMT
Keywords: g++, templates 

In article <1992Aug25.224616.9948@Princeton.EDU> fmidgley@phoenix.Princeton.EDU (Frank M. Midgley) writes:
>The problem I have is not with the code itself, but with the fact that it
>was necessary to create a .h file for every occurence of a template.

>I can't see why the compiler can't be happy with just the template.  I
>don't see why the compiler has to be 'spoon fed' such information as when
>to actually generate the code for a template.

This is a current limitation in g++.  (Or a bug if you want to call it that.)
Not all implementations have this problem.

>  I was under the impression that with templates, only one copy of the template
>code was ever generated, thus giving templates their desirability.

Hum, this is definitely not the case.  You can engineer this to happen (for the
most part) in YOUR code, but it is not a general property.

>If this is the case, can't the compiler generate the template code for the
>.cc file containing the template and leave 'hooks' to attach whatever type
>is being 'templated'?  This seems simply a matter of a few void*'s.

Hum, sounds nice, but template implementations are just a little bit harder
than this.  :-(
Newsgroups: comp.lang.c++
From: brown@ccit02.duq.edu (Jason Brown)
Subject: c++ Compilation Error, Help please
Organization: Columbia University Center for Telecommunications Research
Date: Mon, 31 Aug 1992 16:47:29 GMT
X-Posted-From: ccit02.duq.edu
X-Posted-Through: sol.ctr.columbia.edu


Ok C++'ers we're trying to re-compile a c++ application, originally  
written for the sun, on the NeXT to run it under X-windows.  Not knowing  
whole bunches about c++ has made this insteresting to say the least.    
We'd gotten through quite a bit of it when we came upon the following  
error.

	ccit01:/usr/local/src/align/lav->make
	cd ../lib; make
	g++ -I/import/X11R5/include -I/usr/local/include -I. -I.. -I../lib  
	-pipe -Wall -DUSE_LIBGXX_INLINES -DMULTALIGN -O  -fstrength-reduce   
-g -c ButtonChoice.cc
	In file included from ButtonChoice.cc:8:
	ButtonChoice.h:5: warning: `#pragma once' is obsolete
	In file included from ButtonChoice.cc:9:
	Switches.h:5: warning: `#pragma once' is obsolete
	In file included from ButtonChoice.cc:9:
	Switches.h:23: parse error before `fcn'
	Switches.h:23: syntax error before `)'
	Switches.h:24: warning: implicit declaration of function `I'

The '#pragme once' messages haven't really bothered us to date, it the  
parse error on line 23. The following partial code listing causes the  
error.
Line 23 is marked with >*>*>*>

// -*- C++ -*-
// $Id: Switches.h,v 1.8 1991/12/17 01:45:43 schwartz Exp $

#ifndef _switches_h
#pragma once
#define _switches_h

#include <InterViews/interactor.h>
#include <InterViews/box.h>
#include <InterViews/button.h>
#include <InterViews/glue.h>
#include <InterViews/painter.h>

// 
// This takes a constant string, which is used to label a PushButton,
// and an Interactor and a pointer to member of Interactor.  When
// the button is pressed, we call the member of the interactor.
//

class PushSwitch : public PushButton {
  /// XXX - should this really be derived from PushButton?
public:
>*>*>*>  PushSwitch (const char* text, Interactor* i, void  
(Interactor::*fcn)()) : 
  I(i), F(fcn), 
  PushButton ("PushSwitch", text, state = new ButtonState (false), true)
    { }

  ~PushSwitch () { delete state; }

Help, we've twisted around a bunch of these types of errors but nothing  
we've tried yet has worked on this one.  Any help would be greatly  
appreciated.

Thanks

--Jason Brown
brown@ccit01.duq.edu

--
   ____               ___
    /                 /  )
   /  _, ,  __       /-,' ,_  __
\_/__</_/>_(_/_/\/  /__)__/__(_/__(_/_)_/\/

"Remember, be humble, always answer the phone...
 No matter who's in the car." --Jack Lemmoon
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Garbage Collection for C++
Date: 25 Aug 92 18:36:19 GMT
Organization: Microsoft Corporation

In article <DAVEG.92Aug20022559@synaptx.synaptics.com> daveg@synaptics.com (Dave Gillespie) writes:
|Do you really think incremental or generational collectors are
|feasible in C++?  I've never looked in the guts of one of these
|collectors, but as I understand it they tend to depend on the
|ability to move data around, and other things that a C++ collector
|might not be able to get away with.  (C++'s use of pointers is so
|unrestricted that it's a minor miracle it's possible to do garbage
|collection at all...)

Generational GC is certainly feasible in C++.  In practice one needs compiler
support for the implied "smart pointers", so that programmers don't have
to remember to use special pointer syntax everywhere.

C++ needs to support moveable objects in any case, in order to handled
ODBMS, persistence, locality of reference, etc.  If you ever have done
store/restore of objects from moveable store,  you've had to handle the
problem of moveable objects.  This is a standard programming problem not
well handled by current C++.  It needs compiler support.  Immovable object
GC schemes do not solve this problem -- they simply leave it to someone else
to solve.


Newsgroups: comp.lang.c++
From: adk@Warren.MENTORG.COM (Ajay Kamdar)
Subject: Re: istrstream
Organization: Mentor Graphics Corp. - IC Group
Date: Wed, 2 Sep 1992 22:39:18 GMT

Follow up to my own previous post:

In article <1992Sep2.163001.2107@Warren.MENTORG.COM> adk@Warren.MENTORG.COM (Ajay Kamdar) writes:

>It is unfortunate that the fact that strstreambase has a char* CTOR should
>dictate that istrstream should have a char* CTOR too. I would have much
>preferred that the istrstream have a const char* CTOR, and that the
>istrstream class cast away the const to create the strstreambase part of
>it self. Along with casting away the const internally, istrstream would
>also set up some other conditions in strstreambase which would ensure that
>even though the strstreambase was created with a char* argument, it does not
>actually modify the buffer. This would making the cast away of the const
>purely an implementation detail of the istrstream class while still
>maintaining the constness of its CTOR argument.
>

BTW, I agree that casting away the const in the implementation is not the
only way to make the istrstream have a constructor taking a const char*.
Nor is it necessarily the best way. There are other ways of achieving the
same results which could be considered linguistically more pure (i.e., do
not resort to cast away const.)

People's mileage varies on this issue, so I hope I have not rekindled the
debate on the virtues of casting away const.

- Ajay

-- 
I speak for none but myself.

Ajay Kamdar                               Email : ajay_kamdar@mentorg.com
Mentor Graphics, IC Group (Warren, NJ)    Phone : (908) 580-0102
Newsgroups: comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: where can I find cfront?
Organization: University of Illinois at Urbana-Champaign
Date: Thu, 27 Aug 1992 20:20:08 GMT

In <1992Aug26.202501.589@unixg.ubc.ca> martin@ucs.ubc.ca (Marilyn Martin) writes:

>I am in urgent need of cfront.  Can anybody please point to a
>public domain or commercial product?  Thanks for your help.

*****>	cfront is one of the components of AT&T C++ compiler; hence, it
	is not public domain.  The AT&T C++ Language System, as it is
	properly called, is available from AT&T Unix System Laboratories.
	They can be reached at: 1-800-828-UNIX.  Thank you for using AT&T. :)
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 28 Aug 92 11:07:46 GMT

mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:

|In <1992Aug26.130335.26725@hemlock.cray.com> dsf@cray.com (Dan Frankowski) writes:

|I believe someone once wrote an article entitled something like
|"Structured Programming Using Goto"; the same person who wrote
|another article that started this whole mess that was entitled "Goto
|Considered Harmful", if my memory has changed state randomly.  In a
|nutshell, 'goto' isn't the problem; it's the 'come from' that kills
|you when it comes to figuring out what is going on.  If you structure
|things correctly and document them clearly, there are times when
|'goto', 'break', AND multiple exits make good sense in making code
|more easily read.

|>Note that I did not
|>say gotos have no uses.  (I haven't made up my mind yet.  Maybe this
|>thread will help me decide.  :-) However, they're not structured
|>programming, as defined by the debate in computer science fifteen-odd
|>years ago.

|According to the guy who started that debate they are (if properly
|used). 

Keep in mind that the guy who started that debate (E. W. Dijkstra)
specified the "proper use of goto" as follows: (And I paraphrase from
his Notes on Structured Programming, "Structured Programming" Page
18-20).  Control sequences can be limited to 3 distinguished forms,
"concatenation", "selection" and "repetition".  These forms can be
describes using flowcharts, these flowchars share the property that
they have a single entry at the top and a single exit at the bottom.




--
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: shite@sinkhole.unf.edu (Stephen Hite)
Newsgroups: comp.lang.c++
Subject: Re: SNIFF C++ environment, what is it?
Keywords: SNIFF, C++ environment
Date: 23 Aug 92 18:14:00 GMT
Distribution: comp
Organization: University of North Florida, Jacksonville

In article <2229@bigfoot.first.gmd.de> jh@first.gmd.de (Joerg Heuer) writes:
>In the recent issue of a german computer magazine, I read about an environ-
>ment for development of C++ software, named SNIFF. Does anybody know/use
>this and can tell about it. At least I'd like to know the company selling
>it, so I could ask them for information.
>
>Thanks in advance,
>J"org.
>
   Sniff 1.1b is available from iamsun.unibe.ch in the C++ hierarchy.
It's a development environment for C++ (minus the C++ compiler or interpreter).
It's freely available and you're gonna need OpenWindows 3.0 if you want
to play with it immediately.  I just downloaded it and haven't had a 
chance to look into whether the XView 3.0 package will be able to handle
everything Sniff requires of the OpenLook part.


Steve Hite
shite@sinkhole.unf.edu
From: Aurelius@cup.portal.com (Mark Christian Barnes)
Newsgroups: comp.lang.c++
Subject: Re: complex classes and temporary destruction.
Date: Fri, 28 Aug 92 21:50:51 PDT
Organization: The Portal System (TM)
Distribution: world
  <23563@alice.att.com> <64821@cup.portal.com> <23578@alice.att.com>

Andrew Koenig writes:

|>  Have the temporary "inherit" (for lack of a better word) the
|> storage class of p. If p is an auto variable then 's+t' should
|> be auto too. Destroy p and 's+t' together. If p is static, then
|> perhaps have 's+t' be static as well, onc instance of 's+t'
|> gets re-used each time the statement is executed.
|
|I'm afraid that wouldn't work.  Consider this:
|
|char* I(char* x) { return x; }
|
|The function I (for identity) just returns its argument, but to make things
|difficult, it is compiled separately.  Now, you would like
|
|char* p = s+t;
|
|to cause the temporary for s+t to stick around as long as p does,
|but what are you going to do about this?
|
|        char* p = I(s+t);
|
|There's no way to know what I() does, so what basis do you have for
|letting the lifetime of p affect that of s+t?

 But Andrew, you have changed the statement completely. The
temporary 's+t' is no longer even being assigned to 'p'. It is
constructed as a parameter for function (or macro) 'I'. In this
case I would suggest that 's+t' is an auto variable with a scope
limited to 'I'.

 I know that this means that your example will not work under
this interpretation. Well I don't think it should. The perpetual
problem of aliasing, to which pointers contribute, should not be
solved by the compiler. I feel that the programmer should pay
attention to what he/she is doing.

 In your example, an expression is evaluated and passed
(on the stack) as the parameter to a function. The function
'I' returns another value of type pointer to char. There should
not be any assumption that the parameter and the return value
have anything in common. You, as the programmer, know that 'I'
returns the parameter. Therefore, you should also insure that
any parameters passed to 'I' are of the appropriate storage
class and scope for the uses that you intend.

<whew, that's enough for now.>

			Regards, Aurelius@cup.portal.com
Newsgroups: comp.lang.c++