HDTenEightyP/NetNews huggingface dataset:
From: ch_purzl@rcvie.co.at (Klaus Puerzelmayer)
Subject: SPARCworks
Reply-To: ch_purzl@rcvie.co.at
Organization: Alcatel Austria Informatik  R&D
Date: Wed, 27 Jan 1993 09:34:49 GMT


Hi,

I wanted to know,if anybody has experience with the SPARCworks products.
I have read in SunFLASH Vol 47 #19 something about the product and I am 
specially interested in SPARCworks Profressionel C++ 3.0.1. Any comments
are wellcome. It is stated that SPARCworks is running under OpenWindows 3.0.
If anybody tried it with Motif I would like to know his experience. 
If there is enough interest I will summarize.

Klaus


----------------------------------------------------------------
Klaus Puerzelmayer		e-mail: ch_purzl@rcvie.co.at
Testing Technology		voice:  +431/391621-272
Alcatel Austria Informatics Research and Development  
Ruthnergasse 1-7, A-1210, Vienna
Austria / Europe
----------------------------------------------------------------
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Newsgroups: comp.lang.c++
Subject: Re: Possible bug in BC 3.1: ellipsis in proto argument list
Date: 27 Jan 93 11:41:06 GMT
Reply-To: nikki@trmphrst.demon.co.uk
Organization: Trumphurst Ltd.
X-Mailer: cppnews $Revision: 1.31 $

In article <1993Jan24.050155.32517@ns1.cc.lehigh.edu> sg0d@ns1.cc.lehigh.edu (STEPHEN R. GILBERT) writes:
> I seem to have found a bug in my Borland C++ 3.1 compiler.  I narrowed
> the problem down to the following prototype:
> 
> void foo(...)

This prototype is not useful in ANSI C, as there is no way to access any 
of the arguments of foo. The ANSI C stdargs mechanism cannot be used 
unless there is at least one fixed argument. This is perhaps why you have 
a problem.

-- 
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: mhopper@cerl.gatech.edu (Michael A. Hopper)
Newsgroups: comp.lang.c++
Subject: Re: Was: Template Use <sigh>
Date: 22 Jan 93 17:49:18 GMT
Organization: Computer Engineering Research Lab, Georgia Tech.

In article <1jp50dINNk34@rs6000.bham.ac.uk> pickerig@eee.bham.ac.uk (Guy Pickering) writes:
->Anyway, my problem in more detail is this: I have three directories
->which contain the following:
->
->  1/ The .C and .H files defining the template class LookupTable.
->  2/ The .C and .H files of an algorithm which uses LookupTable<unsigned
->     char>
->  3/ A main.C which binds the whole lot together, but does not itself
->     use LookupTable<unsigned char>
->
->The problem is that at link time, no template instantiation takes
->place and then the real linker complains about all my member functions
->of LookupTable<unsigned char> being unresolved.
->
->There are unresolved symbols, yet the instantiator doesn't do anything
->about them.
->
->What am I doing wrong??? Any ideas?
->
->Guy. 

Put ALL of your template code in header (.h) files.  Do not put template
code (member functions) in .c files.  In other words, get rid of loopuptable.c
(or whatever you called it).

This worked for me.

-Mike


-- 
| mhopper@cerl.gatech.edu |   ' ) ) ) o  /_       ' )  /   ROLL TIDE !!!
| Office: CRB 388         |    / / / /  /\_) __    /__/______   _   __  __
| Phone: (404) 894-9111   |   / / (_/\_/  \_/_/_  /  / (_) /_)_/_)_/_/_/ (_
| Home:  (404) 723-1718   | ALABAMA: 1993 Nat'l Champs    /   / how Sweet it is!
From: ldup@ta7s49.alcbel.be (Luc Duponcheel)
Newsgroups: comp.lang.c++
Subject: templates and friends (again)
Date: 21 Jan 93 08:14:28 GMT
Organization: Alcatel Bell Telephone, Antwerpen, Belgium

Sorry, there were some little typing errors in my first mail (cut/paste ...).
The (ugly) solutions were, as you might have guessed, template functions with
a type template argument omly. So I repeat the mail .


--------start--------------


I have some question about templates and friends.

Since friend templates are function templates, they cannot have non-type 
template arguments.


Therefore the following example will not compile

---------begin------------

#include <iostream.h>

template<class T, int size> 
class Container {
friend ostream &operator<<(ostream &, const Container<T,size> &) ;
} ;

template<classT, int size>
ostream &operator<<(ostream &os, const Container<T,size> &c) {
 // do something
 return os ;
} 

----------end-------------

The following example compiles

---------begin------------

#include <iostream.h>

template<class T, int size> 
class Container {
friend ostream &operator<<(ostream &, const Container<T,5> &) ;
friend ostream &operator<<(ostream &, const Container<T,10> &) ;
// ...
} ;

template<classT>
ostream &operator<<(ostream &os, const Container<T,5> &c) {
 // do something
 return os ;
} 

template<classT>
ostream &operator<<(ostream &os, const Container<T,10> &c) {
 // do something
 return os ;
} 

// ...

----------end-------------

I do NOT think this is the way to solve the problem.

Are there any better solutions?

P.S.

What is the very reason for not allowing non-type template arguments 
for function templates?
From: clark%asylum.cs.utah.edu@cs.utah.edu (Charles Clark)
Newsgroups: comp.lang.c++
Subject: Re: Objects in Shared Memory
Date: 25 Jan 93 17:54:58 GMT
Followup-To: comp.lang.c++
Organization: University of Utah Computer Science

In article <19930125.084616.825@almaden.ibm.com> jimi@vnet.ibm.com (Jim Meyers) writes:
>>
>>The first of these approaches is not complete in that it does not
>>address the problem of intra-object references.  Thus, virtual base classes
>>can not be used in the inheritance hierarchy of the shared objects.
>
>This is not all clear to me... Can you elaborate on why you believe that
>Jordan's method does not support intra-object references?

After reviewing Jordan's paper, I see that intra-object references will
resolve correctly (Jim, thanks for pointing this out).  His method 
requires that, not only the location of the vtable be coordinated, but 
also the location of the shared memory segment be coordinated.  This means 
that each process which accesses the shared memory segment must attach 
that memory segment at the same virtual memory address.  With the memory 
segment at the same vm address, the intra-object references will resolve 
correctly.  

Straying from the orignal subject a little, how can the location of the 
shared memory segments be coordinated?  The vtable location is fixed at 
link edit time, thus one would know then whether there is a conflict. 
Since the creation and attachment of the shared memory segment is at run-
time, how can one ensure that the vm address of each of the cooperating
processes will be available?

	--Charles
From: grahamd@swdev.research.otca.oz.au (Graham Dumpleton)
Newsgroups: comp.lang.c++
Subject: Re: Was: Template Use <sigh>
Date: 27 Jan 93 23:18:53 GMT
Organization: Technical Development Group, OTC Australia


 >  > The cfront auto instantiation system won't bother attempting template
 >  > instantiation if it cannot find its type map, which is the file
 >  > ptrepository/defmap by default.
 > 
 > As well as starting the template instatiation mechanism when there is a non
 > empty defmap file in the first or default repository directory, the AT&T
 > compiler will also start the template instantiation mechanism in a number
 > of other situations also. The list of cases that we have found, including
 > that that you mention, is:
 > 
 >   1) The default repository directory is being used or only one repository
 >   directory is explicitly defined on the command line, and there is a non
 >   empty defmap file in the repository directory.
 > 
 >   2) A single repository is being used and the directory doesn't contain a
 >   non empty defmap file but does contain a user provided nmap file.
 > 
 >   3) Multiple repository directories are defined explicitly on the command
 >   line and the first directory doesn't contain a non empty defmap file or
 >   user defined nmap files but a subsequent repository directory does.
 > 
 > I should point out that the HP C++ compiler version 3.0 (port of AT&T
 > 3.0.1) doesn't start the instantiation mechanism in situations 2 and 3.
 > Someone in HP whom I had mail contact with does know about this now, however
 > whether they are changing their compiler to behave in the same way as the
 > AT&T compiler I do not know. The last I heard was that they were expecting
 > us to lodge a defect report, however since we don't actually have HP
 > machines we haven't had a reason to do that.

I got a chance to try out a prerelease version of Sun C++ 3.0.1 under Solaris
1.1 and it also doesn't start the template instantiator under all three of
the above situations. Like the HP compiler it will only start the template
instantiator under situation 1.

When I tried the same work around as for the HP compiler, ie. create a non
empty defmap file containing

 >   @dec ____DUMMY____
 >   <____DUMMY____>

it did start the template instantiator but then promptly fell over with the
fatal error

  CC[ptlink] fatal error: bad argument to slp_add()

when trying to read the defmap files in the extra repository directories. I
eventually got it to work by placing an nmap file which we generate in the
repository directory as the defmap file. Since this had all the information
in it which it needed it mean't that it was looking in the extra repository
directories and so was finding what ever it was that was causing it to crash.

-- 
Graham Dumpleton (grahamd@swdev.research.otca.oz.au)
Newsgroups: comp.lang.c++
Subject: Re: Why X::X(X &a), not X::X(X a) ?
From: hood@ualr.edu
Date: 20 Jan 93 13:00:06 CST
Reply-To: hood%eivax@ualr.edu
Organization: University of Arkansas at Little Rock

In article <884@ulogic.UUCP>, hartman@ulogic.UUCP (Richard M. Hartman) writes:
> In article <1993Jan15.092416.1@ualr.edu> hood%eivax@ualr.edu writes:
>>  Since the copy constructor should not normally 
>>modify the source object a better declaration would be X::X( const X a)
> 
> I am assuming a typo.  Shouldn't that be:
> 
> 	X::X(const X &a)	?
> 

Your right, it was a typo; the way you show it is correct.

William G. Hood
University of Arkansas at Little Rock
Internet: hood%eivax@ualr.edu

> 
> 
> 		-Richard Hartman
> 		hartman@ulogic.COM
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> "Who knows what evil lurks in the hearts of men?"
> 
Newsgroups: comp.lang.c++,comp.object
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Pros and cons of C++
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 27 Jan 1993 20:18:38 GMT

In article <C1G9H4.HsA@unix.portal.com> samantha@shell.portal.com (Samantha Atkins) writes:
>Only in that the type understands the message.  OK.  So if I want to get
>the maximum flexibility I would probably tend to factor my class hierarchy
>very highly with lots and lots of mix-in classes for every reasonable 
>set of behaviors.  

	Not every reasonable set: just some basic and fairly
independent sets to form the 'Axioms', and some common combinations
with additional computed functions : 'Theorems'.

>Then for working classes I would mix and match to 
>produce just what I need.  

	For your working Objects: each object a different mixin class
if you need.

>Here we run into some sticky situations in that
>not only would I need all these little mixins but I would also quite likely
>need various equally abstract classes that represent various combinations
>of them as my typing of say, parameters, is only class based and I want to
>leave maximum flexibility and reuse in.  Now it seems pretty obvious to me
>that over time I'm going to want to change this around or add more combinations
>as I can't just declare the whole exponential mess right the first time.  
>Also we would have to contend with the unpleasant fact that all this churning
>through this exponentially growing hierarchy takes real CPU time and resources
>that eventually will get very seriously strained.

	I think its the other way around. WITHOUT mixins you have to
declare a whole lot of different classes to do what you might
want. 

	WITH mixins you only need to declare the sorts of interfaces
you need at in the current program. The basic library functions
operate on the abstract bases of these classes.
>
>Am I going askew here or is it as it seems to me that so called strong typing
>creates an untenable mess if you seriously attempt its use now and for the
>future?

	Class based strong typing does have the disadvantage
that you have to make a class for every object, you cant just
make up the methods you need as you need them.

	Mixins are a sort of compromise between the two approaches:
use classes, but keep them small and independent. Get flexible
object construction AND strong typing.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------
Newsgroups: comp.lang.c++
From: sassoj@rs6415.ecs.rpi.edu (John J. Sasso Jr.)
Subject: GUIs/C++ programming book
Organization: Rensselaer Polytechnic Institute, Troy NY
Distribution: usa
Date: Wed, 27 Jan 1993 14:39:14 GMT

Hello,

   I am trying to find a book on building graphics user interfaces under
   DOS using C++ (Borland, preferably).  I know a little of C++, but have 
   no experience building GUIs, so I figure such a book would help me learn
   C++ and building GUIs at the same time.  Any references would be quite
   helpful.

                -- John

Newsgroups: comp.lang.c++
From: gbj@melb.bull.oz.au (Graham Jose)
Subject: BC3.1 OWL vs MFC
Organization: Bull HN Information Systems Australia.
Date: Mon, 25 Jan 1993 21:38:24 GMT

Could someone please provide a comparison (pros and cons) between
Borland C++ 3.1 Application Frameworks (OWL) and Microsoft Foundation
Classes? I own BC++ 3.1 and I am wondering whether it is worth the
effort porting MFC to run in this environment, or to stick with the
class frameworks provided by Borland.

Thanks,
Graham Jose

 ---------------------------------------------------------------------------
| Graham Jose, Snr Software Engineer (EFTPOS,Comms) |   Phone: 61 3 2464450 |
| Melbourne Development Centre       (Unix  &  DOS) |     Fax: 61 3 2464445 |
| Bull HN Information Systems Australia Pty Ltd     |-----------------------|
| ACSnet  : gbj@bull.oz                             |  C A R P E   D I E M  |
| Internet: gbj@melb.bull.oz.au                     |    'Seize the day'    |
 ---------------------------------------------------------------------------


Newsgroups: comp.lang.c++
From: ole@delab.sintef.no (Ole-Hjalmar Kristensen)
Subject: Re: Dynamic Linking and Sun Sparcs, do they mix?
Organization: SINTEF DELAB, Trondheim, Norway.
	<1993Jan27.192131.14505@ucc.su.OZ.AU>
Date: 28 Jan 93 11:54:06


> 
> 	Applications that require DLLS are those that do
> RUN-TIME linkage and not just LOAD-TIME linkage. Load-time
> linkage is just a convenience --- actually, sometimes an
> inconvenience.
> 
> 	RUN-TIME linkage is different. Consider drawing
> program. It has a class 'drawable'. Standard drawables
> are Square and Circle and Line.
> 
> 	Bored with these? Fine. Write your own DLL
> classes for Oval, EiffelTower, Polygon, Fish. Put the
> names of these in a text file and run the drawing
> program.
> 
> 	Presto: user defined shapes. Cant be
> done without either RUN-TIME linkage or some sort
> of interpreter.
> 
> 	Can Unix's do this? If not, they cant really
> do dynamic linkage at all, just code sharing. 
> Code sharing is certainly nice, but it is not functionally
> equivalent to real dynamic linkage.
> 
> -- 
> ;----------------------------------------------------------------------
>         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
> 	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
> ;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------
> 

SunOs can do it, sort of. The dlopen() and dlsym() system calls are
interfaces to the dynamic linker. You specify the name of the library
to dlopen, and dlsym returns the address binding of the symbol you
give it as parameter. 
Newsgroups: comp.lang.c++
From: pluym@cs.kuleuven.ac.be (Luc Pluym)
Subject: overloading templates
Organization: Dept. Computerwetenschappen
Date: Fri, 22 Jan 1993 01:02:38 GMT

FIRST QUESTION
==============
Can I have 

template <class T1>
class A {...};

and

template <class T1,class T2>
class A {...};

at the same time?

SECOND QUESTION
===============
Suppose I have

template <class T,int i>
class B {...};

and also

template<class T,double d>
class B {...};


Are there any rules for resolving ambiguities, like there are
for overloaded functions? (Such as: a direct match has higher
priority compared to casting).

			Thanks,

			Luc Pluym
			pluym@cs.kuleuven.ac.be
From: KOCHER@nvdv.e-technik.uni-stuttgart.dbp.de (HARTMUT KOCHER)
Newsgroups: comp.lang.c++
Subject: Re: References to functions?
Date: 26 Jan 1993 08:54:15 GMT
Organization: University of Stuttgart, IND (Germany)
Distribution: world
NNTP-Posting-Host: nvdv01.ind.e-technik.uni-stuttgart.de
X-News-Reader: VMS NEWS 1.24

In <1993Jan25.182507.13761@fcom.cc.utah.edu> swillden@news.ccutah.edu writes:
> : > References to functions are legal, but not very useful.  I can't
> : > think of anything you can do with a reference to a function you
> : > can't do with a const pointer to a function in exactly the same way,
> : > except for trivial syntax differences at the point of initialization.
> : > Steve Clamage, TauMetric Corp, steve@taumet.com
> : Not exactly. Let's say I have a callback class which takes a pointer
> : to a function in its constructor. If I use a pointer, a 0-pointer may be
> : passed. If I use a reference instead, I can make sure, that the user
> : supplies a valid function.
> Not really.  Try:
> typedef int (callbackfunc)(int);
> extern void set_callback(callbackfunc&);
> void foo()
>     {
>     callbackfunc* callback = 0;
>     set_callback(*callback);
>     }
> : Hartmut Kocher
> Shawn Willden
> swillden@icarus.weber.edu

Sure, but it's always undefined to dereference a 0 pointer.
With a reference you always clearly state, that you are 
expecting a valid object/function, etc.

Therefore, it's the callers responsibility to make sure he's passing a valid
argument, whereas with pointers, the function implementor has to check for
0 pointers, because these are allowed by the language.

Hartmut Kocher
From: bobhof@hpwala.wal.hp.com (Bob Hoffmann)
Newsgroups: comp.lang.c++
Subject: C++FAQ
Keywords: Need a recent copy of...
Date: 26 Jan 93 21:41:38 GMT
Article-I.D.: boi.C1HDLF.DqE
Organization: Hewlett-Packard Company

This is actually my first post to a news group, although I have been a subscriber to many.  I am requesting that a copy of the FAQ for this group
(comp.lang.c++) be posted, as I am very interested in obtaining as much info 
on C++ programming and OOP concepts as I can.  Thanks in advance.





////////////////////////////////////////////////////////////////////////////
// bobhof@hpbs1813.boi.hp.com
////////////////////////////////////////////////////////////////////////////
From: noam@techunix.technion.ac.il (noam amir)
Newsgroups: comp.lang.c++
Subject: help with borland c++ under windows, OWL and soundblaster
Date: 21 Jan 93 10:54:49 GMT
Organization: Technion, Israel Institute of Technology

we have a very specific problem working with BC++ 3.1.
we are trying to use  both OWL and the soundblaster SDK which
provides DLL's for programmin it.
   calling OWL ony compiles ok. calling the DLL's compiles
okay. calling them both together doesn't compile - we get
a message: undefined symbol.  somwehow this has to do
with case sensitivity - the message refers to the OWL or the
DLL's, depending on how the case sensitivity is set. even
with case insensitive setting, it doesn't work. 

   has anyone in netland experienced similar problems? any
help would be very much appreciated. please answer by email
to: noam@techunix.technion.ac.il

 thanks in advance,
           noam.
From: sg0d@ns1.cc.lehigh.edu (STEPHEN R. GILBERT)
Newsgroups: comp.lang.c++
Subject: Possible bug in BC 3.1: ellipsis in proto argument list
Date: 24 Jan 93 05:01:55 GMT
Organization: Lehigh University

Forgive me if this is a FAQ (probably isn't) or if this question has
been asked before.

I seem to have found a bug in my Borland C++ 3.1 compiler.  I narrowed
the problem down to the following prototype:

void foo(...)

If the above line is by itself in foo.h and I run:
bcc -P -c foo.h
It compiles without mishap.  If you're wondering: -P is to force a C++
compile and -c is compile to .obj only.

The problem is that if I try to compile without the -P, that is,
compile in regular, standard BC 3.1, I get the error message:
) expected

This is no big deal- I can just compile with the C++ option all the
time, but regular BC should be able to compile a prototype with just
an ellipsis in the argument list without a problem- I think.  I guess
my real question is: Does BC 3.1 have a bug?  My bcc.exe is dated
6-10-92 at 03:10a.  If there is a patch floating around somewhere
could someone let me know where to ftp it from.  I checked simtel20
under the borland directory and I already have all the patches for 3.1
installed that are there.  I'd like to avoid calling Borland if someone
else has already found this problem.

I need to use the prototype as shown above, so changing it in some way
will do me no good.

If you have an answer, email to me would be great.  If this is not
possible for some reason, a post is ok.  I'll check for the answer
over the next couple of days.

Thanks.

Steve Gilbert
sg0d@Lehigh.edu
Newsgroups: comp.lang.c++
From: cbrooks@afit.af.mil (Christopher L Brooks)
Subject: Re: C++ develpment environments
Organization: Air Force Institute of Technology
Date: Thu, 21 Jan 1993 13:08:45 GMT

erc@netcom.com (Eric Smith) writes:

>In article <1jhemvINN15h@armory.centerline.com> rose@centerline.com (Bob Rose) writes:
>>Performance and scalability have been targeted extensively for our
>>new release of ObjectCenter (2.0) due out this quarter.  I think you'll
>>find it much better!

>I heard a rumor that ObjectCenter costs $4000 per copy.  Is this true?
>Why on earth would anyone charge $4000 for a software product?  Don't
>you want to make it popular?  How can you get all the bugs out if you
>don't have zillions of users sending in bug reports?  And how can you
>get zillions of users if you charge that much?

The primary reason prices are so high is the very fact that they will
never have a zillion users for such a high-end, limited market product.
This isn't Microsoft Access  - even if they charge $99 they wouldn't
sell 500 thousand copies in the first month.  In the high-end
development world, $4000 isn't really considered "expensive".

--Chris Brooks
--cbrooks@afit.af.mil
Newsgroups: comp.lang.c++
From: ajp@eng.cam.ac.uk (A. J. Piper)
Subject: Wanted: a C++->C++ translator
Reply-To: ajp@eng.cam.ac.uk
Organization: CUED
Date: Thu, 28 Jan 1993 16:23:09 GMT

Has anyone got something more self-contained than simply a C++ parser ? I know some
guys from singapore posted something to the net about something like this but I have
lost their posting. Anyone got it ?

Basically I want something that will parse a C++ program and output the same C++
program but with some small (my) modifications. It must handle templates.

andy
---
Andy Piper					email: ajp@uk.ac.cam.eng
Cambridge University Engineering Department 	tel: +44 223 33 2754
Trumpington St
Cambridge, UK

Xref: sparky comp.lang.c++:20032 comp.object:5096