HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.lang.c++
From: rme@cix.compulink.co.uk (Richard Melvin)
Subject: Re: WHERE CAN ONE BUY AN ELEGANT AND EFF
Cc: rme@cix.compulink.co.uk
Reply-To: rme@cix.compulink.co.uk
Date: Wed, 11 Nov 1992 21:07:00 +0000

>> < problems with the USL standard component library licensing agreement>

We've had problems with this too..
Wew were basically on the point of buying the software, evaluation complete,
purchase order signed, when I happenned to see a copy of the license
agreement. Close shave - we nearly spent $1500 on a piece of software it
would have been illegal for us to use in the way we intended to.

USL seems to only be targeting three types of users:

    - compiler writers, who pay a lot of money and get to do a full
      source distribution.

    - 'shrink-wrap' application programmers.

    - in-house developers.

They seem to have given no thought to those who do contract work for
commercial companies and government organisations, who have to deliver in
source form.
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: object classes
Keywords: Object, DoubleList
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 12 Nov 1992 11:29:44 GMT

In article <1992Nov9.172651.10696@dragon.acadiau.ca> 870086t@dragon.acadiau.ca (Shannon Tremblay) writes:
>
>I am trying to build a graphics editor.  Just the basic shapes, each one 
>to be treated as an object.
>Sounds like a simple task, right?  I thought so.
>
>class Shape : public Object
>{
>public:
>	Shape();
>	~Shape();
>	
>	virtual char* nameOf();			// pure virtual members 
>	virtual classType isA();		// from class Object
>	virtual void printOn( ostream& );
>	virtual hashType hashValue();
>
>	virtual void Draw();
>	virtual void Assign();
>private:
>	int	figure,
>		color,
>		style;
>};

	You are using the old Borland Object library -- dont. It was
designed for when there was only single inheritance. Be suspicious
of 'classType isA()'.

	Here's a proper class IMHO for drawing:

	class drawable {
	public:
	virtual void Draw()const=0;
	};

Derive classes from drawable. Iterating through a list or array,
you can just call

	shape->Draw()

You dont need to know what shape you are drawing, indeed you mustnt
know, thats the objects job.

>Also when I  return something it is of type Object and therefore I loose 
>the member functions I created under Shape.

	Of course. Dont use this technique, it is a Smalltalk method
which is appropriate for Smalltalk (being dynamic) but not C++ 
(being static).

>
>Does anyone know of source code that would demonstrate to me how to go about
>creating an object, placing it in a list, and then being able to retrieve
>the object, intact, as it was placed on the list, that is derived members 
>still avialable.  As well as being able to iterate through the list,
>accessing the derived functions as I go.  
>
>Or am I expecting too much???  I didn't think so...

	You are expecting the wrong thing. You should NOT be able to
access functions special to each shape from the list. All the objects
on the list MUST be treated the same. This ensures you can add ANY shape
to the list, and that none of them are special.

	(Note, for a polymorphic list you need a list of pointers
or references not actual objects.)

-- 
;----------------------------------------------------------------------
        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: shyatt@nyx.cs.du.edu (Steve hyatt)
Subject: Borland C++ 3.1 OWL Windows Question
Summary: Question
Keywords: OWL Windows
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Mon, 9 Nov 92 02:55:09 GMT


Hi,
  i am in the process of writing a windows 3.0 application using the 
Object Windows Library package with Borland C++ v 3.1  What i need to
do is have text strings inputted into an edit control via hotkeys.
eg.  If the user hits <F1> then string BLO IFR would be entered for
instance. Anyone know of a way to do this?
Please send responses to    shyatt@ra.uvic.ca
Thanks.
Steve

Newsgroups: comp.lang.c++,gnu.g++.help
From: enewton@uucp (Eric Newton x2092)
Subject: Re: linking problem using class CursesWindow in libg++-2.2
Reply-To: uunet.uu.net!srg!enewton
Organization: means "in a rut"
Date: 6 Nov 92 11:50:07


 > I have a problem linking the following simple program using g++
 > 2.2.2) under SunOS 4.1.2.  None of the curses-related routines are
 > found, and an error message is produced, although everything is in
 > the standard places.  The problem doesn't occur on the RS6000.  On
 > the Sparc, the program is linked using the following command:
 >
 >	g++ -o window window.C -lcurses -ltermcap
 >

Try:

g++ -o window window.C -lg++ -lcurses -ltermcap

-Eric

--
Remember to mail to: 	uunet.uu.net!srg!enewton    "The more you complain,
<or>			enewton@oswego.oswego.edu    the longer God lets you
<or>			enewton@access.digex.com     live."
Newsgroups: comp.lang.c++
From: hitz@univie.ac.at ( Martin Hitz)
Subject: New Book (GERMAN)
Summary: A new textbook on C++ has been published by Springer in German
Keywords: textbook
Organization: Vienna University
Date: Thu, 5 Nov 1992 12:14:53 GMT

In der Reihe "Springers Angewandte Informatik" ist soeben mein
Einfuehrungsbuch

C++ - Grundlagen und Programmierung

erschienen. Es wendet sich an LeserInnen, die ueber Basiskenntnisse
in der Programmierung in hoeheren Programmiersprachen verfuegen,
setzt jedoch weder C-Kenntnisse noch objektorientierte Grundlagen
voraus. 

Kommentare sind herzlich willkommen an hitz@ifs.univie.ac.at.

Martin Hitz

306 Seiten
oeS 336,- (wohl etwa DM 48 bzw. SFR 42)
ISSN 0178-0069
ISBN 3-211-82415-4 Springer Verlag Wien New York
ISBN 0-387-82415-4 Springer Verlag New York Wien

Inhaltsverzeichnis:

Einfuehrung
Datentypen
Operationen    
Funktionen          
Grundlagen der objektorientierten Programmierung
Klassen   
Abgeleitete Klassen           
Schablonen          
Ausnahmebehandlung       
Ein- und Ausgabe    
"Intelligente" Felder         
Zeichenketten  
Container
Persistente Objekte
Speicherverwaltung  
Literatur      
Anmerkungen und Loesungen zu den Uebungsaufgaben

Newsgroups: comp.lang.c++
From: dan@BofA.com (Dan Brockman)
Subject: Re: Criticisms Wanted
Organization: Bank of America, Capital Products, RMTG #5906
Date: Fri, 13 Nov 92 05:31:42 GMT

In article <1992Nov10.212718.2852@taumet.com> steve@taumet.com (Steve Clamage) writes:
>robert@slipknot.rain.com (Robert Reed) writes:
>
>|But the
>|point is that C++ has been reputed to be a language that finally makes the
>|concept of "software components" realizable.  The argument goes that if you
>|still have to examine the internal workings of component classes to determine
>|how to best use them, then their value as components has been greatly
>|diminished.
>
>I don't see how this is different in C++ than in any other programming
>language.  You have an interface declaration and (one hopes) some
>documentation, but how do you know whether the actual component works
>as claimed?

IMHO C++ is just one more modular language in this respect, sales pitches
notwithstanding.  FORTRAN made "software components" realizable in the 50's.

-- 
 --------------------------------------------------------------
 Daniel Brockman             tel 415-953-0406, fax 415-622-2892
 Bank of America, Dept 5906, 555 Calif St
 San Francisco 94104 USA    email uunet!odinba!dan dan@BofA.COM
Newsgroups: comp.lang.c++
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Explanation for "Null pointer assignment"
Organization: University of Jyvaskyla, Finland
Date: Tue, 10 Nov 1992 06:56:39 GMT

In article <541@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>In article <Bww82p.HIw@peora.sdc.ccur.com> tran@peora.sdc.ccur.com (Nhan Tran) writes:
>>
>>I am using Borland C++ 2.0. When my program finish, it has a run-time error
>>message "Null pointer assignment". According to the manual, 
>>
>>	"Null pointer assignment" is displayed to inform you that
>>	(most likely) a value was stored to an uninitialized pointer.
                                  ^^^^^^^^^^^^^^^^^^
>>	The program may appear to work properly in all other respects;
>>	however, this is a serious bug ...
>>
>>I am puzzled by this. If I declare a pointer without initialzing it, then 
>>the program will assign some value to that pointer (by using it) at run-time.
>
>I read the other answers you got, and noone actually seemed to directly
>address your question about "the program will assign...", so here goes.
> [good explanation deleted]

The original explanation in the manual (above) was extremely incorrect
and misleading.  No wonder the person got puzzled.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
From: holiday@bnr.ca (Matthew Holiday)
Newsgroups: comp.lang.c++
Subject: Re: Discriminating Variant Records Without switch() ??
Date: 12 Nov 92 19:05:18 GMT
Reply-To: holiday@bnr.ca
Organization: Bell-Northern Research, Richardson, TX

In article <BAB.92Nov12074430@se39.wg2.waii.com>, bab@se39.wg2.waii.com (Brian Button) writes:
|> 
|> In article <BAB.92Nov10073324@se39.wg2.waii.com>, bab@se39.wg2.waii.com (Brian Button) writes:
|> |> Is there a simple, OOP based way to discriminate between variant
|> |> records? I saw an article in C Users Journal last month titled "Switch
|> |> Deemed Harmful to C++" or something like that, but I couldn't figure
|> |> out how to do it any other way.
|> 
|> 
|> ->"Matthew" == Matthew Holiday <holiday@bnr.ca> writes:
|>    Matthew> switch statement! :-) There ought to be a convenient way
|>    Matthew> to create objects from network messages, i.e., some way to
|>    Matthew> register message types and their matching class types,
|>    Matthew> such that for every incoming message, its body (an array
|>    Matthew> of bytes) gets turned into the correct object, which would
|>    Matthew> be derived from a root generic message object.
|> 
|> There is such a way using factory classes such as the RogueWave
|> RWFactory class. The problem I'm having is figuring out how to deal
|> with these objects after they are already created. Since there's no
|> common set of operations which are performed on each of the objects,
|> there is no set of methods which may be made virtual and overloaded.
|> Herein lies the problem. This seems to point towards using special
|> purpose code for each class, which would necessitate using a switch.
|> 
|> Have I painted myself into a corner or is there some way out. How are
|> the rest of you OOP programmers dealing with cases like this?
|> 

One thing that would help would be the ability to "transmute" an object into
a subclass of the object's current class.  That is, the factory could create
a top-level object.  After some processing, this object could determine that
it's really more specialized, and turn itself into a subclass object.  Take a
trivial example: a shape is constructed using some points.  Further processing
reveals that the points define a rectangle, so the shape converts itself into
a rectangle.  Yet more processing reveals that the rectangle is in fact a
square -- so it becomes an object of type square, which was derived from
rectangle and shape.  One of the problems with this downward transmutation is
that if you simply replace the object, it will have a new address, so you have
to update all pointers to the object every time it is replaced.  You can't
necessarily transmute in place, because the new subclass object may be too
large to fit into its current space in memory.  In addition to this "transmute"
capability, downcasting is also useful (see Stroutrup's RTTI papers).

-- 
Matt Holiday                                      #include <std/disclaimer>
holiday@bnr.ca
BNR Richardson, TX
From: grahamd@swdev.research.otca.oz.au (Graham Dumpleton)
Newsgroups: comp.lang.c++
Subject: Re: Debugging output
Date: 8 Nov 92 00:28:16 GMT
Organization: Technology Development Group, OTC Australia

In article <6706@otc.otca.oz>, grahamd@swdev.research.otca.oz.au (Graham Dumpleton) writes:
> In article <Bx93Mr.42r@cs.uiuc.edu>, pjl@cs.uiuc.edu (Paul Lucas) writes:
> 
>   #ifdef DEBUG
>   #define CDEBUG if (!debug) ; else cerr
>   #else
>   #define CDEBUG if (1) ; else cerr
>   #endif

One further point about this, in optimising away the body of the 'else' when
DEBUG isn't defined, cfront does not even parse and type check the code which
is eliminated. For example, cfront wouldn't complain about debugstream being
undefined in the following when DEBUG isn't defined

  #ifdef DEBUG
  ofstream debugstream("debug");
  #endif

  #ifdef DEBUG
  #define CDEBUG if (!debug) ; else debugstream
  #else
  #define CDEBUG if (1) ; else debugstream
  #endif

  ...

  CDEBUG << "hello world" << endl;

If this approach is used it may not be wise to rely on this to occur for all
compilers though so you may be better off writing

  #ifdef DEBUG
  #define CDEBUG if (!debug) ; else debugstream
  #else
  #define CDEBUG if (1) ; else cerr
  #endif

I would be interested to hear what other C++ compilers do in this situation,
ie. do they actually check the code which is eliminated.

-- 
Graham Dumpleton (grahamd@swdev.research.otca.oz.au)
From: vander@flab.fujitsu.co.jp (Mike van der Velden)
Newsgroups: comp.lang.c++
Subject: undefined symbol... sometimes
Date: 6 Nov 92 05:53:01 GMT
Organization: Fujitsu Laboratories Ltd., Kawasaki, Japan

I have a curious problem.  If I have the following three files:

base.h:
------
    template <class T>
    class Base {
    public:
        void func ();
        //...
    };


base.cc:
-------
    #include "base.h"

    template<class T> void Base<T>::func ( )
    {
        //...
    }


main.cc:
-------
    #include "base.h"

    main ()
    {
        class Derived : public Base<Derived> {
            //...
        };

        Derived   test;
        test.func ();
}


And compile with the command "g++ base.cc main.cc"   I get the
following linker error:

    ld: Undefined symbol
       _func__t4Base1ZQ24main7Derived
    collect: /usr/bin/ld returned 2 exit status


On the other hand, if I put everything in one file, everything
compiles fine.  I gather that the compiler is mangling the function
name in one file differently than it does in other files.  Have I
missed something?  Is this really correct behavior?  Is there a
work-around?
 
--
Mike van der Velden             
s-mail: Distributed Systems Laboratory, Fujitsu Laboratories Ltd.
        1015, Kamikodanaka Nakahara-ku, Kawasaki 211, Japan
e-mail: vander@flab.fujitsu.co.jp
Newsgroups: comp.lang.c++
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Debugging output
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Fri, 6 Nov 1992 16:27:57 GMT

In <1992Nov6.135017.6870@news2.cis.umn.edu> hansen@deci.cs.umn.edu (David M. Hansen) writes:

>In article <Bx9369.3zL@cs.uiuc.edu>, pjl@cs.uiuc.edu (Paul Lucas) writes:
>|> *****>	This is overkill; the same thing can be achieved without
>|> 	inventing another class:
>|> 
>|> 	#ifdef DEBUG
>|> 	#	define	CDEBUG	if ( debug ) cerr
>|> 	#else
>|> 	#	define	CDEBUG	//
>|> 	#endif
>|> 
>|> 	// ...
>|> 
>|> 	CDEBUG << "here\n";
>|> 
>|> 	This allows the flexibility of having debugging "togglable"
>|> 	during development, presumeably by a command-line option, but
>|> 	can be compiled-out in the final version.
>|> 

>I think it is a mistake to rely on what is essentially a bug in many C++
>compilers.  According to the ARM (section 16.1, page 370)  "...a single white
>space replaces each comment..." _before_ preprocessing directives are 
>executed.  The annotation recognizes that C preprocessors, unless adapted
>for use with C++, will not recognize the // comment form, but it also makes
>it clear that is is inappropriate behavior.

>It is a bug because it means you have to be _very_ careful about how you 
>comment your code.  For example,

>   #define MAX_WIDGETS   12    // maximum number of widgets available to the user

>   Widget user_widgets[MAX_WIDGETS];

>will not parse appropriately, leading to non-sequiter error messages.

*****>	I already pointed out that this only works on C++-ignorant
	preprocessors; the above example is a well-known pitfall and I
	consider it irrelevant.  You always have to do everything
	carefully.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Multiple Header Files Problem
Organization: Rational
Date: Thu, 12 Nov 1992 01:26:16 GMT

coller@alnitak.usc.edu (Lee D. Coller) writes:

|In article <rmartin.721442494@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
|>
|>What I had not realized, until you (and many others) pointed it out to
|>me, is that the #ifndef convention breaks inclusion cycles.  Of course
|>it does.
|>

|Actually it doesn't entirely solve the circular dependency problem.
|Consider two files, file a.h containing:

|#ifndef a_h
|#define a_h

|#include "b.h"

|class a {
|public:
|	b* _b;
|	void do_b_fnc() { _b->b_fnc(); }
|	void a_fnc();
|};
|#endif

|File b.h contains:

|#ifndef b_h
|#define b_h

|#include "a.h"

|class b {
|public:
|	a* _a;
|	void do_a_fnc() { _a->a_fnc(); }
|	void b_fnc();
|};
|#endif

This is an excellent example of the dangers of inline functions.  In
this case, the reason that class a or b cannot be forward declared is
because of the inline functions.  If the inlines are removed, then
both classes could be forward delcared and the cycle could be broken.


--
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: njs@planet.bt.co.uk
Newsgroups: comp.lang.c++
Subject: Re: comp.lang.c++
Date: 12 Nov 92 16:21:34 GMT
Organization: DNM42, BT Labs, Martlesham Heath, Ipswich, UK.
Originator: njs@andromeda


I have noticed many interesting but misplaced - for this newsgroup, e.g Goedel - discussions recently.  I would Imagine that major vendors would be well advised - as someone has suggested recently for Borland - to establish their own groups for their products that work on DOS.  It would be nice if this newsgroup were not filled with questions concerning esoteric matters about vendor specific compiler features and reserved its discussions to those issues concerning the USL cfront as this is closest to what 








an eventual ANSI standard will be.

It is not that I wish to restrict this group to theoretical questions about the language but I do feel that people using specific products, e.g Zortech or Borland or Glockenspiel etc., would be better served by a group that answered questions that helped them.  This newsgroup can't be everything to all, so we should attempt to define what it is for whom.

Nathan
Newsgroups: comp.lang.c++
From: rowe@netcom.com (Rick Rowe)
Subject: Need help for Newsletter
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 5 Nov 1992 05:08:01 GMT


Hi,

I am the editor of a C Newsletter. We are just starting to cover
C++ and need articles on OOP, transitioning from C to C++ (i.e.
function oriented paradigm to object oriented paradigm), etc.

The folks at Taumetric Corp. have been a great help. Was wondering
if anyone else out there would like to contribute. All articles are 
welcome and will eventually be printed. 

The newsletter is far from breaking even. But as an educator, I
love communicating with so many students and instructors. Since I
teach part-time, I put those $$ towards generating the newsletter and
mail the newsletter out to over 1000 colleges and universities around
the world. So, think of your contributions as a way of helping others
learn.

I am also picking out interesting interchanges from this news group
and have included some of the C++ FAQ. But articles from ya'll
dealing with applications, learning C++, etc. are needed.

Much thanks. Please e-mail any submissions to me. I will summarize
all titles of received write-ups and will post it. Anyone interested
can e-mail me and i will route them to ya. The articles do not need
to be polished, but make sure the code examples work. 

Thanks again, 
Rick



-- 
===========================================================================  
Rick Rowe - The C Programmers Network Newsletter+_   int x=10,y=20;       |
Editor      Internet: rowe@netcom.com           +_   x=x^y; y=y^x; x=x^y; | 
On a clear day you can C forever!               +_   /* getting dizzy? */ |
Organization: The American University - University Computing Center
Date: Tue, 10 Nov 1992 12:44:43 EST
From: Kayvon Z. Sadeghi <KSADEGH@auvm.american.edu>
Newsgroups: comp.lang.c++
Subject: thanks: const char *

to all of you who answered: thanks



k1
Newsgroups: comp.lang.c++,comp.std.c++
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Subject: Re: something nasty report
Originator: sasghm@theseus.unx.sas.com
Date: Tue, 10 Nov 1992 20:32:08 GMT
Organization: SAS Institute Inc.


In article <1992Nov10.192157.20810@BofA.com>, dan@BofA.COM (Dan Brockman) writes:
|> re:
|> During a C++ compilation ...
|> "Leg1.c", line 87: internal <<AT&T C++ Translator 
|> 2.1.03 08/31/90>> error: bus error (or something 
|> nasty like that)
|> Compilation failed

                    ...

|>  The error message may be symptomatic of a broad range
|>  of problems, for many tentative diagnoses were 
|>  nominated.  I found one problem.  It occurs in that
|>  part of the C++ translator called "cfront".  It is 
|>  not clear to me whether cfront contains a bug.

When a compiler dies with an internal error, causes an access
violation, etc. it is *always* a bug.
-- 
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
Newsgroups: comp.lang.c++
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Making qsort type-safe
Date: Mon, 09 Nov 1992 15:57:23 GMT
Organization: Security APL, Inc.

In article <dak.721261218@messua> dak@messua.informatik.rwth-aachen.de (David Kastrup) writes:
>walduck@mpr.ca (Andrew Walduck) writes:
>Quicksort needs some tuning to get really good. Fisrt, you should use
>the median 3 algorithm for choosing your pivot, and take the median of
>first, middle, and last element. That way, presorted data will partition
>perfectly. In addition, the O(n^2) worst case becomes REALLY improbable.

An interesting fact: if the array is sorted exactly backwards, this method
is still O(n^2).  If you use median of 2nd, middle, and next to last, you
avoid this problem.  (You should be reverting to insertion sort for small
sub-arrays, anyhow.  This makes a significant difference, whatever the size
of the initial array.)

Also, when the object in the array is equal to the pivot, move it.
Otherwise, you will get O(n^2) behavior when the data to be sorted is all
the same.

>If you are sorting linked lists, however, use a mergesort

Absolutely.