HDTenEightyP/NetNews huggingface dataset:
From: pete@cssc-syd.tansu.com.au (Peter Alexander Merel)
Subject: Re: Templates parameterized on templates (!)
Organization: AOTC - CSSC
Date: Tue, 24 Nov 1992 03:03:58 GMT

frank@Cookie.secapl.com (Frank Adams) writes:
>pete@cssc-syd.tansu.com.au (Peter Alexander Merel) writes:
>>template<template Container, class T>
>>class troppo
>>:
>>    public Container<T>
>>{
>>    ...
>>};
>>
>I'm not up on whether real live 3.0 compilers will do this

>They don't, and I think they should, too.  But the first line should
>probably be either:
>
>template<template<class> Container, class T>
>or
>template<template Container<class>, class T>

You're right - there's not much checking the compiler can do at the template
level, but at least it can see that we've got the right number of arguments.

>In the mean time, you can write:
>template<class Container, class T>
>
>with the assertion that the template will only work if Container is a
>container class whose element type is T.

I'm after something more powerful than this. The containers in the OSE class
library all have different interfaces - there are maps, sets, lists, and all
manner of whatnot, all (well, most, but for my purposes all) based on a
class that will return an iterator and do a number of useful common services.

I want to make available this variety of templated containers from within a 
value-added template of mine. If templates cannot be parameterised on 
templates, then I am forced to write a dozen or so templates to do this, one 
for each templated container type. 

If templates could be parameterised on other templates then I could accomplish
this with just a single template, and of course this template would be
extensible as OSE evolves ... which sounds like the finest kind of interface
to me.

-- 
Internet: pete@cssc-syd.tansu.com.au   UUCP: {uunet,mcvax}!munnari!cssc-syd!pete
Snail: 1/18-20 Orion Road, Lane Cove NSW 2066 Australia    Phone: +61 2 911 3130
I am a big pond in a small fish.
Newsgroups: comp.lang.c++
From: mbersohn@alchemy.chem.utoronto.ca (M. Bersohn)
Subject: RUN TIME ARRAY INDEX ERRORS
Organization: University of Toronto Chemistry Department
Date: Thu, 19 Nov 1992 10:22:58 GMT

Hello experienced people!
     There seem to be two ways to detect array index errors at
run time. One is to explicitly check the index.
int x[20];

if (j >= 0 && j < 20 && function1(x[j]))
    ...
     The other way is the C++ way,to overload the [] operator.
     Explicit checks clutter the code enormously. The operator
overloading method is transparent to us unless we remember the
class definition. It's neat.
     My question to ask you is this: How did C survive all these
years without such an obviously essential feature? How was
anybody able to construct programs of 100,000 plus lines of C
that worked well,without this feature? I'm a naive programmer;
there is some magic there that escapes me.
     BTW using pointers to the array doesn't help. We still
have to check the value of the offset.
     Thanks in advance for somebody's enlightened comment.
Malcolm Bersohn
mbersohn@alchemy.chem.utoronto.ca
Newsgroups: comp.lang.c++
From: wws@iscp.bellcore.com (Wayne Scott)
Subject: DEC's C++ compiler on the Alpha
Organization: Bellcore
Distribution: usa
Date: Fri, 20 Nov 92 00:16:19 GMT
Keywords: anyone using it yet?

I haven't read this group for a while and there are 642 articles in front of me.
Forgive me if the answer lies ahead.

We've just gotten some DEC Alpha processors and a Beta version of their 
C++ compiler.  Several folks are leary of my intentions to use it.  Before I do,
I just wanna' ask if anyone else out there is using it yet, and if there are any
known bugs that I should know about.

Thank you,
Wayne Scott

Newsgroups: comp.lang.c++,comp.std.c++
From: xjzhu@math.uwaterloo.ca (Xiaojun Zhu)
Subject: Can A<S> and A<S, T> coexist ?
Keywords: template, different number of arguments
Organization: University of Waterloo
Date: Tue, 24 Nov 1992 04:06:45 GMT

Q: Can A<S> and A<S, T> coexist?

I.e., is the following declaration valid?

template<class S> class A{};
template<class S, class T> class A{};

AT&T C++ V3.0 fails on comipling the above code. 

As I see it, since the two A's are accepting different number of arguments,
there is no reason why such thing should not be allowed.

Any comments?



--------------------------------------------------------------
   A template version of my signature class is under repair.
Symptom: It dies without a warning if I use certain class 
         as an argument.
         
                                       xjzhu@math.uwaterloo.ca
--------------------------------------------------------------
From: matt@centerline.com (Matt Landau)
Newsgroups: comp.lang.c++
Subject: Re: Multiple Inheritance - Necessary?
Date: 23 Nov 1992 17:57:15 GMT
Organization: CenterLine Software, Inc.
NNTP-Posting-Host: 140.239.1.32

In <1992Nov23.073400.119@news2.cis.umn.edu> burchard@horizon.math.utah.edu (Paul Burchard) writes:
>Organizing "can-do" properties of classes is most appropriately done through
>formal message protocols rather than inheritance (even the looser "forest"
>model of inheritance).  Of course this requires dynamic binding.

Yes, but the original discussion question was "Is multiple inheritance 
necessary?" ... the answer is "For certain kinds of operations, yes, at 
least if you're programming in in C++."

>Only if the common functionality has significant common code does it make
>sense to use multiple inheritance to *implement* the protocol.

That depends on whether the goal is inheritance of interface or inheritance
of implementation.  In the "MI defines mixin attributes" model, the "common
functionality" may not involve ANY common code, which is fine because all
you want to inherit is the interface.

When writing operator== for a slew of different classes, all of which you 
wish to endow with the attribute of collectability, it's perfectly possible 
(in fact, it's very common) for the implementations of X::operator== to be 
completely different for every X.  Inheriting from a Collectble class that
defines a pure virtual operator== simply serves to *force* every derived
class to implement the interfaces requires for collectability.  

In the extreme case (which is the one I most often use), the attribute
base class contains *no* code whatsoever -- just a bunch of pure virtual
functions.  There are certainly other implementation strategies available
in other languages, but this is C++ we're talking about here.
--
 Matt Landau			Waiting for a flash of enlightenment
 matt@centerline.com			  in all this blood and thunder
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Overload operator to concatenate Strings?
Date: 17 Nov 92 01:07:44 GMT
Organization: Microsoft Corporation

In article <1992Nov13.111415.1@happy.colorado.edu> srheintze@happy.colorado.edu writes:
|I have considered using operator|| but Plum and Saks discourage it for reasons
|I don't completely understand.  It is intuitive to old PL/I programmers to use
|operator|| for character string concantenation. It seems logical to be
|consistent with something that already exists rather than invent some new
|notation.  

If your target audience is old PL/I programmers, then use the || notation.

If your target audience is C++ programmers, then use + since that is the 
most common operator chosen to mean string cat in the C++ world.  
If you're writing an overloaded I/O operator use << and >> like iostreams 
-- these choices don't have to make much sense -- they've become established 
by convention.  If you try to rethunk them now, you'll just be making
your work gratuitously incompatible.  Then again, why not get an 
existing class library with an existing string class?  Why keep reinventing
the [square] wheel?

Newsgroups: comp.lang.c++
From: ort@netcom.com (David Oertel)
Subject: Re: Is Ctor X() required for the object of class X to be able to be dynamically allocated?
Summary: Re: Is Ctor X() required for dynamic allocation
Keywords: constructor X(), dynamic allocation
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 20 Nov 1992 08:06:26 GMT



>>In article <BxxC3p.Btn@math.uwaterloo.ca> xjzhu@math.uwaterloo.ca (Xiaojun Zhu) writes:
>>Q: Is it necessary to have a constructor which took no argument in order
>>   for the object of a class to be able to be dynamically allocated?
>>
>>More specifically,  I have a class X, when I can say
>>
>>X *x=new X[10] ?
>>
>>Is it required that class X have a constructor X()?
>>
>I can't cite chapter and verse, but such a constructor is required to
>create arrays of objects.

	This is wrong, the compiler should automatically generate the 
	default constructor as well as the copy constructor, the assignment
	operator, and the address-of operators, if you don't explicitly
	specify them.

	ort@netcom.com
--
From: beery@clipper.cis.ohio-state.edu (brian david beery)
Newsgroups: comp.lang.c++
Subject: Simple question: class objects & pointers
Date: 16 Nov 92 16:21:30 GMT
Article-I.D.: cis.1992Nov16.162130.11475
Organization: The Ohio State University Dept. of Computer and Info. Science

I am new to C++, and have a question regarding pointers and class objects:
The following code:
class cl_object
{public:
  int value;
}
generic_function(cl_object *o)
{
  *o.value=0;
}; 

causes an error message, to the effect that the right side of the '.' must
be a structure.  (I am using Borland C++, if that matters.)  How do I access
member data of an object referenced by a pointer?
                           
                                 Thanks in advance,
                                   Brian D. Beery
                                   Ohio State University
           
Newsgroups: comp.lang.c++,comp.os.ms-windows.programmer.misc
From: u8123033@cc.nctu.edu.tw ()
Subject: gcc in info-mac/lang/ ?
Organization: National Chiao Tung University
X-Newsreader: TIN [version 1.1 PL6]
Date: Sat, 21 Nov 1992 13:24:35 GMT

Hello all,

     Sorry to bother. I'd like to know that what are the files
/info-mac/lang/gcc-137-part?.hqx on sumex-aim.stanford.edu ?

     Are they gcc implement for Macintosh? Looking up available
data, I don't see such an implement for Mac(although I'm glad to 
know there is one). After downloading them, none of them is able
to be extracted by my CompactPro.

     But if not, why are they put in info-mac directory?

     Well, please reply if you have any comments about those files.
Actually I do hope someone to tell me "You were wrong, man. There
IS a gcc for Macintosh, and your CompactPro just need to be upgraded!" :)

     See ya!

                       Paladin Mu, u8123033@cc.nctu.edu.tw
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Calling pure virtual functions in base class constructor
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 19 Nov 1992 17:08:10 GMT

In article <721505557snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk writes:
>
>Sorry about the length of this posting, but I really would like to 
>understand the reasons for all this :-)

	I suspect it is a quirk. To ban or not to ban a body for
a pure virtual? Bjarne chose to allow them. I now see and accept that
apart from some unrelated meaning for the body, some 'default' behaviour
or, better, 'core' behaviour might well be a good use.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Subject: Re: Should I use a generic object which all others inherit f
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.20 $
Organization: Trumphurst Ltd.
Date: Thu, 19 Nov 1992 12:24:40 +0000

In article <1992Nov17.190821.18348@informix.com> cshaver@informix.com (Craig Shaver) writes:
> In article <3762@news.cerf.net> hlf@nic.cerf.net (Howard Ferguson) writes:
> >I am working on the early stages of design on an embedded C++
> >project. One of the decisions which we will have to make in the
> >near future is whether to make all of the objects inherit from 
> >onie generic object at the top of the tree or to go for the forest 
> >approach. 
> 
> An embedded system!  C++!?  JUST USE C!!!!
> 
> UNLESS ....
> 
> You have some of the benefits of OOP in mind, such as inheritance, reuse, 
> and information hiding.  Then if you are willing to take small dings in
> performance go all the way and use the tree approach as pioneered by
> Smalltalk.  I recently saw a review of the toy code that comes with the
> borland compiler.  The article's author commented that the tree type
> libraries were "passe" because of templates.  What a stupid thing to say!
I agree with that author, not with you !

> One of the big wins of OOP is reuse.  By using an inheritance structure
> you can reuse existing code and do incremental development.  Related and
> unrelated classes can be used in the same context where a similar protocol
> is enforced.  
> 
> I have to think some of the people involved with C++ have no idea what the
> basis of OOP really is.  They are simply using C++ as an improved C.
True. However, many people involved with C++ have no idea of the 
usefulness of static type checking, the simply pervert C++ to be a faster 
Smalltalk :-)

-- 
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Making qsort type-safe
Date: 17 Nov 92 01:21:56 GMT
Organization: Microsoft Corporation
Keywords: sorting, templates, qsort

In article <1992Nov13.215612.7145@netcom.com> mdr@netcom.com (Marc D. Rossner) writes:
|Can you think of a good example of this?  I realize that COPYING an objects
|bits may be insufficient for making a conceptually independent copy, but I
|can't think why swapping the bits of two objects would not leave the two 
|objects physically and conceptually swapped.

A common object-model conceptualization [whether the C++ programmer 
realizes it or not] is that the identity of an object is represented
by its address.  In which case swapping the bits of the objects exchanges
their values, but not their identity.  In which case they remain conceptually
unswapped.

If Fred is on my left and Bart is on my right and I pick the contents  
of their wallets and swap them, Fred remains on my left, and Bart remains
on my right.  Of course, IF I ask Fred who he is, and ask Bart who he is,
and they each look in their wallets for their IDs and reply "Bart" and
"Fred" respectively, THEN perhaps you can argue that conceptually they
*have* been swapped.  In which case you are conceptualizing an object's
identity to be its surrogate, not its address.   See "Mostly Harmless" 
Newsgroups: comp.lang.c++
From: hansen@deci.cs.umn.edu (David M. Hansen)
Subject: Re: Is Ctor X() required for the object of class X to be able to be dynamically allocated?
Keywords: constructor X(), dynamic allocation
Organization: University of Minnesota
Date: Fri, 20 Nov 1992 15:21:31 GMT

In article <1992Nov19.191043.18010@bellahs.com>, jjamison@bellahs.com (John Jamison RD AC) writes:
|> In article <BxxC3p.Btn@math.uwaterloo.ca> xjzhu@math.uwaterloo.ca (Xiaojun Zhu) writes:
|> >Q: Is it necessary to have a constructor which took no argument in order
|> >   for the object of a class to be able to be dynamically allocated?
|> >
|> >More specifically,  I have a class X, when I can say
|> >
|> >X *x=new X[10] ?
|> >
|> >Is it required that class X have a constructor X()?
|> >
|> I can't cite chapter and verse, but such a constructor is required to
|> create arrays of objects.

From the ARM...

Chapter: 5.3.3 (p 61)
Verse: "Arrays of objects of a class with constructors can be created by 
operator new only if the class has a default constructor"

and from 12.1, p 264: "A default constructor for a class X is a constructor
of class X that can be called without an argument."

Two points: A default constructor is needed only if your class already 
has constructors, and the default constructor need not take the form X::X(),
but something along the lines of X::X(int i=0) is also acceptable, because
that constructor may be called without an argument.

					-=Dave
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Interobject member function calls while in construction
Organization: Rational
Date: Fri, 20 Nov 1992 16:53:31 GMT

warlok@rhps.chi.il.us (Jon L Fincher) writes:

|So, now the situation is this - I have a member function
|screen::init() constructing a window.  window::window() calls other
|owned member functions (not a problem, right?) and some functions
|in screen (again, not a problem?). However, some member functions
|in screen call window member functions, which has, at this time,
|not finished instantiation.

There are two dangers inherent in this kind of situation.  First,
Screen may be calling virtual function in Window.  Virtual deployment
will not dispatch the function lower than the currently executing
constructor.  Thus you may not get the function you expect.  Worse, if
the virtual function is pure, the system will probably abort, since it
is a fatal runtime error to call a pure virtual function.

So take care.  You may wish to create Window::init() functions which
do all the initialization work after the window has been constructed.


--
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: rene@hamel.uucp (Rene Mueller)
Subject: Re: g++ debugger?
Organization: Free University of Berlin, Germany
Distribution: comp.lang.c++
Date: Tue, 24 Nov 1992 01:08:21 GMT

In article <ROBC.92Nov23124503@rocket.sanders.lockheed.com>, robc@rocket.sanders.lockheed.com (Rob Costantino) writes:
|> What do g++ users use for debuggers?
|> 
|> I have been developing code in C on a Sparc using gnus gcc for the
|> compiler and CodeCenter (CenterLine) for a debugger.  I am starting to
|> use c++, so naturally when to gnu g++.  I found that the object files
|> are not compatible with ObjectCenter (CenterLine) due to the different
|> name mangling schemes.  So, what do g++ users use for debuggers?
|> 
|> Rob Costantino		phone: 603/885-7414
|> 			email: robc@rocket.sanders.com
Depending wether you're using X11 or not:
xgdbx or gdbx...

	rene@math.fu-berlin.de
From: philbo@arasta.UUCP (Phillip Lindsay)
Newsgroups: comp.lang.c++
Subject: Re: comp.lang.c++
Keywords: comp.lang.c++
Date: Sun, 22 Nov 92 23:10:04 PST
Distribution: world
Organization: Phillip Lindsay, Tustin CA

njs@planet.bt.co.uk writes:
> The ideas presented below - or some close form of them - have my definite vote
> 
> Nathan
> 
> |> I Also vote for a hierachy (if someone invents one)
> |> 
> |> i.e. 
> |> 	comp. lang. c++.  std	  (discusion on standard (old comp.std.c++)
> |> 			. advocay (discusion on new isues)
> |> 			. problems (bugs, code, problems)
> |> 			. tools    (tools ..., porting,)
> |> 			. source... 
> |> 			. don't_know_anmore_idea. bye.bye
> |> 
> |> ciao vincent@datmuc.dat.de

I spend most of my time hitting 'n'
Something needs to organize the traffic...adding at least a newuser
group would help (we can filter cross posts).

--
Phillip Lindsay "Government for the Politicians."
INTERNET: 75230,300@compuserve.com ** UUCP: uunet!zardox!dhw68k!arasta!philbo
Phone: 714-385-2311 ** USMAIL: 2955 Champion Way, #175, Tustin, Ca. 92680
Newsgroups: comp.lang.c++,comp.std.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Proposal - enhancement for switch statement.
Organization: Computer Science, University of Melbourne, Australia
Date: Mon, 23 Nov 1992 00:14:18 GMT

mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:

>Removing the need for break between case clauses is a bad idea -
>the need to avoid fallthrough is better handled by a compiler warning.

The difficulty with this is that there has to be a standard way to
prevent the compiler warning in cases where the fallthrough is
deliberate rather than accidental. Because there isn't, the compiler
warning would wrong more times than not, and so most compilers don't
seem to include such a warning.

Perhaps a good way to indicate that the fallthrough is deliberate would be to
use an explicit goto.

	switch(x) {
		case 1:
			...
			break;
		case 2:
			...
			goto case_3:	/* fall through */
		case_3:
		case 3:
			...
	}

Any half-decent compiler will of course be able to optimize out the goto.
It is still irritating that you are not allowed to jump to case labels,
so you have to invent an extra case_3 label. [ObLanguageExtension:
allow goto's to jump to case labels (so long as the jump is unambiguous)].

//----------------------------------------------------------------------//

A technique that I have seen used is to
	#define	   when		break; case
	#define    otherwise	break; default
and then use
	switch(x) {
		when 1:
			...
		when 2:
			...
		otherwise:
			...
	}
If your compiler doesn't warn about fallthrough in switch statements,
then this may well be worthwhile.

-- 
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: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
Subject: Re: Wanted: Real Example of MI
Date: Fri, 20 Nov 1992 16:12:43 GMT
Organization: TU Darmstadt

In article <1992Nov19.101210.1@happy.colorado.edu>, srheintze@happy.colorado.edu writes:
> I am revising a course on C++.  I have been looking for some examples of
> multiple inheritance for some time now.  I look thru the plethora of C++ books
> at the local book stores and so far, I have yet to encounter one that has a
> good example of multiple inheritance.

Take a look at

    @article{c++:shopiro:iostream,
     author = {Jonathan E. Shopiro},
     title = {An Example of Multiple Inheritance in \C++: A Model of the
	    Iostream Library},
     journal = sigplan,
     year = 1989,
     volume = 24,
     number = 12,
     pages = {32-36},
     annote = {\js{} Good explanation of multiple inheritance with example.}
    }

I hope you will accept the iostream class as a `real world example' ;-)

--
Joachim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
Newsgroups: comp.lang.c++
From: henryc@ic.Berkeley.EDU (Henry Chang)
Subject: Nested Templates in g++
Reply-To: henryc@ic.Berkeley.EDU (Henry Chang)
Organization: University of California, at Berkeley
Date: Mon, 23 Nov 1992 04:55:17 GMT

It is my understanding that nested templates in g++
are not yet supported.  Does someone have a work-around?

What I wish to do is essentially...
**********************************************************************
template <class X, class Y> class A { };
template <class X> class B { };

template <class X, class Y> class C {
   B<A<X,Y>> a;
};

main ()
{
   C<int,int> a;                // This causes the error to be produced
}
**********************************************************************

-Henry Chang

--
Henry Chang                                        henryc@ic.Berkeley.EDU
UC Berkeley Graduate Student                                 Berkeley, CA

Newsgroups: comp.lang.c++