HDTenEightyP/NetNews huggingface dataset:
From: paul@svl.cdc.com (Paul Kohlmiller)
Newsgroups: comp.lang.c++
Subject: Re: What's the status on a standard on this language??
Date: 13 Oct 92 20:54:10 GMT

robert@charon.jpl.nasa.gov (Robert Angelino) writes:

>Hello,
>	I'm interested in knowing if IEEE or ANSI or some org. has developed
>an industry accepted standard???  How close is it??  How far is it??
>Will there ever be one???  Is one already here and I've lived in a cave
>for the last three years???
There is an ANSI/ISO committee that is developing a C++ standard. They meet
3 times/year. The ANSI designation is X3J16 ( I think the ISO # is WG22).
The current plan is to have a committee draft by the end of 1993. The review
and final approval process will take 18-24 months from that time.
The likelihood of completing a committee draft by the end of 1993 is 50/50
or less. we'll see.
BTW, the latest on the standardization process can be gleaned from the notes
on comp.std.c++.

--
     // Paul H. Kohlmiller             //  "Cybers, Macs and Mips"    //
     // Control Data Systems, Inc.    // Internet: paul@svl.cdc.com  //
     // Acronym under construction.  // America Online: Paul CDC    //
     // All comments are strictly my own. I won't lie but my       //
     // perception of reality is at best a personal hunch.        //
From: engelsma@golden.cps.msu.edu (Jonathan Engelsma (Reid))
Newsgroups: comp.lang.c++
Subject: Re: Distributed C++ System
Date: 14 Oct 92 19:53:43 GMT
Organization: Dept. of Computer Science, Michigan State University

In article <13472@ztivax.UUCP>, champ@ztivax.UUCP (Manfred Vorwalter) writes:
|> We are going to implement a distributed system under C++ and UNIX. We are 
|> looking for standard components (libraries, etc.) that can help us to keep 
|> distribution and/or communication in an object oriented manner. 
|> 
|> We welcome every reply. Hints for books or articals, too.


Motorola has developed such a system.  They call it Pleiades.  If anybody
from Motorola is listening, maybe they can provide more info.  I've got
info on it filed somewhere which I'll try find.

-------------------------------------------------------------------------
Jonathan R. Engelsma                            Michigan State University
                                                     Department of
E-mail:   engelsma@cps.msu.edu                     Computer Science
	  uunet!frith!engelsma	
	  uunet!frith!jresys!engelsma (home)	
-------------------------------------------------------------------------
From: jara@fulcrum.bt.co.uk (Jara Kandhola)
Newsgroups: comp.lang.c++
Subject: AT & T Class Library
Date: 12 Oct 92 14:26:56 GMT
Distribution: comp.lang.c++
Organization: Fulcrum Communications Ltd., Birmingham, England

Hi,
	Could anybody out there let me know how I can get hold of the 
AT & T class libraries. Also any info on the cost and whether you get 
the source code as well would be very useful. Please email any info 
or contact details you may have.

	Thank is advance - Jara



	
--
==========================================================================
Jara Kandhola                                     (jara@fulcrum.bt.co.uk)
==========================================================================
Fulcrum Communications Ltd., Fordrough Lane, Birmingham, B9 5LD, ENGLAND.
From: abed@venus.wustl.edu (Abed M. Hammoud)
Subject: Problems with template function instantiation.
Reply-To: abed@saturn.wustl.edu
Organization: Washington University, ESSRL
Date: Tue, 13 Oct 1992 15:38:01 GMT


Hello, 

The following is a simple program that I wrote to test the template
instantiation mechanisms of g++. I have the latest version (I think its 2.2).
I am running the program on a sun sparc station. When I compile the program
I get the error message:

eval_test.c: In function  main ()':
eval_test.c:16: type unification failed for function template sample'

Is it a bug or I am doing something wrong. Please help.

/*---------------------------------Cut here--------------------------*/
#include <iostream.h>

double func(double x) {
   return x * x; 
}

template <class T>
void sample(double (*f) (double), T bias, int n) {
   for (int i = 0; i < n; i++)
      cout << (f(n) + bias) << endl; 
}

main()
{

   sample(func, 10.0, 10); 

}
/*---------------------------------Cut here--------------------------*/

+-------------------------------------------------+-----------------------+
|Abed M. Hammoud (KB0INX)			  | abed@saturn.wustl.edu |
|Washington University.				  | Office:               |
|Electronic Systems & Signals Research Laboratory.| -Voice:(314) 935-7547 |
|Department of Electrical/Biomedical Engineering. | -FAX:  (314) 935-4842 |
|Campus Box 1161, One Brookings Drive.		  |			  |
|St. Louis, MO , 63130 USA			  |                       |
+-------------------------------------------------+-----------------------+
From: feustel@netcom.com (David Feustel)
Newsgroups: comp.lang.c++
Subject: Re: Another Good C++ Book!
Date: 10 Oct 92 20:29:17 GMT
Organization: DAFCO: OS/2 Software Support & Consulting

sdm@cs.brown.edu (Scott Meyers) writes:

>In article <1992Oct9.235734.1107@netcom.com> feustel@netcom.com (David Feustel) writes:
>| "Effective C++: 50 Specific Ways to Improve Your Programs and Designs"
>| by Scott Meyers(ISBN 0-201-56364-9, $24.95, Addison Wesley).
>| 
>| This book covers so many ways that you can hang yourself in C++ that I
>| wonder why someone doesn't write a Lint++ that checks for all of them.

>I'm glad you like the book.  There is currently a project at Brown
>University that is working on the development of a lint++-like tool, but it
>will offer much more power than lint, because you'll be able to write your
>own constraints and then have the system look for violations.  For more
>information, take a look at this paper:

>@CONFERENCE{ccel,
>        AUTHOR = {Carolyn K. Duby and Scott Meyers and Steven P. Reiss},
>        TITLE = {{CCEL: A Metalanguage for C++}},
>        BOOKTITLE = {USENIX C++ Conference Proceedings},
>        YEAR = {1992},
>        MONTH = aug
>}

>I will also arrange for this to be installed as a Brown University
>Technical Report on wilma.cs.brown.edu.  From there you will be able to
>grab it via anonymous ftp.  I don't know how long it will take for the
>installation to take place -- figure about a week.

>Scott

Thanks. I will definitely get a copy of the paper as soon as it
becomes available.
-- 
Dave Feustel N9MYI <feustel@netcom.com>
 
[.sig on vacation]
From: joec@cybernet.cse.fau.edu (joseph cossette)
Newsgroups: comp.lang.c++
Subject: Re: ProtoGen is worthless?!?
Date: 10 Oct 92 15:37:23 GMT
Organization: Cybernet BBS, Boca Raton, Florida

myhre@plains.NoDak.edu (Robert Myhre) writes:

> 
>   HI all.  I recently purchased BC++ 3.1 and it includes a free copy of
> Protogen.  However, from what I have seen from the initial reading the
> Resource Workshop already does what Protogen does.  Further, Protogen
> requires Resource Workshop for creating the menus, dlg, etc.  Can anyone
> tell me what the real use of Protogen is?  I must have missed it!  :)
> 

You're lucky, you got it for free! I paid $50 for it, and the week after 
I got it they gave it away! I agree it's worthless.
From: sra@ecs.soton.ac.uk (Stephen Adams)
Newsgroups: comp.lang.c++
Subject: C++ documentation tools?
Date: 14 Oct 92 15:06:50 GMT
Organization: Southampton University Computer Science

Are there any tools that will take a bunch of C++ header
files and produce a skeleton document?

I am looking for a tool that will automatically generate
something like Borland's library documentation.  I would
like the output to be a sorted list of classes, with

  . an inheritance diagram/list (sub- & super- classes)
  . an introductory piece of text
  . a subsection for each member with text

I am not particular about the output -- plain text,
wordperfect, MS word, LaTeX, nroff would all be wonderful.

It would be an added bonus if all the text for the
documentation could be provided as C++ comments in the
header files.

I believe Zortech used to produce their manuals like this;
are there any similar tools available?
--
Stephen Adams                           Email: S.R.Adams@ecs.soton.ac.uk
Electronics and Computer Science        Tel: 0703 593649
University of Southampton               Fax: 0703 593045 
Southampton  SO9 5NH,  UK
Newsgroups: comp.lang.c++
From: thail@seas.gwu.edu (Samuel R. Posten)
Subject: Questions!
Originator: thail@seas.gwu.edu
Organization: George Washington University
Date: Wed, 7 Oct 1992 07:01:13 GMT

I'm sorry to bug you all with this, but I need help in a hurry.  I'm
looking for an internet ftp site that has

Borlant C++  or Turbo C++  Libraries for

1.  source code for 16 and 24 bit graphics imaging.
2.  good source code routines for svga and vga.
3.  The full Soundblaster and/ or preferably the soundblaster pro
developers kit or a  home brew development kit.  
  
Thanks alot, I really appreciate any help.
                 Sam

From: kevinc@hpcc01.corp.hp.com (Kevin Collins)
Date: Tue, 13 Oct 1992 23:31:55 GMT
Subject: Re: C++ Class Libraries for drawing charts/graphs ?
Organization: the HP Corporate notes server
Newsgroups: comp.lang.c++


If you have information on C++ libraries for charts and graphs on 
Unix platforms, HP and IBM in particular, please forward it to me at :

kevin@hppcih1.svale.hp.com

Thanks,

Kevin 
Newsgroups: comp.lang.c++
From: c7821027@csie.nctu.edu.tw (Shih-Hao Liu)
Subject: Const and Reference
Organization: National Chiao Tung University
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 8 Oct 1992 17:32:36 GMT

I don't know if this have been discussed before.
Have anyone try the following code,

#include <stdio.h>
main()
{
    char a = '-';
    const char &b = a;

    b = '+';
    printf("%c\n");
}

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

Shih-Hao Liu
c7821027@csie.nctu.edu.tw


Newsgroups: comp.lang.c++
From: sidney@genghis.borland.com (Sidney Markowitz)
Subject: Re: Borland 3.1 nested comment highlighting problem.
Originator: sidney@genghis.borland.com
Organization: Borland International
Date: Thu, 15 Oct 1992 23:32:18 GMT

smclewin@ultrix.ramapo.edu (Scott M McLewin) writes:
>But that switch is ignored by the syntax highlighter.   This is the 
>glitch the original poster was commenting on.  I am not saying nested
>comments are either bad or good, but if a company puts a feature in
>their product, they should support it all around.

I'm the person responsible for the syntax highlighting not recognizing
nested comments even when the nested comments switch turned on. It's
listed here as a bug, but one whose fix was deferred because: 1)
Fixing it would involve either adding a data field for every line in
every editor buffer to keep track of comment nesting levels, or else
lots of rescanning of the entire buffer to reparse; 2) The feature
itself is not legal ANSI C or C++, and anyone who uses it is giving up
portability; 3) The purpose of the feature is to make it easy to
comment out blocks of code that may contain comments without paying
attention to exactly what is there. It is just as easy to do that with
#if ... #endif, which makes it much clearer what is going on and does
nest. Or if you really want to, use // type comments everywhere, and
then you can use /* ... */ to comment out blocks. Since I think that
use of nested comments is error-prone and not necessary, I was
unwilling to compromise the product and the schedule by giving this
"bug" a higher priority than other bugs I had to fix.

So, to summarize in a way that is relevant to comp.lang.c++, which is,
after all supposed to be for C++ language discussions and not about a
particular compiler, nested comments are not standard, and you should
use #if instead to get the desired effect.

 -- sidney markowitz <sidney@borland.com>
From: heilig@plains.NoDak.edu (Zachary Heilig)
Newsgroups: comp.lang.c++
Subject: delete question (fixed)
Date: 8 Oct 92 00:00:42 GMT
Article-I.D.: plains.21051
Organization: University of North Dakota, Grand Forks

Thanks for all your responses.  For some reason I assumed that delete would
return a NULL pointer.  Probably delete didn't change foo, but changed foo[0]
to a NULL, terminating the string.
I wonder how portable that would be... :-)
-- 
    - Zach Heilig (heilig@plains.nodak.edu)

Ninety-Ninety Rule of Project Schedules:
	The first ninety percent of the task takes ninety percent of
	the time, and the last ten percent takes the other ninety
	percent.
Newsgroups: comp.lang.c++,comp.std.c++
From: pete@genghis.borland.com (Pete Becker)
Subject: Re: Random Walks Away From "The concept of templates considered ill designed"
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Thu, 8 Oct 1992 17:16:05 GMT

In article <1992Oct7.155329.24107@cadsun.corp.mot.com> shang@corp.mot.com writes:
>Exactly. See, I call it a constrained parameterized class and never 
>call it a template. In fact, a constrained parameterized class IS a 
>class, it can be used anywhere as an abstract class is used. Therefore, 
>it is NOT a template. For exmaple:
>
>  class < class MemberT[GroupMember] > Group {...};
>
>You can use Group to declare a pointer or a function argument:
>
>  Group * group;
>  group = new Group <class MemberT=SomeMemberType> (...);
>

	What does that get you that you can't do with the language as it now
stands?  Isn't this equivalent?

	class Forwarder
	{
	    SomeMemberType *target;
	public:
	    Forwarder( SomeMemberType *targ ) : target(targ) {}
	    // member functions go here.  They simply invoke members
	    // of SomeMemberType for target.
	};

	Forwarder *group;
	group = new Forwarder( new SomeMemberType );

	Now, granted, this is a little more work to set up.  But is there
anything that a "constrained parametrized class" can do that can't be done
this way?

>or,
>
>  void foo (Group & group);
>
>You cannot use template this way.
>

	No, but you can use inheritance this way.  Simply write your template
so that every instantiation inherits from a common base class:

	class Group
	{
	// whatever...
	};

	template <class T> class Derived : public Group
	{
	// whatever...
	};

	Derived<int> di;
	foo( di );

	-- Pete
Newsgroups: comp.lang.c++
From: pete@genghis.borland.com (Pete Becker)
Subject: Re: Boolean Tests on Streams
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Sat, 10 Oct 1992 17:10:15 GMT

In article <1992Oct9.185647.9689@spectrum.xerox.com> male@eso.mc.xerox.com writes:
>There seem to be two elementary approaches to performing boolean tests
>on streams:
>
>1)  while (cin >> ch)
>       {...}
>
>2)  if (cin)
>       {...}
>
>I've been unsuccessfully trying to find out what is going on under
>the hood in these cases.  How are the tests being made?   I read somewhere
>that for case #1, after every I/O operation, a test of the ios::state buffer
>is made for the stream reference that is returned from ios::operator >> (), and

	Actually, both cases are doing exactly the same thing.  istream,
ostream, and all their relatives are derived from class ios.  ios provides a
member function named 'operator void *() const', which provides a conversion
from an object to a void *.  That conversion returns 0 if any error flags are
set, and returns non-zero otherwise.  Since cin is an object of a type derived
from ios, you can use that conversion in your programs.  When the compiler
sees a statement like this

	if( cin )
	    ...

it has to figure out how to make sense out of it.  The if() statement requires
an arithmetic type or a pointer inside the parentheses.  The compiler sees that
it can convert cin to a pointer by using operator void *, and it does that,
just as if you had said

	if( (void *)cin )
	    ...

Similarly for

	if( cin >> ch )
	    ...

since operator >> return a reference to an istream.  Like this:

	if( cin >> ch )

	if( operator>>( cin, ch ) )
            ^
	    |
	    |
       function returning istream&

	if( (void *)(operator>>( cin, ch )) )
        	^
		|
		|
	    convert the istream& to a pointer

	-- Pete

Newsgroups: comp.lang.c++
From: arthur@solomon.technet.sg (Arthur Sombrito)
Subject: Re: friend declaration scope
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 8 Oct 1992 07:24:46 GMT


--



Hi,

I'd like to add something to my original post.

One ambiguity is regarding the visibility and scope of a friend.
ARM p. 248 states that the name of a friend is not in the scope of 
the class.  I would assume that this refers to friend functions only.
Otherwise a nested class can't be made a friend. 

ARM p. 250 states that an undeclared class or function name is
entered in the same scope as the name of the class containing
the friend declaration. It would then mean that if a nested class 
exists with the same name as the friend class, then the friend class 
refers to the nested class. Otherwise if no class exists by that 
friend name, then it is a forward declaration of a class which is 
in the same scope as the class containing the friend declaration.

Given:

  short f() {}
  class C { protected: enum A {}; class F {};};
  class D {};
  class F {};
  class B : public C
  {  
    long f() {}
    friend short f(); // ok? Does it refer to ::f()?

    friend class F;   // ok - refers to C::F 
    friend class A;   // ok - forward declare a ::A class

    class D {};
    friend class D;   // Does it refer to B::D?

    enum C {};
    friend class C;   // Is ::C visible?
                      // If my interpretation is correct, ::C is still
                      // visible since no class exists within class B
                      // definition
  };

Many thanks.



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

In article <1992Oct13.164331.29699@genghis.borland.com> pete@genghis.borland.com (Pete Becker) writes:
>In article <1992Oct12.214358.33483@Cookie.secapl.com> frank@Cookie.secapl.com (Frank Adams) writes:
>>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.
>
>	If you use a member instead of inheriting you can't override virtual
>functions.  Whether this is a useful thing to be able to do is left as an
>exercise...

It strikes me as cleaner to create a separate public subclass of the
proposed private base class, override the virtual functions there, and
include a data object of the new class.

If you've thought out the changed functions properly, you may even want to
use the new class somewhere else...
Newsgroups: comp.lang.c++
From: jclf@anwaya.demon.co.uk (Jason Fordham)
Distribution: world
Subject: Re: operator->() considered harmful
X-Mailer: cppnews $Revision: 1.14 $
Organization: 
Date: Thu, 1 Oct 1992 02:26:37 +0000


In article <Br4tDn.Bnu@taligent.com> cep@taligent.com (Christophe Pettus) writes:

> Again, I feel that overloadable operator->() is an error in the
> language, a mis-feature.  It doesn't correspond to standard operator
> syntax (a postfix operator that requires something special following
> it?  Come on), and introduces problems like the overloable operator.()
> nonsense.  There are much better ways of accomplishing the same thing.

I know I'm entering into this late, have no C++ experience, but a
reasonable grounding in OOP theory.

It seems to me that this position is not sensible. If * is
overloadable, then (since '(*struc).field' is historically
equivalent to 'struc->field') -> has to be for orthogonality to
be possible at all. Surely one must either make an orthogonal set
possible for structures, or stick to the old definition forever.

It seems to me that there are three other, mutually related,
arguments for overloading access operators:

    o  reusable components
    o  memory architectures
    o  operating system implementation

I can imagine that an OS designer who wished to provide an OS for
platforms of different sizes with different numbers of processors
and shared memory would want to be able to overload all the
access operators.

----------------------------------------------------------------
Jason Fordham                            jclf@anwaya.demon.co.uk
38a Albert St                             jasonf@cix.clink.co.uk
London NW1                             Signatures - just say no!
----------------------------------------------------------------

Newsgroups: comp.lang.c++
From: ded@aplcen.apl.jhu.edu (nod sivad)
Subject: virtual destructors
Reply-To: ded@aplcen.apl.jhu.edu 
Organization: Johns Hopkins University
Date: Sun, 11 Oct 92 17:00:52 GMT


If one defines the following classes:

class A {
public:
	~A()			{}
	virtual void func()	{}
};
class B : public A {
public:
	~B()		{}
	void func()	{}
};

Then runs the following code:

	A* ptr = new B;
	ptr->func();	// thanks to polymorphism, B::func() is called
	delete ptr; 	// DAMNIT, A::~A() is called, not B::~B()

It is natural to have a base class pointer point to several derived
class instances.  Thus a "polygon" pointer can point to "squares,"
"rectangles," "pentagons", etc.  However, when one wants to 
delete this instance, it seems as if you have to cast the object
to get the correct destructor.  This requires knowledge of the
actual derived class involved.  I can think of ways to do this,
but they all smell kludgy.

I guess what I want is a virtual destructor.  Is there a way to invoke 
destructors of derived types with a base class pointer (without casting)? 

				me
From: pete@genghis.borland.com (Pete Becker)
Newsgroups: comp.lang.c++
Subject: Re: Proposal: Preconditions and PostConditions in C++
Date: 13 Oct 92 16:43:31 GMT
Article-I.D.: genghis.1992Oct13.164331.29699
Organization: Borland International
Originator: pete@genghis.borland.com

In article <1992Oct12.214358.33483@Cookie.secapl.com> frank@Cookie.secapl.com (Frank Adams) writes:
>
>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.

	If you use a member instead of inheriting you can't override virtual
functions.  Whether this is a useful thing to be able to do is left as an
exercise...
	-- Pete