HDTenEightyP/NetNews huggingface dataset:
From: mrs@kithrup.COM (Mike Stump)
Subject: Re: Template functions and g++ - why are they not exported????
Reply-To: mrs@cygnus.com
Organization: Cygnus Support
Date: Wed, 02 Sep 1992 09:38:25 GMT

The problem is that the linker cannot yet do template instantiation.

AT&T's cfront will link the file, and depending upon what globals are still
undefined, go back compiler some more code, and try linking again, this process
can be repeated n times.

g++ for now requires that it see a use in each file, to produce an
instantiationin each file.  It will not notice at link time it missed a few
needed definitions.  This is considered a known bug, and one day, will probably
be fixed.

But until then, you have to ``show'' the compiler a use of what it needs in
each file.

In article <1992Aug24.123831.20134@ugle.unit.no> bjornmu@idt.unit.no (Bj|rn P. Munch) writes:
>I have just started to do add some ++ to my C programming, and have
>stumbled on a problem that baffles me.
>
>I took some of the "pseudo"-templates from libg++ to make myself a
>hash table or two.  I thought it would be a good idea to clone these
>into real templates, so I did.
>
>It didn't work.  After ours of struggling, I found the reason: the
>member functions _are_ created when the're supposed to be (I can see
>that by doing "nm" on the object file), but g++ makes them static,
>i.e., they are not exported to the linker.  Aaaargh.   :-(
>
>This simple file will demonstrate it:
>---
>#include  <iostream.h>
>
>template<class T>
>void foo (T t)
>{
>  cout << t << '\n';
>}
>
>void bar(char *str)
>{
>  foo (str);
>}
>---
>
>bar() is here exported, while foo<char *>() is not.  The same happens
>to my non-inlined member functions.
>
>What gives?  From what Lippmann says about this (2nd ed., p198), I
>should be able to create the functions in one file, and use them from
>other files.  Is this a bug in g++ (v2.2.2, Sun4), or do I have to
>do something weird to make it work?
>
>  What I _can_ do, is defining a derived class and explicitly redeclare
>  all the non-inlined functions:
>
>  class OptTable : public VHSet<Option *> {
>  public:
>    Pix  add (Option *o)  { return VHSet<Option *>::add (o); };
>  //....
>  };
>
>  , and compile with -fno-default-inline to make them "real" functions.
>  This is inelegant and tedios, and will add an extra function call.
>
>Who can give me some insight?  If there is no way to make it work,
>I'll try the above trick (or skip the templates), but I'd rather not
>have to.
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Turbo C++, function prototypes
Organization: TauMetric Corporation
Date: Wed, 2 Sep 1992 16:27:28 GMT

harrison@lclark.edu (Mark Harrison) writes:

>>main's correct return type is 'int'.

>It should make no difference whether you try 'int' or 'void' as long as
>main() returns the correct value (or doesn't with void.)

It ought to make a difference, since the only valid definitions of
main() have return type 'int' (explict or implied).  This is the case
in both Standard C and in C++.  If you write, for example,
	void main(){ }
The compiler is obligated to diagnose an error in C and C++.

The return value from main() is supposed to be supplied to the calling
environment in some implementation-defined way.  Some systems appear not
to care whether you return a value, but some report error conditions
based on the garbage value which main() otherwise implicitly returns.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: delete this???
Date: 4 Sep 92 14:22:15 GMT

heilig@plains.NoDak.edu (Zachary Heilig) writes:

|I saw the previous thread about calling the destructor in member functions,
|and was wondering how legal the following code would be:


|void foo::remove( int call_destruct )
|{
|	if( call_destruct ) delete this;
|}


|or, should I just call the destructor function?

|any ideas?

The syntax is correct, but the practice is ill-advised.  There are
some possible ambiguities when an object deletes itself.  They have to
do with the fact that the member function for that object is still
executing, even though the object has been destroyed.  If any of the
objects variables, or its vtbl, get accessed on the way out of the
call, then trouble can ensue.  So your best bet is never to use the
structure: delete this.  (And also avoid goto)

By the way, calling the destructor is also legal syntax:  foo::~foo();
But the result may not be what you expect.  Calling the destructor
executes the code that you wrote for the destructor, but it does not
destroy the object.  Moreover, when the object is finally destroyed,
the destructor will be called again.  So, take care.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
Newsgroups: comp.lang.c++
From: wai@csuvax1.csu.murdoch.edu.au (Julian Wai)
Subject: Compuserv offer
Organization: Murdoch University
Date:  1 Sep 92 02:08:58 GMT

Hi,

I've just received my BC++3.1 upgrade and with it an offer to Compuserv
membership and use for $15.  Can anyone tell me what the rate/per minute to
Compuserv is?  Is there similar offer in Australia?

Thanks

julian
wai@csuvax1.csu.murdoch.edu.au
Newsgroups: comp.lang.c++
From: petras@scs.carleton.ca (juraj petras)
Subject: persistant objects
Organization: School of Computer Science, Carleton University, Ottawa, Canada
Date: Mon, 31 Aug 1992 18:41:51 GMT

Hi,

I am novice in C++ world but with experience with C and Smalltalk. The C++ is my
implementation language for the persistant object base for my thesis.

Is there better way to store objects on secondary storage than  to provide or to inherit from the base functions "retrieve from stream" and  "save to stream" for each class which instances have to be persistant.

I have just started to read this group. If this topic was already discussed,
I would appreciate some summary. If not, go ahead with comments.

Thank in advance.

Juraj (George) Petras, School of Computer Science, Carleton U., Ottawa
email: petras@scs.carleton.ca
From: morgaine@siap.sublink.org (Nadia Pitacco (Morgaine))
Newsgroups: comp.lang.c++
Subject: Name space of enumeration lists identifiers
Keywords: enumeration name space
Date: 1 Sep 92 14:14:22 GMT
Reply-To: morgaine@siap.sublink.org
Organization: SIAP Sistemi S.p.A.


I have the following source file:

	    #include <pwd.h>
	    enum my_enum {comment, some_other_value};
	    
	    main () {
		    /* code omitted */
		exit (0);
	    }
    
pwd.h includes the definition of the following struct:

	 struct comment {
		 char    *c_dept;
		 char    *c_name;
		 char    *c_acct;
		 char    *c_bin;
	 };
        
Compilation under ObjectWorks, which includes a modified version of At&T cfront, produces the following results:

	CC  /tmp/main.c:
	"/tmp/main.c", line 2: error: syntax error
	"/tmp/main.c", line 2: error: syntax error
	"/tmp/main.c", line 2: error: bad declaration of some_other_value -- 
    did you forget a ';'?
	3 errors
   
While both Liant C++ compiler and g++ rev.1.39 (with option -Wall) do not
produce any error or warning message.

According to "The Annotated C++ Reference Manual" (p. 27)
"A name s can be declared as a type and as a non-type in a single scope."
and I though that identifiers in an enumerator list belonged to the same 
name space of constants. 

Who is wrong, and why?
                                             Nadia Pitacco
-- 
	------------------------------------------------------------
	-  Nadia Pitacco                 SIAP Sistemi S.p.A.       -
	-  via Mercantesse 3 - 20021 Baranzate Milano ITALY        -
	-  E-Mail: morgaine@siap.sublink.org                       -
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 29 Aug 92 13:10:17 GMT
Article-I.D.: alice.23585
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Aug28.221841.149034@Cookie.secapl.com> frank@Cookie.secapl.com (Frank Adams) writes:

> I don't claim to have a complete solution to the problem.  However, for the
> specific case   c ? a+b : a   where a+b creates a temporary, I would be
> tempted (as a compiler writer) to always return a temporary: a+b if c is
> true, and a copy of a otherwise.  This solves the problem of not knowing
> whether a temporary has been created.

I'm afraid it doesn't solve the problem.  For example, suppose `a' is of type
const char*, `b' is of type String, and String has one of those problematic
conversions to const char*.  Now, let's modify your example a tiny bit and
look at c?(const char*)(a+b):a.

This expression always returns a value of type const char*, but that's not
where the problem likes: the problem is in the temporary of type String
yielded by the subexpression a+b.  The value of (const char*)(a+b) is valid
only so long as that temporary stays around, so any games you play with
the const char* values themselves won't affect that.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: disp.h for BC/C++ Yes/No? Where...Al Stevens...*.hpp?
Organization: TauMetric Corporation
Date: Wed, 26 Aug 1992 18:04:34 GMT

jamshid@ut-emx.uucp (Jamshid Afshar) writes:

>>What does "*.hpp" stand for ???

>Some C++ programmers use this extension instead of ".h" for their
>header files.  See the c.l.c++ FAQ (ftp sun.soe.clarkson.edu,
>pub/C++/FAQ).  I just use ".h" since there's not much reason to use a
>different extension (you don't 'make' .h files) and I think most C++
>programmers do also.  ANSI C++ will probably use ".h" for any standard
>C++ headers they introduce (confirmation?).

Some compilers have used ".hpp", ".hxx", and ".h++" as file extensions
for C++ headers, while others have just used ".h".

The Standard will not address the subject of file names, since it is
outside the language.  Like the C Standard, it will just specify the
form of character sequences to be used in #include directives to
access the standard headers.

A standard header is not necessarily a file.  If it is a file, the
character sequence appearing in the #include directive might be the
same as the file name, but need not be.

Example:  #include <stdlib.h>
1.  The compiler might recognize this reserved directive and just enable
    declarations internally without ever looking for any actual file.
2.  There might be a file somewhere called "stdlib.h" which the
    compiler then reads in response to this directive.
3.  There might be a file somewhere called "etaoin.shrdlu" which the
    compiler then reads in response to this directive.
4.  There might be a single file somewhere which contains all the
    standard header declarations.  This directive tells the compiler
    to read a certain portion of that file.

I believe all of these schemes are currently in use in various compilers.

Whether the Standard eventually mandated, for example, <iostream.h>
<iostream.hpp>, <iostream.hxx>, <iostream.h++>, or anything else, it
would make some vendors and users unhappy.  Accordingly, we decided
some time ago that the Standard C++ headers (iostreams, strings, and 
whatever else is standardized) will not have an extension in the
include directive header name.  That is, you will just write
	#include <iostream>
This way we avoid offending only a few, and offend everyone equally :-)

I think we can and should word the Standard so that a compiler would
be allowed to accept
	#include <iostream.h>
or
	#include <iostream.hpp>
if it wished, so long as it also accepted
	#include <iostream>
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: a question about '[ as an operator
Date: 26 Aug 92 21:52:20 GMT

cyberman@toz.buffalo.ny.us (Cyberman) writes:

>1: is it possible to specify the '[ as an operator?

No, but you can specify '[]' as an operator.

>2: HOW?  I'm confused about this

class X
{
  public:
    int operator[] (int index);  // the return value and argument 
                                 // don't need to be ints. They can be
                                 // anything at all.
};

>3: if so can they be doubled scripted ie  [X][Y]

Yes, but this is tricky.  You have X::operator[] deal with the first
subscript, and then return an instance of class Y.  You then have
Y::operator[] handle the second subscript.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: moisan@irit.irit.fr (Bruno MOISAN)
Newsgroups: comp.lang.c++
Subject: a freeware data structure library ?
Date: 2 Sep 92 11:10:22 GMT
Organization: IRIT-UPS, Toulouse, France


	a good question for the FAQ !

does it exist a freeware data structure library for c++ (with linked list...) like in eiffel?

If somebody knows it, please email to moisan@irit.irit.fr

	Thanks in advance.
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: Overloading in the presence of ellipsis
Date: 28 Aug 92 02:47:25 GMT
Article-I.D.: alice.23574
Organization: AT&T Bell Laboratories, Murray Hill NJ



srinivas@lgc.com (Manapragada Srinivas @ Landmark Graphics Corporation) writes

 > Hi,
 > 
 > 	If I overload a function in the following way
 > 
 > 		foo( int ) { cout << "non ellipsis version" << endl; }
 > 
 > 		foo( int ... ) { cout << "ellipsis version" << endl; }
 > 
 > 		main() { foo(1); }
 > 
 > 
 > 	The CC 2.0 on sun complains about finding an exact match for 'foo' and
 > 	aborts.
 > 
 > 	g++2.2.2 on the other hand doesn't complain even with the -Wall flag,
 > 	and on running the executable prints out
 > 	
 > 			"non ellipsis version"
 > 
 > 	which is the behaviour I would expect.
 > 
 > 
 > 	Unfortunately, ARM (page 326) explicitly states that this is an error.
 > 
 > 	The problem I am having is that the g++ behaviour is what I am looking
 > 	for, does anyone know what the ANSI committee adopted?

The ARM rule (as in almost all other cases because the mamnual proper part of the
ARM Is a base document). Cfront 3.0 says
	"", line 4: error: ambiguous call: foo ( int )
	"", line 4: choice of foo()s:
	"", line 4: 	 int foo(int );
	"", line 4: 	 int foo(int ... );
From: jcm@evolving.com (Jack Morrison)
Newsgroups: comp.lang.c++
Subject: Re: Inherited nested classes?
Date: 28 Aug 92 16:48:13 GMT
Organization: Evolving Systems, Inc.

I've just run into what I think is a related problem, but maybe a bit simpler.
Here's the stripped-down code:

	class C {
	private:
		struct A { int x; };
		struct B { A a1; };
		A a2;
	};

The AIX 3.2 xlC compiler complains about the struct B declaration, saying
it can't access private type C::A. I guess I understand this, since B is
basically a (nested) class. Making A protected doesn't seem to help, which
apparently means B is not a subclass of C. Making A *public* works, but I 
didn't really want to bother anyone outside the class with the struct type.

-- 
"How am I typing?  Call 1-303-969-3354"    jcm@evolving.com
Jack C. Morrison, Evolving Systems, Inc. Lakewood, Colorado
Newsgroups: comp.lang.c++
From: mcgrant@rascals.stanford.edu (Michael C. Grant)
Subject: the 'standard' complex class
Organization: Information Systems Laboratory, Stanford University
Date: 26 Aug 92 14:34:00


I am rather frustrated with the approach that AT&T took with its complex
class, specifically the decision to make the real and imaginary fields
private. (GNU's libg++ makes them protected, which is similarly frustrating
but not quite as much so).

Because the class does not need to be specially notified when the .re or
.im fields change, why not make them public? It certainly allows for
maximum flexibility; it won't break a single function already written
for complex numbers.

It also seems silly that in <math.h> we have
   double log( double );
but in <complex.h> it is declared as a friend function:
   friend complex log( complex )

I rarely if ever use public data members in my classes. But, if there is no
need for my class to 'know' that a member was changed (if I don't change
my behavior based on that field, and if I don't need to check if its value
is legal, for instance), often I just make it public. I say 'often' because
sometimes in the effort of providing a consistent interface I supply set 
and get methods for those fields too.

In this case, though, there are only TWO fields, in a class whose behavior
is invariant to changes in those fields, whose values you cannot assign
'illegal' values. I suppose complex infinites and NaN's are a tricky issue
but to handle them inside the class would be to slow things down way too
much anyway. So, I see no reason besides some overly-dogmatic
information-hiding argument to keep the fields private

I'm complaining because I'm trying to really tighten some inner loops in my
code (routines on the level of BLAS). Having to go through the various
public double->complex conversions, plus the fact that because complex is
two doubles wide and can't be stored in a register, hinder the optimization.
When I open up the complex class by altering the header file, I can easily
make things just as fast as I expect they can be by allowing me to treat
the real and complex fields separately. Since this is supposed to act like
a basic data type, these optimization differences should not occur; and,
if making the fields public and letting me treat them individually is the
way to make things faster, I say so be it.

Well, I have said way too much on this simple issue. I'd like to hear
some other opinions. Believe me, I virutally never use public data fields,
so I am indeed advocating this as more of an exception rather than the
rule. What does everyone else think?

Michael C. Grant
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c++
Subject: Re: Is there a way to flag errors when an automatic array is returned
Date: 27 Aug 92 06:34:57 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <1992Aug25.135401.17891@bnr.ca>, holiday@bnr.ca (Matthew Holiday) writes:
> In article <KENDALL.92Aug24123852@pen.centerline.com>, kendall@centerline.com (Sam Kendall) writes:
> |> smp@cathedral.cerc.wvu.wvnet.edu (Shailesh M. Potnis) writes:
> |>    Is there a way to flag [returning a pointer to an automatic] as an
> |>    error during compilation.  This is a serious void in C++ which claims
> |>    to remove the pitfalls in C.

> |> This pitfall can't be removed without breaking backward compatibility
> |> with C.

It didn't work in C either, so it would hardly be a serious loss.

> I'm not sure that it would be possible to verify at compile time that a returned
> pointer isn't a pointer to a local variable.

At the time, people said that Algol 68 was behind the times.  Maybe it was
ahead of its time.  Yes folks, Algol 68 had the same possible problem, and
forbade it.  If you want to know how to add a reasonable check to a compiler,
read the old how-to-compile-Algol-68 literature.

The implementation of Burroughs Algol used to rely on the operating system
detecting "up-level pointer returns", but they made the compiler smarter
around about the II.7 release, I think it was.

Basically you do this:
    an L-value is local if it is based on a local automatic value or parameter
    a pointer variable is classified as local if it is ever assigned a local
    pointer
    an R-value is local if it is derived from a local L-value or from
    a pointer variable which might contain a local pointer
    WARN whenever a possibly local pointer value is assigned to a static or
    non-local variable or returned as a result.

You can warn about all sorts of likely mistakes "without breaking
backwards compatibility"; a C compiler can warn about anything it pleases
("%W-CC-BADNAME I don't like variables called "FRED".  Change it.")

-- 
You can lie with statistics ... but not to a statistician.
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 28 Aug 92 02:37:53 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: hendrik@vedge.UUCP's message of 26 Aug 92 13:42:47 GMT

In article <28619@vedge.UUCP> hendrik@vedge.UUCP (Hendrik Boom) writes:

   tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
   : 
   : Under either rule, expressions can already be rewritten to obtain the
   : desired lifetime. For example:
   : 
   : 	X result = x.a().b().c().d();
   : 
	[...]
   : 
   : Language: late destruction, Wanted: early destruction:
   : 
   : 	X a = x.a();
   : 	X b = a.b();
   : 	destroy(a);
   : 	X c = b.c();
   : 	destroy(b);
   : 	X result = c.d();
   : 	destroy(c);
   : 
   What is 'destroy'? Some language feature I don't know about that
   isn't in the ARM syntax?  Or a user-defined member funtion that has
   no control over the calling of the actual destructors of members
   of a, b, and c?

"destroy(x);" is whatever you want to do to destroy "x". Usually,
"destroy(x);" will _not_ simply be a call to the destructor, since
most destructors will do odd things when called twice on the same
object (in code like "{X x; x.X::~X();}", the destructor for "x" will
get called twice).

					Thomas.
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.c++
Subject: Re: named loops
Date: 23 Aug 92 13:46:49 GMT
	<1992Aug21.143653.10805@alias.com> <1992Aug22.171535.29638@taumet.com>
Organization: Department of Computer Science, University of Manchester
In-reply-to: steve@taumet.com's message of 22 Aug 92 17:15:35 GMT

In article <1992Aug22.171535.29638@taumet.com> steve@taumet.com (Steve Clamage) writes:
   The main reason, as I see it, is that it adds no functionality and no
   notational convenience to the language.  Compare:

	   while loop1 (...) { ... break loop1;   ... }
	   while       (...) { ... goto endloop1; ... } endloop1:

IMHO it also shows that "break" doesn't really buy you that much
either.  For the price of a label + goto you have "break".  If "break" is
considered such a major win, then the addition (at a minor cost) of a
optional label would seem to be a win as well.

bevan
From: kpearce@magnus.acs.ohio-state.edu (BULLDAWG)
Newsgroups: comp.lang.c++
Subject: sscanf?  What am I doing wrong?
Date: 31 Aug 92 15:47:23 GMT
Organization: The Ohio State University

Hi:

	Forgive me if this is a stupid question:

I am using Borland C++ and am compiling as default C file.

Why doesn't this work?

char command[80]  \* This is data from a file read off of the disk 'r' type.*\
char partA[20];   \* and is for example "transmit data" *\
char partB[60];
char tran[] = "transmit"
sscanf(command,"%s %s",partA, partB);

void main(void)
{
  if (partA==tran)
  {
  	printf("We have a match\n");
  }
  else
  {
  	printf("failed again  :(  \n");
  }
}

This always fails.  I have tried putting \r\0 and various other control
characters at the end of the ttest string tran[] to no avail.

Putting a printf("%s\n %s\n %s\n",command,partA,partB) yields the correct output
e.g.
    transmit data
    transmit
    data

So what am I doing wrong?  As far as the program goes they don't match.  But I
say they do.

Please e-mail to me.  Thanks.

Ken Pearce
Newsgroups: comp.lang.c++