HDTenEightyP/NetNews huggingface dataset:
From: dak@messua.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: Making qsort type-safe
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date:  8 Nov 92 22:20:18 GMT

walduck@mpr.ca (Andrew Walduck) writes:


>It is precisely due to this behaviour that I prefer heapsort to quicksort...
>Quicksort performance can rapidly approach O(N^2) as the list becomes closer
>to being sorted!! (It depends how the pivot is chosen...)

>Many people think of qsort as an O(nlogn) sort...it isn't. Its average
>case is O(nlogn)...but its worst case is O(n^2) (the same as a bubble
>sort!!) This behaviour, when combined with its stack requirements, is
>why I prefer heap sort. In all cases, it performs as an O(nlogn) sort...
>and it can be implemented in 2 success loops...(about 30 lines of code
>or so...)

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.

Secondly, you should look which of the two partitions you get has less
elements and sort that partition first in recursion. THEN sort the second,
larger size partition by a tail recursion. That way, your stack space
will be strictly O(lg n) even in worst case.

If you are sorting linked lists, however, use a mergesort, which combines
sorting a sublist with scanning to the head of the next sublist.

Short code, guaranteed LESS than n lg n comparisons, guaranteed at most
lg n recursion depth, no data copying, etc. And you need no tricks (as
opposed to quicksort) to let it work well behavedly. Beats average quicksorts
by a factor of more than 2 (at least in Turbo C it does.)
Newsgroups: comp.lang.c++
From: scannell@bubba.ma30.bull.com (P Scannell)
Subject: Re: Just what is so great about streams?
Reply-To: P.Scannell@bull.com
Organization: Bull HN, Worldwide Information Systems, Billerica, Mass., USA
Date: 12 Nov 92 12:03:12

In article <1992Nov12.061942.16473@nuscc.nus.sg> tim@gold.iss.nus.sg (Tim Poston) writes:

   a number very near zero should _not_ be output as 1.472e-6
   It should be 0.0, or PostScript will barf.

   So I have to use a function call to say
   "Please Mom, I want the next one decimal,"
   pass a number,
   say "Please Mom, I want the next one decimal,"
   pass another number,
   say "Please Mom, I want the next one decimal,"
   pass another number,...

I may be wrong, as I haven't mucked with streams in a while,
but it seems to me that the C++ way to handle this
situation would be to derive a postscript stream class
whose "<<" operator for floating point handled
the case as desired.  The whole point of a stream
CLASS is that it allows you to do that sort of thing.

The fact that a lot of compilers have buggy implementations
has no bearing on whether the concept is good or bad.
--
 == Pat Scannell                      Bull HN Information Systems Inc. ==
 == (508) 294-2190                    300 Concord Road   MA30-826A     ==
 == P.Scannell@bull.com               Billerica, MA 01821              ==
Newsgroups: comp.lang.c++
From: srheintze@happy.colorado.edu
Subject: Overload operator to concatenate Strings?
Organization: University of Colorado, Boulder
Date: 13 Nov 92 11:14:15 MDT

I have a question concerning the book "C++ Programming Guidelines" 
by Thomas Plum and Dan Saks.

On page 91 they discourage programmers from overloading operator||. They
say "Because of any form of overloading destroys the 'sequenced' property
of &&, || and comma, these operators should seldom (if ever) be overloaded."

What is the issue here? Are we talking about a maintainence programmer's 
expectation of what operator|| or operator&& do or are we stating 
that we should not overload operator|| (to concatentate strings, 
for example) because the compiler might not evaluate the second 
argument in all cases?

It seems logical to use some operator to concatenate strings. It seems to 
me that character strings really should be defined as a vector of char since
that is what they really are.  If we do that however, it is inappropriate to
use operator+ because that means add two vectors.

I have considered using operator|| but Plum and Saks discourage it for reasons
I don't completely understand.  It is intuitive to old PL/I programmers to use
operator|| for character string concantenation. It seems logical to be
consistent with something that already exists rather than invent some new
notation.  However, I have my own reason for not using operator|| for character
string concantenation:  I recently discovered there is no operator=||!

So I don't like operator+, neither I nor Saks like operator||, what should we
use?  How about operator& for character string concatenation?

So, I would love to hear your recommendation on (1) what Plum and  Saks meant
when they discourage the overloading of operator|| and (2) what you recommend
be used to concatenate strings.

			Thanks,
					Sieg

  Thanks,
     Sieg

Xref: sparky comp.lang.c++:15838 gnu.emacs.help:4707
From: ethanb@ptolemy.astro.washington.edu (Ethan Bradford)
Newsgroups: comp.lang.c++,gnu.emacs.help
Subject: Re: Emacs mode for C++
Date: 6 Nov 92 00:03:31 GMT
Article-I.D.: ptolemy.ETHANB.92Nov5160331
Organization: U. of Washington
To: hughg@brutus.ee.su.oz.au (Hugh Garsden)

From lispdir:

	   GNU Emacs Lisp Code Directory Apropos -- "C\+\+"


c++-mode-2 (1.0)  87-12-08
     Bruce Eckel,Thomas Keffer, <eckel@beluga.ocean.washington.edu,uw-beaver!beluga!eckel,keffer@sperm.ocean.washington.edu>
     archive.cis.ohio-state.edu:/pub/gnu/emacs/elisp-archive/as-is/c++-mode-2.el.Z
     Another C++ major mode.
c++-mode (2.195)  92-08-28
     Barry A. Warsaw, <c++-mode-help@anthem.nlm.nih.gov>
     archive.cis.ohio-state.edu:/pub/gnu/emacs/elisp-archive/modes/c++-mode.el.Z
     Mode for editing C++ code (was Detlefs' c++-mode.el)
c-support (46)	  89-11-04
     Lynn Slater, <lrs@indetech.com>
     archive.cis.ohio-state.edu:/pub/gnu/emacs/elisp-archive/misc/c-support.el.Z
     Partial support for team C/C++ development.
Newsgroups: comp.lang.c++
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Borland Debugger/Win3.1 question
Organization: Texas Instruments Inc
Distribution: usa
Date: Thu, 5 Nov 1992 16:07:40 GMT

In <Bx7CsB.KIy@Interlan.com> consigli@interlan.interlan.com (Frank Consiglio) writes:

>Hi everyone.  Question: does the debugger included in Turbo C++ v3.0 
>for Windows operate under MS Windows v3.1?  Windows is reporting a DLL
>missing when I try to install the debugger under Win3.1.

>Feel free to send mail with any relevent experiences.  Thanks.

I believe there is a patch for this.  When Microsoft rolled from
Windows 3.0 to Windows 3.1, they broke the debugger.  I'm speaking
from experience with Borland C++ rather than Turbo C++, but I suspect
the same problem would occur with both.  There was both a patch for
Borland C++ 3.0 and a new revision to Borland C++ 3.1.  You may need
to contact Borland for the patch (since I don't think they rolled the
version on Turbo C++).

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.lang.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: 'new' syntax?
Date: Fri, 13 Nov 1992 12:46:12 GMT
Organization: University of Birmingham

In article <1992Nov13.095152.26819@rs6000.bham.ac.uk>, pickerig@eee.bham.ac.uk (Mr. G. Pickering) writes:
> I want to create an array of 'size' long**, is the correct syntax:
> 
>   long*** new_blocks = new (long**[size]);
> 
> I am having memory corruption problems and suspect this is not doing
> what I really want.
I have trouble with the new operator myself I normally give up trying to
understand the syntax and use a local typedef.
{
  typedef long **longPtrPtr;
  longPtrPtr *new_blocks = new longPtrPtr[size];
}
Possibly not the most elegant solution but at least it works.
--
    \\   ( )    No Bullshit!   |  Email: B.A.McCauley@bham.ac.uk
 .  _\\__[oo        from       |  Voice: +44 21 471 3789 (home)
.__/  \\ /\@    /~)  /[   /\/[ |    Fax: +44 21 625 2175 (work)
.  l___\\      /~~) /~[  /   [ |  Snail: 197 Harborne Lane,
 # ll  l\\    ~~~~ ~  ~ ~    ~ |         Birmingham, B29 6SS, UK
###LL  LL\\   (Brian McCauley) |   ICBM: 52.5N 1.9W                                                                       
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Just what is so great about streams?
Organization: TauMetric Corporation
Date: Thu, 12 Nov 1992 17:55:53 GMT

tim@gold.iss.nus.sg (Tim Poston) writes:

>This posting is a genuinely answer-seeking question,

>  what _is_ so great about streams?

Streams are not the best solution for all I/O or formatting problems.
Streams provide useful solutions to common I/O and formatting problems.

Streams provide type safety, generalization of I/O, and user
extensibility.  These features are not available in C stdio.

1. Type safety:  Printf and scanf provide no verification that the
format codes match in number or type the parameters passed.  This is
frequent cause of program failures which are hard to find.  More
subtly, there are no formatting codes which portably correspond to
the standard types size_t, ptrdiff_t, or wchar_t:
	size_t x;	// is it sizeof int or sizeof long?
	scanf("%u", &x); // might work, might give wrong anwser
	scanf("%lu", &x); // might work, might trash the stack
Portable code has to work around this problem.

2. Generalization of I/O:  If 's' is (derived from) an ostream, you can write
	s << foo;
without knowing or caring whether it is a file, a string, or some
other kind of device.  You have to use separate calls based on
external information with stdio.

3. User extensibility:  You can define your own "shift" operators for
your own types, and do I/O without the need for special function calls:

	typedef ... T;
	ostream& operator<<(ostream&, const T&);
	istream& operator>>(istream&, const T&);
	...
	extern T t;
	cout << t;
	cin >> t;
The last two statements continue to work unchanged even if the type of
T is changed.  (You could get comparable functionality with overloaded
I/O functions in C++ using stdio internally instead of streams.)
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: bbrown@willamette.edu (Brian Brown)
Newsgroups: comp.lang.c++
Subject: Borland's OWL -- How can I find it?
Date: 12 Nov 92 19:27:07 GMT
Organization: Willamette University, Salem OR

Where can one find Borland's Object Windows Library?  I thought it came
with Borland C++ 3.0 compiler, but I found a copy of it, and no OWL. 
Everything else is there, as far as I can tell.

Is there a copy of the OWL at an FTP site somewhere?

Please help!  I don't want to attempt Windows(tm) programming without it!
Thanks.

-- 
----------------------------------------------------------------------------
bbrown@willamette.edu  (Brian W. Brown, Hailing from Salem, Oregon)
Remember:  57% of the voters in the United States voted AGAINST Bill Clinton
----------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: pickerig@eee.bham.ac.uk (Mr. G. Pickering)
Subject: Bad 'for' statement?
Summary: for statement fails under AT&T C++
Date: Thu, 12 Nov 1992 16:04:20 GMT
Organization: The University of Birmingham, England
X-Newsreader: TIN [version 1.1 PL6]
Keywords: AT&T for

Hi,

Could you tell me if this is really a syntax error as AT&T 2.1 reports?

  for(int i=0, int j=10;   i<10;   i++, j++)
  {
    // do something
  }

Thanks,

Guy

--
+--------------------------------+-----------------------------------------+
| Guy Pickering                  | School of Electronic & Electrical Eng,  |
| E-MAIL: G.PICKERING@uk.ac.bham | University of Birmingham,               |
| Tel: (021) 414 4340            | Edgbaston, Birmingham. B15 2TT.         |
+--------------------------------+-----------------------------------------+
| "I have ten pairs of trainers...One for each day of the week" - Sam Fox  |
+--------------------------------+-----------------------------------------+


Newsgroups: comp.lang.c++
From: martid@vccsouth21.its.rpi.edu (David Martin)
Subject: Referencing `...' arguments in functions
Organization: Rensselaer Polytechnic Institute, Troy NY
Distribution: usa
Date: Mon, 9 Nov 1992 18:22:31 GMT


I wish to write a function having an unknown number of arguments.  I know
that the '...' in the function declaration will allow for any number of
arguments, but how do I actually access these variables.

If there is a solution to that question (which I'm sure there is), is
there any way for me to know the number of arguments and, more
importantly, the variable type of each argument?

Thanks for your help.  I would appreciate responses through e-mail since
I am not a frequent usenet reader.
From: kilitzir@antigone.csi.forth.gr (Xristos Kilitzirakis)
Newsgroups: comp.lang.c++
Subject: yagh!(yet another hard g++ (problem))
Date: 12 Nov 1992 14:28:08 +0200
Organization: Institute of Computer Science, FORTH Hellas
NNTP-Posting-Host: antigone.csi.forth.gr

Suppose the following program :
----------------------

#include <ostream.h>
class base {
              int ss;
		public:
		virtual show() { cout <<"bbb ";}
};

class derived:public base {
		int ff;
  		public:
		virtual show(){cout << " dddd";}
};
//-------------
base f1()
{
derived d;
return d;
}
//------------
derived f2()
{
derived d;
return d;
}
//-----------
main()
{
base x = f1();
x.show();
x = f2();
x.show();
base x2 = f2(); // Compiler error
x2.show();
}
-------------------------
1.(compiled under g++ with unknown version).
Now, there's a compiler error in line "base x2 = f2()" - YET the 
statement "x = f2();" IS CORRECT!Any comments ?
2.What do you expect for the program to write ???
answer --> bbb bbb !
Is that also correct ???


XXXristos K.


mail yr e-mail  at
kilitzir @csd.uch.gr
kilitxir@csi.forth.gr

"I love making people crazy"
From: andy@federation.gatech.edu (Andy Register)
Newsgroups: comp.lang.c++
Subject: Re: how to initilize an array inside of a class??
Date: 13 Nov 92 15:54:36 GMT
Organization: CERL-EE, Georgia Institue of Technology

As long as there is no ctor or dtor, you could do:

// ***************************************************************
#include<iostream.h>
#include<stdio.h>

class X {
  public:
    enum {ARR_SIZE=10};
    int SomeInts[ARR_SIZE];
    void Write();
};

void X::Write()
{
	for (int i=0 ; i < ARR_SIZE ; i++)
		cout << SomeInts[i] << "  ";
	cout << endl;
}

void main() {
  X Some = {10, 20, 30, 40, 50, 100, 90, 80, 70, 60};
  Some.Write();
}
// ***************************************************************

Toodles
Andy
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Discriminating Variant Records Without switch() ??
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 12 Nov 1992 22:37:35 GMT

In article <BAB.92Nov11075454@se39.wg2.waii.com> bab@se39.wg2.waii.com (Brian Button) writes:
>The point I'm trying to make is that there is no common set of
>operations which may be performed on these arbitrary objects.
>
>Since the set of operations is not common, we need to know the type of the
>object before proceeding with processing. Have we painted ourselves
>into a corner? It seems that we need a switch() to do this, but in a
>proper OOP design, it shouldn't be necessary.
>

	Yes, it should be necessary. To me the implications of
a common base with arbitrary derived classes are that there is indeed
a single set of common operations that are known statically.
Then polymorphism allows this homogenous interface to be used
to access (via virtual functions) different derived objects.

	In the case of many unrelated classes one cannot use
polymorphism. To access each object you must know its type
statically, and the switch is the only way to do this, you must
select physically different code for processing each object,
and the number of said objects must be known and fixed
and embodied in separate physical code.

	The key problem here is to have an arbitrary set of
application programs P1, P2 .... each with a finite and fixed
set of classes interfacing with a single server which can store
arbitrary objects without losing the type information.

	One way to do that is to set up a global registry.
 

-- 
;----------------------------------------------------------------------
        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: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: Making qsort type-safe
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Tue, 10 Nov 1992 13:46:51 GMT

In article <1992Nov09.155723.112061@Cookie.secapl.com> frank@Cookie.secapl.com (Frank Adams) writes:
>In article <dak.721261218@messua> dak@messua.informatik.rwth-aachen.de (David Kastrup) writes:
>
>>If you are sorting linked lists, however, use a mergesort
>
>Absolutely.

I have sometimes sorted linked lists by creating an array of pointers to data,
sorting this array using my modified qsort, and then adjusting the linked list
pointers.  I have not noticed this to be grossly inefficient.  That way I just
had a few lines of coding to do to be able to use existing code.  Is there a
problem with my approach?

Also, if the comparison function is at all complicated (like comparing field a,
and if that is equal, compare field b) I do a first pass through the data to
construct a temporary array of the fields I want to compare in the correct order.
The purpose of this is to simplify the comparison function as much as possible.
It also reduces paging problems with qsort on huge collections.  If I want to
do a pass like this anyway, I see no reason to have the temporary collection
in a linked list.  So what exactly do you mean by "Absolutely"?  Under all
circumstances it is the best thing to do?

On a slight variation of this topic:  the Lipmann code for qsort compares 
two objects using operator<().  That is,  "a < b".  But there can be more than
one sort order on a collection.  I could sort people by name or by birth date.
The actual ordering of the objects in the collection is a property of the
collection, not of the objects themselves.  How is this best resolved?
Should the objects in the collection be able to compare themselves according
to different orderings?  Is operator<() enough?  Surely it is not a good idea
to have the collection class know details of how to sort the objects in the 
collection.

Stuart
--
: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
Newsgroups: comp.lang.c++
From: robert@slipknot.rain.com (Robert Reed)
Subject: Re: const char *
Reply-To: robert@slipknot.rain.com.UUCP (Robert Reed)
Organization: Home Animation Ltd.
Date: Sat, 7 Nov 1992 20:49:46 GMT

In article <92311.184452KSADEGH@auvm.american.edu> Kayvon Z. Sadeghi <KSADEGH@auvm.american.edu> writes:
|I have this subroutine call that says:
|mycall("");
|and then somewhere down in my code I have:
|
| mycall(const char *msg){
|     if(msg=="")
|          dothis();
|     if(msg!="")
|          dothat();
|}
|
|Strange, but my compiler doesthat() instead of dothis().
|I even checked the value of msg and it *IS* equal to "". Is something wrong
|with my C++ compiler or what? or are strings treated differently in here?

The problem is obvious.  Your "" is not the same as your "".  Remember that
what you're really defining here is a pointer to a string that contains no
non-NUL characters, but that doesn't mean the pointers have to be the same.
Try something like:

const char *Empty = "";

mycall(const char *msg) {
	if (msg == Empty)
		dothis();
	else
		dothat();
________________________________________________________________________________
Robert Reed			Home Animation Ltd.		503-656-8414
robert@slipknot.rain.com	5686 First Court, West Linn, OR 97068

Why is it a penny for your thoughts, but you have to put your two cents
in?  Somebody's making a penny.
--Steve Wright
________________________________________________________________________________
Newsgroups: comp.lang.c++
From: duvalld@liberty.uc.wlu.edu (Danek Duvall)
Subject: Serializing Multiple Objects
Date: Fri, 13 Nov 1992 20:53:31 GMT
Distribution: local,world
Organization: Washington & Lee University
X-Newsreader: Tin 1.1 PL5


I have been slowly learning C++ in my spare time with MSC/C++7.0.
Everything has been going OK, but I ran into an interesting problem when
using the serialization properties. I wanted (as a test) to create three
objects and serialize them to a file inside of a for loop. It serialized
something, but always only the first of the objects get serialized and
then later read back in. Funny thing is, I looked at the file, and among a
little binary garbage, there was only the text for that first object...but
only once!  My question is, why would it, given three serialize commands,
only serialize once, and then, given three deserialize commands,
deserialize the same object three times without ever returning an error or
throwing an exception? Is this at all possible? Do I need to create a list
for these objects and then serialize one list? (I am going to have to
anyway, but I'd like to know.)

Thanks

Danek


-- 
Danek Duvall: Washington and Lee U.
Internet: duvalld@liberty.uc.wlu.edu
***
Newsgroups: comp.lang.c++,comp.std.c++