HDTenEightyP/NetNews huggingface dataset:
From: adk@Warren.MENTORG.COM (Ajay Kamdar)
Subject: strdup()  Was: Re: Renew?
Organization: Mentor Graphics Corp. - IC Group
Date: Mon, 27 Jul 1992 20:18:34 GMT

In article <1992Jul27.173054.396@taumet.com> steve@taumet.com (Steve Clamage) writes:
>There is no requirement that 'new', for example, have any relationship
>whatever to 'malloc' or 'realloc'.  Either might be implemented in
>terms of the other, or they might be independent implementations.  They
>might even manage different address spaces. 

Given that new and malloc are not necessarily related, deleteing memory
returned from strdup() [STRINGS(3)] could be a recipe for disaster since the
returned memory is malloced and not newed. It is onerous to keep track of
which memory is newed, and which is malloced. C++ code written using strdup()
might work with one compiler but not with another if care is not exercised
in freeing the returned memory.

Is there any move towards providing C++ified versions of functions like
strdup() as part of some standard library? Right now the only solution
I know is to implement my own version of such functions.

- Ajay

-- 
I speak for none but myself.

Ajay Kamdar                               Email : ajay_kamdar@mentorg.com
Mentor Graphics, IC Group (Warren, NJ)    Phone : (908) 580-0102
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: signals and exceptions
Date: 27 Jul 92 22:44:36 GMT
Article-I.D.: alice.23330
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ

In article <VICTOR.92Jul27095415@irt.watson.ibm.com> victor@watson.ibm.com writes:

> With the advent of the C++ exception handling mechanism, it would seem
> logical that for those systems (like Unix) that have signal handlers,
> that there would be a standard way of turning these into C++
> exceptions -- that is have them act like a throw of something standard
> had been done.  Have any implementations of C++ done this (or are any
> planning to do this)?

This is a much more difficult problem than just implementing exceptions.
The difficulty is that a signal can potentially occur between any two
machine instructions, particularly including those that maintain the
function call stack.  Unwinding the stack correctly in the presence of
such asynchronous exceptions is very difficult indeed.

For that reason, the original exception handling proposal explicitly says
that an implementation is not required to turn signals into exceptions.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: drenze@icaen.uiowa.edu (Douglass J. Renze)
Subject: PD/Shareware C++ compiler/translator for the Mac?
Date: Tue, 21 Jul 1992 23:50:38 GMT
Organization: University of Iowa, Iowa City, IA, USA

The subject says it all...it can be MPW-dependent or standalone, for all I
care.

-- 
| Douglas J Renze            | "Jerry [Brown] is the equivalent of a          |
| drenze@icaen.uiowa.edu     |  drive-by shooting."                           |
| drenze@chop.isca.uiowa.edu |                                                |
| drenze@aol.com             |         * NPR's Morning Edition, 13 July 1992  |


Newsgroups: comp.lang.c++
From: mat@uunet.uu.net!mole-end
Subject: Re: Committee Members -> What do you think?
Summary: A minor correction
Organization: :
Date: Fri, 24 Jul 1992 06:53:10 GMT

In article <1992Jul23.010605.16404@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
 
> Again, your statements fly in the face of the reality of the committee's
> actions.  If ALL "changes" to the language were equally routed through
> the "extensions" committee and ALL changes to the language were equally
> placed on the extensions WG queue for a couple years and if ALL changes
> were required to be written up in detail by their proposers, subject to
> days and days of "extensive" extensions WG detail analysis, THEN your
> statements would make sense.  BUT, ON THE CONTRARY, there are many changes
> to the language that are happening without going through the extensions
> group.  The work of the libraries WG being one example.  "Humpty Dumpty"
> const being another example....

By ``Humpy-Dumpty const'' I assume you mean the proposal for  ~const  members,
which aren't quite Humpty-Dumpty as the programmer declares AHEAD OF TIME
what  const  is to mean, rather than letting the reader discover afterward.
That proposal IS going through the Extensions WG.  It resulted in about five
hours discussion in Toronto, with the WG interested in the core of the
proposal, but not in all of the secondary parts.  Issues that were discovered
are being discussed by email among the WG members right now.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: pjl@sparc3.cs.uiuc.edu (Paul Lucas)
Subject: Re: I need to pause until return is pressed...how?
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Wed, 29 Jul 1992 21:04:30 GMT

In <156m1dINN7lr@matt.ksu.ksu.edu> kentiler@matt.ksu.ksu.edu (Kent Iler) writes:

>Hi,
>  How, in C++, without including stdio.h can I wait until
><return> is pressed?  You can do a getc/getch by
>using stdio.h, but I would think there would be some
>way in C++ to do this without including that file?

*****>	What's the matter with iostream.h?  If you meant "how do I do
	this without any .h"...well, C(++) has _no_ I/O at all, so
	there's no implementation-independent way.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: carterb@topaz.ucq.edu.au (Heaven can wait...)
Newsgroups: comp.lang.c++
Subject: BI Template classes. Arrays.
Date: 23 Jul 92 13:33:27 AET
Organization: U.C.Q. Rockhampton, Qld.

Hi..
I don't know weather this has been discussed before, but here goes...

Has anyone used the Template classes, in particularly, array class. If so,
is there any way to use it that will enable you to simply check to see if
it has actually resized, or it ran out of memory..  As it stands, it dumps
everything if there isn't enough memory left. Is there anyway short of a  
rewrite to make it more useable??

Any help is greatly appreciated.  I just get the feeling I am missing
something. What would be the use of "insert a line, opps, sorry, no memory
left, so i'll dump you without saving your last 3hrs work:)"

Thanks in advance...

-- 



********************************************************************************
Brett Carter 						3rd Year,
  *GSX400*					Bachelor of Applied Science
							Computing.

"The only words I can spell are reserved words."
                                      			       
CARTERB@TOPAZ.UCQ.EDU.AU               
********************************************************************************
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: New C++ type: boole
Date: 29 Jul 92 19:37:23 GMT
Organization: Microsoft Corporation

In article <1992Jul27.135243.28686@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
|NO!  Do *NOT* make this warning mandatory.  Some of us prefer to write
|code like this on purpose.  

"Mandatory warnings" in a language standard is an oxymoron.  From the 
context of the *language* either something is illegal and therefore cannot
be legally done, or something is legal and therefore can be legally done.
IE either its an error or its not.  "Warnings" then, are not part of the
language, but rather are part of an implementation -- typically they represent
an area of the language where the implementors of a compiler disagree with
the specifiers of the language, in effect a warning says: "you can do this
if you insist, but *we* think its stupid!"

|The only 'advantage' I can see to a 'real' boolean type is if you can
|guarantee me that it will only take up one bit and the compiler is
|bright enough to store them all off in some bit array someplace to
|save space.  Otherwise, I guess I fail to see any pressing need for
|this.

I don't see this as being a very plausible feature of a 'boole' or whatever
you want to call them.  A byte is already the smallest addressable unit of
storage.  The reason for this is simply in most hardware a byte is the smallest
addressible unit of storage.  Implementations could be required to implement
a non-native pointer that gives bitwise addressibility, but such a pointer
would be incompatible with native pointers [in much the same way the
"pointers" to member are incompatible with native pointers]

BUT, people can and do do this ALREADY without compiler support.  IE people
already DO write bit arrays and use bit pointers and bit indexing.  Its just
that since CPUs don't typically support this in hardware, such bit addressing
is not terribly efficient.  This is primarily a hardware problem.  To a lessor
extent its a problem in the optimization efficiency of current C++ compilers,
and also to some extent its a problem with committee members who support
"humpty dumpty" const.
Newsgroups: comp.lang.c++,comp.std.c++
From: mat@uunet.uu.net!mole-end
Subject: Re: Language extensions for run-time type identification
Summary: On Bath-Buns
Organization: :
Date: Sun, 26 Jul 1992 01:42:23 GMT

In article <1992Jul24.141611.19647@cadsun.corp.mot.com>, shang@corp.mot.com (David (Lujun) Shang) writes:
> In article <1992Jul23.183041.147@uunet.uu.net!mole-end>  
> mat@uunet.uu.net!mole-end writes:

> > But without virtualization (polymorphic behavior) derivation is effectively
> > useless. There is no reason to code inheritance without providing for
> > virtualization. 
> I disagree. The language Oberon ... has derivation without virtualization.
> Can you say that the  derivation is useless in Oberon, or the language
> Oberon is useless since it adds only a useless thing to Module-2?
> Derivation is introduced mainly for code reuse, not for polymorphism. ...

The catch is that C++ DOES support both polymorphism and polymorphic
conversions of pointers and references.  Given that the language supports
those conversions, to NOT make the proper things polymorphic is to invite
type errors.
 
> > Then the case which you mention is of no use unless and
> > until it is provided with RTTI; ...
> Even we suppose what you said was true, it is still against logic to get the  
> conclusion that only those polymorphic classes need RTTI:
 
> if
>     Derivation requires RTTI, and
>     Derivation requires virtualization (otherwise it is useless)
> then
>     Only virtualization requires RTTI

How about this:

	Derivation is only useful when used properly with virtualization.
	Virtualization is only meaningful in the context of derivation.
	Only derivation can make use of RTTI.
  therefore
	RTTI is only useful in the presence of virtualization.

 ------------------------------------------------------------------------------
	1) Every idea of mine, that cannot be expressed as a syllogism,
		is really ridiculous;
	2) None of my ideas about Bath-buns are worth writing down;
	3) No idea of mine, that fails to come true, can be expressed as
		a syllogism;
	4) I never have any really ridiculous idea, that I do not at
		once refer to my solicitor;
	5) My dreams are all about Bath-buns;
	6) I never refer any idea of mine to my solicitor, unless it
	   is worth writing down.
					--RAH/CRD _The Number of the Beast_
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Language extensions for run-time type identification
Date: 22 Jul 92 17:51:37 GMT

tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

>As I understand it (I haven't read the proposal), there will
>apparently be a half-hearted attempt at adding runtime type tags to
>some user-defined classes. From the descriptions of the proposal that
>I have heard, that will not be sufficient to make the C++ language
>safe (in the sense of eliminating most sources of "undefined
>behavior"). In fact, at best, it will encourage a careless programming
>style that relies on runtime type tests rather than inheritance and
>virtual functions.

Ack!  Such cynisism; and from someone who hasn't even read the
proposal yet!  First read the proposal, *then* you can be cynical.

Actually, the RTTI proposal sounds pretty good to me. (I have read
it.)  It is a trade-off, as is nearly every feature of C++; but it is
a well thought out one.  It certainly makes the language safer, since
casts which had been legal and unchecked will now become dynamically
checked.  Will it encourage careless programming?  Please!  Careless
programing is perpetrated by careless programmers.  Careless
programmers are not thwarted in their intentions by the language they
use.

Can RTTI be misused?  Certainly!  So can integers:
		for (i=0; i<1e99; i++) ;

Does RTTI improve the language?  Yes, emphatically.  Specifically in
the area of identifying objects which come out of heterogenous
containers.  Some have expressed the opinion that RTTI should not be
used in this way since the objects in heterogenous containers should
be accessed only by their known interface.  This is usually correct.
But there are occasions where DOWNCASTING such objects is useful.


--
+---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting         |
| rmartin@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering    |
|     (Uncle Bob.)     |-RRR--C----M--M--M-| OOA/OOD/OOP Training      |
+----------------------+-R--R--CCC-M-----M-| Product Design & Devel.   |
Newsgroups: comp.lang.c++
From: kinne@delfin.com (Kinne Strong)
Subject: Re: C++ compiler macros
Organization: Foxglove Associates
X-Newsreader: Tin 1.1 PL4
Distribution: usa
Date: Wed, 22 Jul 1992 18:54:57 GMT

steve@taumet.com (Steve Clamage) writes:
: 
: You could do this:
: 
: #if defined(__cplusplus)
: 	... C++ compiler
: #elif __STDC__ == 1
: 	... Standard C compiler
: #elif defined(__STDC__)
: 	... you probably have function prototypes
: 	... no telling what else you can count on
: #else
: 	... K&R
: #endif
: 
: Of course, not all pre-Standard compilers recognize #elif.  Sigh.

I wouldn't want to bet on the test of __STDC__ not generating an error
when __STDC__ was not defined, either, although it worked just fine on
Sun C++ when I tried it. Sun C++ seems to treat undefined symbols as
having a value of 0 -- something I can find no justification for (though
I haven't tried very hard). Anyone know if this can be relied on?

If you must worry about very very old compilers you will need to use
#ifdef instead of #if defined() (and you have my sympathy).

--
Kinne Strong
kinne@netcom.com
From: pathak@mitre.org (Heeren Pathak)
Newsgroups: comp.lang.c++
Subject: Re: Language extensions for run-time type identification
Date: 21 Jul 92 15:36:25 GMT
Followup-To: comp.lang.c++,comp.std.c++
Organization: Mitre Corporation

In article <N3A5KQD@netmbx.netmbx.de>, jrobie@netmbx.netmbx.de (Jonathan
Robie) wrote:
> 
> pathak@mitre.org (Heeren Pathak) writes:
> 
> >In article <EY048MK@netmbx.netmbx.de>, jrobie@netmbx.netmbx.de (Jonathan
> >Robie) wrote:
> >> 
> >> shang@corp.mot.com (David (Lujun) Shang) writes:
> >> 
> >> >The language should provide run time type checking as well as array bounds  
> >> >checking. You can also have a switch to turn off them if you like to.
> >> >  
> >> 
> >> It may be important for compilers to provide such a switch since the
> >> memory overhead needed to store type information for all classes can
> >> be significant.  Pragmas would be necessary to switch it on and off
> >> since you might need it for some classes but not for others....messy,
> >> isn't it?
> >> 
> 
> >Why not use MI to provide a "standard" mix-in class that provides run-time
> >identification?  
> 
> I assume you mean that this class would give access to the run-time

This is exactly what I meant.

> identification provided by the compiler, right?  That might make sense,
> but I don't like the idea of making the compiler look at the derivation
> tree to see whether it should generate run time identification.
> 

I don't see how this is any worse than using pragmas or having a new
keyword to identify objects that use run-time identification.  Could you
explain the problem with the complier looking at the derivation tree?  From
my viewpoint, run-time id would be another characteristic of a class and
all classes derived from it.  

> Obviously, no class is going to be able to generate run time identification
> for objects including it or derived from it.  How should it know the
> relevant types?
> 

Well, if the complier uses the class tree when it determines the type, it
can generate "proper" run-time id for all objects in the tree.  That is I
suggest that people look at using MI instead of pragmas.  

-------------------------------------------------------------------------
Heeren Pathak                      | Television is a device that permits
pathak@mitre.org                   | people who haven't anything to do to
Mitre Corporation                  | watch people who can't do anything.
(617) 271-7465                     |	               	-- Fred Allen
-------------------------------------------------------------------------
Disclaimer: Mine not Mitre's.
From: dsims@thor.ece.uc.edu (David Sims)
Newsgroups: comp.lang.c++
Subject: WANTED: Date/Time classes that work with g++
Date: 21 Jul 92 13:12:02 GMT
Distribution: usa
Organization: University of Cincinnati

I've checked into the NIH class library.  Unfortunately, NIHCL doesn't
work with g++, the C++ compiler that I use.

Would someone kindly send me some date/time classes that will work with
g++?  At the very least, how about an ftp site?

Thanks in advance.  I don't relish the thought of writing date/time
classes when they have been written so many times before!



-- 
David Sims                      Dept. of Electrical and Computer Engineering
dsims@thor.ece.uc.edu           University of Cincinnati
(513) 556-2499                  Cincinnati OH  45221-0030
                                USA
Newsgroups: comp.lang.c++
Subject: Re: How to avoid calling destructor twice after fork()?
From: Bruce.Hoult@bbs.actrix.gen.nz
Date: Thu, 30 Jul 1992 12:01:50 GMT
Organization: Actrix Information Exchange

In article <1992Jul29.180655.4716@cis.ohio-state.edu> gyu@cis.ohio-state.edu (george yu) writes:
> I am using fork() system call in my C++ program. The problem is that each
> calling of fork() creates a copy of calling process. The problem is any
> instances created and not destroyed before fork() calling will be 
> destroyed twice. The following figure shows the problem.
> 
> class MY_CLASS;
> main()
> {	
>    MY_CLASS my_class;
> 
>    if(fork()==0)
>     {
>        // process 1
>     }
>    else
>     {
>        // process 2
>     }
>    
>    // everything beyond this point will be executed twice, including
>    // the destructor of my_class.
> }
> 
> Any suggestions?


What's the problem?  After the fork you've got two seperate objects in
different processes and running the destructor on both of them is the
correct thing to do -- the only possible problem is that the fork()
call effectively does a default operator= to create the second copy
instead of using any operator= that you've defined.

If you really do have a problem with this then either ensure that the
object is destroyed before the fork() ...

    {
       MY_CLASS my_class;
       // use it
    }
    if(fork()==0){
       // ...

... or else don't declare it until you get into the true and/or false
branches of the fork().

































































-- 
Bruce.Hoult@bbs.actrix.gen.nz   Twisted pair: +64 4 477 2116
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: strdup() Was: Re: Renew?
Organization: TauMetric Corporation
Date: Tue, 28 Jul 1992 16:33:56 GMT

adk@Warren.MENTORG.COM (Ajay Kamdar) writes:

|Given that new and malloc are not necessarily related, deleteing memory
|returned from strdup() [STRINGS(3)] could be a recipe for disaster since the
|returned memory is malloced and not newed. It is onerous to keep track of
|which memory is newed, and which is malloced. C++ code written using strdup()
|might work with one compiler but not with another if care is not exercised
|in freeing the returned memory.

|Is there any move towards providing C++ified versions of functions like
|strdup() as part of some standard library? Right now the only solution
|I know is to implement my own version of such functions.

Good analysis.

The strdup() function is not part of Standard C, and is thus not being
contemplated for Standard C++.

Since strdup is a very tiny function, your best bet is to write one
yourself for use with C++, using new rather than malloc if you wish.

You will run into problems with header files and library organization
if you call it strdup, so probably you should pick a different name.

Since strdup is so common, I don't know why it was not made part of
Standard C.  Does anyone know whether it was dicussed by X3J11 and
if so, why it was rejected?
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Xref: sparky comp.lang.c++:11863 comp.std.c++:1008
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: run-time type checking, freezing, and thawing
Date: 31 Jul 92 17:59:59 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: rbbb

In article <FAM5HFE@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
>Somebody out there is not listening.

I'll say (but with different meaning).  Perhaps, people have looked at
the problems of freezing and thawing data structures before in other
languages?  Perhaps, people have even built tools to allow easy
generation of "freeze" and "thaw" code for data types in the past,
or libraries that colluded with the compiler so that it was just
another run-time facility? Perhaps people have even built systems that
used these tools?

Reading about what other people have already done is so dull and
boring.  It's much more fun to re-invent the wheel, I think.

What I am sarcastically referring to is the work done, years ago, at
both Olivetti and DEC on "pickling" data structures.  DEC uses the
library approach; at Olivetti we used the tool approach.  We used
pickled data structures as part of the input to the pre-linker.  This
was done for a couple of languages in the Modula family (2+ and 3, I
believe).  

David Chase
Sun
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: boolean (was: Re: typedef vs enum)
Date: 23 Jul 92 17:50:27 GMT
Organization: negligable

In article <1992Jul19.142813.9295@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>In article <1992Jul18.193943.3804@taumet.com> steve@taumet.com (Steve Clamage) writes:
>>If you come up with a proposal, please remember that existing code
>>which assumes 0/1 int results for || && ! operators should still work.
>>Such code should also work in if/while/for/switch control expressions.
>>So should expressions of type boolean.
>
>	It follows that pointers and numbers MUST convert to
>type boolean automatically.

Why?  Couldn't we overload || && and ! to return bool?

>	Now there is only ONE decision left:
>
>	should boolean convert to int without an explicit cast?

This we DO need, since we cannot overload "if", and if we want

to write 
	bool cond;

	if (cond) 
		something;

I *think* we need to provide auto-conversion from bool to int.


> 	I say yes, although such a boolean type is hardly
>	isolated from integral types!

Since I have suggested NO auto conversion from int-->bool we
still have some isolation.  You can use a bool where an int
may be expected (such as in "if"), but NOT (without casting)
use an int where a bool is expected!

Of course, if the compiler accepts a bool in an "if" condition
w/o providing a bool-->int auto-conversion even better.
Newsgroups: comp.lang.c++