HDTenEightyP/NetNews huggingface dataset:
From: theobald@ucunix.san.uc.edu (Allen M. Theobald)
Subject: Is there a lint++?
Organization: University of Cincinnati
Date: Thu, 17 Dec 1992 19:55:58 GMT


Fellow Netters!

This may seem peculiar, but is there such a thing as lint++ to 
check C++ code?  Or does lint have a switch to do the same?

Any and all ideas welcome...


		Thanks,

		Allen


P.S. Please e-mail me directly
Newsgroups: comp.lang.c++
From: sandys@aruba.UUCP (Sandy Schindler)
Subject: inlining friend functions
Date: Tue, 15 Dec 1992 18:28:58 GMT
Organization: Project Zed
Keywords: friend inline

I would like to inline some friend functions for a class, without placing
the method definitions inside the class declaration.  Such as:

class Foo{
public:
  friend inline doFoo(const Foo&, const Foo&);
};

inline doFoo(const Foo& f1, const Foo& f2)
{
   //something...
}

This _should_ be legal, according to the 2nd ed., pg 567, "A friend 
function defined in a class declaration is inline and the rewriting rule 
specified for member functions (r9.3.2) is applied..."  The HP C++ 
compilers (2.x and 3.0) compile this sort of thing without complaint.

BUT, when I try to compile this with Borland's C++ 3.1, I get the error
message 
  Error inl.hh, line xx: Storage class 'inline' is not allowed here 
Borland will not allow the inline keyword to used on a friend function 
inside a class declaration, no matter where the definition happens.

Is this a mere compiler bug on Borland's part, or is this the first 
appearance of a standard restriction?  I hope not.  With the volume of 
code we're working on, omitting the inline keyword from the headers is not 
an option.


-- 
            ...Mix it all together, and viola! ... hmm, wait, that's not quite it...
Sandy Schindler                  |Internet Style: aruba!sandys@uu2.psi.com
Systems Programming/UI, Club Zed |UUCP: ...!uunet!uu2.psi.com!aruba!sandys

Newsgroups: comp.lang.c++
From: thom@mapthom.b17a.ingr.com (Thom)
Subject: MVC Paradigm
Keywords: MVC, GUI
Reply-To: thom@mapthom.b17a.ingr.com
Organization: "Mapping Sciences Division, Intergraph Corp, Huntsville AL"
Date: Fri, 11 Dec 1992 20:40:56 GMT


I'm interested in references involving the application and of the Model,
Viewer, Controller paradigm for user interface design.  I believe it
originated from Smalltalk, but I'm interested in applying it to C++.  I
would appreciate any references on this paradigm regardless of whether they
apply to C++ or not.  If references are not possible, I'm specifically
interested in the Controller portion of the paradigm.  I understand the
purpose of the Model and Viewer, but I don't have a grasp on purpose and
use of the Controller.


-thom

--
Email: thom@mapthom.b17a.ingr.com
Voice: (205)730-7117

"I stayed up all night playing poker with tarot cards.  I got a full
house and four people died."
                -- Steven Wright
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: What is Object Oriented Programming? Is C doomed?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 14 Dec 1992 19:18:12 GMT

In article <1992Dec11.215013.4654@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>In article <1992Dec10.101100.1@happy.colorado.edu> srheintze@happy.colorado.edu writes:
>|I believe it was Ed Yourdon who first said:  "it is far easier to optimize a
>|correct (i.e. working) program than correct an optimized program".
>|
>|  (2) What Youdon said was correct?
>
>No, because it is easy to construct correct programs that are practically 
>impossible to optimize and it is easy to construct optimized programs that
>are practically impossible to correct.  The only way to make either correctness
>or optimization "easy" [or even *possible*] is to plan, design and build to
>make both possible from the start.  Given that a program is designed to be
>easy to optimize, and given that a program is designed to be easy to correct,
>then either task becomes easy [or at least *possible*]
>

	Actually, I believe the two are intimately related.
Imagine a program with an array access

	... a[i] ...;

For the program to operate properly, i must be in bounds.
To ensure an invalid access will terminate the program gracefully,
the compiler inserts a run-time bounds check. This doesnt
make the program correct, nor fast, but it does ensure a certain
class of bugs will be detected at run-time.

Now to optimise the program we prove to the compiler that i
*must* be in bounds. Then the compiler will remove the run-time
check, as it cannot be useful.

	What have we done? We have simultaneously proved a component
of the program correct (in some sense) and at the same time
optimised it.

	(A really smart compiler could do the proof by itself.
In the case of a lazy programmer and dumb compiler, we could just assert that
i is always in bounds---at least the assertion is then explicit
in the code.)

	This is the approach A++ takes to things, although C++
turns out to be too complex to reason about .. the idea seems
sensible to me. It is vaguely the same thing that happens in C++
when we cast away const (or some other naughty cast).
(*I* the programmer *know* that this is OK ..)

	Or, when a derived pointer converts silently to a base pointer
(*I* the compiler know this is OK --- you dont have to tell me).

	Eiffel has formalised this to some extent, at least providing
an assertion syntax (even if the run-time checks cant be optimised away).
Wouldn't C++ benefit from this too?




-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: dwr@cci632.cci.com (Donald W. Rouse II)
Newsgroups: comp.lang.c++
Subject: Re: Who is wrong? me, BC , GNUC ?
Date: 14 Dec 92 17:29:21 GMT
Organization: [Computer Consoles, Inc., Rochester, NY

In article <718@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>I am confused.
>
>I thought overloading took into account the argument list of the
>member function being overloaded.
>
>What you just said implied that if class B had not declared
>
>	operator+=(int);
>
>that the inherited A::operator+=(A&) *would* be available?

Yes.

>
>If not, then inheritance does not work as I understood it.
>If so, why does a function with a different argument list
>( B::operator+=(int) } hide the inherited one?

Scope resolution occurs first.  Once operator+= was found in B,
any overloading that would occur would occur within B.

>                                                The mangled
>names should not be equivilant....

Mangled names are an implementation issue.
Newsgroups: comp.lang.c++
From: warsaw@nlm.nih.gov (Barry A. Warsaw)
Subject: Re: Survey: File Extension
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.
	<1992Dec12.014834.926@netcom.com> <WARSAW.92Dec12174801@anthem.nlm.nih.gov>
	<MATT.92Dec13011012@physics.berkeley.edu>
Date: 13 Dec 92 20:47:33 GMT


>>>>> "Matt" == Matt Austern <matt@physics.berkeley.edu> writes:

    Matt> This is only possible for certain operating systems.  Two of
    Matt> the three operating systems that I use on a regular basis
    Matt> are case-insensitive, so .C isn't much of an option.

Oh yeah, you're right. I forgot about those Durned Other Systems :-)
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: Who is wrong? me, BC , GNUC ?
Date: 18 Dec 92 01:18:09 GMT
Organization: negligable

So it is then impossible to selectively override one of a set
of inheirited functions of the same name.  In order to accomplish
this we have to override the one we want, the put "passthrough"
inline member functions in for the rest, e.g.:

class A {
	A &operator += (A &);
	A &operator += (int);
	};

class B : public A {
	{
	B &operator += (int);
	A &operator += (A &a) { return *((A *) this) += a; }
	};

is this an accurate summary?

(the inline may perhaps need a different declaration:
	A &operator += (A &a) { return A::operator+=(a); }
I really haven't tried this....)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Between the silence of the mountains	|
and the crashing of the sea 		|	-Richard Hartman	
there lies a land I once lived in	|	hartman@uLogic.COM
and she's waiting there for me.		|
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Give me safe C++
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Trumphurst Ltd.
Date: Tue, 15 Dec 1992 16:33:35 +0000

In article <1992Dec12.145403.26483@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> 	What makes virtual functions so useful is the fact that they
> are so tightly restricted .. for example, unlike a genuine
> function pointer they cannot be modified after object creation,
> nor specialised on a per object basis.
> 
> 	So when language designers propose restrictions, one must
> carefully weigh up the pros and cons: most restrictions also
> grant freedom. In the case of virtual functions, if your
> program compiles and links they are sure to be properly initialised,
> freeing you from checking this manually. 

This is a very good point. It is where something like Modula scores - you
have very tight restrictions over what you can do, unless you specifically
state you want to relax the restrictions for a particular module.

One of the drawbacks of C++ is that it is not always (often ?) clear 
whether a particular line of code is doing something completely pure, or 
is a nasty hack. My particular pet hate is the use of the same source code
construct for casts and conversions, but there are many other examples.

I rather like the idea of a restricted subset of C++ which disallows 
everything dubious, provided, of course, you can use the full power of the
language occasionally (maybe in separate modules, or inside some #pragma 
section). That way I get protected from my own mistakes, but I can still 
work round any shortcomings in the language, the machine architecture or 
the design.

This would also extend the appeal of C++ to a wider audience - I have seen
many accounting (and similar) software writers reject C++ out of hand, 
because they aren't happy with using a language where a single typing 
mistake can re-write the operating system ! They are currently waiting
for Object Oriented Cobol :-) 

How about a -safe-c++-only switch to the compiler :-)

-- 
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.
Newsgroups: comp.lang.c++
From: 76336.3114@CompuServe.COM (Kevin Dean)
Subject: Private base classes
Date: 16 Dec 92 21:06:02 GMT

In the excitement generated by the fact that someone had managed to post
to comp.lang.c++ from CompuServe, the intent of my original posting was
lost.  Here it is again:

I tried to do the following:

class A {};
class B : private A {};
class C1 : public B, public A {};

My compiler naturally warned me about A being both a direct and indirect
base class of C1 and so refused to compile it.  I was able to get around
the problem:

class CA : public A {};
class C2 : public B, public CA {};

My first thought, however, was that the declaration of C1 should have
been allowed.  If A is a private base class of B, no class derived from B
can access A so there should be no ambiguity in accessing members of A
from C1: the only A visible is the direct base class of C1.

This leads to an interesting hole in the C++ programming paradigm.  A
class derived from B has no access to or knowledge of the private portion
of B (I'm ignoring friendship here).  Up until now, I have always believed
that, as long as the public and protected interfaces don't change, I can
do whatever I like with the implementation of B, including changing its
private interface.  If, as I did in this case, I decide that B (and other
related classes) can be better implemented with A as a private base, I
need to know everything about classes derived from B so that I can be sure
that everything will compile.  In other words, I need to have forward
knowledge of all classes that are or could be derived from B.  Similarly,
I need to know more about B than just its public and protected interfaces;
I need to know what its private base classes are before I can reliably use
it as a base class.  (I am not debating the need here for multiple
inheritance; I may have a genuine need for two instances of A.  What I am
debating is the semantics of private vs. public or protected.)

Any thoughts?

Kevin Dean

SNAG: acronym for Sensitive New-Age Goof, one who, usually without any
relevant experience, is always willing to enlighten the ignorant masses
on the social issue of the day.  Have you hit any SNAGs lately?


Newsgroups: comp.lang.c++
From: coons@ct46.med.ge.com (James J. Coons)
Subject: Borland C++ Dialogs
Reply-To: coons@ct46.UUCP (James J. Coons)
Organization: GE Medical Systems - CT, New Berlin, WI
Date: Tue, 15 Dec 92 15:58:44 GMT

In the Borland 3.1 C++ for Windows Dialogs where you enter compiler
settings such as search directories and defines there does not seem 
to be any way to delete mistyped entries.  So far the only thing I 
have found I cound do was to delete the entire project and start over. 
If this is true, it is an unbelievably poor design.  Is there a way 
to delete mistyped entries and if not, How could the Borland have 
committed such an obvious blunder.


Newsgroups: comp.lang.c++
From: bjl2k@helga10.acc.Virginia.EDU (Beng-Jit  Lim)
Subject: Borland C++ 3.1 with application and frameworks
Organization: University of Virginia
Date: Sun, 13 Dec 1992 18:24:41 GMT


			For Sale:
Borland C++ 3.1 with application and frameworks complete with manuals.
Original price is over $600.  I am selling it for $200 (super deal!!).
Call BJ at 296-3025 or e-mail to bjl2k.
From: cnc@sweep.bt.co.uk (Colin Crist)
Newsgroups: comp.lang.c++
Subject: Re: Survey: File Extension
Date: 16 Dec 92 10:28:56 GMT
Reply-To: cnc@sweep.bt.co.uk
Organization: British Telecom

In article 78146@hydra.gatech.EDU, andy@federation.gatech.edu (Andy Register) writes:
>In article <1gb1h0INNle2@tsavo.hks.com> webb@hks.com writes:
> >I have a survey question for you all:
> >
> >	What extension do you believe is correct for C++ source code?
> >	Is a clear majority winner emerging?  The contenders are: .C, .c
> >	and .cxx. 
>
>don't forget .cpp for all us borland users.

I've always preferred .cc

Colin.

	-----------------------------------------------------------
	Colin Crist	+44 473 648136		cnc@muppet.bt.co.uk	
	BT Research Labs, Martlesham Heath, Suffolk, United Kingdom
		Standard disclaimer and all that ...
Newsgroups: comp.lang.c++
From: kirby@xerox.com (Mike Kirby)
Newsgroups: comp.lang.c++
Subject: C++ Reuse Class -- HELP
Date: 16 Dec 92 18:36:23 GMT
Reply-To: kirby.roch803@xerox.com
Organization: Xerox Corporation, Webster NY

I am taking a course in reusability at a university near me.  We have to  do
either a project, or a paper on reusability.  I have chosen to do a project.  The
project is (in short) write something worth reusing or reuse something already
written (we get to choose what we write).  I want to write something worth reusing.

My problem is I don't really know what to write.  Are there any suggestions out
there?  Something that someone thinks is mildly useful and would have written it
themselves, but never got around to it?  Would Yet Another Strings Class be
useful?  I realize that the NIH and COOL class libraries have a lot of things
in them, but is there something about either or both of those classes that
was done "wrong"?  The intent of this project is to give us a chance to get our
hands dirty and learn about inheritance and templates and their applicability in
reusability (say that fast 10 times).

thanks,

Mike Kirby
Xerox Corp
E-mail: kirby.roch803@xerox.com
Newsgroups: comp.lang.c++
From: mr@delfin.com (Mark Rosenberg)
Subject: Name-scope semantic differences between 2.1 and 3.0
Reply-To: mark@delfin.com
Organization: Delfin Systems, Sunnyvale CA
Date: Fri, 11 Dec 1992 18:19:27 GMT

How are CFRONT 2.1 name-scoping semantics different from CFRONT 3.0
name-scoping semantics? We are developing a product that needs to be
supported on several different platforms (currently RS-6000 and Sparc).
This product relies upon Objectstore. According to their support
people, their compiler has templates but 2.1 name-scope semantics.

Apparently 2.1 name-scope semantics are not a subset of 3.0 name-scope
semantics. What are the implications of these semantic differences?
What should one do or not do to maximize compatibility?

-- 
Mark Rosenberg
internet:mark@delfin.com
phone: (408) 562-1126	fax: (408) 748-1140
snail: Delfin Systems, 3000 Patrick Henry Drive, Santa Clara, CA 95054-1814
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Give me safe C++
Date: 11 Dec 92 22:27:09 GMT
Organization: Microsoft Corporation

In article <Bz2nDF.7B6@fiu.edu> feathers@serss0 (Michael Feathers) writes:
>In article <9234501.15945@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>feathers@serss0 (Michael Feathers) writes:
>>
>>>In article <1992Dec07.193214.13720@microsoft.com> jimad@microsoft.com (Jim Adcock) DOESNT write:
>>>
>>>I have been thinking recently about whether it would be possible to design a 
>>>C++-like language which abandons the pointer syntax, yet provides the full
>>>functionality of pointers....

Not *my* words -- somewhere along the line this original thread has become
misattributed.
From: friedman@hp-and.an.hp.com (joel friedman)
Newsgroups: comp.lang.c++
Subject: Any inheritance experts out there
Keywords: Inheritance, virtual functions
Date: 18 Dec 92 14:44:03 GMT
Organization: Hewlett-Packard Company

Hello all,

I'd like to start off by thanking the many of you who provided me info about the ARM.  I now have Stroustrup 2nd edition and it's just what I needed.  The book I originally had was Stroustrup 1st edition, not a book by Dijikstra.  My apologies for the mass confusion this caused!!

Down to business.  I need some assistance designing my class hierarchies for the following situation:

I am writing device drivers for external memory devices.  I currently have to support two types devices (say A and B), but that number could grow.  The functions each device must support are common, but the implementations used to provide them are quite different for each.  The type T below can be a char xor a short.  The following template class defines these core functions:

template <class T> class core_functions
{
public:
   T Read cell(int address);
   void Write_cell(int address, T data);
};


I want to design the hierarchy so I can easily add device C, D, E etc.  Here's the catch.  How can I do this so that the application programs only need to see the core_function class declaration; not the derived class declarations for A or B.  I need to enhance the core_functions class so that the user can call a core_functions function, and it will be directed to the implementation in the proper derived class (A or B).

If I derive A or B from core_functions, then the application must declare objects of type A or B, thus they will need to have access to the derived class declarations.

If I use A or B as a base class, then there have to be different derived core_functions classes; one derived from A, the other from B.  This prevents the user from seeing the declarations for A and B, but doesn't seem very elegant.  I want to have only 1 core_functions class.

I tried making the core_functions functions virtual.  That let me call core_functions functions, redirecting them to the implementations in A and B.  This didn't prevent the application from needing the A and B class declarations,
which is a requirement.

Any Ideas?? Thanks in advance.
Joel
-- 
__________________________________________________________________________
Joel Friedman           friedman@hp-and.an.hp.com           (508) 681-2709

 ///  /_ _  \\\   H E W L E T T          Imaging Systems Division
(((  / //_/  )))                         3000 Minuteman Road
 \\\   /    ///   P A C K A R D          Andover, Massachusetts 01810-1087
__________________________________________________________________________
Newsgroups: comp.lang.c++
From: matt@physics.berkeley.edu (Matt Austern)
Newsgroups: comp.lang.c++
Subject: Re: Need help implementic data structures of generic objects
Date: 11 Dec 92 16:26:29
Organization: Lawrence Berkeley Laboratory (Theoretical Physics Group)
	<1992Dec10.114636.16861@ucc.su.OZ.AU>
	<1992Dec11.233253.27540@informix.com>
Reply-To: matt@physics.berkeley.edu
NNTP-Posting-Host: physics.berkeley.edu
In-reply-to: cshaver@informix.com's message of 11 Dec 92 23:32:53 GMT

In article <1992Dec11.233253.27540@informix.com> cshaver@informix.com (Craig Shaver) writes:

> >>class Object {
> >>    /* ...etc... */
> >>};
> >
> >	Dont do this Smalltalk hack please. A queue of Objects is
> >totally useless, since they are just Objects and not ever Widgets.
> 
> YES! Do that elegant Smalltalk thing.  Do not listen to C++ hacks and
> bigots.  Put a little thought into it and do something (re)useful.

The problem is that in C++, as opposed to Smalltalk, this *isn't*
terribly elegant.  The question is: what can you do with an Object?
If you put a Widget into a list of Objects, you can't call any of the
Widget member functions; you can only call the Object member
functions.

You can, of course, access the Widget member functions by downcasting
the Object* to a Widget*, but I would scarcely call that elegant.
(Also, of course, you're deliberately violating the language's type
checking, so you're opening yourself up to all sorts of fun bugs.)  I
would suggest that if your program makes heavy use of downcasting,
then you are probably not using the best possible design.

There probably are some programs for which Smalltalk is a better
choice of language than C++.  For those programs, the simple solution
is just to use Smalltalk; as Dr. Stroustrup has pointed out, Smalltalk
does a far better job of being Smalltalk than C++ ever will.
--
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: crt@zoo.bt.co.uk (Clive R Thompson)
Newsgroups: comp.lang.c++
Subject: Re: question about "this"
Date: 16 Dec 92 11:55:55 GMT
Reply-To: crt@zoo.bt.co.uk
Organization: BT Laboratories

In article 13147@news.columbia.edu, ae2@cunixb.cc.columbia.edu (Amiran Eliashvili) writes:
>
>Hi all:
>
>
>I have been reading C++ code as I am new to the language. Recently I
>have run into a segment of code that I did not quite understand what
>is exactly meant.
>
>
>     String & String::operator= (const String& string)
>     {
>	 if (this != &string)
>	 {
>	     destruct(this->d_string_p);
>	     this->d_string_p = init(string);
>	 }
>	 return *this;
>     }
>
>
>I am not quite sure why and what for the clause "this"is compared to
>&string? Could anyone shed some light on this matter. Thanks much.
>

	Simple, see below 

	String s1;

	s1 = s1;   // The test for (this != &srtring) simply detects this assignment

or looking at it the another way  s1.operator=(s1);
			
					

			Clive Thompson.
From: mike.quinlan%phant@hpbs938.boi.hp.com (Mike Quinlan) 
Newsgroups: comp.lang.c++
Subject: Re: Survey: File Extensio
Date: 14 Dec 92 18:18:00 GMT
Distribution: world
Organization: Phantasia BBS - Boise, ID - 208-939-1350
Reply-To: mike.quinlan%phant@hpbs938.boi.hp.com (Mike Quinlan) 

webb>I have a survey question for you all:
webb>
webb>   What extension do you believe is correct for C++ source code?
webb>   Is a clear majority winner emerging?  The contenders are: .C, .c
webb>   and .cxx.

andy>don't forget .cpp for all us borland users.

    Why not use .c++ for c++ programs?
---
 * Ever stop to think and forget to start again?