HDTenEightyP/NetNews huggingface dataset:
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: feedback wanted on appropriate OOPL
Date: 13 Jan 93 01:26:11 GMT
	<TMB.93Jan10170408@arolla.idiap.ch> <1993Jan10.220917.22879@netcom.com>
	<TMB.93Jan11010738@arolla.idiap.ch> <rmartin.726795534@thor>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: rmartin@thor.Rational.COM's message of Mon, 11 Jan 1993 23:38:54 GMT

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

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

   |Detecting errors at compile time is better than detecting them
   |at runtime. But detecting errors at runtime is better than not
   |detecting them at all.

   |Unfortunately, the majority of errors that are detectable at all can
   |only be detected at runtime.

   I disagree with this statement.  In my experience, the majority of
   detectable errors, are detected in the compilation phase (and in the
   code review phase of course).

Array bounds violation, bad pointers, and type errors involving type
unions, are all detectable errors, but for most algorithms and
programs, they are not detectable at compile time.

From a practical point of view, I have used languages that have much
stricter compile time error checking than C++, and they still need a
lot of runtime checks.

   | C++ has no support for runtime error
   |checking, 

   Although there are common environments that provide it.

These "common environments" have a significant overhead, making them
useless for production use (if you are willing to accept that kind of
overhead, you would be better served with another language).
Furthermore, even for debugging some kinds of applications, they are
too slow to get your code to the point where the bug occurs.

   This I doubt.  I think it is more that some runtime features are
   expensive, period.  Languages that support them, have made a different
   tradeoff than that made in C++, and have sacrificed something else
   (probably speed) thereby.

Well, we'll just have to see. All the attempts of supporting safety in
C++ that I have seen (Purify, ObjectCenter, user-defined classes,
various GC implementations) have had much more overhead for supporting
those features than other languages.

In any case, it's not an "either/or" situation. You can support safety
features like array bounds checking etc. and let the user
enable/disable it for specific sections of code. The only reason why
this isn't a realistic approach in C++ is for reasons of backwards
compatibility with C, not because the C++ approach is somehow "more
efficient".

					Thomas.
Newsgroups: comp.lang.c++
From: dschieb@muse.cv.nrao.edu (Darrell Schiebel)
Subject: Template Quirk (Sun cfront/3.0 compiler)
Organization: National Radio Astronomy Observatory
Distribution: comp
Date: Tue, 12 Jan 1993 20:01:30 GMT


	I've run into a curious problem which must be a bug in the Sun
	cfront 3.0.1 based compiler. Below I have a test program
	which works as expected. However, if the inline function, "id",
	is changed to define its body within the class, i.e. the commented
	out line, it fails with the following errors:

"dum5.C", line 8: error:  qualified name A:: name not found in  fx
"dum5.C", line 8:        error detected during the instantiation of fx <A>
 "dum5.C", line 16:      is the site of the instantiation

	Anyone else ran into the "feature"?? Any ideas where the
	compiler is going astray??

						thanks,
						Darrell Schiebel
-------------------X-----X-----X-----X-----X-----X---------------------
#include <iostream.h>
#include <string.h>

class FX {};
template<class t> class fx : public FX{
public:
  fx *dup() {return(new fx());}
  fx() {cout << "fx - " << t::name() << endl;}
};

class A {
public:
  static const char *name() {return("A");}
//const FX *id() {return(new fx<A>());}
  inline const FX *id();
};
inline const FX *id() {return(new fx<A>());}

main() {

  fx<A> f;

}
From: alane@wozzle.linet.org (J. Alan Eldridge)
Newsgroups: comp.lang.c++
Subject: Re: More Gnu C++ fun
Date: 4 Jan 93 04:26:29 GMT
Organization: Disorganization

tel@adimail.uucp (Terry Monks) writes:

> This minimal program
> 
> 
> class node 
> {
> public:
>   static int level;
>   
>   node(){};
> };
> 
> main()
> {
>   node::level=1;
> }
> 
> 
> compiles and links fine using the AT&T compiler from Sun, but will not link
> under Gnu c++.  (sparc-sun-sunos.4.1)
> 
> I get the message
> ld: Undefined symbol
>    __4node$level
> 

Try adding:

int node::level;

to your code at file scope.

Should clear it right up.

alane@wozzle.linet.org (J. Alan Eldridge)
Fido: The University of Walamaloo 1:272/38.473
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Passing 2-d arrys to functions
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Trumphurst Ltd.
Date: Mon, 11 Jan 1993 12:09:35 +0000

In article <RUNE.93Jan10125255@pandora.nta.no> rune@nta.no (Rune Henning Johansen FBA) writes:
> I'm including a little program that seems to work fine. Here I'm pas-
> sing only the pointer to  a two dimensional array.  Can I expect such
> programs to work, and if so, why?
> 
>  - Rune
> 
>  = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> 
> #include <stream.h>
> 
> #define begin {
> #define end   }

I refuse to look at this program beyond this point :-)

-- 
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
From: Roy_Williams
Newsgroups: comp.lang.c++
Subject: parsing
Date: 8 Jan 1993 00:34:23 GMT
Organization: CCSF Caltech, Pasadena, CA
Distribution: world
Reply-To: roy@willow.ccsf.caltech.edu
NNTP-Posting-Host: willow.ccsf.caltech.edu

Suppose I have some class, for example vectors, with lots of
operators defined so I can do things like

	a += b + 3*c + a*b;

meaning in normal language

	for(int i=0; i<vector_length; i++)
		a[i] += b[i] + 3*c[i] + a[i]*b[i];

If the vectors are small and 'new' is cheap, we can define
each operator by creating a new one to hold the result, 
evaluating, then returning the whole vector. They get destroyed
by the system.

When the vectors get a bit larger, we want to return a pointer
to the new vector, using the magic of reference counting
to do the garbage collection.

Now suppose we get stingy about either the time taken for
memory allocation, or we are working at the limits of the
machine's available memory: if I were computing the above
operation with a hand-held calculator and pencil, I wouldn't
write down any temporaries, so I want my implementation of
vectors to do as well.

I'd like a vector to be either a set of numbers, as before,
or an operator type and pointer(s) to vector(s). Nothing would 
actually get computed until we get to the assignment (or even
until the thing is written out!).

Is there any code or book or reference or ftpable class library 
so I don't have to do this myself? How about optimizing the 
parse tree before evaluation so a*b + a*c becomes a*(b + c)?

Roy Williams
Caltech Concurrent Supercomputing Facilities
Pasadena, CA
From: chris@cad.gatech.edu (Chris McClellen)
Newsgroups: comp.lang.c++
Subject: Borland C++ & TVision
Date: 9 Jan 1993 16:41:27 -0500
Organization: Georgia Institute of Technology, CAE/CAD Lab
NNTP-Posting-Host: cae.cad.gatech.edu


I am using Borland C++ 3.1 with TVision.  Currently, I am running
into a problem with the Help subsystem....


Basically, if i compile up the TVDemo program, run it, and press f1 for
help, I get the help.  Now, if i hit escape, I get an "assertion failed",
and get dumped to dos.  Any program I try to put the help system in does
the same thing.  Any clues as to what is happening?  I havent modified
any RTL source, nor the TVdemo source.

Secondly, BC++'s TVision screen IO is absolutly slow compared to
Pascal's TVision.  WHat can I do to speed C++'s tvision up?

Main problem is the help system though -- their demo doesn't even work right.

Newsgroups: comp.lang.c++
From: heliotis.ROCH803@xerox.com (Jim Heliotis)
Subject: Re: Callbacks in C++
Reply-To: heliotis.ROCH803@xerox.com
Organization: Xerox Corporation, Webster NY
Date: Tue, 12 Jan 1993 14:17:28 GMT

In article 726677907@thor, rmartin@thor.Rational.COM (Bob Martin) writes:
>
>If you are designing a class library, you don't generally want to
>provide callbacks to your users.  Instead, you want to provide them
>with interfaces that they can use to receive information from you.
>These interfaces are abstract classes.  Pure virtual functions are
>declared which allow information to be passed from your class library
>to user objects derived from the abstract classes.  The users can
>implement the derivatives of the pure virtuals as they see fit.
>

That sounds like a callback to me, especially if something else in the
library calls the base class's pure virtual function.  I think it's
just a question of semantics.

============================================================================
Jim Heliotis                                       Voice Phone: 716-383-7410
Xerox Corporation                                   FAX Phone:  716-383-7395
435 W. Commercial St.                                     Mail Stop: 803-01A
East Rochester, NY 14445              Electronic Mail: JEH.ROCH803@Xerox.COM
============================================================================


Newsgroups: comp.lang.c++
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: why `int X: :X()' ?
Date: 11 Jan 93 19:36:57 GMT
Organization: negligable

In article <5501@miramon.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
>Matt Wette (mwette@csi.jpl.nasa.gov) wrote:
>
>: Why are constructor and destructor functions usually declared to return
>: ints when the usage typically warrents a `void' declaration.
>
>The "default int" rule does not apply to constructors and destructors.
>You can't return an "int" from those functions.  You can't explicitly
>mark them as procedures (void) either.
>
>I'd say that "default void" (as for constructors and destructors)
>makes more sense than "default int".  Having no default type at all
>makes the most sense, avoiding compiler and programmer confusion.

I'd say you are misleading yourself.  The best way (IMHO) to think
of constructors is returning the type for which they are a constructor.

e.g. (if you could):
	
	classType classType::classType() {}

but this would have been very confusing.  Therefore, just

	classType::classType() {}

but if you start thinking of

	void classType::classType() {}

Then declarations such as:

	classType classInstance = classType();

won't really make sense.  Don't try to second guess the
spec and put a mental "void" infront of the constructor,
because it doesn't belong there any more than the "int"
which would normally be implied (if the exception weren't
called out) belongs there.



		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"There are no problems, only opportunities!"
"What we have here is an insurmountable opportunity..."
From: rmckenna@fox.nstn.ns.ca (Rob McKenna)
Newsgroups: comp.lang.c++
Subject: dos/extenders and borland c++
Summary: comments on dos extenders wanted
Keywords: borland memory extenders
Date: 5 Jan 93 13:35:24 GMT
Organization: NSTN Network Operations Centre, Nova Scotia, Canada

I need a memory extender for use with borland turbo c++. Any comments on the various 
ones available would be appreciated
From: hlf@nic.cerf.net (Howard Ferguson)
Newsgroups: comp.lang.c++
Subject: How to prevent local instances, but allow "new"
Date: 5 Jan 1993 18:04:16 GMT
Organization: CERFnet Dial n' CERF Customer Group
NNTP-Posting-Host: nic.cerf.net

I wish to define a class in a library which the library user
can create by dynamic allocation via the new operator, but
I want to prevent him from creating automic instances.

I thought that giving the class a public new operator,
but a private constructor would work, but this prevents
any instances of either type from being created.

I suppose writing a satic member function called "createSomething"
which would then call a private constructor via new woulod work,
but it seems a little kludgy. I want my library users to create
their objects using new, as our creator intended, rather 
than calling some   non-standard function. Has anyone got this 
to work simply by manipulating the visibility of the 
existing functions.

I am reliably informed that if I wanted the inverse (i.e allow
automic instances but dissallow dynamic creation) then making
new private but the constructor public would work.

	tanx,
		hlf

Newsgroups: comp.lang.c++
From: lightw@cetra.trl.OZ.AU (Liron Lightwood)
Subject: Help. Is this a templates bug?
Organization: Telecom Research Labs, Melbourne, Australia
Date: Fri, 8 Jan 1993 00:36:33 GMT

I was experimenting with templates for use in our project, when I managed to
obtain a compiler error message which effectively said that there was an
error with the argument given to the constructor, even though what it got
was identical to what it expected.

Is this a bug with templates, or the compiler I am using?
How can I overcome it?

I am using an AT&T C++ 3.01 compiler on a SUN SPARCstation running under
SUNOS 4.1.1.

Here is the code, followed by the error message.

-------------------------------------------------------------------
class x
{
    public:
    int x_int() { return 21; }
         // x_int is a member function of class x which returns an
         // integer
};

template <class A,class B> class GetFunc {
public:
   B (A::*a_b_func)();  
        // func contains address of a member function of class A 
        // (e.g. class x) which returns an B (e.g. an int) 

   GetFunc(B (A::*f)()) : a_b_func(f) {}  // constructor
};

main()
{
    GetFunc<x,int> getfunc_x_int ( &(x::x_int) );
}


--------------------------------------------------------------------

Here is the compiler error message:

/usr/local/bin/CC a.c
CC  a.c:
"a.c", line 20: error: bad argument  1 type for  GetFunc <x, int >::GetFunc__pt__4_1xi(): int (x::*)() ( int (x::*)() expected)

------------------------------------------------------------------------


Liron Lightwood                     Internet : r.lightwood@trl.oz.au
Telecom Research Laboratories       Phone : +61 3 253 6535
770 Blackburn Road                  Snail : P.O. Box 249 Clayton 3168 Australia
Clayton  Vic. 3168 Australia        Disclaimer : My views are not my company's
Newsgroups: comp.lang.c++
From: msodhi@agsm.ucla.edu (Mohan Sodhi)
Subject: dos/extenders and borland c++
Summary: Use Phar Lap 286 with Borland 3.1
Keywords: dos extenders, pahr Lap 286, borland c++ 3.1
Date: 6 Jan 93 22:05:20 PST

I have been using Phar Lap/286 with Borland 3.1 (and earlier with 3.0) for a few months now: it is quite good and I would recommend it without hesitation.

The tech staff is quite knowledgeable and helpful.

Note that Phar Lap 286 limits you to 16Meg.

-Mohan Sodhi

(msodhi@agsm.ucla.edu)

Newsgroups: comp.lang.c++
From: Mar@esse1.dei.unipd.it (Marco Munari 345602/IL)
Subject: ?Serial program autor? who is?
Organization: Universita' di Padova, Italia
Date: Tue, 12 Jan 1993 17:42:06 GMT

I found at oak.oakland.edu a GOOD c++ program
in the dir. pub/msdos/cplusplus (I think that it's a copy of Simtel20)
This program implements a class of type Serial for the RS232 of
PC-IBM & conv. 
But the program has not a signalature nor the autor's name;
if someone know it, please, tell me his e-mail.

Thanx in advance

Bye,			Marco Munari

P.S. Excuseme for english errors; but I talk better C++ and ASM x86 :-)

--
/~v~~\    ::: ... Marco Munari ... :::::::::::::::::::::::::::::::::::
\_  */    :: .E-Mail:                =-> Mar@paola.dei.unipd.it <-= ::
  \  \    :: .Mail: Via A. Grimani 8  or mar@sabrina.dei.unipd.it   ::
 o \  \,  ::   31033 Castelfranco V.to (TV) (Italy, North)          ::
 O  \ _\  :: .Tel.: ++39 (423) 49.03.07                             ::
____// \\ :: La vera fonte del progresso e` l'abnormalita` perfetta ::
\__/    ' ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Newsgroups: comp.objects,comp.lang.c++,comp.lang.smalltalk,comp.lang.ada
From: cffs@fox.nstn.ns.ca (Doug Brown)
Subject: Re: example application software from Booch
Organization: Software Training Department
Date: Mon, 11 Jan 1993 12:12:43 GMT

>Does anyone have any pointers for ordering the Booch software for the
>example applications?
 
>A. Lester Buck   buck@siswat.hou.tx.us   ...!uhnix1!siswat!buck

We ordered a license two years ago.  The address used then was:

  Wizzard Software
  2171 South Parfet Court
  Lakewood, Colorado, 80227       (303) 986-2405

You may also be interested in the GRACE (Generic Reusable Ada Components for 
Engineering) library.  I have persoanlly never used it, but it seems to be
along the same lines as the Booch components.  GRACE is distributed by

  EVB Software Engineering
  5303 Spectrum Drive
  Frederick, MD                     (301) 695-6960

Hope this helps.

Doug Brown
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: forward declaration of a parameterized type?
Date: 5 Jan 93 13:42:25 GMT
Article-I.D.: alice.24555
Organization: AT&T Bell Laboratories, Murray Hill NJ




 > How do you do a forward declaration of a parameterized type?  This sort of
 > thing doesn't seem to work:

 > class LinkedList<foo>;

template<class T> class LinkedList;	// <<< this way
					// tells the compiler that LinkedList
					// is a template of one type argument

 > class foo{
 > public:
 > 	LinkedList<foo> *internal_foo_list;
 >
 > };
From: hlf@nic.cerf.net (Howard Ferguson)
Newsgroups: comp.lang.c++
Subject: Preventing inheritance
Date: 11 Jan 1993 04:40:25 GMT
Organization: CERFnet Dial n' CERF Customer Group
NNTP-Posting-Host: nic.cerf.net


If I create a class which I am supplying to other users, how do I
make sure that they do not inherit from it ever. I could overload new
and check the size of the object that is being allocated, but there
are two catchs. The first minor one is that this is a run-time check,
and it would be far preferable to catch this sort of thing at compile
time. More seriously, they could over-ride the new operator and by-pass
the check.
	yours totally paranoid,
			hlf
From: hlf@nic.cerf.net (Howard Ferguson)
Newsgroups: comp.lang.c++
Subject: Re: Callbacks in C++
Date: 11 Jan 1993 03:46:33 GMT
Organization: CERFnet Dial n' CERF Customer Group
NNTP-Posting-Host: nic.cerf.net

In article <rmartin.726677907@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>hlf@nic.cerf.net (Howard Ferguson) writes:
>
>>The FAQ for this group describes how to put wrapper functions around 
>>member functions so they can be called as callbacks from X libraries
>>and the like. But if I am writting a c++ class library, surley I should
>>be able to provide a cleaner mechanism to my customers. Is there
>>a standard way of doing this???
>
>If you are designing a class library, you don't generally want to
>provide callbacks to your users.  Instead, you want to provide them
>with interfaces that they can use to receive information from you.
>These interfaces are abstract classes.  Pure virtual functions are
>declared which allow information to be passed from your class library
>to user objects derived from the abstract classes.  The users can
>implement the derivatives of the pure virtuals as they see fit.
>
Does this derived function not just end up being a large
switch statement -- which is exactly what you are trying to avoid.
For example if the user has a display object with 2 members save_screen()
and zoom_screen(). When the buttons for these pieces of functionality
are created the application wants to tell the button that when it is
selected then the save_screen() function should be called.

If I derive from the ButtonCallback (supplied by the class library)
then I presume I will have to overwrite the ButtonHasBeenClicked() 
function which is a member of the ButtonCallback to do something like 
this 

UserButtonCallback::ButtonHasBeenClicked(Buttonvoid *userInfo)
{
	switch (userInfo) {
	case SAVE : display->save_screen();
			break;

	case ZOOM : display->zoom_screen();
			break;
}

I can see where your suggestion of deriving from a pure virtual would
be very useful in the situation where the number and types of 
callbacks are restricted -- but does it provide any easy way of getting
the functionality required for the example just given ???????

	hlf
Newsgroups: comp.lang.c++
From: suresh@papaya.iss.nus.sg (Suresh Thennarangam - Research Scholar)
Subject: Re: Help: using GDB to debug G++-compiled programs
Reply-To: suresh@iss.nus.sg (Suresh Thennarangam - Research Scholar)
Organization: Institute Of Systems Science, NUS
Date: Tue, 12 Jan 1993 01:48:48 GMT

In article <1993Jan11.122250.23513@iti.gov.sg> cmlow@iti.gov.sg (Low Chee Meng (KSL)) writes:
>Hi,
>
>I'm currently using GDB to debug a C++ program (compiled with
>-g flag with G++). One thing I couldn't figure out how to do is to
>execute some method call inside GDB, eg:
>
>gdb> print someObj.someMethod(someArgs....)
>   or
>gdb> set someVar = someObjPtr->someMetthod(....)
>
>GDB would always return back something like "there's no component
>named someMethod", even though someMethod is a valid method of
>the class to which someObj belongs to.
>
>Is there something I have to do make the above work? has anyone ever
>had success getting GDB to execute any method call?
>
>I'm current using GDB 4.6 and GCC 2.2.2 on Sun OS.
>
>Thanks in advance for any help,
>
>Chee Meng
>---------------------------------------------------------------------
>Chee-Meng Low (cmlow@iti.gov.sg) (fax: 65-777-3043)
>Knowledge Systems Lab, Information Technology Institute, Singapore
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Some native object code format's are not rich enough to hold
sufficient information for debugging C++ programs as well as one
would desire. The SUN OS 4.1 environment does put guite a lot of 
debugging info.  but you can use the -ggdb option to include 
extra debugging info.  which only gdb can use.

Compile using  the option g++ -ggdb

g++ -ggdb myC++.C -o myOut

This will solve your current problem.

Note that even then you may not be able to access inline methods
unless you move their declaration outside the class definition.

Also FYI: there are newsgroups called gnu.g++.help and gnu.gcc.help.


    __
   (_   / /  o_   o  o |_
   __)/(_( __) (_(_ /_)| )_

***************************************************************************
* Suresh Thennarangam               *  EMail: suresh@iss.nus.sg(Internet) *
* Research Scholar                  *         ISSST@NUSVM.BITNET          *
* Institute Of Systems Science      *  Tel:  (065) 772 2588.              *
* National University Of Singapore  *  Facs.: (065) 778 2571              *
* Heng Mui Keng Terrace             *  Telex: ISSNUS RS 39988             *
* Singapore 0511.                   *                                     *
***************************************************************************


Newsgroups: comp.lang.c++