HDTenEightyP/NetNews huggingface dataset:
From: nwatson@enuxha.eas.asu.edu (Nathan F. Watson)
Subject: Templates, classes, and enumeration types
Organization: Arizona State University
Date: Wed, 26 Aug 1992 07:12:12 GMT

I am trying to write a member function of a class A<T> that will take
an enumerated type argument.  The enumerated type is defined within
A<T> itself.  The code is presented after the discussion.

The question is:  how should I specify the enumerated type?  The inline
version (defined within class definition) of the function works fine
in BC++3.1:

   template <class T> class A
   {
      public:
         enum Aenum { ... };
         void Afunc(Aenum v) { ... }
   }

But no combination I have tried so far works outside the class definition.
The best I can come up with is:

   template <class T> void A<T>::Afunc(A<T>::Aenum v) { ... }

How should I do this?  Is this a BC++3.1 bug?  Thank you from
nwatson@enuxha.eas.asu.edu.

Here is the code:

// ---------- try.cpp (BEGIN CODE)

#include <iostream.h>

#define DO_A 1              // Try class A<T>.
#define DO_B 1              // Try class B (without templates, for comparison).
#define FUNC_INLINE 1       // Inline vs. outline functions.

#if DO_A
template <class T>
class A {                   // Class A<T>.
   public:
      enum Aenum { enum0 = 0, enum1 = 1, enum5 = 5 };
      #if FUNC_INLINE
	 void Afunc(Aenum v)
	    {  cout << (int) v << endl; }
      #else
	 void Afunc(Aenum v);
      #endif
};
#if !FUNC_INLINE
template <class T> void A<T>::Afunc(A<T>::Aenum v)
{
   cout << (int) v << endl;
}
#endif
#endif

#if DO_B
class B                          // Class B -- works fine in all cases.
{                                // Presented for comparison.
   public:
      enum Benum { enum0 = 0, enum1 = 1, enum5 = 5 };
      #if FUNC_INLINE
	 void Bfunc(Benum v)
	    { cout << (int) v << endl; }
      #else
	 void Bfunc(Benum v);
      #endif
};
#if !FUNC_INLINE
void B::Bfunc(B::Benum v)
{
   cout << (int) v << endl;
}
#endif
#endif

int main()
{
   #if DO_A                      // Try A<T>.
   cout << "Doing A" << endl;
   A<int> a;
   a.Afunc(A<int>::enum0);
   a.Afunc(A<int>::enum1);
   a.Afunc(A<int>::enum5);
   #endif
   #if DO_B
   cout << "Doing B" << endl;    // Try B.
   B b;
   b.Bfunc(B::enum0);
   b.Bfunc(B::enum1);
   b.Bfunc(B::enum5);
   #endif
   return 0;
}


--
---------------------------------------------------------------------
Nathan F. Watson                             Arizona State University
nwatson@enuxha.eas.asu.edu                Computer Science Department
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: enum problem.
Organization: TauMetric Corporation
Date: Thu, 27 Aug 1992 18:42:37 GMT

nandraj@unisql.UUCP (Nandraj Arni) writes:


>   I have this problem. Two versions of GNU's compilers are
>acting in different ways. Which is correct?


>class EnumTest {
>public:
>   enum varType { Apple, Orange};
>   varType get_fn();
>}


>varType EnumTest::get_fn() { ... }

>EnumTest::varType EnumTest::get_fn() { ... }

>  Neither compilers like the other definition.


This is an area of language change, and the two compilers implement
different versions of the language.

It used to be that the name of a type declared in a class was
exported to the outer scope.  Now the type name remains local to the
scope, and the name must be qualified when used outside that scope.

If you need to use compilers with different rules, you will
probably have to use some conditional code to keep them both happy.
This gets rather ugly.

A better solution might be to upgrade the earlier compiler.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: swillden@news.ccutah.edu (Shawn Willden)
Subject: Re: BC++ templates broken
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Mon, 31 Aug 92 15:53:13 GMT

I'm replying to my own post.... (Since there has been an odd and somewhat ominous 
silence in response to my first :-)

swillden@news.ccutah.edu (Shawn Willden) writes:
: Hi all,
: 
: 	I have discovered a problem with BC++'s templates.  Given code like
: this:
: 
: 	template<class T> class A1;
: 	template<class T> class A2;
: 	
: 	template<class T> class A { A1* a; A2* b; };

Slight correction here, I meant to say:
	template<class T> class A { A1<T>* a; A2<T>* b;};

: 	template<class T> class A1 : public A<T> {};
: 	template<class T> class A2 : public A<T> {};
: 
: 	main() {A1<int> myA1;}
: [stuff deleted]

gcc-2.2.2 barfs in the same way and apparently for the same reason.  Except that
BC++ does it gracefully whereas gcc has an "Internal compiler error" and dies.
Am I asking something too difficult?  It seems to me that since A contains only 
*pointers* to objects of type A1<T> and A2<T>, that the compiler should be able to 
say "Oh, okay, this is a pointer to a type that has been forward-declared, I'll 
just make the structure N bytes larger to hold a pointer there and go get the next
token," and not *care* what the expansion is.

I think I'm going to take a look at the guts of gcc and see what it would take to
fix it (probably creating another stack of "Templates to expand when I'm done with
my current pile of stuff to do" that will then have to be compared with "Templates
already expanded") but that won't help me with the DOS version (which is the one
that matters).

--
Shawn Willden
swillden@icarus.weber.edu
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.lang.c++
Date: Tue,  1 Sep 1992 02:00:39 -0400 
From: Stefan Monnier <sm86+@andrew.cmu.edu>
Subject: Overloading (method redefining)


Although I'm already used to OOP, I'm new to C++

Whiel experimenting with a silly example, I have a little problem when
I want to redefine a method in a subclass:

class bidon1 {
public:
  void Fonction();
};

void bidon1::Fonction()
{
	// do something not too silly
};

class bidon2: public bidon1 {
  int a,b;
public:
  void Fonction();
};

void bidon2::Fonction()
{
	printf(...,a,b);
};


The loader always teels me: Fonction__8bidon1: multiply defined

I tried to put a 'virtual' in front of void in bidon1,
I tried to put a '-fall-virtual' on the command line (I use G++)
Always the same result!

What do I need (well, maybe I just need a book) ?

	Stefan Monnier


-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 2 Sep 92 15:33:01 GMT

cbarber@bbn.com (Chris Barber) writes:

|Well I must admit that it seems that most people posting on this topic
|say that they do not use gotos, even those who disagree with you. So I
|guess I will just have to come out of the closet and admit that I have
|been using them for several years and with no regrets. I can't recall 
|finding any bugs that were related to my use of gotos and I haven't heard
|any complaints about the readability of my code. In fact, I resent your
|implication that because I use gotos I am lazy and write unstructured
|code. 

Code which uses gotos in a manner which is inconsistent with one of
the 3 control structures of structured programming is not structured.
This does not mean that it doesn't have a structure, of course it
does.  But it does mean that it is not "structured" according to the
tenets of SP.

Are you lazy?  I doubt it.  But you have decided to ignore some of the
lessons of the past.  

[traditional example of error processing eliminated]

There are lots of ways of using gotos which appear relatively benign,
perfectly safe, easy to read, easy to maintain ... at least to the
author.  And, if he gets no complaints, then perhaps he was right.  Or
perhaps he was wrong.  Absence of complaint is not a mandate.

Before "Structured Programming", we all used gotos.  And not all our
programs were maintenance monsters.  Many were quite elegant, well
thought out, flexible and robust.  So what?

We have since learned that writing algorithms that conform to the
principles of structured programming can enhance the robustness and
maintainability of the code.  When you violate those principles, you
take a needless risk.  You may be satisfied that the risk was worth
it, but so what?  You aren't the only one who will be responsible for
your code.  Others will come after, and have to work through the same
reasoning that you did to assure themelves that your "way" is safe.




--
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: pete@genghis.borland.com (Pete Becker)
Newsgroups: comp.lang.c++
Subject: Re: Inherited nested classes?
Date: 31 Aug 92 18:04:12 GMT
Organization: Borland International
Originator: pete@genghis.borland.com

In article <4902@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
>pete@genghis.borland.com (Pete Becker) writes:
>: In article <1992Aug28.164813.51739@evolving.com> jcm@evolving.com (Jack Morrison) writes:
>: >
>: >	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 *public* works, but I 
>: >didn't really want to bother anyone outside the class with the struct type.
>: 
>: [...]
>: The name of a private member "can be used only by member
>: functions and friends of the class in which it is declared."
>: [...] Since struct B is neither a member function
>: nor a friend of class C, it cannot use the name of struct A.
>
>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)...
>
>Are private nested types useful at all, given the current language definition?
>

	I'm not aware of any compiler that enforces the privacy of the name of
B within B.  Agreed, it's a problem in the current wording...
	-- Pete
From: adam@micromuse.co.uk (Adam Kerrison)
Newsgroups: comp.lang.c++
Subject: Stream classes and Inheritance
Date: 25 Aug 92 08:21:49 GMT
Reply-To: adam@micromuse.co.uk
Organization: MicroMuse Ltd, London, UK

Hello there,

I am a bit of a C++ novice. I have developed some applications in C++ but
nothing very involved. I am now  looking at developing a VERY simple
windowing system for DOS. I am not trying to emulate Windows or Desqview but
I am looking at something which gives me output (and possibly input) into 
several text windows.

My idea so for is to use the ostream class and derive a class from it. This 
class would handle output into a window. Thus I can then assign cout 
(or cerr or clog) to one of my window classes and get output into windows - 
does this make sense ???

My question is - which functions in the ostream classes handle the output of
characters from the internal buffer to the screen ? Obviously, to get the effect
I want I will have to overload these functions.

If anybody has any ideas on this please mail me at the address below as I
don't get chance to read this newsgroup all that much ( too busy :-( )

Thanks in advance

Adam
---
==========================================================================
Adam Kerrison                  | Phone : +44 71 352 7774
Technical Support              | Fax   : +44 71 351 7834
MicroMuse Ltd                  | E-mail: adam@micromuse.co.uk
London                         | 
SW10 0RN                       | ==========================================================================
Newsgroups: comp.lang.c++
From: kgorlen@alw.nih.gov (Keith Gorlen)
Subject: Re: Trouble compiling NIH classes
Organization: National Inst. of Health, DCRT, CSL
Date: Wed, 26 Aug 1992 02:46:09 GMT

In article <RJESSE.92Aug22144049@netcom.Netcom.COM>, rjesse@netcom.Netcom.COM (Rick Jesse) writes:
|> In article <1992Aug19.181622.12608@tcsi.com> sriram@tcs.com (Sriram Srinivasah) writes:
|> 
|>    Newsgroups: comp.lang.c++
|>    Path: netcom.com!csus.edu!wupost!uunet!tcsi.com!sriram
|>    From: sriram@tcs.com (Sriram Srinivasah)
|>    Sender: news@tcsi.com
|>    Organization: Teknekron Communications, Inc
|>    Date: Wed, 19 Aug 1992 18:16:22 GMT
|>    Lines: 20
|> 
|> 
|> 
|>    I used Sun's C++ compiler, and also Centerline's cfront 2.1 compatible compiler, 
|>    and get the following error on compiling the NIH classes (the SUN CC version,
|>    from alw.nih.gov)
|> 
|>    CC    -DNESTED_TYPES   -c -I../nihincl Arraychar.c
|>    ./nihclconfig.h: 31: sparc redefined
|>    "./nihclconfig.h", line 279: error: two exact matches for ENV_PC(): unsigned
|> 		  int (const JMP_BUF &) and unsigned int &(JMP_BUF )
|>    "./nihclconfig.h", line 280: error: two exact matches for ENV_SP(): unsigned 
|> 		  int (const JMP_BUF &) and unsigned int &(JMP_BUF )
|>    "./nihclconfig.h", line 281: error: two exact matches for ENV_FP(): unsigned 
|> 		  int (const JMP_BUF &) and unsigned int &(JMP_BUF )
|>    Compilation failed
|> 
|>    Can anyone give me some tips on this?
|> 
|>    Sriram,
|> 
|>    I'm getting the same errors using Sun's cfront 2.1 on a 4/110.  The
|>    problem looks like the ENV_ functions are being overloaded at the
|>    end of nihclconfig.h but the arguments from the previous defintions
|>    of ENV_ in nihclconfig.h (the platform specific ones) have the
|>    same arguments.  I haven't found a solution yet, but I'm posting
|>    to K. Gorlen.  I'll let you know what happens.
|> 
|>    Rick Jesse
|> 
|>  

I just returned from a long vacation and am swamped with work, so I don't have time to investigate this right now.  However, I'll make a wild guess and say you should try compiling without the BUG_48 preprocessor symbol defined.

-- 
Keith Gorlen
National Institutes of Health
Bethesda, MD 20892
Phone: (301) 496-1111
FAX: (301) 402-2867
Internet: kgorlen@alw.nih.gov
Newsgroups: comp.lang.c++
From: oherb@jhunix.hcf.jhu.edu (Zoher B Bambot)
Subject: Re: PD C++ => C translator wanted
Organization: HAC - Johns Hopkins University, Baltimore
Date: Tue, 25 Aug 1992 20:26:45 GMT


I am working on developing classes for simulation of finite element meshes
using the object-oriented language c++. I would be grateful if anyone could
send me any programs in c++ which would help me in my work. Also has anyone 
developed a class for the simulation of a FEM for any particular structure.
You can mail them to me at my e-mail address and then I will summarize in
the net. Also are there any ftp sites from where I could get any useful
information. Thanx in advance.
                         Zoher.
From: nandraj@unisql.UUCP (Nandraj Arni)
Newsgroups: comp.lang.c++
Subject: Protected Derived classes.
Date: 31 Aug 92 23:41:47 GMT
Reply-To: nandraj@unisql.UUCP (Nandraj Arni)
Organization: UniSQL, Inc., Austin, Texas, USA



     I wanted to know why protected derived classes are not disscussed
in ARM and not implemented in our GNU C++ compiler. What I am talking 
about is:

class B { /*...*/ };

class D : protected B { /* ...*/ };

class DD : public D { /* ...*/ };


  I want to use B's functions and data in D and DD but should not visible
outside D and DD. Is this feature implemented in other compilers? Why
ARM doesn't disscuss this?

-- 
*******************************************************************
Nandraj Arni

UniSQL, Inc.                           Voice: 512 343 7372 Ext. 107
9390 Research Blvd.                              Home: 512 794 9386
Kaliedo II			   	          FAX: 512 343 7383
Austin, TX 78759

Email: unisql!nandraj@cs.utexas.edu
*******************************************************************
Newsgroups: comp.lang.c++
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: a few rookie questions about testing for CLASSS membership.
Date: 27 Aug 92 02:09:49 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <1992Aug25.204448.15682@cs.wisc.edu> roth@ordin.cs.wisc.edu (Bill Roth) writes:
>
>I'm a relative rookie to C++, though not to OOP (due to many moons of
>programming in Objective-C).

Learning C++ won't be just a matter of learning new syntax in that case.
C++ is a strongly typed language; Objective-C is not.  There's a tradeoff
in this; C++ will catch many more errors at compile time, but certain
things are more difficult to do.

>1. I have a pointer p to some object. How do I test if p is a member
>of the CLASS a.

There's no builtin way to do this, and programs that depend on the ability
to do so are against the C++ philosophy.  If you must do it (and sometimes
you must) you can add a method that returns the type.

>2. Is there a way to test if p, which is a pointer to an object, can
>test if p can execute method m?

Since C++ is a strongly typed language, your program fails to compile if p
cannot execute method m.

To understand the distinction between the C++ model of types and that of
Smalltalk (which is very close to that of Objective-C), I suggest reading
Chapter 12 of Stroustrup's "The C++ Programming Language, 2nd edition".

I'm not going to tell you that C++'s model is better or worse than that of
Smalltalk.  But it's very different; so much so that you're going to have
to "re-learn" a great deal.




--
Joe Buck	jbuck@ohm.berkeley.edu
From: baden@sys6626.bison.mb.ca (Baden de Bari)
Newsgroups: comp.lang.c++
Subject: OOD programming... Smalltalk vs. TC++
Date: Sun, 30 Aug 92 02:22:49 CST
Organization: system 6626 BBS, Winnipeg MB

 
   Well, I guess that the subject sais it all.  I would like to know 
which would be most versitile for OOD programming.  I also require good 
compatability with external I/O... ie: Serial/Parallel interfacing, etc.
 
        Please reply!
 >>Baden<<


;--- (Baden de Bari) a user of sys6626, running waffle 1.64
;E-mail: baden@sys6626.bison.mb.ca
;system 6626: 63 point west drive, winnipeg manitoba canada R3T 5G8
Newsgroups: comp.lang.c++
From: glw@ioit.uswc.uswest.com (Glenn Williams)
Subject: Re: BC++ 3.1 and 386 code generation
Organization: US WEST Information Technologies
Date: Tue, 1 Sep 1992 15:08:46 GMT

According to the PC Week, August 3, 1992, review of Borland C++, the 386 code is
only related to longs and to uses certain 386 specific instructions not necessarily related to 32-bit addressing.

glenn williams
US WEST
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: complex classes and temporary destruction.
Date: 31 Aug 92 13:16:58 GMT

Aurelius@cup.portal.com (Mark Christian Barnes) writes:

|Andrew Koenig writes:

||
||char* I(char* x) { return x; }
||
||The function I (for identity) just returns its argument, but to make things
||difficult, it is compiled separately.  Now, you would like
||
||char* p = s+t;
||
||to cause the temporary for s+t to stick around as long as p does,
||but what are you going to do about this?
||
||        char* p = I(s+t);
||
||There's no way to know what I() does, so what basis do you have for
||letting the lifetime of p affect that of s+t?

| But Andrew, you have changed the statement completely. The
|temporary 's+t' is no longer even being assigned to 'p'. It is
|constructed as a parameter for function (or macro) 'I'. In this
|case I would suggest that 's+t' is an auto variable with a scope
|limited to 'I'.

| I know that this means that your example will not work under
|this interpretation. Well I don't think it should. The perpetual
|problem of aliasing, to which pointers contribute, should not be
|solved by the compiler. I feel that the programmer should pay
|attention to what he/she is doing.

But, the problem of when to "safely" destroy temporaries is all
wrapped up in how to deal with aliases.  And I disagree that the
compiler should ignore the creation of an alias to a temporary.  It
should at least warn that such aliases are being created.

| In your example, an expression is evaluated and passed
|(on the stack) as the parameter to a function. The function
|'I' returns another value of type pointer to char. There should
|not be any assumption that the parameter and the return value
|have anything in common. You, as the programmer, know that 'I'
|returns the parameter. Therefore, you should also insure that
|any parameters passed to 'I' are of the appropriate storage
|class and scope for the uses that you intend.

Yes, but an alias to the temporary was created before the function was
called.  The expression s+t created a temporary, and its address was
taken (alias created) to be passed into the function.  The compiler
should issue a warning at this point.


--
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: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: the 'standard' complex class
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 27 Aug 1992 07:21:24 GMT

mcgrant@rascals.stanford.edu (Michael C. Grant) writes:

>   Inlining access functions might give
>   the efficiency you need.
>
>Nope, unfortunately that's not true---the way AT&T set things up, that is.
>Their functions pass by value and not by reference, and from examining the
>assembly I can tell you that the efficiency isn't there, even for the
>inlined functions. Of course, when I manually changed appropriate functions
>to accept 'const complex&' instead of 'complex', that improved things a
>lot, but not quite to the point that I'm happy with keeping .re and .im
>private. 
>
>Michael C. Grant

Sounds like you should be blaming your compiler's poor optimization,
not the fact that .re and .im are private. If you have inline set_real()
and set_imag() methods then you should get exactly the same code using
them as using the private members.

Maybe you could post a specific example of some code that would be more
efficient if you could use the private members.

Ah... I see from looking at <complex.h> that set_real() and set_imag()
methods have NOT been provided by AT&T.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c++
From: adk@Warren.MENTORG.COM (Ajay Kamdar)
Subject: istrstream
Organization: Mentor Graphics, Silicon Design Division
Date: Tue, 1 Sep 1992 22:52:59 GMT

Why do istrstream constructors take a char* instead of a const char* ?
This either stops me from reading a formatted input string (which I get
as a const char*) as an istrstream, or compels me to cast away the const
on the string when constructing the istrstream.

Any one knows why? Does the istrstream actually modify the input buffer?

Thanks.

- Ajay

-- 
I speak for none but myself.

Ajay Kamdar                               Email : ajay_kamdar@mentorg.com
Mentor Graphics, IC Group (Warren, NJ)    Phone : (908) 580-0102
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: Inherited nested classes?
Summary: just make them friends
Date: 2 Sep 92 23:32:13 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

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)...

C'mon, let's save the pedantry for the ANSI C++ draft :-).

>Are private nested types useful at all, given the current language definition?

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

	class A {
	   enum E { zero, one, two, three };  // a private type of A
	   class PrivateBuddy; friend PrivateBuddy;
	   class PrivateBuddy {
	      E e;  // E only accessible to A and friends
	      //...
	   };
	public:
	   //...
	};
	// A::PrivateBuddy and A::E only accessible by A

Jamshid Afshar
jamshid@emx.utexas.edu