HDTenEightyP/NetNews huggingface dataset:
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Newsgroups: comp.lang.c++
Subject: Re: A modest proposal...
Date: 11 Dec 1992 17:47:09 -0600
Organization: Kansas State University
NNTP-Posting-Host: matt.ksu.ksu.edu

cs911461@ariel.yorku.ca (C. Armour-Kidson) writes:

>comp.lang.c++'ers,

>Due to amount of traffic on this group concerning Borland C++ and
>other DOS specific compilers, would it be rude to suggest that 
>such material be moved to another newsgroup, say, comp.lang.c++.borland
>or comp.lang.c++.dos or something?  I can't speak for everyone but
>it's getting hard to find articles specific to C++.

Well, I just answer the person's qusetion via mail and append a little
note:

This group is for the discussion of the C++ language (and occasionaly
the Unix implementations of it).  Please take your MS-DOS specific
questions to comp.os.msdos.programmer next time.

(Note:  I do read c.o.m.p regularly)
-- 
Dan Odom
danodom@matt.ksu.ksu.edu

Newsgroups: comp.lang.c++
From: pandrews@lovat.fmrco.com (Paul Andrews)
Subject: C++ Lex classes?
Reply-To: pandrews@lovat.fmrco.com
Organization: Fidelity Investments Ltd.
Date: Wed, 16 Dec 1992 16:28:20 GMT

I'm sure this is asked for alot but: Does anyone know of any 'good' non-commercial
class libraries that do the same job as lex?

'Good' here means:

1. C++ good, i.e. you can have more than 1 instance.

2. Lex good, i.e. providing at least the same functionality as lex.

Thanks in advance etc...
---
Paul Andrews

EMail				Telephone
pandrews@lovat.fmrco.com	+44-71-975-4723

Organization: Robotics Institute, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.lang.c++
Date: Thu, 17 Dec 1992 13:42:36 -0500 
From: "Jon C. R. Bennett" <jb7m+@andrew.cmu.edu>
Subject: Re: C++ Reuse Class -- HELP



kirby@xerox.com (Mike Kirby) writes:
> themselves, but never got around to it?  Would Yet Another Strings Class be
> useful?  I realize that the NIH and COOL class libraries have a lot of things
> in them, but is there something about either or both of those classes that
> was done "wrong"? 

yes, (and i can only realy speak to the question about NIH) its too large
and "gunky", and it forces its view of a programing environment upon you,
what we need are class librarys that are more like libc and less like NIH

jon
Newsgroups: comp.lang.c++
From: kriss@blues.ibp.fr (Christophe GROSJEAN)
Subject: Why not nested functions ?
Keywords: nested functions, c++
Reply-To: grosjean@masi.ibp.fr
Organization: Laboratoire MASI, Paris, France.
Distribution: comp
Date: Wed, 16 Dec 1992 15:24:33 GMT

Why nested functions are they not allowed in C++ ?

There is many cases where they would be usefull.

My point is that you can *simulate* nested functions using
a local class. To call the function you call a member function
of the local class, you explicitely give the syntaxic context 
you need for the function copying the automatic variables
you want to use in local class members variables.

In one word : I *do* it, so it can be done.

Why is it not a C++ feature ? Adding it wouldn't change *anything*
in todays working code (right now it is forbidden !).
If it's an efficiency problem, so what... People who don't need it
don't have to use it. People who need it should use it without having
the trouble i have. I hav'nt found any other way than nested functions
to provide a context to recursive iterators (that can't easily give control
back to users after each element : no next() function available !).

I'd appreciate to hear what you C++ lawyers have to say about it.
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: new returns address it already returned!
Date: 11 Dec 92 22:08:27 GMT
Organization: Microsoft Corporation

In article <Bz24B3.62A@news.cso.uiuc.edu> dmd39855@uxa.cso.uiuc.edu (Daniel DuBois) writes:
|Anybody know what the heck is going on?  Why in heck would new return the
|same address?

Two common ways for this to happen are:

1) A delete has been called on the prior allocation, freeing the block to
be reused by new.

2) A delete has been called incorrectly on somw prior allocation, corrupting
the heap, leading new to think the block in question is free to be reused by
new.

Common ways to corrupt the heap include:

* Using polymorphism and news/deletes without declaring virtual destructors.

* Mixing up new/delete with new[n]/delete[]

* writing off the end of an allocation.

As a test, I suggest if at all possible start by commenting out ALL of
the delete statements your program uses.  Not some, ALL of them.  This
is only possible to do if your program makes reasonably bounded use of
heap.  If you can do this, and if doing so causes your bug to go away,
then your error is in one or more of the delete statements [or side-effects
they cause]  The question then simply becomes which one[s] to fix.
Note that MFC has a debugging new/delete option that is frequently useful
in tracking down allocation problems.
Newsgroups: comp.lang.c++
From: schouten@sp95.csrd.uiuc.edu (Dale Schouten)
Subject: Re: How to call C++ functions in a C program?
Organization: Center for Supercomputing R & D
	<1gqe3lINNs1v@eagle.natinst.com>
Date: 17 Dec 92 12:55:50

In article <1gqe3lINNs1v@eagle.natinst.com> banshee@natinst.com (Jeff Kellam) writes:
> In article <1gqbepINNt6s@function.mps.ohio-state.edu> ren@function.mps.ohio-state.edu (Liming Ren) writes:
>>I know we can call C functions inside a C++ program. Is there a way to
>>call a C++ function inside a C program?
> 
> Basically, you can't.
Methinks thou doth protest too much.

I'm not sure how standard it is, but with at least some compilers (read, `at
least one', lest I get flamed for being presumptous) you can use an
extern declaration (it's in The Book) and it will solve all your
problems for you (that is to say, it'll take care of naming problems).
Ofcourse you can't do the same things from C that you can in C++, like
calling member functions directly and all that, but with a reasonable
interface it shouldn't be difficult to do whatever you need.
For example, for the compiler with which I am familiar, you say:

extern "C" {
int Cplusplus_function(int,char *);
}

and then in your c code you just call it by that name with those type
of parameters and everythings hunky-dory.

As I said, I don't know how standard it is, but check the docs on your
compiler and there should be something somewhere.

Good Luck!
Dale Schouten
schouten@uiuc.edu
Newsgroups: comp.lang.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: The fate of my exponentiation operator proposal
Date: Wed, 16 Dec 1992 08:37:33 GMT
Organization: None

jimad@microsoft.com (Jim Adcock) writes:
|In article <1992Dec5.063533.1787@frumious.uucp> uunet.ca!frumious!pat writes:
||jimad@microsoft.com (Jim Adcock) writes:
|||Where is the offsetting benefit in *requiring* implementations to make this
|||change breaking conforming programs?  ANSI-C *already* requires that
|||macro implementations only perform one evaluations of the macro parameters,
|||so what are you gaining by forcing implementations to now use inline
|||functions instead of macros for these things?
||
||If these functions may be implemented as macros, then their names may not
||be used in other ways (not by programmers who aspire to write portable
||code, anyway).  For example, consider
||
||   class Prisoner {
||   public:
||      // ...
||      void free();   // Let him out on parole; not related to malloc()
||   };
|
|Agreed.  You give an excellent example of why ANSI-C functions should
|continue to be implemented as macros not as inlines.


I take it you consider the above to be an unreasonable use of the
name free.  Perhaps it is and perhaps it isn't; people often have
different opinions as to what's reasonable.  In the absence of a
strong concensus that something is unreasonable, I would prefer to
allow those who believe it to be reasonable to do it.


Here are a few other examples you might find more convincing.

Consider the above in the context of a project where malloc() and the
normal free() are never used; all memory allocation is done through
new and delete.

Steve Clamage mentioned the possibility of using sin to refer to
immoral acts, instead of the sine function.

In some cases, an existing name from the standard library can
be quite intuitive as a name for a new function.  For example,

   class String {
      // A sequence of characters, possibly including null characters
      // in arbitrary positions.
   public:
      size_t length() const;
         // Length of the sequence, including the nulls (if any).
      size_t strlen() const;
         // The number of characters before the first null character
         // (not including the null); the same as length() if there
         // aren't any nulls in the string.
   };

Stepping to another language for a moment, there's a problem with
this C code, if memory serves me correctly:

   typedef whatever Razor;
   void strop(Razor r);

The problem?  The C standard reserves names beginning with str for
use in future versions of the standard.  So this code might not
compile a few years down the road.  If one takes this restriction
seriously, there are quite a few normal English words one shouldn't
use in C programs (strong, straight, stress, strict, etc., etc.).
It would be nice to be able to use these words in C++ programs
without having to worry about future versions of the standard,
even if only in some contexts (eg. as member function names).

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
From: doug@foxtrot.ccmrc.ucsb.edu (Douglas Scott)
Newsgroups: comp.lang.c++
Subject: Calling a member functn via ptr passed as arg to another functn
Date: 15 Dec 92 04:46:35 GMT
Organization: Center for Computer Music Research and Composition, UCSB

Here is a very much simplified case of what I wish to do:

class Object;	// to allow typedef
typedef int (*Object::InternalFun)(int); // or close to this...

class Object {
	int internalFunctionA(int i);
	int internalFunctionB(int i);

	int anotherFunction(int x, InternalFun funptr);
public:
	int pubFunA(int x) { return anotherFunction(x, internalFunctionA); }
	int pubFunB(int x) { return anotherFunction(x, internalFunctionB); }
};

// trivial cases of these...

int Object::internalFunctionA(int i) { return i * 5; }

int Object::internalFunctionB(int i) { return i * 6; }

int Object::anotherFunction(int x, InternalFun funptr) {
	return (*funptr)(x);	// this is obviously wrong
}

What I wish to do is create a series of public functions that all call a
single private function, with the difference being that pointers to various
other internal functions are passed as the second argument.

I dont have my ARM handy, so I may have the declaration of the typedef wrong,
but my question relates to the final function definition:

How do I call funptr within anotherFunction()?  Something like:

this->(*funptr)(x) ??  (*this->funptr)(x) ??

-- perhaps??  I have not been able to come up with the correct one yet.

Thank you very much in advance.

-- 
Douglas Scott                              (805)893-8352
Center for Computer Music Research and Composition
University of California, Santa Barbara
Internet: (NeXTMail ok)   <doug@foxtrot.ccmrc.ucsb.edu>
Newsgroups: comp.lang.c++
From: feathers@serss0 (Michael Feathers)
Subject: Re: Give me safe C++
Organization: Florida International University, Miami
Date: Sun, 13 Dec 1992 04:44:07 GMT

In article <1992Dec12.145403.26483@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>In article <WARSAW.92Dec11124441@anthem.nlm.nih.gov> warsaw@nlm.nih.gov (Barry A. Warsaw) writes:
>>
>>Agreed. IMHO, the real power of C++ as a development language is the
>>ability to easily climb up and down the abstraction ladder depending
>>on the context of the problem.  Sometimes you need to mingle with the
>>bits in the basement, sometimes you just need ADTs and sometimes you
>>really want to do OOP.  The beauty of C++ is that it seamlessly
>>supports many levels of abstraction.
>
>	While tending to support your liking of the C++ 'hybrid'
>approach, I'm not so sure about 'seamlessly', are you?
>
>	And I think you tend to miss exactly where rigid restrictions
>on functionality are the things which *yield* the very power you desire.
>For example, virtual functions can be trivially implemented
>using function pointers. Function pointers in fact are a vastly
>more powerful technique than mere virtual functions. 
>
>	What makes virtual functions so useful is the fact that they
>are so tightly restricted .. for example, unlike a genuine
>function pointer they cannot be modified after object creation,
>nor specialised on a per object basis.
>

I think that it is useful here to take an overall view of a language.  The
restrictions on virtual functions in C++ that you mention are definitional
restrictions.  If we had specialization on a per object basis, the notion of 
a class would not have the same meaning and the conceptual framework of the
language would be altered.  In the overall view, one could say that C++ does
not have a limitation on functionality by the definition of virtual functions
because it does have function pointers and you can do exactly what you wish 
(ignoring virtual functions).

In some other languages this is not the case.  Some functionality is restricted
because it is deemed hazardous, and special rules are formulated so that it
can not be attained with any language constructs.

Consider the static type checking of C++.  In the same way that you say that
the definition of virtual functions restricts C++, I could say that type
checking restricts C++.  However, in both cases, there is an "out" and no
functionality is sacrificed.  You can use function pointers to specialize
"objects" and you can uses casts to subvert type checking.
From: euajvs@eua.ericsson.se (Jan Skarvall)
Newsgroups: comp.lang.c++
Subject: Hindsight experience?
Date: 15 Dec 92 09:40:01 GMT
Reply-To: euajvs@eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden

Has anyone out there heard of a software environment
called Hindsight?

I think it supports C development, but maybe also C++.

If you have any pointers to the product or experience
of use, please let me know.
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Give me safe C++
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 12 Dec 1992 14:54:03 GMT

In article <WARSAW.92Dec11124441@anthem.nlm.nih.gov> warsaw@nlm.nih.gov (Barry A. Warsaw) writes:
>
>>>>>> "Michael" == Michael Feathers <feathers@serss0> writes:
>
>    Michael> The Ada people had the best of intentions, I'm sure, but
>    Michael> I think that C and C++ are versatile languages precisely
>    Michael> because no one ever tried to limit their functionality
>    Michael> with good intentions.
>
>Agreed. IMHO, the real power of C++ as a development language is the
>ability to easily climb up and down the abstraction ladder depending
>on the context of the problem.  Sometimes you need to mingle with the
>bits in the basement, sometimes you just need ADTs and sometimes you
>really want to do OOP.  The beauty of C++ is that it seamlessly
>supports many levels of abstraction.

	While tending to support your liking of the C++ 'hybrid'
approach, I'm not so sure about 'seamlessly', are you?

	And I think you tend to miss exactly where rigid restrictions
on functionality are the things which *yield* the very power you desire.
For example, virtual functions can be trivially implemented
using function pointers. Function pointers in fact are a vastly
more powerful technique than mere virtual functions. 

	What makes virtual functions so useful is the fact that they
are so tightly restricted .. for example, unlike a genuine
function pointer they cannot be modified after object creation,
nor specialised on a per object basis.

	So when language designers propose restrictions, one must
carefully weigh up the pros and cons: most restrictions also
grant freedom. In the case of virtual functions, if your
program compiles and links they are sure to be properly initialised,
freeing you from checking this manually. Inadvertant execution
of uninitialised function pointers does result in interesting
problems for those who enjoy debugging though.



-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: alane@wozzle.linet.org (J. Alan Eldridge)
Newsgroups: comp.lang.c++
Subject: Re: Wrong directions at Borland?
Date: 15 Dec 92 02:58:00 GMT
Organization: Disorganization

kanze@us-es.sel.de (James Kanze) writes:

> In article <1992Dec4.211512.4167@kronos.arc.nasa.gov>

> |> >Zortech's got one, but I don't think that there up there with Borland
> |> >or Microsoft in sales.
> 
> |> Zortech has other problems.
> 
> Technical or others? :-)

1. Walter's a bright guy (pun intended). His compilers are very good,
but often a little quirky, and often released without sufficient testing.
He does generate absolutely screaming code, though.

2. Symantec's policy has been not to provide interim patch releases. This
will probably change with their 3.1 release.

3. The language group is tremendously understaffed, especially in QA and
support. This has caused support to suffer. Hopefully this will also change.

These are my own opinions resulting from conversations with Symantec
personnel. 

The product is technically very good... but I wouldn't recommend it to
a novice programmer, nor even someone just a novice at 32-bit DOS. This
is a product for professional developers.





alane@wozzle.linet.org (J. Alan Eldridge)
Fido: The University of Walamaloo 1:272/38.473
Newsgroups: comp.lang.c++
From: dgrammel@dgrammel.mentorg.com (Dave Grammel)
Subject: Re: & of inline functions
Date: Tue, 15 Dec 1992 23:30:31 GMT
Organization: mentor
Keywords: 
Followup-To: 

In article <1992Dec13.185310.20140@math.ufl.edu>, x9999bvj@maple.circa.ufl.edu writes:
|> 
|> What is the official method for handling taking the address of an inline
|> function?  For example, if you do this:

Don't make it inline.

|> 
|> inline void Hello( void )
|> {
|>    puts("Hello");
|> }
|> 
|> void HelloFnc( void (*fnc)(void) )
|> {
|>    fnc();
|> }
|> 
|> void main( void )
|> {
|>    HelloFnc( Hello );
|> }

-- 
Dave Grammel                      ||   
Mentor Graphics Corportation      ||   If it's not broke bad enough,   
dave_grammel@mentorg.com          ||         don't fix it.
(503) 685-7000                    ||
From: acanter@sdcc3.ucsd.edu (Adriaan Canter)
Newsgroups: comp.lang.c++
Subject: Templates
Keywords: Template Inheritance
Date: 11 Dec 92 16:59:32 GMT
Distribution: ca


I've read the FAQ, but I don't have a compiler supporting templates.
Does the following code work, or does Vector have to be templated
with a pre-defined Type before I can inherit from a class of Vector
of Vector of Type?

template<class Type>
class Vector {

       .
       .
       .
       .
       .
};

template <class Type>
class Matrix : public Vector < Vector <Type> > {
       .
       .
       .
       .
       .
       .
};


Newsgroups: comp.lang.c++
From: mfrutig@tnd81 (Mark Frutig)
Subject: Re: How to attain Eternity (getting by the universal destructor :)
Organization: First National Bank Of Chicago, Chicago IL, USA
Date: Sat, 12 Dec 92 22:49:35 GMT

In article <1992Dec05.234122.10911@crash> classics@crash.cts.com (Baruch  
Schwartz) writes:
> 			The Original Kriya Science
> 		(How to Attain eternal Realization of the ultimate Self)
> 
> 				The Message
> 				-----------
> 
> 	Can thirst be quenched by merely shouting the word "water"? 
> Certainly not! Shouting only worsens the situation. The uttering of  
words 
> does not produce the desired results as some devotees advocate and 
> propagate.
> 
> etc, etc, etc
This is a very interesting progarmming problem.  My feeling is that we can  
template Brahma and subclass such issues as "The Message".  Anyone
have any ideas how other major religions might be implimented in code.

Mark Frutig
mfrutig@fnbc.com
From: terrer@cybele.inria.fr (Daniel Terrer)
Newsgroups: comp.lang.c++
Subject: Do I get through ?
Date: 17 Dec 92 15:51:50 GMT
Reply-To: Daniel.Terrer@sophia.inria.fr
Organization: Inria Sophia Antipolis


 Sorry all, but just check this gets through you all...

-- 
 ====================================================================
 Daniel Terrer
 S.E.M.I.R.                              (Postmaster@sophia.inria.fr)
 Inria Centre de Sophia Antipolis		Tel: (33) 93 65 77 22
 2004, Route des Lucioles BP 93			Fax: (33) 93 65 76 02
 06902 Sophia Antipolis Cedex

 Email:  Daniel.Terrer@sophia.inria.fr
 or
 X400:    C=fr; A=atlas; P=inria; OU=sophia; S=Terrer; G=Daniel; 
Newsgroups: comp.lang.c++
From: pete@borland.com (Pete Becker)
Subject: Re: Making a constructor fail
Originator: pete@genghis.borland.com
Organization: Borland International
Distribution: usa
Date: Fri, 11 Dec 1992 17:51:20 GMT

In article <vjf2w#+@rpi.edu> nelsonc@colossus.cs.rpi.edu (Chris Nelson) writes:
>Presumably, I could also override the new operator for the class so
>that IT tested the return flag from the constructor and deallocated
>the object and returned NULL if the allocation in the constructor
>failed?
>
>                                  Chris
>
	Isn't there some saying to the effect that "'presume' makes a 'pres'
of 'u' and 'me'"?  Unfortunately, there is nothing in the language that
requires that operator new get control after the
constructor is executed, so you can't use it to check whether construction
succeeded.
	-- Pete

Newsgroups: comp.lang.c++
From: swed@deveel.aero.org (Greg Swedberg)
Subject: Re: How to call C++ functions in a C program?
Organization: The Aerospace Corporation; El Segundo, CA
Date: Fri, 18 Dec 1992 23:39:48 GMT

	Declaring the C++ function using extern "C" make 
sure that the compiler doesn't mangle the name so that it
is callable from C.  However, if the C++ function uses ANY global
variables the programm must have a C++ main so that the
initialization code will get executed.  Remember that cout, cin, 
and cerr, are really just globals.  You also cannot call
member function directly from C you would need to add intermediate
extern "C" functions between the C code and the C++ member functions.

Gregory Swedberg
Newsgroups: comp.lang.c++,comp.sys.unisys
From: pfschell@unccsun.uncc.edu (Patrick F Schell)
Subject: C++ on Unisys U6000?
Organization: Decision Support, Inc.
Date: Tue, 15 Dec 1992 16:54:43 GMT

I hate this sort of posting too, so I'll keep this short.

If you know of a C++ implementation available on the U6000, please
send mail at this address.  Unisys apparently doesn't provide one
or even provide references; CenterLine doesn't support this platform,
but info on other such environments is also welcome.

Thanks.

Really Jim Perry, but you can think of me as Pat Schell for now...
Newsgroups: comp.lang.c++