HDTenEightyP/NetNews huggingface dataset:
From: knight@henson.cc.wwu.edu (Matthew Scott)
Newsgroups: comp.lang.c++
Subject: trying to link .o's produced by g++ <PLEASE HELP>
Keywords: link g++ help
Date: 14 Oct 92 19:00:08 GMT
Article-I.D.: henson.1992Oct14.190008.17946
Organization: Western Washington University

PLEASE SAVE MY SANITY!!  I am fairly new to g(c)++ and as an attempt
to learn more I am going to use InterViews and g++ to do some graphical
applications.  gcc (and therefore g++) ~v2.2.2 has been installed on the
system I am using.  I have spent days making the InterViews code
compile.  I am finally there!  HOWEVER when I try to link the object files
together to produce the executables I get the following:


g++ -w     -o a.out *.o     -L../../../.././src/lib/IV/MIPSEL -lIV 
     -L/usr/lib -lXext -lX11 -lm  
ld:
Undefined:
localtime__FPCi
asctime__FPC2tm
strncpy__FPcPCcUi
strncat__FPcPCcUi
sscanf__FPCcT0e
fprintf__FP6_iobufPCce
exit__Fi
sprintf__FPcPCce
abort__Fv
perror__FPCc
strncmp__FPCcT0Ui
fflush__FP6_iobuf
_flsbuf__FUcP6_iobuf
getenv__FPCc
cos__Fd
sin__Fd
__assert__FPcT0i
close__Fi
open__FPcie
fstat__FiP4stat
read__FiPci
collect: /usr/bin/ld returned 1 exit status
*** Error code 1

Stop.

As I look at the other methods that have been defined it looks as though
g++ appends the class to the method?  It also looks like it is doing the
same thing for standard C system calls! I want g++ to KNOCK IT OFF!  How
do  get g++ to not put the garbage after the standard C calls so the
linker can actually find them?

INFO:  I am including /usr/gnu/lib/g+-include, and then /usr/include,
plus other needed includes (in this order).  We are using collect and
/usr/bin/ld (not gld).  The g++ and gcc libares are getting linked in.

What can I do! I have no hair left after tring to get this stuff linked!

THANK YOU in advance for any help in tracking this down

-------------------------------------------------------------------------------
Matthew J. Scott - knight@cs.wwu.edu
Western Washington University

- Its your world change it its your world change it its your world CHANGE IT! -
-------------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: dhoward@novell.com (Dirk W. Howard)
Subject: Comm package for C++ (Borland)
Organization: Novell, Inc.
Date: Wed, 14 Oct 1992 17:48:28 GMT

I was wondering if anyone knew of a Asynchronous Communications class 
library for Borland C++.  I am looking for a class library that will allow 
me to write to multiple async ports.  I want to be able to have access to 
transfer protocols (Kermit, XMODEM, YMODEM, etc.) and use high line speeds.  
If anyone knows of such a package, please let me know.

I will post a summary.

---------------------------------------------------------------------------
Dirk W. Howard              These are my personal opinions.  No one else 
Novell Technical Support    in their right mind would claim them.
dhoward@novell.com
---------------------------------------------------------------------------
From: dstevens@educ.ucalgary.ca (Douglas Stevens)
Newsgroups: comp.lang.c++
Subject: C++ Compiler for Mac.
Date: 14 Oct 1992 19:54:57 -0500
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

Can anyone tell me if there is a Borland compatable C++ compiler
for the Macintosh?  I have written a program using Turbo C++, and
I would like to run it on the Mac without having to do a whole
bunch of re-coding.
From: eeharvey@cybaswan.UUCP (i t harvey)
Newsgroups: comp.lang.c++
Subject: Re: NIHCL C++ class library and X11's libXt both use Object
Date: 13 Oct 92 10:17:00 GMT
X-Newsreader: Tin 1.1 PL3

hanlon@cray.com (Jim Hanlon) writes:
: 
: 
: In article <1992Oct10.022733.24514@netcom.com> geoff@netcom.com (Geoffrey Leach) writes:
: 
: >It appears that there is an unfortunate interaction between the C++
: >class library NIHCL and X11's Xt intrinsics, in that both declare "Object".
: >Is there a workaround, or am I missing something?
: 
[Kludge deleted]
: 
: You may get a warning about "String redefined" in "Intrinsic.h", but other than
: that the approach seems to work.
: 
: I don't see a lot of point in flaming on about C/C++'s lack of a package
: facility, etc.  I just wish folks would use a little bit of sense when staking
: out their namespace.  For example, the X developer's seemed to be asleep on the
: day they defined 'String', 'Object', 'Cardinal', etc.  All the rest of their
: thousands of names begin with a predictable 'X', 'Xaw', 'Xm', etc.  Same fault
: for NIHCL (and most other class libraries that float around).  I once built NIHCL
: with all the class names prefixed with 'Nih' (the way I think it should have been
: done in the first place), but I've thrown it away because it is too much trouble
: to maintain.  This kludge, though not elegent, does the job well enough.
: -- 
: 
: -----
: 
: Jim Hanlon                                 (internet) hanlon@cray.com

Thanks for the workaround. I've run into the same conflicts with the ONTOS (OODBS) and
X11 and thought I'd see if the net had anything to offer. I was hoping for something
more elegant though.

Anyway, why do those dorks do this?! If I'm creating a library to be used by anyone
else, even one other person, I take precautions in naming things sensibly. What
excuse do they have for grabbing names/types/classes such as Object, Boolean and so
on. Aren't there any guidelines on this, a register of pre-fixes or something?

Grrrrrrrrr.


-- 
_______________________________________________________________________
  Ian Harvey, University College Swansea         Too old to rock'n'roll
  eeharvey@uk.ac.swan.pyr                              Too young to die
From: kps@cunixb.cc.columbia.edu (Karthik P Sheka)
Newsgroups: comp.lang.c++
Subject: template question...
Date: 7 Oct 92 04:56:25 GMT
Reply-To: kps@cunixb.cc.columbia.edu (Karthik P Sheka)
Organization: Columbia University


Can anyone please tell me why the following does not compile? (The problem
is with the constructor.)
The compilers (GNU's g++ and AT&T's CC) complain about an undefined symbol.
(The symbol is a mangled version of the constructor).

//Karthik

template<class U> class stack {
  U* v;
  U* p;
  int sz;
 public:
  stack(int s);
  ~stack(){delete[] v;}
  void push(U a){*p++=a;}
  U pop(){return *--p;}
  int size() const {return p-v;}
};

main()
{
  stack<double> www(4);

  www.push(2.3);

  cout << "hello, world\n";
}


template<class U>
stack<U>::stack(int s)
{
  v = p = new U[sz=s];
}
Newsgroups: comp.lang.c++
From: eny@ermes.enea.se (Erik Nykvist)
Subject: Re: Only 'public' stuff in .h file?
Organization: Project ERMES, Teli Telecom Sweden
Date: Mon, 12 Oct 1992 16:06:03 GMT

mark@sdd.hp.com (Mark Overton) writes:
> I'm really hoping that C++ will let me totally hide all implementation
> info from the "user" of a class.  This means the .h file for the class
> must contain solely the public interface, and not contain any private
> members (which would be in the .cpp file).
> 
> Is such separation of public and private members possible?
> 
> I'm afraid the answer is 'no' because such separation would require that the
> layout of memory for a source file be decided at link-time instead of at
> compile-time (the compiler wouldn't know how much space to allocate for
> private instance-variables).
> 
> So it seems to me that 60's compiler+linker technology has trapped us into
> a serious violation of the principle of information-hiding.  I don't want
> to force all the users of my container class to recompile their files just
> because I added a private variable, or switched from binary trees to
> skip-lists.

Many people has suggested abstract classes but in fact there is another way to do
this. Use a forward-declaration!

.h-file
=======
class MyClassImp;

class MyClass
{
   private:
      MyClassImp* data;
   ...

};

.cpp-file
=========
#include "MyClassImp.h"

As long as you don't implement any inline functions using data or
creating instances of MyClassImp, you only need to include its
defintion in the .cpp-file.

The advantage of this is that we only have one level of indirect, not
many levels as with virtual functions. I.e the code could be slightly
more efficient.

I am not certain which solution that I prefer. Abstract classes makes
the use of alternative implementations easy to handle. 

Well, you can choose for yourself ...

Erik



Newsgroups: comp.lang.c++
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Proposal: Preconditions and PostConditions in C++
Date: Mon, 12 Oct 1992 21:43:58 GMT
Organization: Security APL, Inc.

In article <1bcbgrINN3lh@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe Buck) writes:
>But yes, private derivation does end up looking a lot like including
>the privately inherited object as a member (for example, if private
>inheritance were dropped from the language, you could get the same
>effect in most cases by including the privately inherited baseclass as
>a member of the (no longer) derived class and passing method calls along).
>However, there are often some efficiency and space advantages, as well
>as coding advantages, to doing it with private inheritance.

The question (for future language developers; it's already *in* C++) is
whether these advantages are worth the cost in, e.g., getting the compilers
to accept the idea of private inheritance.  My guess is that it isn't.

For myself, I don't expect to use private inheritance when I am doing the
system design.  Since anything done by it can be done by including data
members without excessive cost (as far as I can tell), it seems to me to be
conceptually cleaner to use a single approach.
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Typedef name and variable name clash
Organization: TauMetric Corporation
Date: Thu, 8 Oct 1992 16:00:58 GMT

nikki@trmphrst.demon.co.uk (Nikki Locke) writes:

>Is the following C++ code legal, or not ?

>typedef unsigned color;

>class ColoredButton {
>	ColoredButton(color &color);
>	};

I think this fragment is legal, but you will not have access to the
type name 'color' inside the constructor.  The ARM explictly lists (p 106)
	typedef long I;
	int I;
as illegal, because the two "I" declarators are in the same scope;
typedef names and variable names are in the same name space.  In this
example, the parameter name 'color' is in a new scope.

In any event, it is certainly poor programming practice.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: rmartin@donner.Rational.COM (Bob Martin)
Subject: Re: streams
Organization: Rational
Date: Thu, 15 Oct 1992 16:23:12 GMT

cshaver@informix.com (Craig Shaver) writes:

>In article <1992Oct13.155518.22845@rs6000.bham.ac.uk> pickerig@dns0.bham.ac.uk (Mr. G. Pickering) writes:
>>My first reaction is to use FILE functions rather than streams, unless
>>you have a good reason to use streams. This is just the way I do things,
>>feel free to flame me for this.

>Praise the lord for a breath of fresh air -- streams are hard to use!

IMHO this statement is too strong.  Streams are different, to be sure;
but they are not truly hard to use.  Moreover, they have a number of
advantages that should not be ignored.  

	They are type safe.  You cannot foul up your stack with
statements like printf("%d\n", 1.0); or the more malignant scanf form.

	They are extensible.  You can create I/O operators for new
data types.

	They are polymorphic.  You can invoke the correct I/O
operators without knowing the types of the data you are I-ing or O-ing
(this requires a little preplanning, and some appropriately placed
virtual functions)

When I first started using C++, I often fell back on stdio.h, simply
because I knew it well, and was comfortable with it.  But over time I
used streams more and more.  Now, I never think about using stdio
anymore.  Not that stdio is bad, it's just that now I am used to
streams.

--
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++,comp.std.c++
From: pete@genghis.borland.com (Pete Becker)
Subject: Re: The concept of templates considered ill designed
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Wed, 7 Oct 1992 17:03:51 GMT

In article <UeoW1kS00awV0GbEpY@andrew.cmu.edu> Stefan Monnier <osoelgaultier+@CMU.EDU> writes:
>
>The point with templates in general, IMHO (but I believe it's shared
>by others), is to to be able to typecheck. Else, a pointer to void with
>some casts could do the trick.
>
>template <class T> T hello(T t)
>
>is not the same as
>
>T hello(T t)
>
>cause if you call hello with a type Hi (which inherit from T), you know 
>that it will return an object of type Hi, whereas without templates, 
>this is not checked: It can return any object of type T (maybe it is also of 
>type Hi, but no typechecking occurs here: you're only responsible for it)
>
>Constraints templates doesn't change anything to this fact. The only
>thing it changes is that the internals of a function (or anything else)
>depending on a template (like hello) can be checked (and compiled)
>before using it: separately !
>

	Constrained parameters alone do not make it possible to compile a
template without regard to how it will be instantiated.

	class Parameter
	{
	public:
	    virtual void f( long );
	};

	template <class T : Parameter>
	class DoSomething
	{
	};

	class SmartParameter : public Parameter
	{
	public:
	    void f( long );
	    void f( int );
	};

Presumably, SmartParameter adds f(int) because it can handle small values
in a more efficient manner.  If DoSomething is compiled without knowledge of
the actual template parameter being used, this smarter interface is lost.
	As I mentioned earlier, the other place where you pay for this is that
all uses of the template parameter must be through pointers.
	Being able to compile a template without knowing how it is in fact
being used may well be useful, but it comes at a price.  The resulting code
will be less efficient.
	I think the argument in favor of compiling templates on their own has
to focus on this point.  What do you get out of it that you cannot get by
simply using pointers?  Easier coding, sure.  But are there significant
differences in the kind of things you can do with them?  Or is this a solution
in search of a problem?
	-- Pete
From: pickerig@dns0.bham.ac.uk (Mr. G. Pickering)
Newsgroups: comp.lang.c++
Subject: Re: (QUERY) How to call an object's member function?
Date: 16 Oct 92 14:19:52 GMT
Organization: The University of Birmingham, England
X-Newsreader: TIN [version 1.1 PL6]

Both g++ and Sun C++ perform function name mangling. Unless your
debugger understands the mangling, you have problems. You have to
mangle yourself (Oh dear!)

Now, I use gdb on CFRONT code. You type 'info functions' for
a list of the mangled names. You can then type these in.

If you use g++ _and_ gdb, you should be able to turn demangling on using
'set print demangle on'. This should solve your problem.

Guy.

--
Guy Pickering
Electronic Eng, University of Birmingham, Edgbaston, Birmingham. ENGLAND
G.PICKERING@uk.ac.bham  or pickering@uk.ac.bham.eee
--
"Simpleton?...Now I know that means something bad." - Kelly Bundy
Newsgroups: comp.lang.c++
From: aldavi01@starbase.spd.louisville.edu (Arlie Davis)
Subject: Re: virtual destructors
Date: Tue, 13 Oct 1992 03:24:14 GMT
Organization: University of Louisville

In <1992Oct12.235515.4506@netcom.com> nagle@netcom.com (John Nagle) writes:

>        It's not your fault.  The language is badly designed in this area.
> Destructors should always be virtual, and it should be an error (at least
> a warning) to declare one that isn't.

So, I must penalize every class, no matter how simple, with a vtable pointer?
Perhaps that would go over better as: "... and it should be an error/warning to
derive from a class that does not have a virtual destructor."

I like that FAQ's advice: If it has any virtual methods, it should have a 
virtual destructor.

-- 
lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null
From: mittle@siena.watson.ibm.com (Josh Mittleman)
Newsgroups: comp.lang.c++
Subject: Re: Const and Reference
Date: 8 Oct 92 19:58:29 GMT
Organization: IBM T. J. Watson Research

Shih-Hao Liu writes:

1> #include <stdio.h>
2> main()
3> {
4>     char a = '-';
5>     const char &b = a;    // error: asignment to constant
6> 
7>     b = '+';
8>     printf("%c\n");       // missing argument; you will get no output
9> }

> What output should we excepted?
> The CC compiler on Sun yield '+', but gcc give a '-'. Which correct?

If this compiled at all, then you have serious problems with your compiler:
At line 5 you are assigning to a constant, which is undoubtedly an error.

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
Newsgroups: comp.lang.c++
From: yho@otto.carleton.ca (Y. Ho(S.Kennedy))
Subject: Fortran_+C+Cplusplus, How to link?
Organization: Carleton University
Date: Thu, 8 Oct 1992 00:27:33 GMT

I have a program written mainly in "C" with some Fortran subroutines.
In sun, they are linking together by "f77 ...". Now I want to add
some C++ functions to this program, if there are no Fortran routines
involved, CC is right command to use, but with Fortran routines, I
do'nt know how to do?

Any ideas?

Yushang
From: alindbac@aut.abb.se (Anders Lindbck)
Newsgroups: comp.lang.c++
Subject: Re: Proposal: Preconditions and PostConditions in C++
Date: 9 Oct 92 09:59:55 GMT
Organization: THHS (krfc) tlps

In article <1992Oct7.185350.8033@walter.bellcore.com> bytor@grumpy.bellcore.com (Ross Huitt) writes:
>In article <1992Oct7.125441.10012@aut.abb.se>, alindbac@aut.abb.se (Anders Lindbck) writes:
>|> In article <Bvq8tF.J3C@fiu.edu> feathers@serss0 (Michael Feathers) writes:
>|> >I advance this idea with some trepidation... (ooh! noo! new language 
>|> >feature!) but has anyone considered adding Eiffel-style pre and post 
>|> >conditions to C++?
>|> 
>|> Yes, and it is rather trivial to do so using macros.
>|> 
>
>No, it is not trivial. It may be trivial for C, but not for C++.
>See the A++ work of Doug Lea and Marshall Cline for details.

I don't think I know that...

>The major problem that prevents macros from being used is inheritance of conditions.
[Example deleted]
>Problem:
>Base::i(int) has specified a precondition. A user is then free to derive a class and redefine
>the method and violate the precondition in a way that is never detected. The user must have
>the discipline to copy the precondition down everytime the method is redefined. In Eiffel,
>at least, pre-post/conditions and class invariants are inherited. 

But is that really a good thing ?

There is nothing that says that a precondition which is valid in a base 
class is a prescondition which must be valid for a derived class. 
A base class may have more restrictions than a derived class 
(and sometimes vice versa but that's not the issue here). 

So to always inherit the pre- and post-conditions may not be a good thing. 

On the other hand one can always question the fact that one has a derived 
class that is more tolerent than a base class; but that's another question. 

>
>There are other problems but, IMNSHO, this is the worst of the lot.
>
>Ross Huitt
>bytor@ctt.bellcore.com
From: edwin@maui.cs.ucla.edu (Edwin Tisdale)
Newsgroups: comp.lang.c++
Subject: The C++ Matrix class
Date: 15 Oct 92 18:09:03 GMT
Organization: UCLA, Computer Science Department

The C++ Matrix class is available via anonymous ftp from `ftp.cs.ucla.edu'.
Get the compressed tarfile `pub/Matrix.tar.Z'.  Uncompress `Matrix.tar.Z'.
Extract the `Matrix' directory from `Matrix.tar'.  Then go to the `Matrix'
directory and type `make'.  Now print and read the paper in `Matrix.dvi'.

In order to demonstrate an application of the \verb"Matrix" class,
it was used to implement the backward error propagation algorithm
for multi-layer, feed-forward artificial neural networks.

Enjoy, Bob Tisdale (edwin@cs.ucla.edu)

P.S.  I hope the following notes will be helpful.

unix% ftp ftp.cs.ucla.edu
Name (ftp.cs.ucla.edu:your_login_ID): anonymous
Password: your_login_ID
ftp> cd pub
ftp> binary
ftp> get Matrix.tar.Z
ftp> bye
unix% uncompress Matrix.tar.Z
unix% tar xvf Matrix.tar
unix% cd Matrix
unix% make
unix% dvips Matrix | lpr
unix% mv ffnet.new ffnet.old
unix% cat ffnet.old ffnet.S | (backprop -v > ffnet.new) >>& ffnet.err
unix% cat ffnet.new ffnet.S | evaluate | graph -m 0 | plot

Note: If you have trouble, verify that the `SYS5' variable
      in the `Matrix/src/genclass' shell script contains
      the path to the System V version of the `m4' macro
      pre-processor.
      The `fig2dev' program is part of the `transfig' package
      available via anonymous ftp from `ftp.cs.cornell.edu'.
      Get `pub/transfig/transfig.tar.Z'.
      The EPIC style file is available via anonymous ftp from
      `ymir.claremont.edu'. Get `tex/inputs/latex-contrib/epic.sty'.
      File `pub/Matrix.sun.tar.Z' includes all the files created by
      `make' on UCLA CSD Sun4 computers.  It may be useful to Sun
      computer users or those who just want to print the documentation.
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: My objects are too big - why?
Date: 16 Oct 92 22:40:41 GMT
Organization: Microsoft Corporation
Distribution: comp

In article <1992Oct16.223226.27023@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
|	char* pc1 = (char*)pc1;
                     ^pf1
Newsgroups: comp.lang.c++
From: brister@decwrl.dec.com (James Brister)
Subject: Re: My objects are too big - why?
Organization: DEC Western Software Lab
	<1992Oct09.141039.18062@watson.ibm.com> <Bvv31E.9rn@apollo.hp.com>
Distribution: comp
Date: 9 Oct 92 11:21:25

On Fri, 9 Oct 1992 15:58:26 GMT, vinoski@apollo.hp.com (Stephen Vinoski) said:

> The Base class is empty, but must have a non-zero size (ARM, chapter
> 9, page 164), so its size is 1.

Why must an empty class have non-zero size? Speculation around here was so
that:

		int foo ;
		base bar ;
		base bat ;


would all have unique addresses.

Thanks

James
--
James Brister                                           brister@wsl.pa.dec.com
DEC Western Software Lab., Palo Alto, CA                        decwrl!brister
Newsgroups: comp.lang.c++
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Proposal: Preconditions and PostConditions in C++
Date: Fri, 09 Oct 1992 16:22:15 GMT
Organization: Security APL, Inc.

In article <1992Oct7.185350.8033@walter.bellcore.com> bytor@grumpy.bellcore.com (Ross Huitt) writes:
> In article <Bvq8tF.J3C@fiu.edu> feathers@serss0 (Michael Feathers) writes:
> >I advance this idea with some trepidation... (ooh! noo! new language
> >feature!) but has anyone considered adding Eiffel-style pre and post
> >conditions to C++?
>
>The major problem that prevents macros from being used is inheritance of
>conditions. ... A user is then free to derive a class and redefine
>the method and violate the precondition in a way that is never detected.

You can get some of what you want by encapsulating the virtual function in a
non-virtual function.  For example:

class A {
    protected: virtual int f();
    public: frient int f(&A a) {
	assert(...); int r = a.f(); assert(...); return r;
    }
}

This guarantees that any public call of f through the A protocol will have
the assertions checked.  It doesn't let you add additional conditions in
subclasses, and subclasses can access the member function directly (and
hence can provide access to same); they can also overload the non-member
function.

I have a strong temptation to do this anyhow, hence avoiding the
member-function syntax whenever possible.
Newsgroups: comp.lang.c++