HDTenEightyP/NetNews huggingface dataset:
From: vinoski@ch.apollo.hp.com (Stephen Vinoski)
Subject: return values and destructors
Organization: Hewlett-Packard Corporation, Chelmsford, MA
Date: Wed, 11 Nov 1992 23:36:07 GMT


In section 6.6.3 on page 90 the ARM states:

"A return statement with an expression can be used only in functions
returning a value; the value of the expression is returned to the
caller of the function."

Given the statement

	return foo;

where foo is an object with some value, does the statement from the
ARM mean that the compiler *must* return the value that foo has in the
return statement, rather than the value foo might have at some point
after the destructors for local automatic objects have been executed?

Consider this example:

template<class T>
class A
{
  public:
    A(T *p) : ptr(p) {}
    ~A() {if (ptr) *ptr = 0;}
  private:
    T *ptr;
};


int
func1()
{
    int x = 10;
    A<int> a(&x);
    return x;
}


Under cfront 3.0.1, func1() returns 0, not 10, even though the value of
x in the return statement is clearly 10.  The value of x is changed to
0 due to the destructor of the A object going out of scope at the end
of the function.

What's more interesting is that if a func2() is created that returns
by value an object of a class type with a constructor and destructor,
the desired value is returned because of the generation of a
temporary:

class B
{
  public:
    B(int x) : val(x) {}
    ~B() {}
    void operator=(int x) {val = x;}
    operator int() {return val;}
  private:
    int val;
};

B
func2()
{
    B b(10);
    A<B> a(&b);	// same A as above
    return b;
}


In this case, func2() returns a B whose val member has a value of 10,
due to the generation of a temporary, even though the same A
destructor sets the value to 0.

Shouldn't both of these cases perform the same way?  Is this a cfront
bug?  Shouldn't the value of the return expression be returned to the
caller regardless of side effects of destructors for auto objects?
Does the language enforce any of this?  The pre-Boston mailing doesn't
seem to discuss this any differently than the ARM does.

thanks,
-steve
-- 
Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
From: mjv@mv.com
Newsgroups: comp.std.c++
Subject: Re: Array anachronisms
Date: 12 Nov 92 12:44:01 GMT
Article-I.D.: mv.9211121744013030
X-Mailer: rnMac Buggy, I mean Beta, Test Version


> From: jimad@microsoft.com (Jim Adcock)
> Subject: Re: Array anachronisms
> Message-ID: <1992Nov11.004038.17772@microsoft.com>
> Date: 11 Nov 92 00:40:38 GMT
> Since non-C-braindead-flavors of arrays can easily be implemented using
> templates, why invent a new slightly-less-braindead implementation of 
> arrays built-in to C++?  Instead, lobby the C++ libraries committee to
> put the arrays features you like into their proposed array class 
template.

Sounds reasonable.  I look forward to seeing a proposal and/or suggested
improvement to the current proposal (X3J16/92-0005R1, WG21/N0084).
--
Mike Vilot,   ObjectCraft Inc.,   Nashua NH  USA
mjv@objects.mv.com
X3J16 Library WG
Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Initialization of const dynamic objects
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 10 Nov 1992 01:28:03 GMT

In article <1deqlgINNmc0@darkstar.UCSC.EDU> daniel@cse.ucsc.edu (Daniel R. Edelson) writes:
>
>Section 7.1.6 contains the following statement:
>
>	``Unless explicitly declared extern, a const
>	object does not have external linkage and
>	must be initialized.''
>
>Does that prohibit the following code?
>
>	new const int;
>
>This allocates an uninitialized const object. 

	IMHO there is no such thing as a const *object*. 'const' controls
the access to an object, const T and T are the same type (this not
how the ARM is written though).

	However,

	const int *p=new int;

makes p a pointer with const access to an undefined int. This is just like

	int x; // no init
	const int *p=&x;

>Seems like this should be explicitly prohibited (assuming
>there's no constructor, of course.) Is it?
>
>Incidently, section 5.3.3 says:
>
>	``If [a new-initializer is] not [present], the object
>	will start out with an unspecified value.''
>
>Thus, an unitialized const dynamic object has and keeps
>forever an unspecified value. This should be prohibited.

	Not necessarily. With p as above 

	*(int*)p=5; // p now points to 5, we can cast away const :-(

	And of course 

	x=5;

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Xref: sparky comp.std.c++:1537 comp.lang.c++:16089
From: dlarsson@aut.abb.se (Daniel Larsson)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Operator -> cannot return non-class types?
Summary: HP C++ 3.0 won't allow me to return e.g. char* from operator ->
Keywords: HP C++ 3.0, operator ->
Date: 11 Nov 92 09:23:16 GMT
Organization: ABB Automation AB, Vasteras, Sweden

Yesterday, I tried HP's new C++ compiler (3.0) and templates for the first
time. To my surprise, I noticed that operator -> can only return the following
three types:
   - a pointer to a class,
   - a class, or
   - a reference to a class.

This means I cannot do simple things like:

  template< class T >
  class OffsetPtr 
    {
    public:
      OffsetPtr();
      OffsetPtr( T* );
      ...
      T* operator ->();
      ...
    };

  OffsetPtr<char> ptrToString;


What is the rationale behind this restriction? I couldn't find anything in
C++PL 2nd ed. that mentions this restriction, although I didn't look too hard.

-- Daniel


-- 
---------------------------------------------------------------------------
Daniel Larsson          Email:	   dlarsson@aut.abb.se
ABB Automation AB	Telefax:   +46 21 34 25 25
V{ster}s, Sweden	Telephone: +46 21 34 30 29
Newsgroups: comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Can Standard C functions be overloaded?
Organization: TauMetric Corporation
Date: Wed, 11 Nov 1992 20:01:31 GMT

jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:


>Can Standard C functions be overloaded?

>	#include <string.h>
>	int atoi(const String&);   // legal?
>	char* s = "123";
>	String str = "456";
>	int i1 = atoi(s);
>	int i2 = atoi(str);

>One problem, I believe, is that ANSI C allows functions to be defined
>by the implementation as macros, so you might have to do:

>	int (atoi)(const String& s);  // now legal?
>	String str = "456";
>	int i = (atoi)(str);   // annoying

The C++ Committee has adopted the following rules (among others)
concerning identifiers in the library section of the Standard:

 - No standard library function may be user-declared, but instead an
   appropriate header must be #include'd.
 - Any function declared in a header must be declared so as to allow
   it to be overloaded by the use of another signature.  (This means
   that a "function" can't be a macro but may be inline.)
 - All identifiers with external linkage are always reserved for use
   as identifiers with extern "C" linkage.
 - Each identifier with file scope is reserved for use as an identifier
   with file scope.
 - Each function signature is reserved for use with both extern "C" and
   extern "C++" linkages as a function signature with file scope in
   the same name space if any of its associated headers is included.

These rules allow an implementation to provide the Standard C functions
as either C or C++ functions with external or file scope (e.g. inline).
They also allow names of Standard C functions to be used as class
member names, or otherwise overloaded.

Of course, current implementations might have tighter restrictions,
since these rules exist only in the Committee Working Paper.

You are probably safe in using a Standard C function name as a C++
function name if you always enclose its name in parens (to avoid clashes
with macro names), and you have a Standard-conforming preprocessing phase.

"Overloading" the Standard C functions is likely to cause odd problems
in general, so for now I would advise against the practice.  (A later
programmer might not appreciate the subtleties and get C macros when
C++ functions were expected.)
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: ameesh@lsil.com (Ameesh Desai)
Newsgroups: comp.std.c++
Subject: Re: Array anachronisms
Date: 13 Nov 92 22:20:12 GMT
Reply-To: ameesh@lsil.com
Organization: LSI Logic Corporation

In article 9211121744013030@mv.com, mjv@mv.com () writes:
>
>> From: jimad@microsoft.com (Jim Adcock)
>> Subject: Re: Array anachronisms
>> Message-ID: <1992Nov11.004038.17772@microsoft.com>
>> Date: 11 Nov 92 00:40:38 GMT
>> Since non-C-braindead-flavors of arrays can easily be implemented using
>> templates, why invent a new slightly-less-braindead implementation of 
>> arrays built-in to C++?  Instead, lobby the C++ libraries committee to
>> put the arrays features you like into their proposed array class 
>template.
>
>Sounds reasonable.  I look forward to seeing a proposal and/or suggested
>improvement to the current proposal (X3J16/92-0005R1, WG21/N0084).
>--
>Mike Vilot,   ObjectCraft Inc.,   Nashua NH  USA
>mjv@objects.mv.com
>X3J16 Library WG


You mention current proposals ... can we get these via anonymous ftp / mail
server ? 

Ameesh

---
______________________________     o__            
| _   /|     Ameesh Desai     \    ,>/_                              
| \`O.o'     LSI Logic Corp.   \__(_)`(_)_              email: ameesh@lsil.com
| =(_|_)=    MS E192, 1501 McCarthy Blvd. \             fax  : (408) 433-6802
|____U_______Milpitas, CA 95035____________\____________voice: (408) 433-4097 
Newsgroups: comp.std.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: Array anachronisms
Date: Wed, 11 Nov 1992 18:19:59 GMT
Organization: University of Birmingham

In article <1992Nov11.004038.17772@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
> In article <1992Nov6.190320.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
>>Why must be live with the anachonistic restictions on the use of array
>>variables?
> 
> I agree with your arguments, but some of the counterarguments are:
> 
> [2 very valid points]
>
> Since non-C-braindead-flavors of arrays can easily be implemented using
> templates, why invent a new slightly-less-braindead implementation of 
> arrays built-in to C++?  Instead, lobby the C++ libraries committee to
> put the arrays features you like into their proposed array class template.

OK C++ libraries committee - did you hear that.

BTW my objection to the handling of arrays was not that it would be useful
to allow array type to behave like any other type but that it was just plain
ugly to have a different set of rules for a subset of types.
-- 
    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)
 .  _\\__[oo 
.__/  \\ /\@  E-mail: B.A.McCauley@bham.ac.uk
.  l___\\        Fax: +44 21 625 2175
 # ll  l\\     Snail: 197 Harborne Lane, Birmingham, B29 6SS, UK
###LL  LL\\     ICBM: 52.5N 1.9W
Newsgroups: comp.std.c++,comp.lang.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: Operator -> cannot return non-class types?
Date: Wed, 11 Nov 1992 18:43:41 GMT
Organization: University of Birmingham

In article <1992Nov11.092316.306@aut.abb.se>, dlarsson@aut.abb.se (Daniel Larsson) writes:
> To my surprise, I noticed that operator -> can only return the following
> three types:
>    - a pointer to a class,
>    - a class, or
>    - a reference to a class.
> 
> This means I cannot do simple things like:
> 
>   template< class T >
>   class OffsetPtr 
>     {
>     public:
>       OffsetPtr();
>       OffsetPtr( T* );
>       ...
>       T* operator ->();
>       ...
>     };
> 
>   OffsetPtr<char> ptrToString;
> 
> What is the rationale behind this restriction? I couldn't find anything in
> C++PL 2nd ed. that mentions this restriction, although I didn't look too hard.

a->b
  ...where a is of a class type is interpreted as...
(a.operator->())->b
  ...which in turn may expand to...
((a.operator->()).operator->())->b
  ...and so on.

but in all cases the thing on the rhs of the -> is a class member. Since
types other that structs and classes do not have members it would be
useless for operator->() to return anything other than a pointer to a class or
a class for which operator->() is also defined.

Now what you could do is define operator T* (). Unfortuneately if you write
`a->b' where a is of a class without an operator->() the compiler does not
try compiling it as `(*a).b' so you'll have to write this out in full each
time. Likewise you can't write `a[5]' but you can write `*(a+5)'.

This has annoyed me in the past and I feel that the language definition
should employ user defined type conversions to resolve the lh operand of
the -> ->* and [] operators.
-- 
    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)
 .  _\\__[oo 
.__/  \\ /\@  E-mail: B.A.McCauley@bham.ac.uk
.  l___\\        Fax: +44 21 625 2175
 # ll  l\\     Snail: 197 Harborne Lane, Birmingham, B29 6SS, UK
###LL  LL\\     ICBM: 52.5N 1.9W
Newsgroups: comp.std.c++
From: se_rossb@rcvie.co.at (Bernhard Rossboth)
Subject: C++ libraries
Reply-To: se_rossb@rcvie.co.at
Organization: Alcatel ELIN Research
Date: Mon, 9 Nov 1992 11:49:36 GMT

Hi everyone

I would need information about C++ libraries for UNIX (cfront 2.1). My major constraints are:

1.) Source available
2.) Commercial support required
3.) cfront 2.1 compatible
4.) no GUI library, but e.g.: container classes, strings, date & time, ...

Thanks for any useful information.

PS: My special interest is to Booch Components and USL (UNIX Systems Laboratories). If you have some experiences with one of these, please tell me.

						Barny :-{)

Newsgroups: comp.std.c++
From: arthur@solomon.technet.sg (Arthur Sombrito)
Subject: forward class declarations
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 5 Nov 1992 09:11:04 GMT




Hi,

I'd like to ask the ARM specifications regarding forward class
declarations.  At what scope would the class name be entered?  
The current scope or the first non-class enclosing scope?  
For example:

  class A {
    class B {
      struct C;              // is it ::C or A::B::C ?
      struct D *dP;          // likewise is it ::D or A::B::D ?
      void f(struct E *eP);  // is it ::E or is it entered in
                             // the local scope of f() ?
    };
  };
  C *cP;                     // so is C visible?
  E *eP;                     // and so is E?

The USL library assumes that forward class declarations are 
entered in the first non-class enclosing scope. As far as I 
could tell in ARM, it should be entered in the current scope.
Which should it be?

Thanks for any replies
From: john.stephens@uttsbbs.uucp (John Stephens) 
Newsgroups: comp.std.c++
Subject: NAMELESS FUNCTIONS
Date: 11 Nov 92 18:59:00 GMT
Distribution: world
Organization: The Transfer Station BBS, Danville, CA - 510-837-4610/837-5591
Reply-To: john.stephens@uttsbbs.uucp (John Stephens) 

I'm trying to write a function that accepts a one variable math function
(double argument, double return type) and returns another math function
which will calculate the derivative of the original function argument.
In other words, the following will be possible:

        double (*dsqrt)(double) = derivative(sqrt);
        cout << dsqrt(x);

The main problem I am running into is that it seems to be impossible for
the returned function to know what function calculate the derivative
for because it only accepts one argument, and the derivative function
has no way of setting the function inside the calculating function!
(Does anyone understand what I'm trying to say?)

I was thinking of somehow doing it with classes, which would be much
easier. The usage would be as follows:

        Function f(sqrt);
        cout << f.derivative(10);

Or, of course, I could write a general derivative function that accepts
a one variable math function and a double value and just return the
derivative at that point. But I would still like to be able to do it the
way I stated originally. One thing that would solve the problem would be
a modified version of C/C++ that would allow the following:

        double (*derivative(double (*f)(double)))(double)
          {
          double derivCalc(double x)
            {
            ...calculate and return the derivative of f(x)...
            }
          return derivCalc;
          }

It would allow functions to be defined within other functions and use
all of their local variables, without having them explicitly entered as
arguments. In other words, each derivCalc returned could access a
different version of f. Unfortunately I think this is impossible in C
and C++, but who knows.

John Stephens
john.stephens@uttsbbs.uucp
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Newsgroups: comp.std.c++
Subject: Re: Initialization of const dynamic objects
Date: 7 Nov 92 15:57:17 GMT
Organization: University of Birmingham

In article <1deqlgINNmc0@darkstar.UCSC.EDU>, daniel@cse.ucsc.edu (Daniel R. Edelson) writes:> 
> 	new const int;
> 
> This allocates an uninitialized const object. 
> Seems like this should be explicitly prohibited (assuming
> there's no constructor, of course.) Is it?
> ...
> None of the compilers I tested detected this error.

Borland 3.1 does detect it. In fact I don't think it is necessary for a
compiler to spot such a mistake as the action of `new const int' is perfectly
well defined even if utterly useless!

BTW Borland rejects    `new const A' (an implicit call to A::A()) but not
`new const A()' (an explicit call to A::A())

Does anyone know if this is the _standard_ behaviour?

    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)          
 .  _\\__[oo  ============
.__/  \\ /\@
.  l___\\     E-mail: B.A.McCauley@bham.ac.uk
 # ll  l\\ 
###LL  LL\\
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Newsgroups: comp.std.c++
Subject: Re: Unitialized dynamic reference
Date: 7 Nov 92 16:06:34 GMT
Organization: University of Birmingham

In article <1dessbINNn1b@darkstar.UCSC.EDU>, daniel@cse.ucsc.edu (Daniel R. Edelson) writes:
> ... is the following illegal?
> 
> 	new (int&)
Yes the type of this expression is `int&*'. There is no such type!
(Because if you try to take the address of reference what you get is the
address of the thing referred to.)
 
> All the compilers I tried permitted it.
Get some better compilers - Borland 3.1 spotted the error.

    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)          
 .  _\\__[oo  ============
.__/  \\ /\@
.  l___\\     E-mail: B.A.McCauley@bham.ac.uk
 # ll  l\\ 
###LL  LL\\
Newsgroups: comp.std.c++
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: c++ implementation (hard)
Keywords: c++
Organization: University of Jyvaskyla, Finland
Date: Thu, 12 Nov 1992 14:54:26 GMT

In article <kilitzir.721552974@news.forth.gr> kilitzir@antigone.csi.forth.gr (Xristos Kilitzirakis) writes:
> ...
>all right by then.The problem is,that any operator between these
>2 classes , can give any of the 4 classes,depending on many
>things , not only the type of operands.for ex.
>a+b --->c|d|a,
>so I cannot define the return type ,before inspecting the operands.
>
>Any suggestions of implementing (reordering,add a new class,
>  forgetting the hole thing, etc).          ^^^^^^^^^^^^^^^
>
>Well , the implementation is 
>a -> m_n matrix
>b-> n-n topelitz matrix (needs only 2*n-1 elems)
>c-> n_n circulant matrix(needs only n elems)
> ...

No wonder that this looked like a potential "standards" problem to you.
However, there is a conventional technique to do this kind of thing;
it is applicable to other statically-typed OOPLs as well.
It's described in Stroustrup's second edition: "13.9 Handle Classes".
Essentially, you define a Matrix class with the correct interface
(this is the handle class), and then any number of classes that
implement the different representations, and whose instances
the Matrix objects create and handle "behind the scenes".
They would probably not be actually derived from Matrix.

The inconvenient thing here is that you must write all member functions
both in the representation classes and in the handle class (which just
passes most calls to the representation object).  Indeed, a delegation
facility was added to an experimental version of C++ together with
the first implementation of multiple inheritance (described in
Stroustrup's paper in the EUUG Spring Conference proceedings, 1987)
to avoid such chores.  However, it was abandoned because it appeared
to be error-prone in use.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
Newsgroups: comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Zero-length structures and pointer comparisons
Organization: TauMetric Corporation
Date: Wed, 11 Nov 1992 19:37:44 GMT

lewis@sophists.com (Lewis G. Pringle) writes:

|In article <1992Nov4.080805.13496@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
|...
|>I would first like to return to a much more important, related problem,
|>which somebody brought up here rather recently.
|>Namely, there is nothing in the ARM explicitly saying that
|>p == q  might not yield 1 even when p and q are pointing at two different
|>objects.  This hole makes e.g. some standard idioms in Stroustrup's books
|>implementation dependent.

There is language in the C standard (ANSI 3.3.9, Equality Operators)
which requires that pointers which compare equal point to the same
object (plus some weasel wording).  This is missing from 5.10 of the
ARM and (so far) from the C++ Committee Working Paper.  This issue
should probably be addressed.

|Given code like:

|char* start = new char [10];
|char* end   = start+10;
|char* p     = start;

|assert ((p >= start) && (p <= end));	// 1. this is gauranteed by ANSI-C
|p += 10;
|assert ((p >= start) && (p <= end));	// 2. this is gauranteed by ANSI-C
|p = start;
|p--;
|assert (! ((p >= start) && (p <= end))); // 3. ???????

|Is the last assertion portable? ARM/ANSI-C References?

The first two are also guaranteed by 5.9 in the ARM.

The third example does not have defined behavior in Standard C or C++.
You are allowed to create an address one unit past the end of an array,
but you are not necessarily allowed to create an address ahead of the
array.  The expression "p--" is not necessarily valid, and the following
comparison has no defined semantics.  See ANSI C 3.3.8 and ARM 5.9.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.std.c++