HDTenEightyP/NetNews huggingface dataset:
From: zeev@cybvax0.uucp (Zeev Mehler)
Subject: Special-purpose-heap-managers - references, FTP?
Organization: Cybermation, Inc.
Date: Tue, 22 Dec 92 16:58:26 GMT

> BS says, that use of a special-purpose-heap-manager could speed up a program,
> -that is, a "normal" program, that uses medium-heavy dynamic-allocation, 
> I guess(!)-, with a factor 2! Based on a few simple tests, I would not be 
> surpriced, if the speed-up could be much, much higher - say, 100x for a not 
> too heavily, dynamically allocating program of mine! Is that unrealistic; 
> based on an unrealistic, simple test? 

> 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? 

>         -- Morten.

Since this is an area that we are currently working in I'll throw in my 2 cents
worth on the subject.

C++ tends to exercise the heap manager very intensively.  Some system vendors
have put in quite a bit of effort to improve their malloc packages to 
primarily become space effecient.  Typical programs on these machines
running in memory, spend less than 10 percent of their time in malloc.  Memory
buffering tricks will save max about 5% of run time.

However, if a program is in a situation where paging is unavoidable, which
tends to occur more quickly for systems that have not made their mallocs space 
effecient, then the time a program spends in malloc/free can jump dramatically.

In a paging situation, focusing on managing free lists and being able to 
reallocate efficiently becomes paramount to a C++ programs performance.  

Ideally one wants a system that works very quickly in memory, but also 
inherently minimizes paging hits.

In practice we have found that for optimum performance one needs a variety
of allocation strategies that work together.  A strategy that works well for 
32 byte allocations is not necessarily optimum for 700 byte allocations.

While it is possible to accomplish this on a class basis, we feel that this 
stuff should be hidden from the individual programmer and managed on a system 
wide basis.

				       Ze'ev
-- 
-------------------------------------------------------------------------------
Ze'ev Mehler				Tel: (617) 396-3009  
NewCode Technology, Inc.		Fax: (617) 395-9452
200 Boston Ave.				Email: zeev%cybvax0@uunet.uu.net
From: mike@istech.msk.su (Michael Korotkih)
Newsgroups: comp.lang.c++
Subject: Re: Operator "new" - how to catch array-allocation?
Date: 22 Dec 92 16:06:15 GMT
Reply-To: mike@istech.msk.su
Organization: Information Systems and Technologies


> A* a=new A[25];

> the global new operator is used, it seems! Can it be true, it should
> work like this?
        YES. A::new used only if you allocate exactly one object of
    class A or derived from A ( size == sizeof( classname ) ),
    if you use this for derived class, size will be bigger.


>        Until I tried, I thought, A's 'new' would just get a bigger
> argument - but maybe there is a very good reason, it works like this?
> Please tell me about it! No way to catch array-allocation for a class?
    You can override global ::operator new. If you want execute
    class - specific initialization, may be constractor - the best place.


> Same question goes for 'delete'. Comments and explanations greatly
> appreciated!

    delete behavior is the same.

>        -- Morten.

> ---------------------------------------------------------------------------
>  Morten Sabroe Mortensen,         e-mail: sabroe@daimi.aau.dk
>  Department of Computer-science - University of Aarhus, Denmark.
> ---------------------------------------------------------------------------


                                                  Michael Korotkih
From: dodd@dodd.UUCP (Mike Dodd)
Newsgroups: comp.lang.c++
Subject: FAQ - where is it? mail, ftp site please.
Date: Sun, 27 Dec 1992 07:21:01 GMT
Keywords: FAQ RTFM C++
Distribution: world
Organization: Not
X-Newsreader: Arn V1.00 beta rel2

I know that many of you know where it is, and this is probably a FAQ
itself.  But, I don't know, I have seen it posted and did save it, but
alas I cannot find it, it is lost due to a reformat of my hard disk.

If we are not going to have the FAQ posted each month as in some other
groups, could we post its whereabouts once a month, or at least post to
RTFM.mit.edu (the official (?) holder of FAQ from usenet groups) ?  I saw
FAQs in the comp.lang.c++ directory but these seemed to pertain to the
g++ compiler more than the language itself.

Please mail response to me direct to save bandwidth (many responses might
pour in), I can post the message stating the location so that others
fearing flames will know too. :-)

			    -Mike

+-----------------------------------------------------------------------+
|   Michael E. Dodd		Internet:  dodd!dodd@seq.uncwil.edu     |
|   219 Pershing Court		Voice:     919/799-9453                 |
|   Wilmington, N.C. 28412	(Answering Machine on between 4-10PM)   |
+-----------------------------------------------------------------------+
From: roger@genie.UUCP (Roger H. Scott)
Newsgroups: comp.lang.c++
Subject: Re: Virtual base classes
Date: 22 Dec 92 05:29:13 GMT
Reply-To: roger@genie.UUCP (Roger H. Scott)
Organization: proCASE Corporation, Santa Clara, CA

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
>> 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, and if not, what does it mean to
have a collection of objects that *claim* to be WellFormeds but are in fact
Kludges?  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++.
Newsgroups: comp.lang.c++
From: 76336.3114@CompuServe.COM (Kevin Dean)
Subject: Standard library functions and macros
Date: 1 Jan 93 23:47:33 GMT

In an article date Dec. 31, Jim Adcock (jimad@microsoft.com) says:

>"Reserved" in the same sense that ANSI-C reserved them -- that is if you
>#include the corresponding ANSI-C standard header, then the function
>names in that standard header become reserved. 

In what sense do they become reserved?  I see no problem with reserving
::fcnName() but I have difficulty accepting the idea that Class::fcnName()
is reserved as well.

>If this is not acceptible, then simply don't include that standard header
>file.

All well and good but I've seen some compilers (Microsoft's among them)
that, with certain optimizations turned on, reserve the function name
anyway even though its corresponding header has not been included.  (I
don't know if this applies to MSC 7.0 since I haven't played with it yet
but it was certainly the case with 6.0).

Kevin Dean

SNAG: acronym for Sensitive New-Age Goof, one who, without any relevant
experience, is always willing to enlighten the ignorant masses on the
social issue of the day.  Have you hit any SNAGs lately?


Newsgroups: comp.lang.c++
Newsgroups: comp.lang.c++
From: 76336.3114@CompuServe.COM (Kevin Dean)
Subject: Piping and return code
Date: 1 Jan 93 23:47:40 GMT

In an article dated Dec. 30, Binh Tong (tongb@woods.ulowell.edu) asks:

>Does any one know how to put redirect output and get return code in C ?

The ANSI-standard function freopen() followed by the appropriate spawn
command can be used as follows:

FILE * newIn = freopen("LOGIN.IN", "r", stdin);	// Redirect input.
int result = spawn...("LOGIN.EXE", ...);	// Run command.
freopen("CON", "r", stdin);			// Restore input.

It's been a while since I did this so it may need some fiddling but I know
for certain that freopen() will work.  Share and enjoy.

Kevin Dean

SNAG: acronym for Sensitive New-Age Goof, one who, without any relevant
experience, is always willing to enlighten the ignorant masses on the
social issue of the day.  Have you hit any SNAGs lately?
From: koen@cv.ruu.nl (Koen Vincken)
Newsgroups: comp.lang.c++
Subject: Re: Sizeof and Virtual functions
Date: 30 Dec 92 14:26:51 GMT
Organization: University of Utrecht, 3D Computer Vision Research Group

In <1992Dec29.211505.21322@taumet.com> steve@taumet.com (Steve Clamage) writes:

>suresh@papaya.iss.nus.sg (Suresh Thennarangam - Research Scholar) writes:
>
>>One of the things that distinguishes virtual functions from other
>>normal member functions of a class is that some compilers that I
>>know of, store an extra pointer that is  probably used to index 
>>a vector table...
>
>'sizeof' better tell the truth.  It must report the amount of storage
>required by an object of that type.  If the object has extra data added
>by the compiler, that is part of its size.  This is conceptually no
>different from the padding a compiler might add to get suitable alignment
>of individual members.  You are not allowed to assume the size of any
>type other than "char" (which is always 1 by definition).  In C as well
>as C++, struct types might have a size different from that calculated
>by adding the size of each member.
>

[...good points deleted...]

>C++ allows control of pure data types in exactly the same way as C.
>You can, for example, create a C-style struct containing just the data
>of interest, and derive a class from it which has all the functionality
>you want.  You can still write and read back the data as you would in C.
>-- 
>
>Steve Clamage, TauMetric Corp, steve@taumet.com

I agree with Steve. New C++ programmers often make the 'sizeof' mistake
(just as I did). 
Now I save my rather complicated classes with explicit member functions.
Instead of using structs or using 'sizeof(object)' I have (for every class 
of interest) a function 'Write()', which simply writes all member variables
to a file. Also, this allows me to write only those variables that need to 
be saved. This way, file sizes were reduced from about 50 Mbyte to 25 Mbyte!

	Koen Vincken


    /   /                      Koen Vincken, AZU E 02.222, Heidelberglaan 100, 
   /  /    _  /  ___/   \   / 3584 CX Utrecht, The Netherlands. 
  /  \    /  /  _/    /  \ / e-mail: koen@cv.ruu.nl, or vincken@cs.unc.edu
__/  _\ ____/ ____/ _/   _/ phone: +31-30-506710/506711
Newsgroups: comp.lang.c++
From: fgreco@shearson.com (Frank Greco)
Subject: weird messages from dbx and c++
Organization: Lehman Brothers
Date: Wed, 30 Dec 1992 21:41:39 GMT


One of our app pgmrs built a library using SPARCWorks C++ 2.1 (SunOS
4.1.1) and a little main routine also compiled with C++.  The pgm runs
more-or-less fine when run from the shell.  But when they use dbx[tool]
on this app, a stream of messages like the following appears on
stderr.

warning: Couldn't translate C++ name "strip_a_line"; .stab ":ZtF"
warning: Couldn't translate C++ name "CAL_Enable_Logging"; .stab ":ZtF"
warning: Couldn't translate C++ name "CAL_Disable_Logging"; .stab ":ZtF"
warning: Couldn't translate C++ name "CAL_Init_Libs"; .stab ":ZtF"
warning: Couldn't translate C++ name "CAL_Close_Libs"; .stab ":ZtF"

I originally thought that the pgmr was using the wrong (ie, the non-C++
version) dbx/dbxtool, but "which dbx" and "which dbxtool" gave me
the correct paths.

Any clues as to what the problem is and what the solution is?

Thanks all,

Frank G.
please use email, thanks.
--
+-On Assignment at: Lehman Brothers-+-Office: Mercury Technologies, Inc.-+
| World Financial Center, 11th Floor| PO Box 529                         |
| New York City, NY 10285 Desk: 1515| Fanwood, NJ 07023                  |
| email: fgreco@shearson.com        | email: fgreco@mercury.com          |
Newsgroups: comp.lang.c++
From: Ian_Upright@mindlink.bc.ca (Ian Upright)
Subject: Re: Zortech C++ v3.1
Organization: MIND LINK! - British Columbia, Canada
Date: Sun, 3 Jan 1993 02:47:22 GMT

> Joe Huffman writes:
>
> Org.  : FlashTek, Inc.
>
>
>         A) $600.00
>         B) $400.00
>         C) $200.00
>


A: Maybe
B: Probably
C: Definitely

If it just recompiled and relinked, no code changes from my BC++ 3.1 code..
Just like that..  Oh.. I'd probably pay a grand.  (assuming it hand
windows support as well..)  ..  But Borland may well beat you guys to it.


--
/-----------------------------------------------------------------------------
  Origin:  Astaria Digital Enterprises             Ian_Upright@mindlink.bc.ca
  BBS: (604) 852-1866, or FidoNet  :-)  1:153/513                  CANADA eh?
\-----------------------------------------------------------------------------
/
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Call to Order
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 28 Dec 1992 02:56:36 GMT

In article <1992Dec23.205843.23467@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>Can we all *try* to do better at keeping postings on topic and constructive?
>
>Please consider pondering the following questions before posting here:
>
>1) Does your posting pertain generally to the C++ programming language
>and/or programming community?
>
>2) Does your posting make a positive contribution to the community of
>C++ programmers who try to read these postings?
>
>My concern is that we seem to be straying off-track, both away from
>C++, and also towards negative postings.
>

	Negative feedback is important, IMHO. I dont think we should
exclude critical postings: such may well lead to constructive
improvements in the future. Such criticism should be technical,
however, flames should be carried on using email.

	Furthermore there are many topics of interest to C++
people (and prospective C++ people) which do not relate
specifically to the language, but do relate to the C++ community,
or some significant section of it, such as criticisms of 
vendor support, problems installing compilers and tools, etc.

	Perhaps comp.lang.c++ is not appropriate for these comments,
but it is more appropriate than any other newsgroup.

	Questions unrelated to the language or the C++ community,
however, should not be posted here, for example, questions about
how to access the mouse on a PC or create a dialog
box using X. If such a question is posted
and you wish to reply, please do so using email.

	The comp.std.c++ newgroup is available for discussion
of issues directly relating to the ARM and upcoming standard.
I've been asked to retract a prior suggestion that comp.std.c++
could be used for some of the more language specific issues to
reduce the traffic in comp.lang.c++ and hereby do so. My
apologies if I have misdirected any readers.

	Please read comp.std.c++ for a while before posting to
it, to be sure your posting is appropriate for that group.

	For those with mouse questions, by the way, there is
a mailing list for Borland C++ users. 

-- 
;----------------------------------------------------------------------
        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: lwloen@rchland.vnet.ibm.com (Larry Loen)
Subject: Re: Automatic conversion! Can we do this?
Date: Mon, 28 Dec 1992 19:36:17 GMT
Reply-To: lwloen@rchland.vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

Won't the following work:

a = string("Merry") + "Christmas"   ;

By converting "Merry" to a string, it should enable your overloaded +
operator to be found.  It works on my C++ compiler:

 /*  Non-production code!!  */

#include <iostream.h>
#include <string.h>
 class string{
    char *str;
    int size;
    friend ostream& operator<< (ostream& x,string& y)
          { x << y.str; return x; };
   public:
     string()  {str=new char[10]; size=9;}
     string(const char *p){ str=strdup(p); size=strlen(p);}
     string(const string& s){str=strdup(s.str); size=s.size;}
     ~string(){delete [] str;}
     string& operator=(const string& s){ strcpy(str,s.str); return *this; }
     friend string operator+(const string& x,const string& y)
           { char* str2;
             str2= new char[strlen(x.str)+strlen(y.str)+1]; strcpy(str2,x.str);
             strcpy(str2+strlen(x.str),y.str); return string(str2); };
  };

int main()

{
     string a;  string hny;


     /******  the point of it all is this next line *******/
       a= string("Merry") +" Christmas";
       cout << a;
     /******   and, a secondary point *****/
       hny = string(" and ") + "a " + "Happy New " + "Year! ";                            
       cout << hny;                                                                       
       return 0;
}


Not 100% of what you are looking for, to be sure, but at least one avoids
declaring "b".  I believe you will find that only the first such reference
needs to be a string as my second example shows.  You might even try
string("") as an experiment and see what happens.  (E.g string("")+ "Merry "
+ "Christmas").

-- 
   Larry W. Loen        |  My Opinions are decidedly my own, so please
                        |  do not attribute them to my employer
Newsgroups: comp.lang.c++
From: feathers@serss0 (Michael Feathers)
Subject: Re:  Give me safe C++
Organization: Florida International University, Miami
Date: Sat, 26 Dec 1992 13:42:41 GMT

In article <1992Dec21.141735.20949@bcrka451.bnr.ca> sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:
>In article <BzICnn.LDx@fiu.edu> feathers@serss0 (Michael Feathers) writes:
>>My conclusion was that run time checking was being used as a crutch.
>
>Be careful what you say.  I have heard managers object to debuggers because
>the people used them as a crutch.  While I agree with you that it is good
>to code properly in the first place by habit, I disagree with your implied
>reluctance to use the tools at your disposal.  There are those who object
>to code walkthroughs done by computer (i.e. using the debugger to step 
>through code to make sure that it does what it is supposed to do), and I
>suppose there are still those who insist on checking their code for syntax
>errors before running the compiler.  Are you sure that the runtime checking
>was being used as a crutch and not a development aid?


Actually, I hope that what I said was not taken that way.  I was implying
that students should not have those tools too early or else "crutch habits"
may develop.

To be truthful, I use a debugger at times but I still am not comfortable with
them.  I spent too much time desk checking my code for semantics a long time
ago.  I get anxious when I feel that I don't fully understand my code.  
Thankfully, I think that anxiety helps me.

I think that desk checking code for syntax is kind of ridiculous though.
To me, a compiler with good warnings and errors is the best development
tool available.  

I've heard from a friend about the "clean room" approach to developing 
software in which compiles are minimized in order to make sure that humans
are actively involved in the process.  
 
I'm not sure I subscribe to that view, but I definitely think that when
students are learning how to design software, they are learning more than that
they are learning how to think about programs and design them in such a way
as to understand them.  I don't think that this kind of learning can be
accomplished unless students learn to overcome adversity by good habits in
the beginning rather than tool reliance.
 
Michael
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: Newbie Wants Advice on C-Programming
Date: 31 Dec 92 18:47:57 GMT
Organization: negligable

In article <1992Dec30.211924.2614@leland.Stanford.EDU> kocks@leland.Stanford.EDU (Peter Kocks) writes:
>In article <1313@ottawa.opl.com.opl.com>, sas@regina.aruba.UUCP (Steve Sciandra) writes:
>I took me some time to realize that it is not the language that counts, but the
>paradigm or idiom you use.  The language is important, but not as important as
>knowing a few of the basic computer *tricks*.  For example, do you know what
>the following things are:
>
>1)  Linked list
>2)  Hash Table
>3)  bTree
>4)  Recursion  (a critical programming trick that most fortran programmers 
>                no nothing about).
>5)  Data structures
>6)  Modularity
>7)  Shell sort

These aren't "tricks", they are FUNDAMENTALS!  A "trick" is:

	((a<b)?f1:f2)(arg)

>If you know the very basics of any computer language (like what an array is and
>what assignment means (eg c = c + 2), you can learn all of these techniques

do you mean:

	c := c + 2;		{ student days are back again! }

or 
	c += 2;			// sorry, I couldn't resist!

>by just reading books.  Yes, many of these books may have "C" or "C++" in the
>title, but you can read them just the same.  You may not understand all the
>syntax in the examples, but you will get the general concept.  It is much
>more important to get the general concept early, than wait 5 years and get
>it from experience in a specific language.

Yes, but I find that books on Pascal tend to be more useful for teaching
the general concepts than most of the C or C++ books I've seen.
Again, IGNORE the language, learn the concept.  Take Grogono's
Pascal book (although there may be a better one by now, that one's
about ten years old!) to learn about using pascal's records and
pointers, change the syntax and voila!  You now know how to use C's 
structs and pointers!


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Philosopher and plowman			|
each must know his part			|	-Richard Hartman	
to build a new mentality		|	hartman@uLogic.COM
closer to the heart!			|

Newsgroups: comp.lang.c++