HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: BORLAND C++ ; new int(1,000,000)
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sun, 3 Jan 1993 02:52:14 GMT

In article <9300302.976@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>mwb@ulysses.att.com (Michael W. Balk) writes:
>
>>ghica@fig.citib.com (Renato Ghica) writes:
>>> 
>>> Is it possible to allocate more than 640K (from extended or
>>> expanded memory) on a DOS 5.0 system using a borland 3.1 C++ program?
>>> 
>>> Using the huge memory model, I'm trying to do the equivalent of 
>>> 	new int(1,000,000);  
>>> I have not successed. (I know I can allocate 64k+ at the time).
>
>new int(1000000) is *dynamic* allocation, so the limitations on *static*
>data don't apply. It is possible to allocate objects >64k, I think, but
>not >640k. (Get a _real_ operating system, like Linux, not this horrible
>MSDOS :-)
>
	int * x = new int[1000000];

will not work. Neither will

	int* x = new int[36000]; // >64K

because operator new takes an argument of type size_t which is only
16 bits ( at least in the large model ).

	The restrictions on MS-DOS are those of the 8086 processor.
There is NO 640K limit, the limit is 1Meg. (I know, I had 
a machine with 720K RAM available to MS-DOS). Actually, under
DOS-5 for the 386, the limit is 1Meg + 64K due to a quirk of
the 386 processor in real mode.

	I am yet to be convinced Unix is a particularly good
operating system either. Its principal advantages are exactly
those of MS-DOS: wide availability of software and familiarity.

	Maybe Plan-9 will be better :-)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: sasha@ipm.msk.su (Alexander Kolbasov)
Newsgroups: comp.lang.c++
Subject: Re: Need help implementic data structures of generic objects
Date: Mon, 21 Dec 92 16:54:14 +0300
Distribution: world
Organization: unknown
Reply-To: sasha@ipm.msk.su

mat@mole-end.matawan.nj.us (Mark Terrible) writes:

> The template should describe the nature of a collection; the template
> should be instantiated for the type of the thing being collected.
> With the exception of collections of things to freeze and thaw and
> a few like problems, there are no truly heterogenous lists in problems.
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> You are collecting objects because you are going to gurklemont them;
> then you have a list of gurklemont'ables, NOT a list of wholly anonymous
> Objects.

First of all the question: Are you SURE that there are no truly heterogenous
lists in problems?

Suppose that you design a collection class for the library. You don't know,
who and how will use it. You design the collection abstraction. The ONLY
service of the Collection abstraction is to store something provided by its
clients and to retrieve the SAME THING that was stored. There is nothing in
the Collection abstraction that should know what kind of things does it
contain. It doesn't matter. And there is no reason (except some language
limitations) for the collection abstraction to be strictly homogenous.
Homogenous Collection is a very limited subclass of general Collection. And I
bet that great manu users will find the Collection of anything very very
useful. As for your statement, I'd restate it in the following way:

There are problems without truly heterogenous lists.

                        - Sasha -
__
.......................................................
. Alexander V. Kolbasov  |  INTERNET sasha@ipm.msk.su .
. Moscow, Russia         |  (095) 434-2031 (o)        .
.......................................................



Newsgroups: comp.lang.c++
From: ghica@fig.citib.com (Renato Ghica)
Subject: Re: Problem with BC++ 3.0 TLINK and missing symbols
Originator: ghica@duck
Organization: Citibank IBISM
Date: Wed, 30 Dec 1992 23:28:59 GMT


In article <33820012@hpcuhe.cup.hp.com>, defaria@hpcuhe.cup.hp.com (Andy DeFaria) writes:
|> I have been receiving errors from Borland C++ 3.0 of the form:
|> 
|> 
|> Linker Error: Undefined symbol foo<int>::foobar() in module BAR.C
|> 
|> given the following files:
|> 
|> FOO.H:
|> ------
|> template <class TYPE>
|> class foo {
|>    private:
|>       int i;
|>    public:
|>       void foobar (void);
|> };
|> 
|> FOO.C:
|> ------
|> #include "foo.h"
|> 
|> template <class TYPE>
|> void foo<TYPE>::foobar (void) {
|>   i++;
|> } // foobar
|> 
|> BAR.C:
|> ------
|> #include "foo.h"
|> 
|> void main (void) {
|>    foo<int> x;
|> 
|>    x.foobar ();
|> } // main
|> 
|> These example is a chopped down version of the real one that I had originally
|> had had problems with.  Notice that there is no need for a template anymore as
|> TYPE is not really used.  I am using Borland C++ 3.0 and in the IDE I create a
|> project file that has both FOO.C and BAR.C.  Every thing compiles but fails to
|> link with the above message.  Why?


with BC 3.1,

The linker does not see the definition of foo<int>::foobar().
This is because pre-compiling the foo.c file does not implement
the <int> instantiation. This does not seem to be the case in other
compilers (ie SUN's).


solution:

I'm not saying this is the best, but it works for me. I've tried
various #pragmas switches before giving up and going the brute force
method:

[conditionally include foo.c or move the foo.c source into foo.h]
in foo.h
ie

FOO.H
// template function definition

#ifdef SOMEDEF
#include <foo.c>
#endif

This way the compiler will "generate" the member function template
definition at compile time.
---------------------------------
-- 

"delete *this"

"These views are my own. / Mail me or Flame me"
From: reznick@acf3.nyu.edu (Daniel Reznick)
Newsgroups: comp.lang.c++
Subject: Intersting Data Structure
Date: 21 Dec 92 21:35:52 GMT
Organization: New York University

Can anyone suggest a feasable Data Structure/Class Hierarchy to
implement a Rubik's Cube?

Daniel Reznick
reznick@acf3.nyu.edu
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Virtual base classes
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 23 Dec 1992 15:49:29 GMT

In article <449@genie.UUCP> roger@genie.UUCP (Roger H. Scott) writes:
>In article <724475492snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk writes:
>>In article <445@genie.UUCP> roger@genie.UUCP (Roger H. Scott) writes:
>>> If Kludge is a non-public subclass of WellFormed then there

	Please say 'base' and 'derived' or you'll confuse me. 
I assume you mean that WellFormed is a private base of Kludge?

>>> isn't much point in talking about Kludge redefining WellFormed's virtual
>>> functions since you can't use a Kludge in a place where a WellFormed is
>>> expected (i.e., who would ever have hold of a Kludge and send it one of
>>> WellFormed'd messages, other than a member function of Kludge?).
>>
>>Imagine that WellFormed's constructor adds all WellFormeds to some 
>>Collection of WellFormeds. Notice that all Kludges will also be added to 
>>this collection. Now imagine some calling some virtual function for all 
>>WellFormeds in the Collection.
>
>This seems to raise an interesting question: does there exist an Is-A
>relationship between Kludge and WellFormed, 

	If this was intended, Kludge should have been derived
using public virtual inheritance:

	class Kludge : public virtual WellFormed { ..

>and if not, what does it mean to
>have a collection of objects that *claim* to be WellFormeds but are in fact
>Kludges?  

	If we have

	class Kludge : private WellFormed { ...

it is not so easy to obtain a pointer to the WellFormed to put
in the collection. In particular, a cast by the public wont work 
because WellFormed is a private base. 
Given that WelFormed is closed and locked away in
the library, how would Kludge get access to the WellFormed subobjects
address?

	Can Kludge perform the cast?

	WellFormed *Kludge::GetWellFormed()const 
		{ return (WellFormed*)this;}
	// legal ??

>Do we see a small whole in the type system here, where within
>member functions inherited from a non-public base class an object which
>is in fact a Kludge can be used interchangably with an object that is a
>WellFormed (the example cited by Nikki uses the base class's constructor, but
>any member function of the base class will do)?  I'd like to see some sort
>of comprehensive statement about the (intended? actual?) semantics of non-
>public inheritance in C++.

	The statement is just the ARM. For a critique try

"A Critique of the Inheritance Principles of C++" by
Markku Sakinnen, Computing Systems Vol 5 No 1.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: kaelin@Bridge.COM (Kaelin Colclasure)
Newsgroups: comp.lang.c++
Subject: C++, Without Exceptions
Keywords: exceptions exception handler setjmp longjmp
Date: 22 Dec 92 21:44:08 GMT
Organization: Bridge Information Systems

I have been trying for over a week now to track down a copy of the paper
"C++, Without Exceptions" by Johan Bengtsson of Telia Research.  I have
yet to obtain a single lead.  If any kind soul out there could point me
at an archive site with a copy, I`d be most grateful.

Kaelin Colclasure
kaelin@bridge.com

Newsgroups: comp.lang.c++
From: jlnance@eos.ncsu.edu (JAMES LEWIS NANCE)
Subject: Newing a pointer to a pointer
Originator: jlnance@chow2.ece.ncsu.edu
Reply-To: jlnance@eos.ncsu.edu (JAMES LEWIS NANCE)
Organization: North Carolina State University, Project Eos
Date: Tue, 29 Dec 1992 17:48:43 GMT


I am attempting to learn C++.  I have declared a class called list and class
called generic.  In generic, lspace is declared as:

list **lspace.

Both g++ and cfront tell me that the line containing new in the following 
constructor has a syntax error.

generic::generic() {
this->lrow   = 100;
this->lcol   = 100;
this->lsize  = 0;
this->lspace = new *list[lcol];
this->addrow();
printf("Constructing element\n");
}

Can someone tell me what I am doing wrong?

Thanks,

Jim Nance
From: ANDREW@odin.uniras.dk (Leif Andrew Rump, Software Engineer, UNIRAS A/S)
Newsgroups: comp.lang.c++
Subject: Re : Converting EXE c++ files back to source code
Date: 30 Dec 1992 04:45:53 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

twb51@isuvax@iastate.edu answer to this letter was
>> I have some old C++ programs that I written 2 or 3 yrs ago.  I have more 
>> EXE files than C++ source code.  Some of these programs I've written are
>> quite good but I only have the EXE file that the compiler created.  I
>> was wondering if there is a way to convert the EXE files back to there
>> original source code?  Can it be done?
>
>It is not possible to do this! If there was such a tool, then it would be
>a lot easier for us to modify all EXE and COM programs out there.

This is going to be an academic answer  :-)  I would say it is possible
to decompile a program but only IF and only IF you as the programmer of
the decompiler know the inner structure of the compiler. You must know
what code blocks the compiler would use in each program construction (if,
case, while, functions...) and how it optimize the code - I didn't say it
would be easy! The decompiler will of course not be able to reconstruct
the original indentation of the code and if the symbol table has been
stripped off it has to fall back on variable V0..V99 and so on. It will
probably also have problems finding out if a variable is part of a class/
structure - and unions will also cause a bit of a headache - hmm - it may
not be possible to do more than just a half heartet job!  :-(

HAPPY NEW YEAR!!!

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

Project: Toolmaster-UIM/X (tux)
Plan:
begin 644 plan
M5&AI<R!S<&%C92!H87,@=6YI;G1E;G1I;VYA;&QY(&)E96X@;&5F="!B;&%N
L:RXN+@H*"0D)"0E!;F1R97<**$-O<'ER:6=H=" H8RD@1&]U9R Q.3DR*0IN
 
end
From: steve@taumet.com (Steve Clamage)
Subject: Re: Simulate "Pointer to char" by an array
Organization: TauMetric Corporation
Date: Thu, 31 Dec 1992 17:04:49 GMT

cmchan@dcs.warwick.ac.uk (C M Chan) writes:


>How can I simulate "pointer to char" by an array in a class whose size will be
>delayed to be defined at run time?
> 
>For example,
> 
>     class X {
>     private:
>             char string[      ];    /* not define size of the array */
>                              ^^^^^^^^
>     public:
>             ...............
>     };

You cannot have an incomplete type as the member of a class (or struct,
even in C).  You may be thinking of this C trick:
	struct foo {
	    ...
	    char string[1]; /* last member of struct */
	};
	...
	struct foo *fp = malloc(sizeof(foo) - 1 + SIZE);
You then treat fp->string as if it had SIZE elements.  It is probably
not legal in C, but it seems to work on most if not all implementations.

Do NOT do this with a C++ class!

This trick breaks the type system, and you are lying to the compiler
about the type of such objects and pointers.  The exact composition
of a class is wired into a lot of C++, and you may find bizarre
program behavior.

If you want to defer choosing the size of the array until run time,
make "string" a pointer and allocate the space with "new":

	class X {
	    char *string;
	public:
	    X(size_t size) { string = new char [size]; }
	    ~X()           { delete [] string; }
	};

Although this seems to add another indirection to string access, I
think you will find in practice that the difference is negligible.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c++
From: nkripoto@rd.hydro.on.ca (Nick Kripotos (T))
Subject: Is this a Bug in Borland C++ 2.0
Organization: Ontario Hydro - Research Division
Date: Tue, 22 Dec 92 20:01:26 GMT

Hello there everyone.  I have a small problem which is more of a nuisance
and would like to fix it.

I have a piece of code which compiles and links no problem.  However sometimes
when I try to run the executable the computer will crash or I get a message
like the following:

    Abnormal program termination
    Floating point error: Domain

Sometimes all I do is add a simple printf statement and the program crashes
when I try to execute it.  This usually happens after a few normal compilations
and then a crash will occur

I think it must be the way I'm allocating memory but I can't tell.

Here is a chuck of my code:

#define MAX_READ_BYTES 65532
#define unsigned int SIGPT

ulong MaxBufPts;
SIGPT *DBuffer;

etc.

if ((MaxBufPts=farcoreleft()/sizeof(SIGPT)))>MAX_READ_BYTES/sizeof(SIGPT))
  {
   MaxBufPts=MAX_READ_BYTES/sizeof(SIGPT);
  }
if ((DBuffer=(SIGPT *)farmalloc(MaxBufPts*sizeof(SIGPT)))==NULL)
  { 
  printf("Not enough memory");
  }

etc.

farfree(DBuffer);

end

At first I didn't have the farfree(DBuffer) line but then I added it and
I still get the occasional crash.

If anyone has any ideas or suggestions please post or e-mail me at

kripotos@ice5.kcps.rd.hydro.on.ca

Thanks
Nick
Newsgroups: comp.lang.c++
From: tostan@dumbo.lerc.nasa.gov (Stan Mohler)
Subject: where the name C++ came from
Organization: NASA Lewis Research Center
Date: Wed, 23 Dec 1992 16:27:58 GMT

Hi-
I had a dream last night in which I figured out a possible reason for C++
having the name C++.  Yesterday I was reading about C and C++.  I skimmed
across a few lines showing the use of operators such as ++.  i++ measns to
increment variable i.  Incrementing something means to increase it, expand it
if you will.  Is it possible that "C++" simply means an "expanded C" in the
most economical and cute way a C programmer might think of?

-- 
-----------------------------------------------------------------------------
Stan Mohler
NASA Lewis Research Center     	|    
Cleveland, Ohio  44135         	|     email: tostan@dumbo.lerc.nasa.gov 
-----------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: pauljo@microsoft.com (Paul Johns)
Subject: Re: Bug in BC/C++ 2.0 ?
Date: 29 Dec 92 01:38:02 GMT
Organization: Microsoft Corp., Redmond, Washington, USA
Keywords: bugs

In article <BzrsxL.7t9@hpuerca.atl.hp.com> aaa@hpuerca.atl.hp.com wrote:
> In article <1992Dec23.202206.29576@microsoft.com>, pauljo@microsoft.com (Paul Johns) writes:
> >
> > 2.  Put the size in the delete.  This is upwards-compatible:
> > 	it's ignored in AT&T 2.1 and 3.0.  This can be a little
> > 	bit of a pain, but it's probably cheaper than upgrading.
> 
> Not ignored in IBMC++

I'm wrong about this being upward-compatible according to the
standard.  The standard makes no mention of allowing a number
between the []'s.

It is a Microsoft (and perhaps others) extension to allow the
number and ignore it, allowing existing code to work without
modification.

// Paul Johns
Newsgroups: comp.lang.c++
From: feathers@serss0 (Michael Feathers)
Subject: Re: feedback wanted on appropriate OOPL
Organization: Florida International University, Miami
Date: Tue, 29 Dec 1992 13:15:41 GMT

In article <1992Dec28.173620.14793@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>2) Having just done an interview with a interview candidate who has
>an MS in CS, who claimed C/C++ as a primary language, but who couldn't 
>program simple problems in a straight-forward manner, using style
>appropriate for the C/C++ languages, I must again express frustration
>at CS departments who don't teach students the skills they need to
>get a job.  C is the mainstream programming language for the software
>industry.  C++ is the mainstream OO programming language for the
>software industry.  Non-mainstream languages are fine for PhD candidates
>who plan to remain in acedemia.

I once had it explained to me by a professor that universities are not in the
business of giving people the skills that they need to get a job.  Vocational
schools do that.  His opinion was that universities teach people how to learn
and give them wide exposure within a field.  The degree is nothing more than
an indication to a prospective employer that this person knows how to learn.

I know that practically all the skills that I use in developing software have
been reformulated severely after I graduated.  
 



Newsgroups: comp.lang.c++
From: euamts@eua.ericsson.se (Mats Henricson)
Subject: Re: Special-purpose-heap-managers - refere
Reply-To: euamts@eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Mon, 21 Dec 1992 10:26:20 GMT

In article 4338@daimi.aau.dk, sabroe@daimi.aau.dk (Morten Sabroe Mortensen) writes:
#euamts@eua.ericsson.se (Mats Henricson) writes:
#
#>In article 11510@daimi.aau.dk, sabroe@daimi.aau.dk (Morten Sabroe Mortensen) writes:
#>#Could anyone, -who have tried-, tell, what kind of experiences they have with 
#>#special-purpose-heap-managers like 'Pool', in what kind of program, with what 
#>#kind of result/speed-up? 
#
#>We did a test of several class libraries, of which one was using a Pool class.
#>In one test (putting and removing integers from a Set class) the Pool-based
#>solution was ~20 times faster. That was the extreme case. In another test the
#>gain was "only" 2.3 times.
#
#Nice, nice, - sounds interesting!!! 
#Are some of these classes, you tested, availably on the net - 
#do you remember where?

None of them can be fetched for free, I'm afriad - you have to pay for them!
I don't want to hang them out on the net, but I can tell you the Pool-class
library: USL Standard Components. Just to avarage out this free ego-boosting
for the USL crowd, I can tell you that you can find some rather messy code
in the USL SC (just an example):
   -->grep -c goto getbuf.c 
   5
i.e. 5 goto:s in one single file!

#>BUT REMEMBER: all this performance difference is NOT because of a Pool class.
#>The libraries differed in many other respects, which affected performance.
#
#>And then again: size and performance isn't everything...
#
#You're right! -size and performance isn't everything!
#
#BUT: If you want high performance, doing SOMETHING to dynamic allocation
#     seems to be one of the better ways to gain speed, i think! 
#     _IF_ allocation could be handled transparently, -like 'Pool' _nearly_ 
#     can do, then.... But arrays...-one should be careful with arrays, 
#     since they can't be managed transparently...YET! 
#
#It ought to be possible to let a special manager manage ALL kinds of
#allocation involving a certain class, -that's what I want, I think!
#TRUE TRANSPARENCY - ABSTRACTION, ABSTRACTION, ABSTRACTION - HIGHLY WANTED!
#
#I'm thinking: When constructing a special-purpose-heap-manager, one should
#be careful not to ramble into some kind of ALIGNMENT-PROBLEM (it could
#easily happen!!!) - that is, it should, -of course(!)-, be portable; 
#size and performance isn't everything!

I don't know how portable the USL SC are.

Mats Henricson
Ellemtel Telecom Systems Labs
Stockholm
Sweden
Newsgroups: comp.lang.c++
From: jng@aslslc71.asl.dl.nec.com (James Ng)
Subject: Access non-static data members in Motif callback functions.
Organization: NEC America, Inc. Irving, Texas
Date: Mon, 21 Dec 1992 14:43:44 GMT


We use X11/R4 and Motif 1.1 for our GUI development. Our C++ compiler is
Object Center C++ (formerly called Saber C++). When we try to use a
non-static member function as a callback, sometimes nonstatic data members
get corrupted inside the callback function. Static data members seem to
maintain their integrity. Does anyone have similar experience or even
solution to solve the above problem? Any suggestion will be appreciated.
Suggestion can be mailed to jng@asl.dl.nec.com or posted if you prefer.

James Ng
From: harvey@opl.com (Harvey Reed)
Newsgroups: comp.lang.c++
Subject: Re: Newbie Wants Advice on C-Programming
Date: 31 Dec 92 00:18:16 GMT

sas@regina.aruba.UUCP (Steve Sciandra) writes:

>|> > 1) There seems to exist C, as well as C++, and possibly other variants.  What
>|> >    are the differences between these?  Which should we learn first?
>|> 
>|> You really have to learn C before learning C++, but you might as well learn
>|> C++ _programming_ directly.
>|>  

>I learned C++ programming as my first language ( if you don't count COBOL).
>My finding was that i didn't need to know a thing about C syntax wise to
>learn C++.  it turned out, however, that learning about pointers, structs,
>etc, I then realized that I have learned some C in the process of learning C++.I cannot claim that I learned all the C idioms and such things that one
>learns from years of C programming, but learned enough of it through C++
>to read C programs and maintain them..

>Another point, which supports your point, is that most people I ran across
>while learning C++ already knew C and would often compare a C++ construct
>to a C construct, etc.  By knowing C, one could benefit from  a understanding
>of where C++ came from...

I learned C++ after using Modula-2 extensively. I found (after some time)
that my initial lack of exposure to "just C" was actually beneficial.
The tendency for C programmers is to make their C++ programs look like
C programs (which is easy). However C programs don't necessarily make
good C++ programs.

In the long run however I made sure to learn (and keep ref manuals
handy) both ANSI C and C++ thoroughly, and keep mindful of their
syntactic and semantic differences.


-- 
++harvey
========================================================================
internet:  harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
voice:     617-965-0220