HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: declare keyword, type inference
Keywords: declare, type inference
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 1 Oct 1992 17:59:58 GMT

How do you feel about:

	int x,y;
	long z;

	declare var=z+x*y;
	declare const cvar=x/y;

that is, when 'declare' (or dcl for short like PL/1) is used,
the type is infered from the initialisation. Am I correct in
assuming that the type is always determined?

Would this be 'a good thing' or do you hate it?  Does the syntax
actually work?

One advantage is that if, say 'z' above was made 'float' then
the types of var and cvar would change automatically. This
could be a disadvantage too.

One could also write

	declare float x;

which is equivalent to the usual

	float x;

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: prato@qut.edu.au
Newsgroups: comp.lang.c++
Subject: C Routines to Print Barcodes on HPLJIII
Date: 2 Oct 92 15:51:07 EST
Organization: Queensland University of Technology


Would anybody know where I may obtain a copy of Borland C 
routines that would print barcodes on a HP Laserjet III?

If anybody has experience/knowledge in this area,
please let me know.

Your assistance would be greatly appreciated.

James Prato,
Computer Systems Officer,
MIS Section,
Queelnsland University of Technology,
Brisbane. Qld
Australia.
email:J.PRATO@qut.edu.au
Newsgroups: comp.lang.c++
From: pete@genghis.borland.com (Pete Becker)
Subject: Re: downcasting (was Re: GOTOo wars)
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Sat, 3 Oct 1992 19:16:22 GMT

In article <1992Oct2.141636.17829@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
>>
>>That only works if you compiler supports templates.....	:(
>
>And templates only help in defining homogeneous container classes.

	"Only" is misleading here.  Virtually all of the situations in which
programmers who don't have templates available use heterogeneous data
structures can be handled with templates which implement homogeneous data
structures. 

>If you really need a heterogeneous list, it's hard to avoid castdowns.
>

	Yes.  But you rarely need heterogeneous structures.
	-- Pete
From: vinny@astro.ocis.temple.edu (Vinit Karandikar)
Newsgroups: comp.lang.c++
Subject: C++ for Windows
Date: 6 Oct 92 21:44:40 GMT
Organization: Temple University
X-Newsreader: Tin 1.1 PL5

I was looking for a book for programming borland C++ to develop
windows applications.

I would appreciate if someone could reccommend something along 
these lines for a beginner with C++ and windows.

If you could mail me at
vinny@astro.ocis.temple.edu I could post the stuff up eventually
since I don't read this group much.

Thanks in advance everyone for your time and info

--
                                           ---===( Vinit Karandikar )===---
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: OOP in Dynamic simulation
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 1 Oct 1992 15:44:32 GMT

In article <gate.80moRB1w165w@toz.buffalo.ny.us> cyberman@toz.buffalo.ny.us (Cyberman) writes:
>I'm intrested in using C++ for OOP programing in an interactive
>simulation.  Does C++ lend to such endevors?  This will make
>heavy use of a visual enviroment.
>                                                              
	Perhaps Smalltalk is worth looking at. 


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Re: C++ Style
Organization: Harvey Mudd College, Claremont, CA 91711
Date: Tue, 29 Sep 1992 07:47:11 GMT

In article <717712154.18@mailbox.bison.mb> Russell.Fleming@mailbox.bison.mb.ca (Russell Fleming) writes:
>
>Another possible advantage can be a reduction in stack required.  A
>smart compiler may be able to determine that a declaration is used in a
>small portion of the code.  This is aided when code sections are
>bracketed (using the braces {}).  When a compiler can make this type of
>determination, it will allow the declarations to share storage on the stack.

But...but...

void myfunc() {
    int var1, var2;
    ...
    {
        int subvar1;
        ...
    }
}

is perfectly good C.  Many people believe that subscopes can only be created
in conjunction with loops, for some reason...I must admit that I did until
I took a programming languages class and the prof mentioned that you could
subscope any time you felt like it.  I didn't believe him until I had tried
it for myself...

--
Jason Merrill					jason@jarthur.claremont.edu
From: matt@physics.berkeley.edu (Matt Austern)
Newsgroups: comp.lang.c++
Subject: Re: scientific object-oriented programming?
Date: 30 Sep 92 14:39:57
Organization: Lawrence Berkeley Laboratory (Theoretical Physics Group)
Reply-To: matt@physics.berkeley.edu
NNTP-Posting-Host: physics.berkeley.edu
In-reply-to: thacker@enh.nist.gov's message of 30 Sep 92 19:58:44 GMT

In article <30SEP92.15584491@enh.nist.gov> thacker@enh.nist.gov writes:

> I would greatly appreciate all suggestions and examples of scientific 
> codes written in o-o style and opinions as to whether o-o style is 
> appropriate for such computations.  Also, opinions as to c++ (and/or 
> fortran90) being appropriate.

This isn't really related to fluid-dynamic calculations, but there are
a few people working on object-oriented programming in high energy
physics.

In particular, some folks at Lund are working on what they call MC++,
an object-oriented version of the Lund Monte Carlo programs.  They've
published a few papers on it.  Paul Kunz, at SLAC, also wrote a paper
about the early stages of an object-oriented Monte Carlo program.

There are also some people in high-energy physics who are working on
what is basically an object-oriented version of PAW, and on
object-oriented event reconstruction and analysis.  (I don't know of
any publications about these, though.)

Most of these programs are written in C++, although a few are in
Objective C.  For this most part, I think this has to do with the
availability of high-quality compilers.  This is a significant point!
It doesn't matter how elegant a language you choose, if you can't find
a compiler on the machine you use that produces an acceptable
executable.

My understanding is that Fortran 90 fixes many of the deficiencies in
Fortran 77, but it is in no sense an object-oriented language.  If you
think that your problem would benefit from object-oriented
programming, Fortran is probably not a good option.
--
Matthew Austern                   Just keep yelling until you attract a
(510) 644-2618                    crowd, then a constituency, a movement, a
austern@lbl.bitnet                faction, an army!  If you don't have any
matt@physics.berkeley.edu         solutions, become a part of the problem!
From: fellin@sumax.seattleu.edu (Phillip Fellin)
Newsgroups: comp.lang.c++
Subject: Toolbar | Speedbar Object
Date: 26 Sep 92 18:25:57 GMT
Organization: Seattle University, Seattle WA

Does anyone have a toolbar or speedbar object
for Windows 3.x in c++?  Or any example code
for implementing a toolbar?
Thanks :-)
Phil
From: tmr@faceplnt.dr.att.com (54626-RebmanTM(DR1867)000)
Newsgroups: comp.lang.c++
Subject: Re: Turbo Vision's redraw()
Date: 1 Oct 92 16:57:13 GMT
Reply-To: tmr@drutx!att.com
Organization: Bell Labs, DCTT, Denver, Co.

In article <13050@biggs>, theoretj@Software.Mitel.COM (Jean-Francois Theoret) writes:
|> 
|> 
|> Has anyone had any experience with Turbo Vision's view redrawing
|> funcion?  Mine have no effect whatsoever.  Do you have to change
|> the state of a flag so TView::redraw() will have an effect on a
|> specific window?
|> 
|> I would also need a good Turbo Vision Reference Book (apart from 
|> Borland's original...) if it exists.  Thanks in advance.
|> 
|> --
|> Jean-Francois Theoret		theoretj@Software.Mitel.COM     |\_____
|> Mitel Corp.			Phone: (613) 592-2122 x3718     | O o /
|> 350 Legget Dr.			                               =(_____)=
|> Kanata, ONT, CANADA K2K 1X3                                        U


I had similar problems with trying to change the desktop color -- found
that if I set the view's sfExposed flag to False, then back to True
and then did the redraw, it worked.  You do this with the setState
member function such as:

TView *v;
// v is set here somewhere
v->setState (sfExposed, False);
v->setState (sfExposed, True);
v->redraw() 

Hope this works for you.  No idea on where to find a better TV
reference book -- the one Borland provides is really poor.
By the way, anyone know how to make context-sensitive Status line
or how to make disabled commands from the menu bar blacked out the
way they are in the IDE??

-- 
-- Tom Rebman (tmr@drutx.att.com)

Xref: sparky comp.lang.c++:14569 comp.std.c++:1325
From: osoelgaultier+@CMU.EDU (Stefan Monnier)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: The concept of templates considered ill designed
Date: 5 Oct 92 10:58:55 GMT
Article-I.D.: andrew.Yeo91je00awVE_zEkI
	<23808@alice.att.com>
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.lang.c++: 5-Oct-92 Re: The concept of
template.. Andrew Koenig@alice.att. (582)

> In article <0enxJ1W00awTMNepU8@andrew.cmu.edu>, osoelgaultier+@CMU.EDU
> (Stefan Monnier) writes:

> > As are currently implemented templates, you don't know
> > anything about the actual type at compile-time.
> > So that no method calls or variable accesses can be compiled
> > for any variable of 'template type'.

> But you still haven't answered my question.

> My question was: what reason do you have to believe that
> adding inheritance constraints would solve the problem?

> In thinking about the answer, don't forget about inline functions.
> -- 
> 				--Andrew Koenig
> 				  ark@europa.att.com


With inheritance constraints, you can restrict method calls
to those known to be present (through inheritance).
Inlining doesn't make it impossible: it's just harder, cause
you can't keep the compiled version in pure object code, but
you have to keep information on where are the 'parameters' used
in order to translate their use !

What I say is just that inheritance constraint permits to check
the file and compile it before using it !

Maybe inlining is harder to implement, but I personnally don't
care (I don't think it's important, and anyway, it is feasible)

One problem is with 'base' types (int, ...) as they don't inherit.
But I think it's not 'unovercomable' (what a great word, I'll have
to suggest it for introduction in the Harrap's)

	Stefan

-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
Xref: sparky comp.lang.c++:14446 comp.std.c++:1283
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: declare keyword, type inference
Date: 2 Oct 92 14:53:56 GMT
Followup-To: comp.lang.c++
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
: 
: >How do you feel about:
: >
: >	int x,y;
: >	long z;
: >
: >	declare var=z+x*y;
: >	declare const cvar=x/y;
: >
: >that is, when 'declare' (or dcl for short like PL/1) is used,
: >the type is infered from the initialisation. Am I correct in
: >assuming that the type is always determined?
: >
: >Would this be 'a good thing' or do you hate it?  Does the syntax
: >actually work?
: 
: Not the dreaded... NEW KEYWORD!!

If this capablity was desired (and I disagree), then the sensible thing
would be to make the "inferenced type" the default type, instead of the
silly "default int" rule we are living with today.

var=z+x*y;	// typeof(var) == typeof(z+x+y)  (long)
const cvar=x/y;	// typeof(cvar) == const typeof(x/y) (const int)

Anyway, what I _really_ wanted to say was this:

Let's get rid of the "default int" rule first, IMHO that is
far more important, since that rule seriously cripples
compilers ability to do sensible error reporting/recovery.

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Xref: sparky comp.lang.c++:14572 comp.std.c++:1326
From: warsaw@nlm.nih.gov (Barry A. Warsaw)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Should friends obey access?
Date: 5 Oct 92 23:11:26 GMT
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.


Here's something I've been thinking about for a little while.  Why not
have friend declarations obey access specification?  Thus, declaring
something as a friend would only extend friendship to the part of the
interface in which the declaration was included.  Here's a concrete
example:

class Me
{
public:
	Me();
	void worldCanCallMe() {};

protected:
	friend class Buddy;
	void derivedAndBuddiesCanCallMe() {};

private:
	friend class Spouse;
	void spouseAndICanCallMe() {};
};


class Buddy
{
	void doit()
	{
		Me theMe;
		theMe.worldCanCallMe();
		theMe.derivedAndBuddiesCanCallMe();
		theMe.spouseAndICanCallMe();		 // would be error, but isn't
	};
};


class Spouse
{
	void doit()
	{
		Me theMe;
		theMe.worldCanCallMe();
		theMe.derivedAndBuddiesCanCallMe();
		theMe.spouseAndICanCallMe();
	};
};


class Derived : public Me
{
	void doit()
	{
		worldCanCallMe();
		derivedAndBuddiesCanCallMe();
		spouseAndICanCallMe();				 // error now and still would be
	};
};


class Stranger
{
	void doit()
	{
		Me theMe;
		theMe.worldCanCallMe();
		theMe.derivedAndBuddiesCanCallMe();	 // error now and would be
		theMe.spouseAndICanCallMe();		 // error now and would be
	};
};



Some issues that I can see:

1. What would be the point of declaring a friend in the public: section?
	a. useless but harmless
	b. give it special meaning

2. Backward compatibility?
	a. adopt 1a above and give public friends access to private members
	b. compilers give grace period on anachronism

I often find myself wanting to extend friendship to only part of the
interface of a class.  In these particular situations, derivation just
for interface sharing would be a compromise of the design, and I
really don't want friends to have access to private data members.
Basically, I want a non-derived class to have the same access as
derived classes so that I can exactly specify the interface for
friends, instead of just giving them blanket access. My current
solution is to put the friend declaration in the protected area
(currently meaningless) and only use protected members by convention.

Seems like it would be pretty easy to adopt, both from a language
standard and from an implementation viewpoint.  Besides, friendship
declarations are one thing (the only?) where access specification is
ignored. Anyway, I'm just throwing this out for discussion.  Makes
sense to me, but maybe others don't run into this situation very
often?

-Barry
From: chenzn@ucunix.san.uc.edu (Zhanzhan Chen)
Newsgroups: comp.lang.c++
Subject: looking for a font editor
Date: 1 Oct 92 01:59:41 GMT
Organization: Univ. of Cincinnati

I have heard Borland has developed a special stroke font 

editor called FE.EXE. I want download it from network.
              ~~~~~~
Please email me the address and information.


Thanks a lot!




Zhanzhan Chen
Newsgroups: comp.lang.c++
From: park@netcom.com (Bill Park)
Subject: NIH is rejecting anonymous logins
Followup-To: poster
Summary: Can't download the NIH Class Library
Keywords: NIH
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Distribution: na
Date: Mon, 5 Oct 1992 18:15:58 GMT

The FAQ says ...
====================
        Document:       Frequently-Asked-Questions for comp.lang.c++
        Revision:       9-Feb-92

Q96: What is the NIHCL?  Where can I get it?
A: NIHCL stands for `national-institute-of-health's-class-library'.
it can be acquired via anonymous ftp from [128.231.128.251]
in the file pub/nihcl-3.0.tar.Z
====================

but when I try to login there ...

====================
ftp> open 128.231.128.251
Connected to 128.231.128.251.
220 ns.nih.gov FTP server (Version 4.106 Sat Dec 10 07:14:55 PST 1988) ready.
Name (128.231.128.251:park): anonymous
530 User anonymous unknown.
Login failed.
====================

Any suggestions?

Thanks,
Bill Park
-- 
Grandpaw Bill's High Technology Consulting & Live Bait, Inc.
From: pete@genghis.borland.com (Pete Becker)
Newsgroups: comp.lang.c++
Subject: Re: Query regarding constructor taking void (*f)(...) as arg
Date: 6 Oct 92 23:25:56 GMT
Organization: Borland International
Originator: pete@genghis.borland.com

In article <1992Oct6.154313.8779@netcom.com> geoff@netcom.com (Geoffrey Leach) writes:
>Here's one for the language-lawyers in the crowd.
>
>The following is rejected by the xlC compiler on IBM's RISC6000
>under AIX 3.2.  Is it truely illegal?
>
>void f(int a) {int b = a;}
>class bar {
>    public:
>	bar::bar(void (*f)(...) ...) {int a = 1;}
>};
>main () {bar b(f,1);}
>
>The complaint is that the constructor invocation bar b(f,1) does not
>match the argument list for bar::bar.
>

	To rephrase the question in simpler form:

	void f( void (*)(...) );

	void g( int )
	{
	}

	f(g);

	The call f(g) is illegal.  f() takes a pointer to a function with an
unspecified parameter list.  g() is a function that takes an integer parameter.
A function that takes an integer parameter is not a function with an
unspecified parameter list.
	The correct way to lie to the compiler is to be explicit and use a
cast.
	-- Pete
Newsgroups: comp.lang.c++
From: glenn@sharebase.com (Glenn Linderman)
Subject: Safe C via C++ ???
Organization: NCR/ShareBase Corporation
Date: Fri, 2 Oct 92 04:30:05 GMT

Under the following assumptions:

   Use of pointers in C is "dangerous" (they can point anywhere)
   I am a C++ ignoramous (I've only just read a bit about it)
   Most programmers today don't know C++ yet (many are learning)

can anyone provide some answers to the following questions?

0. Is it possible to make a "bounds checked C compiler" out of a
   C++ compiler?  The remaining questions serve mostly to clarify
   this one, and start discussion about techniques to do so?

1. Is it possible to "overload" all normal C operators using C++
   so that each normal C operator actually calls a user written
   function?  Including the unary "*" operator (pointer dereference)?

2. Is it possible to "overload" types?  For example, the underlying
   compiler might treat "char" as a signed quantity, but I want to
   be able to declare "char xxx;" and have it be unsigned by saying
   something like

   overlead char as "unsigned char"; -- you tell me the right syntax

3. Is it possible to disable future definitions of new classes,
   overloaded operators, and overloaded types (possibly by
   overloading the operators that allow such definitions) so that
   the remainder of a program can only use the stuff that has
   previously been defined?

I guess a "bounds checked C++ compiler", i.e. one that wasn't quite
C syntax, but was C++ syntax, and supports 1 through 3 above, would
also be acceptable to me.

Basically, I'd like to implement a preprocessor that would take user
supplied C code, add a preamble, and get out object code that would
have complete bounds checking on all array references, all pointer
manipulations, etc.  It would also be nice to support some additional
data types, but my reading about C++ assures me I can certainly do
that.

GLenn
From: cshaver@informix.com (Craig Shaver)
Newsgroups: comp.lang.c++
Subject: Re: C++ Vs C for a GUI
Date: 1 Oct 92 22:17:56 GMT
Organization: Informix Software, Inc.

In article <1992Oct1.165342.13052@fcom.cc.utah.edu> tcrook@u.cc.utah.edu (Tom Crook) writes:
>I can think of a few immediate advantages, more related to C++ object
>orientation rather than any significant GUI advantages.
>
>-IMO large systems are easier to design using an object-oriented approach.
>

Not So!  It will take much longer than a top down structured approach.
Unless you just use c++ as a (supposed) better c.  It will take a while 
to build in proper classes for max reuse and to take advantage of
polymorphism (difficult in c++, you should look at smalltalk, witness
the downcast controversy)

>-C++ implementation should be easier to maintain than C if you use its
> built in features to achieve
>	-stronger typing

Not always useful.

>	-better encapsulation of data and operations

Yes!  C with classes is a win.

>	-looser coupling between modules

Lots of design time, but worth it.

>
>-C++ should allow for easier code reuse due to the capability to construct
> abstract class libraries.
>

Unless you have to build everything from scratch because there is no 
standard there!

>-Recommended reading: "Object Oriented Programming with C++ and OSF/Motif"
> by Douglas A. Young.
>

Good books, see also the C version.

>-You should also consider advantages of C++ X builders and toolkits, such
> as Centerline's ViewCenter and OI Class library.  (I believe ViewCenter
> is derived from a Solbourne product and is marketed by multiple vendors.

I think ParcPlace just bought these guys.  Big $$$$

> I only mention CenterLine because I happened to have their literature at

Big $$$$  

> my desk.  There are several commericial and free toolkits and libraries
> out there.  I'm sure other netters can recommend some of them.)
>

Is there a FAQ on the toolkits?  I would like to see the current state of
the art for C++.

>In summary, I can think of several advantages and no signifcant
>disadvantages to using C++ over C for developing a large X application.

Oh!  Come on, how about some truth in advertising.  C++ is just ATT's
version of ADA.  It is overly complex.  It is more work to keep track 
of the language features than it is to get your application done.
What you need are Application builder tools, not a language.  Whoever
has the best tools wins.

	Craig


-- 
Craig Shaver  (cshaver@informix.com for now) (415)390-0654 (415)926-6407
Productivity Group POB 60458 Sunnyvale, CA  94088
Newsgroups: comp.lang.c++