HDTenEightyP/NetNews huggingface dataset:
From: grahamd@swdev.research.otca.oz.au (Graham Dumpleton)
Newsgroups: comp.lang.c++
Subject: Re: Template with pointer-to-member-function problem
Date: 7 Nov 92 23:37:09 GMT
Organization: Technology Development Group, OTC Australia

In article <1992Nov4.105723.26714@news.uni-stuttgart.de>, KOCHER@nvdv.e-technik.uni-stuttgart.dbp.de (HARTMUT KOCHER) writes:
> The following code shows an excerpt of a call back template class.
> It takes a reference to a class and a pointer to member function
> of the same class. When I compile this code with HP cfront 3.0, I
> get the following error message for the contructor call:
> CC: "test.C", line 33: error: bad argument 2 type for 
> CB <Test> ::CB__pt__6_4Test(): void (Test::*)() 
> ( void (Test::*)() expected) (1264)
> 
> Obviously, the arguments are the same, so why is cfront complaining?
> If I make a non-template class with the same functionality,
> everything works as expected. Any ideas, what's going wrong here?
> Is there a workaround for this? I also tried to use a typedef for
> the pointer to member function, but this confuses cfront even more.
> Also, if I supply 0 for the function pointer, cfront aborts with an
> internal error.
> 
> What can I do? Any help would be appreciated!

If HP's compiler is indeed simply a port of AT&T's compiler then the problem
is because there is a bug in AT&T C++ version 3.0.1 (3.0 as well probably).
We contacted AT&T about this problem and it has been fixed for their version
3.0.2 compiler. In our playing we were not able to find any satisfactory
workaround so we ending up tracking down the problem in the cfront src and
fixing it ourselves.

Since you got your compiler from HP I would suggest contacting them although
what help you can get will probably depend on whether you pay software
maintenance. It would also depend on whether AT&T gives out fixes to
particular problems.

BTW, once this problem is fixed it is not all plain sailing. In particular
if you had actually made CB<T>::CallBack() inline you would have exercised
another bug in cfront 3.0.1 with the result being an internal error. When we
contacted AT&T they indicated that this problem had not been fixed and
probably wouldn't be for version 3.0.2. However since you can quite happily
make the function non-inline and have it work it isn't too serious.

Hope this helps.

-- 
Graham Dumpleton (grahamd@swdev.research.otca.oz.au)
Newsgroups: comp.lang.c++
From: rodc@fc.hp.com (Rod Cerkoney)
Subject: Book suggestion wanted...
Date: Thu, 12 Nov 1992 18:15:40 GMT
Organization: Hewlett Packard, Fort Collins, CO
X-Newsreader: TIN [version 1.1.3 PL6]


	Can anyone suggest a good self-tutorial for learning C++. 

	I'd like to find something that uses the approach of the K&R "C"
	book. [The C Programing Language, Kernigahn & Ritchie, Prentice-Hall]

--


Regards,
Rod Cerkoney
                                                        /\
______________________________________________         /~~\
                                                      /    \
  Rod Cerkoney MS 37     email:                      /      \ 
  Hewlett Packard         rodc@fc.hp.com        /\  /        \  
  3404 East Harmony Rd.  Hpdesk:               /  \/          \    /\
  Fort Collins, CO 80525  HP4000/UX           /    \           \  /  \
_____________________________________________/      \           \/    \__
From: grahamd@swdev.research.otca.oz.au (Graham Dumpleton)
Newsgroups: comp.lang.c++
Subject: Re: Debugging output
Date: 8 Nov 92 00:00:32 GMT
Organization: Technology Development Group, OTC Australia

In article <Bx93Mr.42r@cs.uiuc.edu>, pjl@cs.uiuc.edu (Paul Lucas) writes:
> In <Bx9369.3zL@cs.uiuc.edu> pjl@cs.uiuc.edu (Paul Lucas) writes:
> >In <spuler.720931050@coral> spuler@coral.cs.jcu.edu.au (David Spuler) writes:
>
> >*****>	This is overkill; the same thing can be achieved without
> >	inventing another class:
> 
> >	#ifdef DEBUG
> >	#	define	CDEBUG	if ( debug ) cerr
> >	#else
> >	#	define	CDEBUG	//
> >	#endif
> 
> ****>	That only works if you have a C++-ignorant preprocessor, i.e., so
> 	it won't strip the // comment.  This is one instance, among others,
> 	why I would like to keep cpp //-ignorant; you can do all sorts of
> 	hokey stuff that way.
> 
> >	// ...
> 
> >	CDEBUG << "here\n";
> 
> >	This allows the flexibility of having debugging "togglable"
> >	during development, presumeably by a command-line option, but
> >	can be compiled-out in the final version.

Noting that cfront, and I imagine any 'good' compiler, will optmise away the
body of an 'if' statement if given a condition which can be evaluated at compile
time, you can say.

  #ifdef DEBUG
  #define CDEBUG if (debug) cerr
  #else
  #define CDEBUG if (0) cerr
  #endif

One problem with this though, which David Spuler pointed out to me when I told
him about it, is that for safety you are best off writing

  #ifdef DEBUG
  #define CDEBUG if (!debug) ; else cerr
  #else
  #define CDEBUG if (1) ; else cerr
  #endif

If you didn't and some one wrote

  if (...)
    CDEBUG << "here\n";
  else
    ...

you would end up with the 'else' matching the 'if' within the CDEBUG macro
which could give some unexpected results.

-- 
Graham Dumpleton (grahamd@swdev.research.otca.oz.au)
From: sts@tpki.toppoint.de (Stephan Sievert)
Newsgroups: comp.lang.c++
Subject: Re: Borland Debugger/Win3.1 question
Date: 6 Nov 92 19:56:49 GMT
Distribution: usa
Organization: Toppoint Mailbox e.V.

consigli@interlan.interlan.com (Frank Consiglio) writes:

>Hi everyone.  Question: does the debugger included in Turbo C++ v3.0 
>for Windows operate under MS Windows v3.1?  Windows is reporting a DLL
>missing when I try to install the debugger under Win3.1.

According to the german borland-hotline, Turbo C++ v3.0 is incompatible
to Windows v3.1. I had the same problem (until yesterday when I installed
the update to Turbo C++ v3.1)

Stephan
-- 
   Stephan Sievert	   sts@tpki.toppoint.de
   2300 Kiel               stephan@itk.de
   Phone: +49 431 85205
From: ezachris@cochiti.ucs.indiana.edu
Newsgroups: comp.lang.c++
Subject: Re: Desperate plea for help in writing C++ program!
Date: 13 Nov 92 20:06:11 GMT
Organization: Indiana University

In article <1992Nov1.212508.27282@galileo.cc.rochester.edu>  
fhsn_ltd@uhura.cc.rochester.edu (Farah Hussain) writes:
> 
> 
> 
> 
> Hello to all you C++ programmer geniuses!!!  I need your help in writing  
a 
> program in C++.  Because of illness, I have been unable to keep up with 
> everything in my class and would appreciate help from anyone.  If you 
> reply, I'll mail you my problem.  Thanks for your help!
> 
> 	e'mail me at :  fhsn_ltd@uhura.cc.rochester.edu
> 
> Thanks 

Yeah, right. 
And the dog probably ate your compiler, too.
Write your own programs, fhsn_ltd!!!

Espen Zachrisen,
Indiana University
"Any technology distinguishable from magic is insufficiently advanced."
Newsgroups: comp.lang.c++,comp.sys.hp
From: dkarr@sierra.com (David Karr)
Subject: C code from cfront doesn't compile
Organization: Sierra Geophysics,  Kirkland WA
X-Newsreader: Tin 1.1 PL4
Date: Wed, 11 Nov 1992 23:16:55 GMT

We have been running into a bug with the HP C++ compiler that occurs when
we try to compile certain source files with "-g" to keep a symbol table.
The compiler fails with an "internal error".  This subject has been written
about previously in this newsgroup.

I've been trying to find a workaround for this.  I may have found one, but
it is quite painful, and the reason it is painful is because of a bug in
either the HP C++ compiler or the HP C compiler, I'm not sure which.

The normal operation of the C++ compiler is to generate object code
directly from the C++ source.  There is an option called "translator mode"
(the "+T" option) which makes the C++ compiler generate C code, and then
pass that code to the C compiler.  I thought I would experiment with that
by looking at the generated C code and see if there was something screwy
about it, and then try to manually compile that with the C compiler.  I
found that the original C code generated by cfront would not compile with
the C compiler.  I found it generating sequences of code like this:

-------------------
struct something;
struct something { int stuff; }
struct something;
-------------------

The C compiler would flag the last "forward" declaration with an error
saying:

    error 1587: Redeclaration of tag "something"

I hand-edited the generated C source, removing all the "post-forward"
references, then I recompiled (with "-g").  It compiled with no errors.  I
haven't tried linking the final object file with the rest of my C++ objects
to see whether it would make any sense.

I don't know whether the "error" is on the part of the C++ compiler or the
C compiler, it just doesn't work.

The question is, is anyone aware of this situation?  Will the "manually"
generated object file link properly with a collection of C++ objects, and
will I be able to debug this executable in a debugger and look at the
symbols from the original source file?
--
David M. Karr
Sierra Geophysics, Inc.
ARPA: dkarr@sierra.com, UUNET: uunet!sgihbtn!dkarr
Phone: (206) 822-5200 (x343)
Newsgroups: comp.lang.c++,comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: PROPOSAL: Hidden private parts of classes
Organization: TauMetric Corporation
Date: Mon, 9 Nov 1992 03:22:25 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>	Having hidden data variables causes the compiler some minor
>inconvenience, not knowing the length. However private non-virtual
>member functions cause no problems (if they were allowed). These are
>IMHO needed so as to be able to write small helper members in
>the implementation, I've suggested this be allowed, a suitable 
>syntax does not suggest itself though.

If you mean private non-virtual member functions which don't appear in
the class definition, it would cause another language change.
Overloading is resolved before accessibility is checked.  Suppose we have:

	class X {
	    foo(double);	// private
	public:
	    foo(int);
	};
	void bar()
	{
	    X x;
	    x.foo(2.0);		// which foo() ?
	}

This code is in error, since the best match is a private function.  The
semantics would change if "foo(double)" did not have to appear in the
publicly-used class definition; "foo(int)" would be called.  Overloading
is resolved first precisely to avoid quiet semantic changes based only
on access rights.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: ameesh@lsil.com (Ameesh Desai)
Newsgroups: comp.lang.c++
Subject: C++ and Shared Memory (Was: Linked Lists in Shared Memory: )
Date: 11 Nov 92 20:27:28 GMT
Reply-To: ameesh@lsil.com
Organization: LSI Logic Corporation

In article 22735@ermes.enea.se, eny@ermes.enea.se (Erik Nykvist) writes:
>> >=========

[stuff deleted]

>The proposed technique uses the new-operator  with placement-syntax to
>fix the vtbl-pointer in the object. 
>I have not thought about this very much. I have written ONE example
>program that uses this. 
>My idea is that if you know the address of the object in shared memory
>you could access it after having fixed the vtbl-pointer.
>If you fork your process it is NOT necessary to fix the vtbl-pointer
>because the forked process has the vtbl at the same address as the
>parent process.
>
>Erik Nyquist
>


I guess if all processes that were to access the shared mem were to have the
same parent (forked from one single process), what you say is true. However,
in a more general case, you would like to provide access to the shared 
memory to processes that do not share the same parent.

It is not clear to me if there is a "clean" way to share the pages simultaneously
accross such processes. (when the pages contain C++ objects with vtbl ptrs).

Ameesh

---
______________________________     o__            
| _   /|     Ameesh Desai     \    ,>/_                              
| \`O.o'     LSI Logic Corp.   \__(_)`(_)_              email: ameesh@lsil.com
| =(_|_)=    MS E192, 1501 McCarthy Blvd. \             fax  : (408) 433-6802
|____U_______Milpitas, CA 95035____________\____________voice: (408) 433-4097 
Newsgroups: comp.lang.c++
From: stuart@cosc.canterbury.ac.nz (Stuart Ralston)
Subject: SVGA drivers
Organization: University of Canterbury, Christchurch, NZ.
Date: Wed, 11 Nov 1992 00:46:09 GMT

Looking for the SVGABG40 drivers for Turbo C++ on a 286-16Mhz.  I heard
they're on the Simtel20 mirrors -- anybody got the full address for this 
place?

\||||||/
/ o  o \	   ___  ____  stuart@cosc.canterbury.ac.nz
\ /  \ /	  /__    /   /  /	 
 (    ) 	 ___/   /   /__/     
  \__/
Newsgroups: comp.lang.c++,gnu.g++.help
From: laufer@math.luc.edu (Konstantin Laufer)
Subject: linking problem using class CursesWindow in libg++-2.2
Reply-To: laufer@math.luc.edu
Organization: Loyola University Chicago
Date: Sat, 24 Oct 1992 22:47:09 GMT

I have a problem linking the following simple program using g++
(2.2.2) under SunOS 4.1.2.  None of the curses-related routines are
found, and an error message is produced, although everything is in the
standard places.  The problem doesn't occur on the RS6000.  On the
Sparc, the program is linked using the following command:

	g++ -o window window.C -lcurses -ltermcap

#include <CursesW.h>

main() {
  CursesWindow* w = new CursesWindow(stdscr);
  w->clear();
  w->move(5,5);
  w->addstr("bubububu");
  w->refresh();
  w->mvgetch(8,8);
}

Has anyone succeeded linking a program like this?  Any suggestions
would be greatly appreciated, since I need this for a course.

-- 
-Konstantin [laufer@math.luc.edu]
Newsgroups: comp.lang.c++
From: krc@wam.umd.edu (Kevin R. Coombes)
Subject: Re: Squares and Rectangles (Re: Const Inheritance)
Organization: University of Maryland, College Park
Date: Fri, 6 Nov 1992 21:32:30 GMT

In article <561@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>In article <1992Nov4.165028.1273@wam.umd.edu> I wrote:
>>
>>From a mathematical point of view, there is no question about the
>>relationship that should hold. Every rectangle IS-A polygon, with
>>four sides and four right angles. Every square IS-A rectangle with
>>four equal sides.
>>
>>[lots more omitted]
>
>In your own derivation, both rectangle and square are in turn
>derived from polygon.  What generic "setsize" function would work
>for it?  especially one that could be inheirited?  Is there such
>a concept (not being a geometrist) as a "regular polygon", defined
>as "all sides being same size"?  And where does parallelogram fit
>into this?

Yes, there is a RegularPolygon (but all angles and all sides are equal).
If you really want to go overboard, you might include Quadrilateral and
(polygon with four sides) and Trapezoid (quadrilateral with two of its
sides parallel).

>
>It seems to me that a more full derivation might be:
>
>			Polygon
>			|    |
>			|    |
>	    RegularPolygon   Parallelogram
>			|    |
>			|    Rectangle
>			|    |
>			Square
>
>A "RegularPolygon" (per my guess above) might have a
>single "setSideSize()" function that sets the size of
>ALL sides of the figure to the same value.
>
>I don't think dealing with just Rectangle and Square
>there IS any good, generic "size" type of function that
>you can rely on.  Especially if you do strict IS-A 
>derivation using the mathematical definiations.
>
>However, as someone pointed out, it is possible
>to say: "a Rectangle IS-A Square that is separately
>adjustable in 2 dimensions".  (Perhaps this makes more
>sense if you are an engineer than if you are a 
>mathematician...)
>
>Then Rectangle would inherit Square's setSize(int)
>member function, and also implement it's own
>setSize(int,int) function as well.
>

Overloading SetSize() to take more parameters is an intriguing idea....

But I would be very unhappy inheriting Rectangle from Square. The problem
arises when you have a Square *. The Square class assures you that it
will have equal sides. It hardly seems fair for a derived class to
weaken that assertion.

Kevin Coombes <krc@math.umd.edu>
Newsgroups: comp.lang.c++
From: robert@slipknot.rain.com (Robert Reed)
Subject: Re: Criticisms Wanted
Reply-To: robert@slipknot.rain.com.UUCP (Robert Reed)
Organization: Home Animation Ltd.
Date: Wed, 11 Nov 1992 09:27:00 GMT

In article <1992Nov10.212718.2852@taumet.com> steve@taumet.com (Steve Clamage) writes:
|robert@slipknot.rain.com (Robert Reed) writes:
|
||C++ has been reputed to be a language that finally makes the
||concept of "software components" realizable.  The argument goes that if you
||still have to examine the internal workings of component classes to determine
||how to best use them, then their value as components has been greatly
||diminished.
|
|I don't see how this is different in C++ than in any other programming
|language.  You have an interface declaration and (one hopes) some
|documentation, but how do you know whether the actual component works
|as claimed?

That's the point, and maybe it's just a question of adequate documentation.
One of the great claims of OO programming in general and C++ in particular is
that of software reuse.  But if libraries written in C++ are no more reusable
than libraries written in other languages because the language offers no
advantages, then why switch?
________________________________________________________________________________
Robert Reed, Devil's Advocate	Home Animation Ltd.		503-656-8414
robert@slipknot.rain.com	5686 First Court, West Linn, OR 97068

I have a microwave fireplace.  I can lay down in front of the fire for the
evening in eight minutes.
--Steve Wright
________________________________________________________________________________
Newsgroups: comp.lang.c++,comp.object
From: m086414@pwa-b.uucp (Fred Comins)
Subject: English Language parse help needed.
Organization: Pratt & Whitney Aircraft
Date: Fri, 6 Nov 1992 19:28:21 GMT

I am looking for any papers/algorithms/code that has 
to do with language parsing and interpetion for a
project that I am working on.   

If anyone knows where I can get access to ELISA
souce I would appreciate.

Thank you.

EMAIL: comins@pwfire.pweh.utc.com


-- 
Fred S. Comins				 Pratt & Whitney Aircraft
Email: comins@pwfire.pweh.utc.com        400 Main St. M/S 161-05
Sun Workstation Support                  East Hartford, CT 06108
Newsgroups: comp.lang.c++
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Help! I don't know the language yet!
Date: Thu, 05 Nov 1992 17:10:17 GMT
Organization: Security APL, Inc.

In article <1992Nov4.194123.21282@netcom.com> ort@netcom.com (David Oertel) writes:
>>Common wisdom is to use #ifdef/#endif for commenting out code.
>
>	Because /**/ cannot ( usually) be nested.  An embedded /**/ may
>	cause a premature termination of the comment.

I prefer to use // for commenting out code.  This works whether the code has
/* */ comments or // comments.  It has the advantage over both other
approaches that you can see at a glance what code is commented out.

Of course, you need editor support to comment out any large block of code.
I have two macros defined for my favorite editor (Brief) which do this.
One takes a selected block, and inserts a specified string at the beginning
of each line of the block.  The other takes a selected rectangular block,
and deletes everything in it, moving the remainder of the line back.  (The
latter comes with the editor; the former I wrote myself.)

These are both generally useful macros; neither is used solely for this
purpose.
From: jm@vcd.hp.com (John Matthews)
Newsgroups: comp.lang.c++
Subject: Re: Solution found
Date: 12 Nov 92 20:39:04 GMT
Article-I.D.: vcd.BxMEp4.4H9
Organization: Hewlett-Packard
X-Useragent: Nuntius v1.1a5

Thanks to a private email response, I have found out that the -z5
option on the CPlus command line will prevent unreferenced
static objects with constructors or destructors from being
removed by the linker.

John Matthews
Hewlett-Packard
Newsgroups: comp.lang.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: Bad 'for' statement?
Date: Thu, 12 Nov 1992 18:54:53 GMT
Organization: University of Birmingham

In article <1992Nov12.160420.18097@rs6000.bham.ac.uk>, pickerig@eee.bham.ac.uk (Mr. G. Pickering) writes:
> Could you tell me if this is really a syntax error as AT&T 2.1 reports?
> 
>   for(int i=0, int j=10;   i<10;   i++, j++)
>   {
>     // do something
>   }
Yes. I don't have the actual syntax tables to hand but what they say can be
sumarised as follows:

The comma operator joins 2 expressions into one expression by discarding the
value of the first.

A statement can be either an expression followed my a semicolon _or_ a
definition (amongst other things).

A definition is not an expression so you can't say
`a=4+(int t=5);'
nor can you say
`int i=0, int j=10;'

You may be able to put forward an argument saying that an initialisation
should be an expression returning a reference to the initialised object
but I fear this could lead to gramatical ambiguities. 
-- 
    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)
 .  _\\__[oo 
.__/  \\ /\@  E-mail: B.A.McCauley@bham.ac.uk
.  l___\\        Fax: +44 21 625 2175
 # ll  l\\     Snail: 197 Harborne Lane, Birmingham, B29 6SS, UK
###LL  LL\\     ICBM: 52.5N 1.9W
From: bab@se39.wg2.waii.com (Brian Button)
Newsgroups: comp.lang.c++
Subject: Re: Discriminating Variant Records Without switch() ??
Date: 12 Nov 92 12:44:30 GMT
Organization: Western Geophysical Exploration Products
In-reply-to: holiday@bnr.ca's message of 11 Nov 92 14:42:53 GMT


In article <BAB.92Nov10073324@se39.wg2.waii.com>, bab@se39.wg2.waii.com (Brian Button) writes:
|> Is there a simple, OOP based way to discriminate between variant
|> records? I saw an article in C Users Journal last month titled "Switch
|> Deemed Harmful to C++" or something like that, but I couldn't figure
|> out how to do it any other way.


->"Matthew" == Matthew Holiday <holiday@bnr.ca> writes:
   Matthew> switch statement! :-) There ought to be a convenient way
   Matthew> to create objects from network messages, i.e., some way to
   Matthew> register message types and their matching class types,
   Matthew> such that for every incoming message, its body (an array
   Matthew> of bytes) gets turned into the correct object, which would
   Matthew> be derived from a root generic message object.

There is such a way using factory classes such as the RogueWave
RWFactory class. The problem I'm having is figuring out how to deal
with these objects after they are already created. Since there's no
common set of operations which are performed on each of the objects,
there is no set of methods which may be made virtual and overloaded.
Herein lies the problem. This seems to point towards using special
purpose code for each class, which would necessitate using a switch.

Have I painted myself into a corner or is there some way out. How are
the rest of you OOP programmers dealing with cases like this?

bab

--
|-----------------------|----------------------------------------------------|
| Brian Button          | email : button@wg2.waii.com                        |
| Design Engineer       |         71023.276@compuserve.com                   |
| Western Geophysical   | voice : (713)964-6221                              |
| 3600 Briarpark        |----------------------------------------------------|
| Houston, Texas  77042 |                  Opinions Be Mine!!                |
|-----------------------|----------------------------------------------------|