HDTenEightyP/NetNews huggingface dataset:
From: feathers@serss0 (Michael Feathers)
Subject: Question about temporaries
Organization: Florida International University, Miami
Date: Sun, 24 Jan 1993 23:38:35 GMT


Has the ANSI committee done any more work of the lifetime of temporaries?
I'm very curious about this aspect of the emerging standard.



Newsgroups: comp.std.c++
From: pkt@lpi.liant.com (Scott Turner)
Subject: Re: pointer comparisons
Organization: Liant Software Corporation
Date: Mon, 25 Jan 1993 15:15:16 GMT

In article <1993Jan20.173927.3061@vedge.com>, hendrik@vedge.com (Hendrik Boom) writes:
> In article <1993Jan11.190959.5305@lpi.liant.com>, pkt@lpi.liant.com (Scott Turner) writes:
> > If we have objects of a type which requires no state, e.g.
> >        struct B{} a, b;
> > then in order for them to have distinct identities an implementation
> > might allocate addresses that don't point to valid memory.  Again, no
> > storage is required.
> 
> But if nonempty class C inherits from B, you have trouble comparing
> pointers to B with pointers to C that have been converted to B,
> unless you are careful that addresses of B's are outside of usable
> memory.

The trouble is negligible almost all of the time.  For example,
	struct C : B { int i; };
an implementation could convert "pointer to C" to "pointer to B" using the
same representation for both values.  If some pointers to B are pointing to
invalid memory, the comparison will work out just right.

In unusual cases such as Johan Bengtsson's example, the compiler can "waste"
a byte for the base class.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: Compiler should generate virtual destructors
Date: 22 Jan 93 13:01:52 GMT
Article-I.D.: alice.24679
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <harvey.727664973@regina> harvey@opl.com (Harvey Reed) writes:

> I like this! Compilers could have "compatibility" switches, but for 
> those of us who would rather do it ourselves, we could use the
> full strength version.

The trouble with compatibility switches is that they force people
who care about portability to write in the intersection of the language
accepted in the two modes.
-- 
				--Andrew Koenig
				  ark@europa.att.com
From: ellis@parc.xerox.com (John Ellis)
Newsgroups: comp.std.c++
Subject: Constructors and runtime typing
Date: 26 Jan 93 04:33:42 GMT
Organization: Xerox PARC

Regarding Stroustrup's proposal for runtime typing:

Suppose class B is derived from A and A's constructor calls typeof(*this):

    class A    {A() {...typeof(*this)...}; ...};
    class B: A {...};

(Excuse any mistakes in notation.)

When "new B" is evaluated, will typeof(*this) yield typeof(A) or
typeof(B)? 

The recommended implementation technique seems to suggest typeof(A),
and that's consistent with the handling of virtual functions within
constructors.
From: hendrik@vedge.com (Hendrik Boom)
Newsgroups: comp.std.c++
Subject: Re: pointer comparisons
Date: 20 Jan 93 17:39:27 GMT
Organization: Visual Edge Software Ltd.

pkt@lpi.liant.com (Scott Turner) writes:
: In article <1393@pivot-sts.sbi.com>, linke@kirin (User - Bill Linke) writes:
: > In article <1993Jan11.190959.5305@lpi.liant.com>, pkt@lpi.liant.com (Scott Turner) writes:
: > > If we have objects of a type which requires no state, e.g.
: > >        struct B{} a, b;
: > > then in order for them to have distinct identities an implementation
: > > might allocate addresses that don't point to valid memory.  Again, no
: > > storage is required.

(Not quite a quote -- I named the struct 'B' so I could talk about it.)
There's no problem with allocating no storage for struct B, and using
addresses into deep space or real space to point to B's. Even if user code
dereferences it or copies it this can be done with no action.
But it nonempty class C inherits from B, you have trouble comparing
pointers to B with pointers to C that have been converted to B,
unless you are careful that addresses of B's are outside of usable
memory.
: 
-- 
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work:	hendrik@vedge.com,  iros1!vedge!hendrik
at home:	uunet!ozrout!topoi!hendrik
Newsgroups: comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Question about temporaries
Organization: TauMetric Corporation
Date: Mon, 25 Jan 1993 18:22:32 GMT

feathers@serss0 (Michael Feathers) writes:


>Has the ANSI committee done any more work of the lifetime of temporaries?
>I'm very curious about this aspect of the emerging standard.

It is still under discussion and has not yet been resolved.  I expect
that it will be resolved this year.

It is a hard problem, with excellent arguments both in favor of and
against all solutions proposed so far.

Once it has been resolved, it may take a while for existing
implementations to catch up to any needed changes.  So the best
advice so far is still to avoid dependencies in your code on how
long a temporary will live.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
From: rvloon@cv.ruu.nl (Ronald van Loon)
Newsgroups: comp.std.c++
Subject: Re: stringize preprocessing operator?
Date: 21 Jan 93 14:52:20 GMT
Organization: University of Utrecht, 3D Computer Vision Research Group
Originator: rvloon@triton.cv.ruu.nl

In <KRISS.93Jan21114643@trot.ibp.fr> kriss@trot.ibp.fr (Christophe GROSJEAN) writes:

|"In article <1993Jan19.181741.4779@taumet.com> steve@taumet.com (Steve Clamage) writes:
|"
|"   Preprocessing in C++ is supposed to be the same as in Standard C
|"   (except for // comments).  The ARM tries to say that, and the
|"   C++ Standard will make it so.
|"
|"By the way, does anybody ever thought of the problems that occurs between
|"preprocessors macros and templates.
|"
|"If I define a macro that use *a type* as an argument, whenever I use
|"templates with multiple arguments in this macro, I have a problem :
|"the problem is coma. It's the *only* valid argument separator for
|"macros !
|"Isn't it time to betterize the standard C++ preprocessor.
|"Usefull features would be :
|"	1 - changing separator for a macro
|"	2 - enable macro overloading,	you can do it with functions,
|"	why not with macros ? I don't ask for typed arguments,
|"	(it would be stupid), but for the number of arguments.
|"	3 - compile time vars, in order to save and restore contexts in macro
|"	it could be something like #define inside macros.
|"	this last one would be *very* usefull, but I think it's a dream.
|"
|"However, the other 2 enhancement, seems sensible.
|"Yet, there is another way to bypass my problem : taking care of templates
|"*before* macros. If this were the case, my problem wouldn't occurs
|"any more.

I have successfully used the following trick:

#define COMMA ,

#define f(a,b) template a harry(List ## b);

f(<class some_class COMMA class some_class2>, 
  < some_class COMMA some_class2 >);

(the macro isn't realistic, but it assumes a List class somewhere that can be
 instantiated through this macro)

This works, because the comma is expanded AFTER 'f' is expanded. It doesn't
work, however, if 'f' calls other macros that use arguments passed to your
first macro.
-- 
Ronald van Loon     | Consider this: In the United States, an automobile is
(rvloon@cv.ruu.nl)  | stolen EVERY 14.7 SECONDS. 
3DCV Group, Utrecht |   If that statistic scares you, think how we felt when we 
The Netherlands     | made it up. - Dave Barry, "CHRISTMAS BUYERS GUIDE"
From: hendrik@vedge.com (Hendrik Boom)
Newsgroups: comp.std.c++
Subject: initializing several translation units
Date: 22 Jan 93 15:24:36 GMT
Organization: Visual Edge Software Ltd.

---------------
Translation unit 1:

class x{....
	x();
	....};

extern x y;

foo(){ .... y ....}

Translation unit 2:

class x{....
	x();
	....};
	// same class x as above; presumably both are really in a header file

x y;

-----------------

Can I rely on y being initialized in translation unit 2 by
the constructor x::x() before it is used in translation unit 1?
-- Assuming there is no other dependency of unit 2 on unit 1, of course.

The ARM (section 3.4, page 19) suggests in large print that you can:
	The initialization of nonlocal static objects in a translation
	unit is done before the first use of any function or object
	defined in that translation uniot.

So the initialization of y in unit 2 should occur before any use of y,
which is defined in unit 2. The ARM doesn't say that the use has to be
in unit 1.

The ARM then proceeds undercut this in the small print by suggesting ways
you can accomplish proper initialization order by long, complicated coding.
Is the small print an advice to the implementer (in which case the user
can rely on proper initialization of y) or advice to the user
(in which he can't)?

Is the situation different if foo() is called from the initializer of
another nonlocal static object in unit 1?
-- 
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work:	hendrik@vedge.com,  iros1!vedge!hendrik
at home:	uunet!ozrout!topoi!hendrik
Newsgroups: comp.std.c++
From: ellis@parc.xerox.com (John Ellis)
Subject: ARM ambiguity about member initializers and virtual functions
Organization: Xerox PARC
Date: 27 Jan 93 00:45:05 GMT

For the purposes of binding virtual functions, is a member initializer
considered part of the constructor in which it appears?  The answer
might seem obviously yes, but the ARM appears contradictory on this point.

Consider this test program:

    #include <iostream.h>

    struct A {
        A() {f();}
        virtual int f() {
            cout << "In A::f.\n";
            return 0;}
        int g() {return f();}};

    struct B: A {
        B(): i( g() ) {g();}
        int i;
        virtual int f() {
            cout << "In B::f.\n";
            return 0;}};

    void main() {B b;}

Three compilers we tested believe that member initializers are part of a
constructor as regards virtual functions.  They produced this output:

    In A::f.
    In B::f.
    In B::f.

whereas a fourth compiler, known for its rigid adherence to the
standard, has a contrary belief:

    In A::f.
    In A::f.
    In B::f.

The natural interpretation, that a member initializer is part of its
constructor, comes from two passages in the ARM:

    Page 294, 12.7: Member functions may be called in constructors and
    destructors.  ... The function called will be the one defined in
    the constructor's (or destructor's) own class or its bases, but
    *not* any function overriding it in a derived class.
    
    Page 294, 12.6.2: A mem-initializer is evaluated in the scope of
    the constructor in which it appears.

But some earlier commentary clearly contradicts the natural
interpretation:

    Page 233, 10.9c: When B::B() is executing, the C part of the
    object being constructed exists only as raw storage and cannot be
    accessed through a virtual function.  The available f() is A::f().
    The first point at which C::f() can be called as f() is the first
    *statement* in the constructor C::C(). [emphasis added]

This clearly states that a class's virtual functions are not available
before the first statement of a constructor.  Since member
initializers are executed before the statements of the constructor:

    Page 292, 12.6.2: ...then the members are initialized...then the
    body of D::D() is executed (12.1).

this implies that a class's virtual functions are not available to a
member initializer.

Is section 10.9c wrong?
From: dwr@cci632.cci.com (Donald W. Rouse II)
Newsgroups: comp.std.c++
Subject: Re: structs that define nothing
Date: 27 Jan 93 17:33:19 GMT
Organization: [Computer Consoles, Inc., Rochester, NY

In article <1993Jan25.171222.1@fnalng.fnal.gov> b91926@fnalng.fnal.gov writes:
>Does the c++ standard have anything to say about the legality of a
>construct like the following:
>
>...
>struct
>{
>  int a;
>  int b;
>};
>
>...
>
>Such an example appeared in a recent issue of "C++ Report". The
>problem with this code is that it defines absolutely nothing.

This example reminds me of a possible extension to C++ (and C)
that could occasionally be useful: anonymous structures,
which are analogous to anonymous unions.

Example:
	typedef union
		{
		unsigned long lw;
		struct { unsigned short sw0, sw1; };
		struct { unsigned char b0, b1, b2, b3; };
		}	machword;
	machword	r1, r2;

Now you can access r1.b2, instead of having to do
something like r1.b.b2, etc.

Note that the only place this would be useful
is inside a union.
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.std.c++
Subject: Re: Question about temporaries
Date: 27 Jan 1993 20:11:19 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <1993Jan25.163150.24449@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
> [proposed rule on lifetime of temporaries]
>     Temporaries are normally destroyed at the end of the statement
>     in which they are created.  The exception is that temporaries
>     created within a branch of a conditional (?:) operator are destroyed
>     when that branch is completed (and analogously for && and ||).

This seems like the most reasonable compromise.

>I would say that the committee was ready to compromise and decide on this
>except for one thing.  Nearly all of the discussion has assumed that we
>know what is a "temporary".  When asked directly regarding the formal
>argument x in the function

	class C { ...  C (const C&);  ... };
	void f(class C x) {   ... use x ...   }

>most people would say x is _not_ a temporary.

This is true, but that has nothing to do with your example below.  The
formal parameter x is a different thing entirely from the actual
parameter that is assigned to it.  The latter may be a temporary but
the former is not.

I changed the variable from x to w in your example to avoid confusion
(two different x's).

     String w, y;
     char *z;
     extern char *f(String x);
     z = f(w+y);

In this example there is a temporary that is the result of w+y.  This
temporary gets assigned to the formal parameter x of function f by means
of the copy constructor, at least conceptually.  But it could still be
considered a temporary in the sense of the rule above, meaning that it
lives until the semicolon.  Under this interpretation, we would have the
following action: temporary t is set to the result of w+y; this temporary
is passed to the x parameter of f with the copy constructor; at the end
of f that copy is destroyed, but t is still alive; the result is assigned
to z, and then t is destroyed.

The result is the same as if we replace the final statement above with

	{ String& t = w+y; z = f(t);}

Note that this has a cost: we cannot eliminate the copy constructor and
initialize x "in place" anymore.  This means that the fundamental cost
of passing an object by value has increased.


--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.std.c++
From: rajiv@lobby.ti.com (Rajiv Roy)
Subject: Borland C++ Training
Organization: Process Automation Center
Date: Wed, 27 Jan 1993 18:21:43 GMT


We are currently using Turbo Pascal to implement s/w on our product line. We 
would like to migrate to using C++ (truly object-oriented) and leverage s/w 
productivity, re-usability etc that C++ supposedly provides. We are all 
experienced C programmers (>8 yrs for all of us), however we have not 
seriously done any C++. In fact whenever we start, it is C all over again. 
We have targeted a real project that WILL be done in C++, using true 
objects. All the training listed on TEMS (TIOLR) seems to be using 
Videotapes and is self-paced. I think we would prefer somebody in flesh and 
blood we can ask questions etc. Any pointers? We would specifically prefer 
Borland C++ in the Dallas area.
Thanks in advance and Regards, Rajiv  
----------------------------------------------------------------
Rajiv.roy%rroy@timsg.ti.com, or          TI MSG: RROY
rajiv@lobby.ti.com, or                   V:(214)917-2709
4326168@mcimail.com                      F:(214)917-5512
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.std.c++
Subject: "const" in arglist part of function type?
Date: 24 Jan 93 17:42:57 GMT
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany

(Note to Readers of `comp.lang.c' and `comp.lang.c++': This is a modified
repost of a question I recently posted to the above groups.  Since the
answers I received were not quite satisfactory regarding the C++ aspects,
I post it again here.)

Background: For certain reasons I'm trying to write programs in a way
so that they can be compiled with either an ANSI-C- or a C++-compiler.

Problem:  The following is the narrowed down failing case where my
C++-compiler (Comeau 3.0 on ISC UNIX) rejected some piece of code that
is valid ANSI-C (according to my SysV.R4 compiler and to Jutta Degener
who pointed out in private mail that the `const'-ness of a function's
argument is not part of the function's type in ANSI-C).

	void foo(const int i) { /* i not modified here */ }
	...
	void (*bar)(int) = foo;

Question 1:  Has the C++ standardization already an opinion on this,
i.e. is this is an *intentional* deviation from ANSI-C?

Corretions: I see the following ways to make the program acceptable for
both, ANSI-C and C++.

	a) add `const' to bar's parameter declaration;
	b) delete `const' from foo's parameter declaration;
	c) use an explicit `(void (*)(int))'-cast in the assignment.

Option a) is of no value, since in the `real' program I need to assign
different functions to bar, some of which need non-const parameters,
hence it would just reverse the problem.

Option b) is the way I use right now(*1), but it is somewhat unsatisfactory
that I'm not able to protect foo's argument against inadvertent changes
(e.g. by a typo).

Option c) is to my understanding outruled by the ARM, which says that
type-casting function pointers may be possible but are not further
defined.(*2)

Question 2: Has the C++ standardization an opinion on function pointer
casts which differ from the function's declaration only in the type
qualifiers of one or more arguments?

Footnote 1: In fact, I didn't use it as solution to the problem but the
problem occurred when I changed some programs to use `const' in as many
places as possible, so also for function args that do not change during
time.

Footnote 2: I can see a reason for this if there are different calling
sequences possible (or desirable) for `f1(const int i)' and `f2(int i)'
(again thanks to Jutta for this hint).
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
From: hansen@pegasus.att.com (Tony L. Hansen)
Newsgroups: comp.std.c++
Subject: Re: "const" in arglist part of function type?
Summary: currently under investigation
Keywords: const, function signatures
Date: 27 Jan 93 17:32:50 GMT
Organization: AT&T

< From: martin@mwtech.UUCP (Martin Weitzel)

< Background: For certain reasons I'm trying to write programs in a way so
< that they can be compiled with either an ANSI-C- or a C++-compiler.

< Problem:  The following is the narrowed down failing case where my
< C++-compiler (Comeau 3.0 on ISC UNIX) rejected some piece of code that is
< valid ANSI-C (according to my SysV.R4 compiler and to Jutta Degener who
< pointed out in private mail that the `const'-ness of a function's argument
< is not part of the function's type in ANSI-C).

<	void foo(const int i) { /* i not modified here */ }
<	...
<	void (*bar)(int) = foo;

< Question 1:  Has the C++ standardization already an opinion on this, i.e.
< is this is an *intentional* deviation from ANSI-C?

No and no. This is a topic under active discussion at this time by the
standards committee.

< Question 2: Has the C++ standardization an opinion on function pointer
< casts which differ from the function's declaration only in the type
< qualifiers of one or more arguments?

As I understnad it, the signatures must match. Whether the const is part of
the signature is what is currently under debate.

					Tony Hansen
			    hansen@pegasus.att.com, tony@attmail.com
				att!pegasus!hansen, attmail!tony
From: mharriso@digi.lonestar.org (Mark Harrison)
Newsgroups: comp.std.c++
Subject: Re: stringize preprocessing operator?
Date: 21 Jan 93 21:10:42 GMT
Organization: DSC Communications Corp, Plano, TX

In article <1993Jan19.181741.4779@taumet.com> steve@taumet.com (Steve Clamage) writes:
>
>Preprocessing in C++ is supposed to be the same as in Standard C
>(except for // comments).  The ARM tries to say that, and the
>C++ Standard will make it so.
>
>Are you sure the Lucid compiler does not provide full Standard C
>preprocessing in C++ mode?  Perhaps the manual is a bit misleading.

It turns out there are two C++ modes, -XF (ARM compatible) and -Xf
(cfront 2.1 compatible).  -XF uses ansi style preprocessing, while -Xf
uses K&R style.  The preprocessing style can be specified by using -XAp
for ansi preprocessing and -XKp for K&R style.

Jerry Schwartz (jss@lucid.com) was kind enough to point this out to me.
-- 
Mark Harrison, mharriso@dsccc.com
Newsgroups: comp.std.c++
From: kriss@trot.ibp.fr (Christophe GROSJEAN)
Subject: Re: stringize preprocessing operator?
Reply-To: grosjean@masi.ibp.fr
Organization: Laboratoire MASI, Paris, France.
Date: Thu, 21 Jan 1993 10:46:43 GMT

In article <1993Jan19.181741.4779@taumet.com> steve@taumet.com (Steve Clamage) writes:

   Preprocessing in C++ is supposed to be the same as in Standard C
   (except for // comments).  The ARM tries to say that, and the
   C++ Standard will make it so.

By the way, does anybody ever thought of the problems that occurs between
preprocessors macros and templates.

If I define a macro that use *a type* as an argument, whenever I use
templates with multiple arguments in this macro, I have a problem :
the problem is coma. It's the *only* valid argument separator for
macros !
Isn't it time to betterize the standard C++ preprocessor.
Usefull features would be :
	1 - changing separator for a macro
	2 - enable macro overloading,	you can do it with functions,
	why not with macros ? I don't ask for typed arguments,
	(it would be stupid), but for the number of arguments.
	3 - compile time vars, in order to save and restore contexts in macro
	it could be something like #define inside macros.
	this last one would be *very* usefull, but I think it's a dream.

However, the other 2 enhancement, seems sensible.
Yet, there is another way to bypass my problem : taking care of templates
*before* macros. If this were the case, my problem wouldn't occurs
any more.
From: harvey@opl.com (Harvey Reed)
Newsgroups: comp.std.c++
Subject: Re: Compiler should generate virtual destructors
Date: 22 Jan 93 01:09:33 GMT

db@argon.Eng.Sun.COM (David Brownell) writes:

>...
>So, a pair of proposals that I'd be happier to see accepted:

>   (1)	It is an error for a class to have virtual functions and a
>	nonvirtual destructor.
>	
>   (2a) C++ compilers don't automagically generate ANYTHING for classes
>	any more:  constructors, destructors, assignment and address-of
>	operators, etc.  If such routines are used but not declared and
>	defined, that is an error.


I like this! Compilers could have "compatibility" switches, but for 
those of us who would rather do it ourselves, we could use the
full strength version.

I think I would feel a lot better about my C++ compiler if I didn't
have to make a copy-ctor private/unimplemented (as a safegaurd) just
because I was afraid that I *might* be accidentally copying an object.
It would be much better if the compiler simply said it was an error
to copy without a copy-ctor (or whatever), then the programmer can:

1) remove the need to copy
2) install the proper method to do the copy

This goes for all the other automagic stuff too! I cringe when I 
think about automagically adding virtual destructors, even though
they are most times needed...



-- 
++harvey
===========================================================================
internet:       harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
voice/fax:      617-965-0220    /  617-965-7599