HDTenEightyP/NetNews huggingface dataset:
Newsgroups: gnu.g++.help
Distribution: world
Followup-To: 
Organization: Monash University
Subject: C++ construtor problem  
Keywords: 


Iam a final year computer science student currently working on a
c++ project.  The problem i have is that when i make my program
i get the following message

ld:
Undefined:
_$_4User
collect: /usr/bin/ld returned 1 exit status
*** Error code 1


i have linked the program to all its components e.g User 
the program  will compile except it wont give executable
permission to the final object code.

	When i change mode the program will complete all its tasks 
	till it finishes at which point it gives a segmentation fault

WHAT I  would like to KNOW is what causes the error is it the User constructor
or is it something else
		example of the constructor is provided below

		User::User(String& user_name,String& password)
{
       	
        person= new Personal;  // simple struct 
        if (!Check_password(user_name, password))
                {
                        cout<<" you bombed" << endl;
                        exit(1);
                        //give an error message and abort
                        
                }


          Finances=new Financial(user_name);     
          History=new Tipping_History(user_name);
}
			
		any assistance would be greatly appreciated

				int401a@mdw045.cc.monash.edu.au
				Dragan Vladicic
From: pkturner@world.std.com (Prescott K Turner)
Newsgroups: comp.lang.c++
Subject: Re: Inherited nested classes?
Date: 7 Sep 92 14:44:46 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <4902@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
> Can struct B use its own name?  After all it is a private name to which
> it has no access (access control applies uniformly to all names,
> including nested types)...

pete@genghis.borland.com (Pete Becker) writes: 
> that's clearly a flaw in the wording, and not the intention of the language.

jamshid@emx.utexas.edu (Jamshid Afshar) writes (also in response to Bengtsson):
> C'mon, let's save the pedantry for the ANSI C++ draft :-).

The point is deeper than pedantry.  Is the flaw a small omission in the
wording, or is the rule "Member functions of a nested class have no special
access to members of an enclosing class" a flaw in itself?

A nested class and all of its member functions must be declared within
the body of the enclosing class, so this rule is not needed to enforce
encapsulation.  A nested class is just as much a part of the class
definition as a member function body, and IMO should have the same access
privileges.

> in those situations where the inner class needs to "know" the
> internals of its enclosing class, make it a friend.

In this way the current rule provides more control by allowing the programmer
to choose which nested classes are friends and have access.  But consider
the fact that ALL member function bodies had access to their class
for 6 years before this became an issue for nested classes, and there
are no requests for a capability to designate certain member functions
not to have access.  This kind of control is just as worthless for nested
classes.

It's the rule which is wrong; Johan Bengtsson has pointed out the rule's
most absurd consequence.
--
Prescott K. Turner, Jr.
13 Burning Tree Rd., Natick, Massachusetts USA
Internet: pkturner@world.std.com
From: esw@po.CWRU.Edu (Eric S. Wallace)
Newsgroups: comp.lang.c++
Subject: virtual destructor warning
Date: 6 Sep 1992 18:09:14 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: thor.ins.cwru.edu


I have some classes in the following relationship:

class ibuf {
public:
  ibuf(int);
  ~ibuf(void) { /* ... */ }
};

class obuf {
public:
  obuf(int);
  ~obuf(void) { /* ... */ }
};

class iobuf : public obuf, public ibuf {
public:
  iobuf(int, int);
};

When compiling with gcc-2.2.2, I get the following warning:

  destructor `ibuf::~ibuf()' non-virtual in relationship `iobuf: ibuf'

The warning occurs for whatever class is listed last in the list of base
classes for iobuf. It was my understanding that if a derived class had no
explicit destructor, a default one would be created that destructed each
base class in the reverse order they appear in the list. Is this not the
case? Why would ibuf::~ibuf have to be virtual?

Thanks in advance,

Eric Wallace
wallace@chezmoto.ai.mit.edu
esw@po.cwru.edu
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Destructors and exit()
Date: 5 Sep 92 14:04:24 GMT

rgp@mpd.tandem.com (Ramon Pantin) writes:

|In article <rmartin.715615353@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
|>main()
|>{
|>  MyClass A;
|>  static MyClass B;
|>
|>  exit();
|>}
|>
|>
|>The destructor for B should be invoked.  But the destructor for A
|>probably will not.  I say probably, because a clever compiler might be
|>able to figure out that, upon exit, the enclosing stack frames should
|>be destroyed.

|IMHO, it would be incorrect for a compiler to "know" anything about
|exit (exit is part of the C library, not part of the language, "exit"
|is not a keyword).  A call to the exit function has never triggered
|destructions of automatic objects and should never do.  The block where
|the object was constructed is not being exited when the exit function
|is called so it is incorrect to destroy the object. 

In general I agree with this. But I have seen compilers which have
taken such liberties.  

--
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: boehm@parc.xerox.com (Hans Boehm)
Subject: Re: Garbage Collection for C++
Organization: Xerox PARC
Date: 31 Aug 92 17:22:55 GMT

tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
>To inject some real-world data again, fragmentation can be a problem.
>I have a machine with about 200M swap space, and a program that only
>needed about half that much memory ran out of memory because of
>fragmentation.

Could you give more details as to which allocator this was?  Even
with nonmoving allocators, there is a lot of variation as to how
much fragmentation they introduce.
As I've said before, we have yet to see this sort of ratio
with an allocator that coalesces large objects, and coalesces small objects
if an entire page is free.  And I have seen significant fragmentation
primarily in situations (multiple very large object allocations) in
which moving collection would have been expensive.
Of course, your application may have been different from mine ...

But it certainly is the case that if you can move objects, you have some
hope of obtaining a provable upper bound on space consumption, something
you're unlikely to be able to do with either malloc/free or a nonmoving
collector.

Hans-J. Boehm
(boehm@parc.xerox.com)
From: hines@cme.nist.gov (Lynnwood Hines - pdes)
Newsgroups: comp.lang.c++
Subject: Looking for AT&T C++ info
Date: 15 Sep 92 18:30:01 GMT
Distribution: comp.lang.c++
Organization: National Institute of Standards and Technology


I am trying to get information on who to talk to about aquiring
AT&T's C++ product for various platforms (RS/6000,
HP9000/700,DECstations, and Sparcstations.  I hope this is 
the appropriate place to ask this question; none of the other
newsgroups looked remotely appropriate.

Any and all information will be greatly appreciated!

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
! Lynwood E. Hines                    [] e-mail: hines@trc.scra.org       !
! SCRA                                []         hines@cme.nist.gov       !
! Advanced Technology Group           [] Voice : (803) 760-3488           !
! 5300 International Blvd.            []                                  !
! N. Charleston, SC  29418            []                                  !
!~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~!
! "And so, the littlest giant's heart was filled with blood..." -- Stimpy !
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Newsgroups: comp.lang.c++
From: rogers@eagle (Bill Rogers)
Subject: Wanted:C++ library for report generation
X-Newsreader: Tin 1.1 PL4
Organization: Sangamon State University
Date: Tue, 15 Sep 1992 03:13:35 GMT

Anybody know of a decent report generator class for C++. I've got a
nifty database program, but I programming by the hour and don't really
feel good about charging to invent the wheel. I would really like to
drop in a class that I could pass some descriptors and data records
and produce sharp reports. PD or Commerical, I'll pay.
Thanks,
Bill

--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<> Bill Rogers, Assistant Director for Academic Computing Services          <>
<>              Sangamon State University, HSB-115                          <>
<>              Springfield, Il 62794-9243     fax:217-786-7188             <>  
<> Internet:rogers@eagle.sangamon.edu        voice:217-786-7352(Mon.->Thur.)<>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
From: pveltkam@ems.cdc.com (Paula Veltkamp)
Newsgroups: comp.lang.c++
Subject: c++ compiler
Date: 8 Sep 92 22:53:50 GMT
Reply-To: pveltkam@ems.cdc.com
Organization: Empros Systems International, a division of CDC

Hi,

  I would like to buy the software to run C++ on my 486 IBM compatible
  PC.  I've seen Borland and Turbo C++ out there.

  Any suggestions on what's the best version to buy ?

  Thanks,
   Paula
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Novice question
Organization: TauMetric Corporation
Date: Tue, 8 Sep 1992 16:35:41 GMT

J.March@lut.ac.uk writes:

>I'm getting quite few "warning: assignment to this (anachronism)" messages
>from my compiler.  I do actually want to do this, so how do I let my
>compiler know that I *really* mean it.

It is not legal to assign to "this", and you really DON'T want to do it.

The original version of C++ allowed assignment to "this" to permit a
class to do its own memory management.  This technique was very unsafe,
and subject to errors that were easy to make but very hard to find.

In 1989, C++ introduced overloading "new" and "delete" to allow a class
to do its own memory management.  This is much safer than the older
technique.  At the same time, assignment to "this" was made obsolescent.

Modern C++ compilers no longer support assignment to "this", since
there is no valid reason to want to do it.  Programmers who want to 
assign to "this" generally have a misunderstanding about what the
effect would be if it were allowed.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: zero-length datatype
Date: 13 Sep 92 15:19:04 GMT
Reply-To: ark@alice.UUCP ()
Distribution: comp
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <TMB.92Sep12212903@arolla.idiap.ch> tmb@idiap.ch writes:

> Well, it might be good to remain compatible, in the sense that every
> object that has non-zero size in ISO C also have a non-zero size in
> C++. However, since there are no objects of type "void" (or of some
> other, newly introduced, distinguished type with zero size) in ISO C,
> there can't be any harm in letting objects of this new type have zero
> size: the behavior of existing code would not be affected.

That is not quite true, especially in the presence of templates.

I expect that there will be some committee members who will say
that they want to be able to assume that objects of any type at all
are nonzero in size and admitting a new empty type would violate
that assumption.  And indeed it might even affect old C code, if that
code uses a type that is macro-expanded into something not known until
the code is actually compiled.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: Help on delete
Organization: University of Illinois at Urbana-Champaign
Date: Thu, 10 Sep 1992 14:42:02 GMT

In <etxolpn.716117347@beppe> etxolpn@beppe.ericsson.se (Ola Persson) writes:

>Hello world!

>Suppose

>	char *temp = new char[10];

>will 
>	delete temp;

>do as freeing or is

>	delete []temp;

>necessary ?

*****>	delete[].  See ARM, pp. 64-65.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: Neelakantan Sundaresan <nsundare@silver.ucs.indiana.edu>
Subject: Another one on friends of templates
Organization: Indiana University
Date: Mon, 14 Sep 1992 22:47:40 GMT
X-Mailer: ELM [version 2.3 PL11]


on CC,
The following would work...
--------
class X {
private:
       enum {a=100};
       int i;
       friend class Y;
     };
class Y { int v[X::a];
          f(X *x) { return x->i;};};
-----------

But this one wouldnot...
----------
template <class templ> class T {
 public:
      T() {};
 private:
      friend class C;
      int l;
};
class W { public: W(){};};
typedef T<W> neel;

class C 
{
  dummy(neel *c) { return c->l;};
                          ^^^ access to private member of T<W>?
  public: C() { };
};
------------

any clues?
thanks
neel.
Newsgroups: comp.lang.c++
From: sdm@cs.brown.edu (Scott Meyers)
Subject: Re: inline virtual functions
Organization: Brown University Department of Computer Science
Date: Tue, 15 Sep 1992 15:10:14 GMT

In article <9226000.11363@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
| I just tested cfront 1.2.1, cfront 2.0, g++ 1.37.2, and g++ 2.2.2.
| All of these except cfront 1.2.1 can successfully inline "inline virtual"
| functions. Perhaps you made some mistake?
| 
| Here's the code I used:
| 
| 	extern void ggggg();	// "ggggg" easy to find in the assembly output
| 
| 	class A {
| 	public:
| 		inline virtual void fffff() { ggggg(); }
| 	};
| 
| 	void foo() {
| 		A a;
| 		A& b = a;
| 		a.fffff();	// this gets inlined
| 		b.fffff();	// this doesn't :-(
| 	}

Note first that a.fffff() is not a virtual call -- only calls for pointers
and references invoke the virtual mechanism.  That's why the call from a is
inlined and the call from b is not.  Furthermore, running nm on the .o file
from this source (after compiling with cfront 3.0.1) yields:

    000000b0 D ___ptbl_vec__fjh_C_foo_
    00000098 D ___vtbl__1A__fjh_C
    00000074 t _fffff__1AFv            // note static copy of A::fffff here
    00000000 T _foo__Fv
             U _ggggg__Fv

This static copy will remain even if you eliminate BOTH calls to fffff.

| >This is a pity, because it's the kind of rule that is easy to
| >remember, hence people will continue to follow it even when C++ compilers
| >become agressive enough in their optimization to be able to generate
| >inlined calls to virtual functions.
| 
| Compilers are already that aggressive.

Only in my dreams.

Scott

-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: pointer to member function.
Organization: TauMetric Corporation
Date: Sat, 5 Sep 1992 16:43:03 GMT

dlb@unixland.natick.ma.us (David L. Briggs) writes:

>	A simple question.  If you have a class that has several functions
>with the same name that are overloaded, how can you take the address of one
>of these function?

You have to take the address in a context where the desired function
type is specified.  You normally take the address so as to assign it
to a pointer-to-member-function, or to pass to a function parameter of
that type.  Type matching resolves the ambiguity if possible.

class X {
public:
	int foo(int);
	int foo(double);
	int foo(int, int);
};

int (X::*p1)(int)	= &X::foo; // foo(int)
int (X::*p2)(double)	= &X::foo; // foo(double)
int (X::*p3)(int,int)	= &X::foo; // foo(int, int)
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: elice@hpcuhe.cup.hp.com (Elice Yung)
Date: Wed, 9 Sep 1992 16:27:56 GMT
Subject: Re: C++ Task Library for HP 700
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.lang.c++


> Has anyone successfully used the C++ Task Library on HP 700's (PA-RISC)?
> The library and documentation are present, but whenever I try to use it,
> it crashes the workstation!  We're running HP-UX Version 8.07.

  Customers have been using the USL Task Library on HP S700 successfully. 
  I would like to investigate your problem. Please send sources 
  to me via email at elice@cup.hp.com. 
  
Newsgroups: comp.lang.c++
From: arthur%Solomon.Technet.sg (Arthur Sombrito)
Subject: BC++ Librarian bug?
Organization: National University of Singapore
X-Newsreader: Tin 1.1 PL5
Date: Wed, 9 Sep 1992 03:38:34 GMT

I'd like to know if there is a bug in the Borland C++'s librarian regarding
function name overloading.  We are trying to port our library into the DOS
environment and we get a function name clash message.

Thanks for any help.


Newsgroups: comp.lang.c++
From: suresh@argon.iss.nus.sg (Suresh Thennarangam - Research Scholar)
Subject: Problems with dbx & C++
Originator: suresh@argon
Organization: Institute of Systems Science, NUS, Singapore
Date: Thu, 10 Sep 1992 03:39:20 GMT

I am using Cfront 2.0 on the Sun4 platform and debugging with
the enhanced dbx debugger. The debugger seems to have some
problem resolving names of functions declared as < extern "C" >.
Is it because it demangles all function names and comes a cropper
with symbols declared as  < extern "C" > because it didn't mangle
them in the first place ?  

It comes up with warnings like 
:
warning: Couldn't translate C++ name "AdjustGraph"; .stab ":ZtF"
:


where AdjustGraph is coded as 

extern "C" {

void AdjustGraph(void) { ........}
:
:
}

Help someone ? How do I solve this problem ? I am not able to step
through any function I have declared such.  Please send me direct
mail as well if possible.

      __
     (_       o_   o  o |_
     __)/(_( _) (_(_ /_)| )_


***************************************************************************
* Suresh Thennarangam               *  EMail: suresh@iss.nus.sg(Internet) *
* Research Scholar                  *         ISSST@NUSVM.BITNET          *
* Institute Of Systems Science      *  Tel:  (065) 772 2588.              *
* National University Of Singapore  *  Facs.: (065) 778 2571          *
* Heng Mui Keng Terrace             *  Telex: ISSNUS RS 39988             *
* Singapore 0511.                   *                                     *
***************************************************************************
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 10 Sep 92 23:59:28 GMT

mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:

|In <rmartin.715527587@thor> rmartin@thor.Rational.COM (Bob Martin) writes:

|>The principles of structured programming were an important advance in
|>the science of software engineering.  Those principles are still valid
|>today as a guide to structure the implementation of our methods.   We
|>should not forget them, and if they are in question, then we should
|>discuss them.

|There!  You used the key word.  GUIDE.  Not "hard and fast rule".  Not
|"cast in concrete, GOTO is the ultimate evil".  GUIDE.

|Now if only the rest of your notes reflected that use of the word
|'guide', rather than treating structured programming as if it was
|carved on stone tablets and handed down from the mountain.

I have repeatedly stated that physical need outweighs design
principles.  If you must use gotos, or global variables, or any of the
other evils of software, in order to fulfill the requirements, then
do so, and without hesitation.

--
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: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Subject: Re: defining cast operators outside classes
Reply-To: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Organization: University of Virginia
Date: Mon, 7 Sep 1992 15:41:25 GMT

tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
: Apparently, it is impossible to define a conversion operator for a
: class without making the conversion operator a member function.
: 
: It would be very useful to be able to define something like the
: following without having to modify either class MyMatrix or class
: TheirMatrix:
: 
: 	operator MyMatrix(TheirMatrix &m) {
: 		...
: 	}
: 
: Why was this seemingly arbitrary restriction made? Can it be
: eliminated in the next version of C++?

You can achieve what you want by providing a constructor in your
MyMatrix class that takes a reference to TheirMatrix as its
argument. For example,

class MyMatrix {
	...
public:
	MyMatrix(const TheirMatrix& m) {
		//convert TheirMatrix into MyMatrix
	}
	...
};

void f(const MyMatrix& m) {...}

main()
{
	TheirMatrix	tm(10,10);
	MyMatrix	mm = tm;
	...
	f(tm);
}

-Sekar
Newsgroups: comp.lang.c++
From: jjf@peewee.enet.dec.com (John J. Franey)
Subject: NIHCL on PC (Borland C++) Query???
Reply-To: jjf@peewee.enet.dec.com (John J. Franey)
Organization: Digital Equipment Corporation
Date: Fri, 11 Sep 92 13:26:46 GMT


Is NIHCL available for PC?  Where? or Who?

If not, has anyone done the tedious work of extracting portable
	classes from NIHCL?  And then using them on the PC?

Thanks
Newsgroups: comp.lang.c++
From: potts@itl.itd.umich.edu (Paul Potts)
Subject: Re: GOTO, was: Tiny proposal for na
Organization: Instructional Technology Laboratory, University of Michigan
Date: Tue, 8 Sep 1992 13:45:01 GMT

In article <1992Aug31.170908.13389@us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>...
>
>Apparently most of the responses have been in favor of using break.  Do I
>conclude that most programmers just don't care about having correct programs?

I have been to several talks on the formal verification of programs - it
still strikes me that for anything more complex than a basic academic
exercise, it is pointless to attempt such a thing. I agree that it is in
principle a good idea, expecially, for example, in software used in medical
devices where an error can be life-threatening. But I am writing code that
runs under DOS on some arbitrary system, using a class library I didn't write -
what possible concern could I have for formally verifying my program?

I try to make my code as legible as possible, and try to keep the structure
as simple as is practicable; I examine my loop invariants, attempt to test
with a range of possible values, check error codes, and while debugging use
"assert" tests;  but I also will use GOTO on those occasions when it can
enhance my code, and break. I'm not writing a textbook, I'm writing a program,
and the real world isn't so ideal as to allow me to argue that my program
is formally correct (other than letting me mention in passing that the
compiler doesn't seem to complain).

One man's opinion... can we put this debate to bed soon?

>--
>James Kanze                            GABI Software, Sarl.
>email: kanze@us-es.sel.de              8 rue du Faisan
>                                       67000 Strasbourg
>                                       France


-- 
"...remove protective cap. Hold atomizer with thumb at base and nozzle 
between first and second fingers. Without tilting head, insert nozzle into 
nostril. Fully depress rim with a firm, even stroke and sniff deeply."
-advice for presidential candidates from Paul Potts - potts@itl.itd.umich.edu
Newsgroups: comp.lang.c++