HDTenEightyP/NetNews huggingface dataset:
From: Carlos.Rojas-Guzman@mailbox.bison.mb.ca (Carlos Rojas-Guzman)
Newsgroups: comp.lang.c++
Subject: C++ portability: from g++ to Microsoft 7.0
Date: 24 Sep 92 21:26:54 CST

Organization: Massachusetts Institute of Technology

Do you have any idea on where to find information
about the differences among
   (1) g++,
   (2) Microsoft and/or
   (3) Borland C++ compilers? 

While translating code from one machine to another
that would be very helpful.  If there is some 
information I'll post a summary in the network.

Carlos Rojas

 * Origin: The Electronic Mailbox (1:348/7.0)

Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: GOTOo wars
Summary: Some slightly subjective justifications
Organization: :
Date: Fri, 25 Sep 1992 20:22:13 GMT

In article <rmartin.717284686@thor>, rmartin@thor.Rational.COM (Bob Martin) writes:

On the subject of `strict structure' .vs. `natural structure' (breaks,
continues, returns in the middle of functions)

> And I have not voted for anything slavishly.  I just want decent
> non-subjective justifications.

Well, I'm afraid all justifications have some element of subjectivity,
even those which measure how long it takes a group of individuals to
make a bug-free change.  (Which potential changes do you pick?)

HOWEVER, here are some justifications that I think reasoned:

For the use of a return-in-the-middle:

	Bailing out in an error case:  It is a poor idea, IMnsHO, to
	alter the structure of a program's `correct case' logic to
	accomodate `can't-happen' cases, even when it is proper to
	check for them.

	Quitting after the appropriate case is taken: If a problem
	requires a 1-of-N-cases solution, where the cases are arranged
	in order of increasing difficulty (and length of code) and
	the tests which identify them are not suitable for a `switch'
	statement, it is reasonable to code them sequentially and
	end each one with a `return.'  The alternative is force the
	person analyzing the simple case up front to follow the if/else
	structure to the end to ensure that `nothing else happens.'

For the use of a continue:

	Quitting after the appropriate case is taken: as above.

For the use of either break or continue:

	When alternative is representing program state with flags,
	we have a choice: we can represent a certain state of the
	program solution (and certain statements/assertions we can
	validly make about the program's/solution's state) by a
	place in the program (that is, we can say `At this point we
	know that ...') and act on that knowledge OR we can take
	that knowledge, encode it in data, and act on it at a point
	remote from where we discover we can make the assertions.

	Encoding that knowledge in data and acting on it remotely
	requires the reader to perform extra `cognitive tasks' to
	understand the program.  It is reasonable to expect that
	in some, or many, cases, it is easier to understand the
	program without that extra cognitive cost.

	ALSO: the management of the `solution state variables' is
	difficult to separate from the handling of the variables that
	actually store the program's data.  This means that two tasks
	are intermingled and must be re-segregated in the mind of the
	reader.  This mingling of two tasks is recognized as poor
	style.  Just as a paragraph of text should address one subject,
	a statement or group of statements in code should address one
	`task' in the problem.

Of course, your mileage may vary.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: dcb@slsvitt (David Binderman 3841)
Subject: test suites
Organization: SEL-Alcatel LTS Dept. US/ES
X-Newsreader: Tin 1.1 PL4
Date: Mon, 5 Oct 92 10:48:09 GMT

Hello there,

I have a suggestion for all C++ compiler vendors.

A minimal version of a C++ test suite would make sure that all
the code in the ARM performed as expected.

If there are copyright problems, you might use ANSI C++ papers instead.

I can accept that chapters 14 & 15 might not be tested.

Its a bit embarrassing if a compiler can't even implement a simple
two line example from a _reference manual_ for the language.

Regards
--
David C Binderman     Dept US/ESI, Bau 60, SEL-Alcatel AG, Lorenz Strasse 10,
D-7000 Stuttgart 40, Germany      dcb@us-es.sel.de   Tel: +49 711 821 3841
If you lie to the compiler, it will get its revenge
Newsgroups: comp.lang.c++
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: Persistance Problem Solved by Memory-Mapped Files?
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Tue, 29 Sep 1992 13:36:55 GMT

In article <d8_p1zq.feustel@netcom.com> feustel@netcom.com (David Feustel) writes:
>I'm wondering whether the problem of persistant objects could be
>solved by use of memory-mapped files to store the C++ data structures
>used by C++ programs. Comments?
>-- 

It all depends on which problem of persistant objects you are talking about.

Do you want to have several people able to edit objects in the same
files at the same time?
Do you have more data than will fit in one file/disk?  Do you need objects
in one file to be able to reference objects in another file?  Will your
system know which file to use?  Will addresses be good enough for one 
object to refer to another object in some other file?
Do you want to have a version tree for your objects?
Do you want to have different configurations, e.g. for different releases,
where each release may use different versions of the same objects?
Do you want to be able to recover from power failures?  Or at least 
guarantee that your data is in a consistent state if the machine fails?
(That is, do you want an all-or-none commit?)
Do you want to be able to change your data model over time yet still
be able to access old data?
Even if you are a single user, do you want to be able to have one
process edit data while another is reading it - and guarantee that the
reader is getting a consistent state?

These are just a few database issues that pop into my head at the
moment.  If you just have a bit of data and a single user (and a single
process), you may find that you don't need an object-oriented database.

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++
Subject: Re: C++ to C converter
From: marcello@deis20.cineca.it (Marcello Dalpasso)
Date: 1 Oct 92 14:45:31 +0100
Distribution: world
Organization: Dept. of Electronics, Computer Science & Systems, Univ. of Bologna, Italy

What do you mean, Stephen?!

Can you use g++ to translate C++ code to readable C code?

I'm wondering how...please enlight me!!!

Thanks in advance...

-- 
	Marcello Dalpasso (e-mail: marcello@deis16.cineca.it)
	D.E.I.S. - Department of Electronics, Computer Science and Systems
	Viale Risorgimento 2, I-40136 Bologna, Italy			
	Phone: +39-51-644-3015 (fax: +39-51-644-3073)
Newsgroups: comp.lang.c++
From: kestes@nswc-wo.nswc.navy.mil (Kent Estes)
Subject: AT&T tasking library for MSDOS ?
Organization: Naval Surface Warfare Center
Distribution: comp.lang.c++
Date: Fri, 2 Oct 1992 11:33:55 GMT

Does anyone know if the AT&T tasking library has been ported to MSDOS
& if so, where can I find a (shareware) distribution ?
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: GOTOo wars
Summary: C++'s Ada inheritance
Keywords: jeet kun do of gotos
Date: 27 Sep 92 18:50:33 GMT
Organization: AT&T Bell Laboratories, Murray Hill NJ



mccall@mksol.dseg.ti.com (fred j mccall 575-3539 @ Texas Instruments Inc) writes

 > >Also, BTW, much of the evolution from C to C++ was directly
 > >influenced by Ada:
 > 
 > >    Templates (Ada Generics)
 > >    Strong typing
 > >    Default paramaters and named parameter association
 > >    Exception handling 
 > >    Name scoping within a class.
 > >   
 > 
 > I know.  In point of fact, I find myself periodically reminding people
 > over in comp.lang.ada who are 'bashing' C++ and talking about how C++
 > people are constantly denying that it got anything from Ada that
 > Stroustrup has stated that a number of things he included in C++ were
 > inspired by Ada.

I personally haven't heard people deny that C++ borrowed ideas from
Ada and such denial would be ad odds with fact and in variance with
my public statements. Several C++ features were inspired by Ada and
other languages. However, the list offered is not quite right:

	Templates (Ada Generics)
		- Ada was a major source of inspirartion.

	Strong typing
		- No. The inspiration was Simula and Algol68.

	Default paramaters and named parameter association
		- No, and C++ (deliberately) does not provide
		  named parameter association.

	Exception handling
		- Ada was one source of inspirartion; others include
		  ML and some OS work on fault recovery.

	Name scoping within a class.
		- No.

In addition, Ada features - like features in languages such as Clu,
Modula2, Modula3, CLOS, etc. - are considered where relevant in the
discussions of extensions.
Newsgroups: comp.lang.c++
From: Dietrich.Boles@arbi.informatik.uni-oldenburg.de (Dietrich Boles)
Subject: COOL
Organization: University of Oldenburg, Germany
Date: Mon, 5 Oct 1992 08:31:12 GMT


Does anybody has any references of COOL (a parallel extension of C++) ?

  Dietrich Boles

Dietrich Boles
Universitaet Oldenburg
Fachbereich Informatik
e-mail: boles@uniol.uucp

Newsgroups: comp.lang.c++
From: qbarnes@urbana.mcd.mot.com (Quentin Barnes)
Subject: Re: C++ Task Library/Real Time Cntrl
Organization: Motorola Computer Group, Urbana Design Center
Date: Fri, 2 Oct 1992 21:55:54 GMT

In <1992Oct1.200957.19929@msuinfo.cl.msu.edu> engelsma@borzoi.cps.msu.edu (Jonathan Engelsma ) writes:

>Has anybody sucessfully used the interrupt handling facility provided
>in the AT&T C++ tasking library?

>I seem to be able to catch the interrupts, but if there is any other
>tasks waiting on a delay() call, I get a run-time error.  According 
>to the manual my run-chain is corrupted.

>Below is a very simple program that gives me the problem.  It consists
>of a single interrupt handler which will wait for a ^C.   The main
>loop will just sit and spin, delaying for one simulation time unit
>per iteration.  The interrupt handler will just print a brief message
>whenever you press cntrl-c.  If I comment out the thistask->delay(1.0)
>statement in the main routine, the program works fine.  Am I doing
>something wrong? 

>Any comments/corrections/suggestions would be greatly appreciated.

I poked around in the libtask code and found out what's going on.
When the interrupt_alerter is scheduled as a priority task, its
s_time value is not updated; it remains 0.  When the sanity checker
code in the scheduler verifies that the task scheduled to run has
its scheduled time greater than or equal to the current time (clxck),
it finds that interrupt_alerter has 0 and croaks.

Also, the error message displayed when "corrupted" run-chain error
message is displayed is the data on the running process, not the
interrupt_alerter process about to run so you don't see the "corrupted"
value for s_time in the task.

I have a fix worked up for it and will send it along to USL and see
what they think.

>Jon
-- 
Quentin Barnes
qbarnes@urbana.mcd.mot.com | ..!uiucuxc!udc!qbarnes
Newsgroups: comp.lang.c++
From: tito@di.unipi.it (Tito Flagella)
Subject: C++ garbage collector facilities
Reply-To: tito@di.unipi.it (Tito Flagella)
Organization: Dipartimento di Informatica, Universita' di Pisa
Date: Wed, 30 Sep 1992 15:51:20 GMT


I have been just involved in a project reguarding garbage collection facilities
in C++.
Any information about already done works (papers or C/C++code) in designing
garbage collector facilities for C/C++ program will be very appreciated.
--
------------------------------------------------------------------
Tito Flagella	             email:   tito@di.unipi.it

work address:
Newsgroups: comp.lang.c++,comp.std.c++
From: krc@wam.umd.edu (Kevin R. Coombes)
Subject: Re: Conceptual Constness
Keywords: const, const member, lazy
Organization: University of Maryland, College Park
Date: Thu, 1 Oct 1992 17:04:27 GMT

In article <1992Sep29.160411.9737@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>In article <1992Sep29.140750.29438@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
>>[The]
>>	operator[](int index)
>>should not be a member of a list class. Lists only provide sequential
>>access; Arrays provide random access.
>
>	I dont agree really. If you can get the first element,
>and get the next element, then you can get the n'th element.
>As far as I'm concerned, a list is an array with 'insert' and 'remove'
                                 ^^^^
>operations.

Is that really an "IS-A"? Just like in public derivation of one class
from another? Would  you write

class List : public Array {
  // ...
};

for example? I'm just checking, because I don't want to read more into
your statement than you may have intended. For me, an Array is primarily
characterized by supplying constant-time random-access to any of its
elements. An Array class may supply other services (like inserting 
objects at preallocated locations for later access, or bounds checking), but
those are not the defining properties. A List, on the other hand, is 
primarily a sequential-access structure. From this point of view,
Arrays are usually implemented by the builtin arrays (note the lowercase),
possibly allocated dynamically. Lists can be built with arrays, but they
can also be implemented directly as linked lists, where objects are
allocated on the fly and put into nodes that also contain pointers to
the next object. Lists can, as you suggest, provide a random-access
operator using the more primitive operations of first and next, but
they don't have to do so. I find the claim that a List "IS-A" Array
(again, I apologize if I have misinterpreted that statement), to be
rather inflated. The two are equally primitive; one can be implemented
in terms of the other; forcing a particular dependence or implementation
seems to me to be to restrictive.

Kevin Coombes <krc@math.umd.edu>

Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: How to do record locking?
Organization: TauMetric Corporation
Distribution: usa
Date: Sat, 3 Oct 1992 16:14:40 GMT

morss@ssd.kodak.com (Charlie Morss) writes:

>I hope this is not a FAQ (at least I could not find it in the FAQ!).

>- I have not been able to figure out how to do record locking using
>  the fstream class (or which ever stream class is appropriate).

>I need to do the "normal" type of locking, start at location X and 
>lock for N bytes. I also need to be able to lock the whole file. 

Record locking is not part of C++, iostreams, Standard C, or stdio.
It is exclusively an OS and file system issue.  (Not all file systems
support record locking.)

One simple solution is to derive a class from fstream and add your
own lock and unlock functions.  I would probably do something like this:

class lfstream  : public fstream {
public:
    lfstream(...); // several constructors
    lock(streampos start, long length, int how);
    lock(streampos start, long length);
    lock(int length);
    unlock();
};

The various versions of the "lock" function allow full or minimum
information to be specified.  They and the "unlock" function just
call the underlying "lockf" (or whatever) function, passing along the
file descriptor from the fstream, and explicit or default versions
of its own parameters.  For example, lockf operates from the current
file position, so some versions of lock would first seek to the "start"
position, maybe seeking back afterwards.

The fstream class has inline constructors which duplicate those in the
fstream base class and pass along their parameters.  You might want
an "lofstream" class derived from "ofstream" as well, but probably
not an "lifstream".  (Typically you can't lock a file opened only
for input.)
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: neal@ctd.comsat.com (Neal Becker)
Newsgroups: comp.lang.c++
Subject: Signal Processing Class Lib???
Date: 30 Sep 92 13:41:39 GMT
Organization: COMSAT Labs
NNTP-Posting-Host: neal.ctd.comsat.com
X-Md4-Signature: 073104470316949d815b21dab3529570

I hope this isn't a FAQ (I don't usually read this group).  Is there
any recommendations for signal processing / simulations libraries?  I
have tried to put together a lib several times to cover such things as
signal objects and operators, but I have found it was very difficult
to come up with a good overall design.

Thanks.
Newsgroups: comp.lang.c++
From: agrafiot@wl.com (Dimitris Agrafiotis)
Subject: Need Information on USL Standard Components
Organization: Warner Lambert / Parke-Davis
Distribution: usa
Date: Tue, 6 Oct 1992 13:17:51 GMT


Does anyone know where to get detailed information (including pricing and
license policy) on USL's Standard Components? Also, would anyone have any
comments regarding the relative strengths of Standard Components .vs.
Tools.h++?
Any help would be appreciated.
Thanks


-- 
Dimitris K. Agrafiotis
Computer Assisted Drug Design
Parke-Davis Pharmaceutical Research
(agrafiot@wl.com)
From: pluto@cs.ucsd.edu (Mark Plutowksi)
Newsgroups: comp.lang.c++
Subject: C++ for Sparcs: recommendations?
Summary: Does one exist with BC++'s capabilities?
Date: 6 Oct 92 00:49:33 GMT


Dear Cross-Training C++ Wizards, (i.e., you use both PC & Sparc)


Is there a C++ compiler for Sparc stations that 

	- is up to date with the Real Thing (the Xerox "standard")
	- is cheaper than the Real Thing
	- has a gui debugger with keyword-sensitive on-line help
	- has object browsing
	- has project management (I haven't used make.exe all year.)
	- has gui-building capabilities ala BC++'s OWL & Protogen,
	  but for X Windows instead.

Or, must I bite the bullet and purchase the Real Thing along with
some kind of X Windows gui-building tools?   Come to think of it,
does the Real Thing satisfy the above list?


Signed,

"Sticking With My PC Until My Sparc Becomes More User-Friendly
But My Super Wants Me To Use The Expensive SparcStation
He Bought Me But For Which He Didn't Reserve Any Money For A 
Decent Compiler And My Project Will Be Over Before Sun Comes Out
With Their Next Version" in San Diego.
Organization: University of Illinois at Chicago
Date: Tuesday, 6 Oct 1992 11:00:23 CDT
From: Dimitrios K. Valsamis <U45561@uicvm.uic.edu>
Newsgroups: comp.lang.c++
Subject: Shallow & Deep copies of objects

Could anyone explain to me what is a Shallow and a Deep copy of an object? How
easy is to implement functions for perfoming those operations on ANY kind of
object?

One more question that I am have is dealing with the new and delete operators.
When do we usually overload those operators?

Sorry if these are FAQs!

Thanks in advance,

Dimitrios Valsamis     e-mail : valsamis@earth.eecs.uic.edu
                                u45561@uicvm.uic.edu
Newsgroups: comp.lang.c++
From: cmlow@iti.gov.sg (Low Chee Meng (KSL))
Subject: Persistent objects, database and encapsulation
Keywords: persistent, objects, C++, database
Organization: Information Technology Institute, National Computer Board, S'pore
Date: Wed, 30 Sep 1992 09:57:54 GMT

Hi folks,

I'm currently designing an application where I'll be using C++ and a
relational database. The database is used to store the persistent data
of the 'objects' in the application. However, not all the 'objects'
(ie. instances) stored in the database need to be realized as C++
objects at any one time. For eg: my database may store 1000 instances of
BLOBs, but maybe only 5 instances need to be 'instantiated' as C++ objects
during one stretch of time and a different set of 6 instances of BLOBs
in another stretch of time.

Here's is one proposed scheme:

class Blob {
public:
	Blob();           // creates a new Blob (not found in DB)
	void	save();   // saves the Blob instance to DB
        ...
	static  Blob	 Instantiate(BlobName name);  
	static  SetOfBlobs Find(BlobProperty prop);
	...
private:
	SetOfBlobs instantiatedBlobs;
}

The Instantiate method would return the Blob instance if it is already
created, else it reads the database to retrieve the data using BlobName
as the key. So, to find the Blob with name foo, I do a 
   Blob::instantiate("foo");

The Find method would read the database for records that matches
the BlobProperty given and return a set of Blob instances (creating
new Blob objects if necessary). Eg: to get a set of "red" Blobs, do a
   Blob::find("red");


I wonder if this method of doing things is a good way of encapsulating
the storage of objects. Am I violating any C++ principles in doing so?
If the database can be modified by another application, is maintaining
the currency of the C++ objects a major problem?

Any comments would be appreciated.

Thanks,

Low Chee Meng
Information Technology Institute
Singapore
cmlow@iti.gov.sg



Newsgroups: comp.lang.c++,comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Conceptual Constness
Keywords: const, const member, lazy
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 29 Sep 1992 16:10:24 GMT

In article <1992Sep29.140750.29438@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
>In article <BRENNAN.92Sep28124052@yosemite.hal.com> brennan@hal.com (Dave Brennan) writes:
>>I write a lot of C++ classes that are optimized to not do anything any
>>sooner than they have to.  Here's a contrived example:
>>

	Perhaps a better example:

	Matrix A,B,C,D;
	const Matrix X=A*B+C;

Here, X just stores the tree structure A*B+C without evaluating it.
Later, when X has to be used, the actual calculation is done.

Other well known examples (involving phyiscal/logical constness)
involve things like caching, for example
if you have a singly linked list with the [] operator, you
might cache some index/pointer pairs, even for constant lists.

-- 
;----------------------------------------------------------------------
        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: pete@genghis.borland.com (Pete Becker)
Subject: Re: The concept of templates considered ill designed
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Tue, 6 Oct 1992 17:36:26 GMT

In article <TMB.92Oct5200113@arolla.idiap.ch> tmb@idiap.ch writes:
>In article <1992Oct5.160022.29224@genghis.borland.com> pete@genghis.borland.com (Pete Becker) writes:
>
>   [discussion of how to go about adding various forms of type constraints
>   to template arguments deleted]
>
>	   But this has very little to do with templates.  Constrained parameters
>   and no further knowledge of the actual type is equivalent, as far as I can see,
>   to simply carrying around a pointer to the actual class, and dealing with it
>   only through the known interface.  You don't need templates to implement this,
>   and I don't see that there's anything gained by using the template mechanism
>   to do it.
>
>That's not true. 

	Despite this sentence, the rest of this post seems to agree with what
I said.  Yes, I agree, templates are very useful, and constrained templates
appear to be equally useful.  As I said in my original message, the 
COMBINATION of constrained templates AND no further knowledge of the actual
type (which is the situation you're in if you want to be able to compile a
template definition on its own) offers very little beyond what can currently
be done without ever mentioning templates.