HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: const on pass by value
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 24 Jul 1992 18:52:01 GMT

In article <1992Jul24.151010.11969@PacBell.COM> pjcondi@lepton (Paul Condie) writes:
>Should pass by value arguments be declared as "const" for
>good coding style?  Or is that nit picking?
>
>For example:
>
>void foo (const int a);
>or
>void foo (int a);
>

	you usually declare const.

	However: this is a design flaw IMHO in the langauge.

	Const value arguments dont make sense: they're copied
anyhow, so it makes no difference. The reason for having const
parameters in declarations is that you sometimes want the
COPIED value in the function *definition* to be const.

But this has nothing to do with the declaration except that
the language is incapable of distinguishing them.

I think the following should be legal:

void foo (int a);
void foo (const int a) { .... } // SAME as foo above

My argument breaks down if value parameters are not copied.
Then 'const' can mean: it is ok to pass this one by reference.

A similar issue applies to const RETURN values from functions.
And that one is very important and I think not resolved.


-- 
;----------------------------------------------------------------------
        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: peterg@ixos.de (Peter Ginzinger)
Newsgroups: comp.lang.c++
Subject: C++: Problems with inheritence and virtual member functions
Keywords: Inheritence, virtual member functions
Date: 28 Jul 92 08:11:49 GMT
Organization: iXOS Software, Munich, West Germany


Hi all,

I am a C++ - novice and have the following problem (inheritence and 
virtual functions):

 Scenario:
  - Baseclass X for classes X1,....,Xn
  - Baseclass N for classes N1,....,Nm
  - Memberfunctions of Xi out of {r(N1&),...,r(Nm&)} (subset) where
    r(Nj&) of Xk is different to r(Nj&) of Xl.
  - X1-,..,Xn-objects are collected in an heterogeneous list (I want to 
    use the USL library class List with homogeneous lists with 
    listobjects *x (of type X)).
  - If there is no r(Nj&) for Xi, then r(N&) of X should be called. 

 Wish:
  - Defining a virtual member function of X: r(N&) 
  - Traverse (Iterate) the list of Xi-objects with a Nj:
    -> a Xk-object in the list should call "his" r(Nj&) memberfunction
    (the problem is (simplified): 
      X1 x1; N1 n1; // for example; X1::r(N1&) is defined  
      X *x = new X1; 
      x = &x1;
      x.r(n1); // -> X::r(N&) and not X1::r(N1&) is called!)

 I found two solutions with which I was not very happy:
  1. No inheritence of N and defining only r(N&) for Xi and
     to analyze N with switch (N.type) { case ... } (C-like)
  2. Define virtual memberfunctions r(N1&),...,r(Nm&) of X, which 
     blows up X!
 
 Are there any other (better) solutions, or how can this general 
 problem can be solved in C++ with little effort?


Thanks, 
Peter
 (peterg@ixos.de) 
Newsgroups: comp.lang.c++
From: fabbott@athena.mit.edu (Freeland K Abbott III)
Subject: Help: TC++ template-of-const-ptr problem
Organization: Massachusetts Institute of Technology
Distribution: comp
Date: Thu, 30 Jul 1992 02:46:31 GMT

I'm hitting what's either a bug in Borland's Turbo C++ (3.0), or a bug
in my understanding of templates.  Here's the code, stripped to the
essentials:

   template <class ELEM> class Base
   {
     public:
       virtual ELEM& getelem (void) const;
   };
   
   class Derived: public Base<const char * const>
   {
     public:
       virtual const char* const& getelem (void) const;
   };

Essentially, Base is a container template, and normally holds entire
objects (i.e.it holds ints, Animals, entire arrays of chars); however,
Derived is a similar class which holds pointers instead.  I want to be
able to consider Derived as a Base, and getelem() it, but TC complains
that the virtual types done't match:

  TCC -Ic:\turboc\include -Ic:\turboc\localinc -P -N -v -c -Jgx bugtest.cpp

  Turbo C++ Version 3.00 Copyright (c) 1992 Borland International
  bugtest.cpp:
  Error bugtest.cpp 11: Virtual function 'Derived::getelem() const'
  conflicts with base class 'Base<const char *>'
  *** 1 errors in Compile ***


Now, the thing that bugs me is that it complains about a conflict with
"Base<const char *>", not "Base<const char * const>".  Is this a bug
in Borland, or am I being thick about const?  Also, is there an easier
(or functional, if this is a bug) way to do what I want:  Base is, as
I said, a container; Derived is the same sort of container, really,
but it's for filenames, and it's supposed to do wild card expansion:
if I add "*.cpp" to Derived, I want getelem() to return each matching
file in turn before proceeding to the next entry.  To do that, I've
now got a static space for the filename, to which I'm returning a
pointer: I don't want my client to need to think about memory
allocation.  And it's all so multiply-const because I want anything to
muck in that static space (which gets filled between calls to
getelem(), by the way).

Any help would be appreciated; I'd prefer responses by email, since
I'm pretty erratic about reading news....

--
Freeland K. Abbott              fabbott@athena.mit.edu
104 Madison Ave.                now working for Cambridge Technology Group
Arlington, MA 02174             "And I thought 14-hr days would be over now"
Newsgroups: comp.lang.c++,comp.std.c++
From: bobm@Ingres.COM (Bob McQueer)
Subject: Re: Language extensions for run-time type identification
Date: 22 Jul 92 17:30:19 GMT

In <14ft2uINNjh4@agate.berkeley.edu>,
	dated 21 Jul 92 02:34:06 GMT,
	jbuck@forney.berkeley.edu (Joe Buck) writes:

> In most implementations of classes with virtual functions, each object
> already has, in effect, a type-ID: the pointer to the virtual function
> table.  This is a natural hook on which to hang run time type checking.

I think Mr. Buck has hit the nail on the head here.  I've been meaning to ask
about this myself, and was happy to see this discussion thread start.  The
virtual function table exists as a 1-per-class structure, and is the natural
place to insert other runtime class information without replicating anything.
The reasonable overhead on each object instantiation would be 1 pointer to
the virtual function table, which we might want to start calling a class
descriptor, or something like that.

I think we have to recognize that C++ is not a purist's OO language - it
is a way of adding OO functionality to an existing language.  Its strength
lies in being able to use an OO paradigm, while still retaining the
efficiency of C, and having "escape hatches".  Insisting that only certain
classes can have runtime descriptors seems reasonable, given this intent.

What I was going to ask about was actually support for an "isa" operation,
which requires some type of runtime definition.  Yes, this type of thing can
be abused, but it is definitely useful.  It should NOT be used as a substitute
for proper subclassing and definition of virtual functions, but I think it
is needed.

Another aspect - if we have the ability to get at class descriptors, can there
be an extension which allows them to be used with the "new" operator to
parameterize the class of object being allocated.  I think that as "service"
classes begin to be provided, it might be handy.  Think in terms of C++
application generators which generate the code to manipulate certain classes of
objects, which may be customized by allowing the user to subclass the basic
types.
From: 890751r@dragon.acadiau.ca (Dave Ritacco)
Newsgroups: comp.lang.c++
Subject: GNU version of C++?
Date: 22 Jul 92 18:41:37 GMT
Organization: Acadia University


    Can someone give me the scoop on a public domain or shareware
version of C++? I don't have the 400 bucks Borland wants, so I was
wondering if GNU has some sort of version?
*please e-mail to ritacco@otter.phys.uvic.ca
-- 
************************************************************************
*        Dave Ritacco                Product of Acadia University      *
*           "Why don't you pull the trigger and find out?"             *
*        ritacco@otter.phys.uvic.ca                W.H.Bonney          *
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Power Operator vs NANs
Date: 21 Jul 92 19:22:04 GMT
	<BqM2JG.8Ds@news.cso.uiuc.edu> <1992Jun29.144814.5240@u.washington.edu>
	<819@nazgul.UUCP> <1992Jul15.123527.3771@bnr.co.uk> <850@nazgul.UUCP>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: bright@nazgul.UUCP's message of 20 Jul 92 18:18:48 GMT

In article <850@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:

   C++ has abandoned ones-complement hardware and 6-char linkers, that C
   was unwilling to leave behind. Maybe it is time to leave behind non-IEEE
   floating point too.

C++ does not specify how integer arithmetic is to be performed on the
machine. And, personally, I don't think it's time to leave behind
non-IEEE floating point.

   /Exactly what would a language extension give you that you couldn't do using
   /(FPU specific) function calls?

   What you gain with a language extension vs function calls:
   1. syntactic clarity
   2. portability (assuming others implement it too)
   3. compiler can detect errors
   4. static initialization
   5. efficiency

There is a nice middle road. You can use functional/macro syntax
(isnan(x), isinf(x), ...) to denote standardized IEEE floating point
operations. Such notation is straighforward, simple, and easy to
implement even in existing compilers. Via the usual "#define foo(x)
__foo(x)" trick, you can get macro semantics (i.e., you don't get the
feature unless you #include the header file) with the efficiency and
flexibility of a language extension.

   For instance, only Zortech's compiler correctly (IEEE 754) implements
   == and != (others set the exception bits incorrectly if one operand
   is a NAN). Do you really want to do isequal(a,b) instead of a==b?

I would want neither. The behavior of operator== on NaN's should be
left undefined. If you care to know whether operator== is operating on
a NaN, you should simply test beforehand:

	if(isnan(x)||isnan(y)) { ... }
	else if(x==y) { ... }

Sadly, this is a losing battle. NCEG seems to be determined to go down
this route of adding lots of IEEE specific, complicated, useless
operators, and the C++ language is likely to follow suite.

				Thomas.
Newsgroups: comp.lang.c++
From: wmm@world.std.com (William M Miller)
Subject: Re: Handling of operator . proposal
Organization: Software Emancipation Technology, Inc.
Date: Sat, 25 Jul 1992 18:13:16 GMT

In article <1070008@speedy.CND.HP.COM>, Darren Smith writes:
> [ Side note:  Is that last statement really truly?  If I do something
> like (*anobject).member, the offset to member will be evaluated at
> comile time, but the actual location in memory is determined at
> runtime. ]

It's the "*anobject" that's evaluated at runtime; once that's done,
the processing is exactly the same as if you had used the name of a
static or auto object to the left of ".".

> The argument that operator.() is only a syntactic operation is
> essentially a meaningless, though true, statement.  The question is:
> is there a good reason that it should remain so?

The issue is one of analogy -- all the currently overloadable
operators have a runtime component in the builtin version.  Adding
runtime behavior to an operator that doesn't have it now would be a
completely new thing.

In the expression "expr.member", the entire runtime component is in
the evaluation of "expr", not in the ".".  To add smart references in
a way that is consistent with the current language would mean changing
how "expr" is evaluated, not what "." means.  That's the basis of both
the alternative ideas I mentioned in comp.std.c++ a few days ago --
using either delegation via pointer or conversion to reference to
convert "expr" into a reference to the target class.

> Also, saying that operator.() is only a syntactic operation, says that
> you will never support *any* proposal that makes operator.() overloadable
> in a way that requires a runtime decision (I can envision a scheme that
> could work at compile time only).

This is too strong.  I don't view the "operatorizing" of "." to be a
fatal flaw in this proposal, just one that reduces its attractiveness
and must therefore be weighed with its other pros and cons.

> If that is truly your position, then
> make that a separate argument from a critique of a given proposal.  That
> way people can understand better your position, which is not that a
> given proposal is bad, but that all proposals for overloading operator.()
> are bad.

I have said that I would prefer a smart-reference proposal that does
not involve operator.() to one that does involve operator.(), all
other things being equal.  The problem is that they never are.  If the
other pending non-operator.() approaches prove to be more problematic
than the best operator.() proposal, I would support the latter.  In
the meantime, however, as Jim has pointed out, his is the most
fully-developed proposal around right now, hence it seemed appropriate
to direct my concerns at it specifically rather than at the generic
concept.
From: heinz@edohwg.UUCP (Heinz Wrobel)
Newsgroups: comp.lang.c++
Subject: Re: Borland/MS C++ compiler summary
Date: 24 Jul 92 21:06:15 GMT
Organization: Edotronik GmbH

In article <1992Jul10.224342.23872@ucsu.Colorado.EDU> dixon@spot.Colorado.EDU (Life is real?) writes:
>- Zortech C++ was suggested by one fellow from Germany, but not much
>was said.

I'm another fellow from germany ;-) I hope this is better information:

Zortech is pretty neat. It does not support templates yet, but as a
registered user you can download a preprocessor that does them. IMHO they
got a support BBS that is not bad at all.

Zortech is quite flexible with memory models (You gotta be on those nasty
Intel machines ;-). It has a tiny model which is even smaller than small
;-) The interesting models are V, Z, and X (I hope I got it right). V uses
a compiler supported transparent code overlay manager which gives you up to
4MB _code_ on any DOS machine without doing anything yourself. Z uses a 286
DOS Extender which gives you 16MB code/data and X is a reduced Pharlap 386
extender 4MB code/data. They have compiler integrated EMS support with a
special pointer type. You like MES? I don't.
Zortech comes with complete Win 3.0 support (No SDK needed) and has OS/2
support. Sorry, no OS/2 2.0, yet. I'm waiting for an update myself. They
are working on it. The current OS/2 compiler seems to run fine with OS/2
2.0

IMHO it's flexible, has a neat editor,the Zortech Workbench ZWB and it can
generate code up to the 486. (REAL 32bit code!).

I even used the (C++) ZWB for a one year BASIC 7.1 PDS project. For money
we SW guys do almost everything ;-)

They are _VERY_ proud of their global optimizer. Supposedly Zortech
optimizes _A_LOT_ better than Borland. Can't check that statement, though.

All of this stuff is in the developer's edition which includes complete
library source except for the licensed dos extenders. In germany it's at
about 800DM which is about $520 with the current exchange rate. I don't
know about UK or US pricing.

They offer an additional scientific pack with a class set called M++ for
major number crunching and mathematical programming (arrays and stuff). I
don't know anything specific, though.

I like it. It's not perfect but I'm glad I threw out MS C a couple of years
ago.

>Brian Dixon

--
Heinz Wrobel, Edotronik GmbH (ECG018)
FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)
"It's good to have a mouse, it's faster if you can do without one..."
"He who doesn't develop with an A2024 doesn't know about font independent
 user interfaces..."
Xref: sparky comp.lang.c++:11313 comp.lang.c:11426
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: Population count.
Date: 20 Jul 92 07:06:13 GMT
Organization: University of Helsinki

ncrwater@watserv1.waterloo.edu (Latala - ICR) writes:
>I don't know who the original author of this is so I can't give credit where
>credit is due. The only name on/in the file is the 'chris' in the lint line.
>Anybody know who this is or does this program look familiar to anybody?

Seems awfully similar to something Chris Torek posted a couple of years
back.  Then, as almost every time since, the method of using a lookup
table had the best understandability / efficiency ratio.  This is also
covered by the FAQ!

--
Lars.Wirzenius@helsinki.fi
From: wayne@jahangir.UUCP (wayne)
Newsgroups: comp.lang.c++
Subject: gcc and cfront
Keywords: gcc cfront
Date: 31 Jul 92 20:03:30 GMT
Organization: MDC, NYC


     Does anybody know how to get cfront to
work with gcc?

I have the following variables set...

ccC=gcc
cppC=/usr/local/lib/gcc-cpp


     The problem being... gcc-cpp does not seem to
support the -B option. (allow the pre-processor to
accept // as a comment deliminator.)


     - Wayne  wayne@mktdata.com

Newsgroups: comp.lang.c++
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Subject: Re: const on pass by value
Reply-To: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Organization: University of Virginia
Date: Fri, 24 Jul 1992 19:56:14 GMT

mittle@watson.ibm.com (Josh Mittleman) writes:
|> pjcondi@lepton (Paul
|> Condie) writes:
|> 
|> > Should pass by value arguments be declared as "const" for
|> > good coding style?  Or is that nit picking?
|> 
|> A blanket convention makes no sense.
|> 
|> For scalar arguments, it doesn't really matter: The user can see that the
|> argument is passed by value, so he doesn't care whether or not it is const.
|> If you find it convenient, make it a const.


int f(const int a) {			int f(int a) {
	while(a--) // not possible		while(a--) // quite possible
	{...}					{ ... }
}					}

That is, it matters for the programmer who defines the 
function and it does not matter for the user of the
function.

-Sekar
From: maxtal@extro.ucc.su.OZ.AU
Newsgroups: comp.lang.c++
Date: 17 Jul 92 19:51 MDT
Subject: Re: Coding Standards - Request for ammo
Nf-ID: #R:1992Jul16.081820.984@cbfsb.cb.at:-991195538:1992Jul17.155133.27529@ucc.su.oz:-129083440:001:1045
Nf-From: extro.ucc.su.OZ.AU!maxtal    Jul 17 19:51:00 1992


In article <1992Jul16.081820.984@cbfsb.cb.att.com> nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:
>A while ago I read an item explaining quite well  why
>coding standards were usualy bad and in particular why
>C coding standards are inappropriate for C++. Could
>someone please mail me the item or tell me where I can
>find it.
>
>I would also like to hear of any documentary discussion
>of coding standards.
>
>I would also like to receive/hear of any coding standards
>which sensible and not to onerous for creative geniuses
>like myself!! since it might be easier to change our 
>standards as a whole than change bits here and there
>provided that the replacement had some sort of authority.
>
>Nick Hounsome

	Read Coplien: Advanced C++ programming styles and idioms.

-- 
;----------------------------------------------------------------------
        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: cleary@cpsc.ucalgary.ca (John Cleary)
Subject: Looking for PC version of C++ task libraries
Organization: U. of Calgary Computer Science
Date: Wed, 22 Jul 92 02:09:41 GMT


I am posting this for someone else. Please reply directly to the address at the
end of the post.
John Cleary cleary@cpsc,ucalgary.ca
>>   Looking for PC version of C++ task libraries ...
>>
>>   This seems like a FAQ, but I need to ask!
>>
>>   We are looking for a port of the AT&T task libraries to the PC.  The
>>   distributed source code for 2.1 defines a i386, but several routines
>>   (stack...c) are missing. Release 3.0 provides all code, but the szal's
>>   don't match a PC (Microsoft-C) at all.  This is because AT&T has only
>>   ported them to PC-UNIX, and doesn't support any other systems.
>>   We are looking at porting them ourselves, but thought others
>>   may already have done this.
>>
>>   Please reply directly, I will summarize if there is interest.
>>
>>   Thank you,
>>   Gregory Guthrie
>>
>>   PS: After some looking, we located a working port of 2.1 tasks to the
>>   sun-SPARC (from sun). The code for other machines is very interesting,
>>   for the SPARC, due to the special register architecture, "amazing"!!
>>   We haven't yet seem 3.0 tasks for the SPARC.
>>   **--  Greg Guthrie     MIU Computer Science Department        (515)472-1125
>>   **    Internet:: guthrie@miu.edu
>>   **--  UUCP::     guthrie@miucsv.UUCP     ...uunet!miucsv!guthrie
>>
Newsgroups: comp.lang.c++
From: vadim@cix.compulink.co.uk (Vadim Lebedev)
Subject: Re: Renew?
Cc: vadim@cix.compulink.co.uk
Reply-To: vadim@cix.compulink.co.uk
Date: Sun, 26 Jul 1992 19:04:09 +0000


Well, here are my 2 bits on operator renew.  How about following?:

class Renew { };

const Renew RENEW;

class ObjWithRenew
{
protected:
 void virtual renewed(size_t) { }
public:
 void *operator new(size_t s) { return (void *) new char[s]; }
 void *operator new(void *old, Renew , size_t newsize, size_t)
 {
  ObjWithRenew *p; 
  p = (ObjWithRenew *)realloc(old, newsize);
  p->renewed(s);  // We can do this because realloc copied
           // the vptr too
  return (void *)p;
 }
};  

// Now we can write


class A: public ObjWithRenew
{
 void virtual renew(size_t) { /* whatever */ }
public:
 A(int a, b);
 A(char *s);
      
};

void test()
{
 A *a1 = new A(2, 4);

        .....
 size_t newSize = ....;

 A *a2 = new(a1, RENEW,  newSize) A("abc");

}


-----------------------------------------------------------------------
Vadim Lebedev                      |   Kortex International
vadim@cix.compulink.co.uk          |   139-147 av. Paul-Vaillant Couturier
                                   |   93126 La Courneuve - CEDEX, France
From: hans@pine.circa.ufl.edu (Hans van Oostrom)
Newsgroups: comp.lang.c++
Subject: Bug in Borland C++ 3.1: demonstration included
Date: 22 Jul 92 16:25:00 GMT
Organization: University of Florida - Dept. of Anesthesiology
News-Software: VAX/VMS VNEWS 1.41

I ran into a piece of code that will crash the Borland 3.1 compiler when
you compile it.  It gives a General Protection Fault Exception 0D in the
bcc and bc compilers (I haven't try the tcw one).  Try the following at home:

// file showbug.cpp

#include <stdio.h>

void main()
{
    stat();
}

void stat(void)
{
    printf("hello");
}

void another()
{
    stat();
}

I know that this is supposed to generate an error message because the stat
function doesn't have a prototype.  I also know that stat is defined as 
something else in the sys\stat.h file, but since I am not using that it
should be ok.  If you change the name of stat or include a prototype it
works ok.  

If anybody can shine some light on this I would be interested.
I will forward this to Borland.

Hans van Oostrom                    KD4MUJ
PO Box J-254, JHMHC                 hans@ufpine                (BITNET)
Gainesville, FL  32601, USA         hans@pine.circa.ufl.edu    (INTERNET)
>>>          Hoe ver je ook gaat, overal zie je landgenoten           <<<
Newsgroups: comp.lang.c++,comp.object