HDTenEightyP/NetNews huggingface dataset:
From: mat@mole-end.matawan.nj.us
Subject: Re: comp.lang.c++
Summary: Here be Dragons
Organization: :
Date: Wed, 18 Nov 1992 06:47:46 GMT

In article <1992Nov16.181024.21991@netcom.com>, ort@netcom.com (David Oertel) writes:
> >: In comp.lang.c++, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

> >: > 	It might be appropriate to have a comp.newuser.c++

> >...  If newuser-type questions go in a different conference, they might not
> >get the benefit of replies from more experienced c++ programmers who might
> >avoid such a conference.  Let's stay together.
 
> 	I'm an experienced user who would like to see many of the things that I
> 	learned the hard way transmitted to the newusers.  I have to confess
> 	that the existence of a separate newuser group would create a 
> 	threshold of pain that I wouldn't bother to cross.  Separation is not 
> 	in the fraternalistic spirit of this community.  Another vote for 
> 	just one group.  Also, I don't think that anyone is above learning 
> 	new things from the newusers, because things are always changing and 
> 	nobody can be everywhere at once (except maybe God).

I for one would spend less time in the `less advanced' area, but I would
read and reply from time to time.  I don't want to stop helping people,
but I'd like the chance to help myself, too, with discussions about
`industrial strength' issues.

Perhaps the answer is not to move the `hello world' help line, but to
create a different newsgroup for those who want to discuss their
contravariance and overload in public.  comp.lang.c++.here-be-dragons ,
anyone?
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Member function renaming proposal from the ARM
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.20 $
Organization: Trumphurst Ltd.
Date: Mon, 16 Nov 1992 13:31:40 +0000

I have a question about an extension to the language to allow programmers 
to specify inheriting and optionally renaming functions. The extension is 
proposed in the ARM 10.11c (pp 236-237). 

Let us assume two base classes with name clashes ...

class Lottery {
	// ...
	virtual int draw();
	};

class GraphicalObject {
	// ...
	virtual void draw();
	};

// The suggested extension would allow ...
class LotterySimulation : public Lottery, public GraphicalObject {
	// ...
	virtual int l_draw() = Lottery::draw;
	virtual void draw() = GraphicalObject::draw;
	};

It is stated in the ARM that such a language extension is not _necessary_,
and is only worthwhile if the need to resolve such name clashes proves 
common. It strikes me that the workround suggested in the ARM is going to 
cause some loss of efficiency on most compilers around today.

I see another use for this extension (see ARM also 13.1 pp310-312) ...

class Base {
public:
	// ...
	virtual void set(int i);
	virtual void set(double d);
	virtual void set(char *s);
	};

class Derived {
public:
	// ...
	void set(int) = Base::set(int);
	void set(double) = Base::set(double);
	virtual void set(char *s);
	};

This will prevent set(int) and set(double) being hidden by set(char *), 
without any loss of efficiency in the calling mechanism.

Now I realise that there is no chance of including this in the current 
standard (lets concentrate on getting it finished), but is it a sensible 
enhancement to the language for some future date ? Or is there an existing
construct which will do the job without any run-time efficiency penalty ?

-- 
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: mat@mole-end.matawan.nj.us
Subject: Re: Should I use a generic object which all others inherit from
Summary: It's NOT OOP!  It IS OOP!  IS NOT!  IS!  IS NOT!  IS!  IS NOT!  ...
Organization: :
Date: Sun, 22 Nov 1992 19:04:24 GMT

In article <1992Nov20.133441.27425@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> 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 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.

There's lots of discussion on what `OOP' really is.  To some, it is the
style fostered by a particular OOPL.  To others, the meaning is not so much
in the idiomatic style of message interaction but in encapsulating program
and data in `objects' and programming with them.

A broader view will allow you to see, understand, and learn more.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: mark@mozart.demon.co.uk (Mark Whalley)
Subject: Poll : Microsoft support on the Internet 
Distribution: world
Organization: Telecoms Software Engineer
Date: Mon, 16 Nov 1992 20:08:43 +0000

MS support on the NET ... too bloody right.

YES YES YES YES !


------------------------------------------------------------------
Mark Whalley, 12 Avebury Close, Widnes, Cheshire, WA8 0SF, England
Voice - +44 51 423 5242 (home), +44 51 254 4080 (work)
Email - mark@mozart.demon.co.uk

Newsgroups: comp.lang.c++
From: iperrigo@csr.UVic.CA (Ian Perrigo)
Subject: Re: 3D coordinates conversion to 2D
Reply-To: iperrigo@csr.UVic.CA (Ian Perrigo)
Organization: University of Victoria
Date: Thu, 19 Nov 92 21:22:14 GMT

In article <1992Nov18.164150.203294@uctvax.uct.ac.za>, purves@uctvax.uct.ac.za writes:
>
>	Could anyone please give me a hint on how to convert three dimensional 
>	Coordinates so it can be displayed on a screen and look right as well.
>	
>	Please post to this News-Group as I am using TC++.
>
>	Thanks.
>
>	
I suggest you look into two techniques, parallel and perspective projection. There
are many forms of these techniques, one particularly easy one is to simply
lop off the Z coord (assuming you are using a right-handed coord system, i.e.
Z coming out at you). This is a form of parallel projection. You still keep track
of your Z coord in your "model", i.e. using it for calculations (such as rotation
etc), but ignore it when displaying a point.
Perspective projection gives a more realistic picture of an object by making things that are farther away (in depth or Z axis) seem smaller. 

Ian.
(iperrigo@cs.uvic.ca)
From: hf@telematik.informatik.uni-karlsruhe.de (Harald Fuchs)
Newsgroups: comp.lang.c++
Subject: Re: Wisdom on f(...,const class& xxx = default_xxx)
Date: 15 Nov 92 16:07:22
Organization: Karlsruhe University, Germany
NNTP-Posting-Host: whyaduck.telematik.informatik.uni-karlsruhe.de
In-reply-to: mccauleyba@vax1.bham.ac.uk's message of Sat, 14 Nov 1992 22:15:30 GMT

In article <1992Nov14.221530.1@vax1.bham.ac.uk>, mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:

> In article <mg.721758488@tyrolia>, mg@tyrolia (Michael Golan) writes:
>> what's the net wisdom on a default parameter which is a class?
>> in
>> void f(...,int x = 0 );    		or 
>> 
>> It is inexpensive for the caller to supply x.
>> However, in
>> void f(..., const T& = T(0)) ;
>> 
>> The cost for the caller (to create T(0)) can be pretty expensive.
>> 
>> My best solution is 
>>   T Default_T(0) ;	// global default class T
>>   void f(...., const T& = Default_T);
>> 
>> But this goes "against"  OO, and pollute the name space. Anyone has a better
>> solution (trick?)
> What I do in this situation is same except I'd use `T::Default' rather
> than `Default_T'. (Where T::Default is a static const member of T).
> Much less name space poluting and slightly more OO.

Only slightly :-)
"Default" probably belongs to "f", not to "T". The thing that isn't OO
here is the global function "f". Put it in a class, and add a static
"Default" member.
--

Harald Fuchs <hf@telematik.informatik.uni-karlsruhe.de>
Newsgroups: comp.lang.c++
Date: Thursday, 19 Nov 1992 14:40:57 CET
Newsgroups: comp.lang.c++
Distribution: world
From: wmedetz@risc.uni-linz.ac.at (Medetz Wilhelm)
Reply-To: wmedetz@risc.uni-linz.ac.at (Medetz Wilhelm)
Organization: RISC, J.K. University of Linz, Austria
Subject: 2D graphics editor framework?

Does someone know some 2-dimensional graphics editor framework for C++
which support one of the following environments:
  * Motif
  * Open Look
  * MS-Windows

I want to use it for building NC-programming applications. I do alreay know
about Unidraw/InterViews, but would be intersted whether there exists
something else. I am both interested in commercial or public doman packages.


Many thanks for any information

Wilhelm Medetz



+-----------------------------------------------------------------------------+
| Wilhelm Medetz                                                              |
| RISC-Linz                                phone: Austria (7236) 3231-29      |
| Johannes Kepler Univerity Linz           fax  : Austria (7236) 3231-30      |
| 4232 Hagenberg, AUSTRIA                  email: wmedetz@risc.uni-linz.ac.at |
+-----------------------------------------------------------------------------+
Newsgroups: comp.lang.c++,comp.lang.c,comp.os.msdos.programmer,comp.windows.ms.programmer,ct
From: eduard@htsa.aha.nl (Eduard Beijnes)
Subject: Re: Poll : Microsoft support on the Internet
Date: Fri, 20 Nov 1992 15:34:55 GMT
Organization: Algemene Hogeschool Amsterdam, Polytechnic Institute

It would be real nice of Microsoft to go to the internet,
especially for bug reports !!! (they also can mail fixes )


Newsgroups: comp.lang.c++
From: sailors@CS.ColoState.EDU (robert sailors)
Subject: Re: Complexity in the eyes of the beholder?
Date: Sat, 21 Nov 1992 19:21:01 GMT
Organization: Colorado State University, Computer Science Department

In article <1992Nov18.024553.24081@tagsys.com> andrew@tagsys.com (Andrew Gideon) writes:
>I have been having an extended discussion with a coworker.
>This is someone whom I respect, and with whom I enjoy
>working a great deal.  But this discussion is disturbing
>to me.  He claims that I use too many layers of abstraction.
>
>Specifics: I am of the "small class" and "mixin" school.
>To me, I achieve my goal (except when I violate my own
>rules - which does happen more frequently than I like {8^).
>But this coworker claims that the many levels are too
>complex to follow.  In trying to understand a class, he
>is forced to recurse too frequently and too far.
>
If he needs to understand the implementation, then he has a point.  If he
only needs to understand the interface, then you have a point.  Is co-worker
responsible for checking your code, or just using it?

If he needs to check that your implementations are correct, then you need to
negotiate for an acceptable level of abstraction.  If he doesn't need this,
then tell him to stay out of your objects!
Newsgroups: comp.lang.c++
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: Just what is so great about streams?
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Wed, 18 Nov 1992 20:51:39 GMT

In article <1992Nov18.182420.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
>In article <1992Nov18.134551.5782@bcrka451.bnr.ca>, sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:
>> In article <6994@taurus.cs.nps.navy.mil> skip@taygeta.oc.nps.navy.mil (Skip Carter) writes:
>>>	Now the TimeStamp class can write a comment WITH NO CHANGES MADE TO
>>>	THE TIMESTAMP CLASS.
>    ...
>>>	In fact, TimeStamp can properly write to any class that is ultimately
>>>      derived from ostream.
>>>
>> 
>> What about     fout << t << t << endl;   
>> The wrong operator<<() will be called for the second output unless you provide
>> the appropriate friend function for TimeStamp, no?
>No.
>
>What wrong operator<<()? There only is one that can possibly be called:
>  ostream& operator<< (ostream&,const TimeStamp&)
>
>Are you thinking that << associates right?
>
>fout << t << t << endl;
>  is not...
>operator<<(fout,operator<<(t,operator<<(t,endl)))                             
>
>  it is..
>operator<<(operator<<(operator<<(fout,t),t),endl)                             
>                      \-----v---------/
>                  Returns a ref to `fout'
>           \---------------v--------------/
>                Returns a ref to `fout'
>
>the inner to calls to operator<< call the same operator.
>OK so an ostream& is used to refer to `fout' but when we get down to
>the nitty-gritty of stream io everything is virtual so this doesn't matter.

Perhaps I was thinking too general.  If the class of fout does not need to
redefine operator<<(), everything is ok.  But if there is some processing
that has to be done before the data is passed to the underlying stream, 
doesn't the class of fout have to redefine operator<<()?  In which case
my example does not work.  Because operator<<() is *not* virtual.  I don't
think it is true that TimeStamp can properly write to *any* class that 
is ultimately derived from ostream.  And if it can, I'd sure like to know how.

Stuart
--
: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
Newsgroups: comp.lang.c++,comp.object,comp.unix.wizards,comp.unix.questions
From: william@theory.TC.Cornell.EDU (William Holmes)
Subject: Need questions to test OO, C++ and Unix knowledge
Organization: /home/guest/william/.organization
Date: Fri, 20 Nov 1992 17:31:45 GMT


Greetings net wizards! (and I know there are plenty of you out there)

I need to assemble a set of questions to measure expertise in the
following areas:

    1.  Object Oriented Analysis and Design -

        Preferably not language specific in nature.  Problems which address
        or depend on specific OOA methodologies are OK, as long as the
        methodology is cited as such.

    2.  Programming in C++ -

        AT&T cfront 2.x based examples most useful.  cfront 3.0 is also
        acceptable, but please specify version dependencies.
        Problems ranging from general syntax rules to subtle effects arising
        from initialization sequence and multiple inheritance, etc. are fine.

    3.  General Unix Concepts and Utilities -

        This should distinguish among novice, average and wizard Unix
        _users_.  Vendor or Unix flavor-specific problems (such as those
        referring to system administration or configuration for a specific
        platform) are not useful.

I would *greatly* appreciate the contribution of questions or problems of
varying difficulty which address any of these areas.

(Please include solutions; I humbly admit that I cannot use a problem which I
cannot solve myself, and I am sure that many of these exist.  ;-) )

If anyone is interested in seeing the compiled problem set (with or without
solutions), send me email.

Please email your responses directly to me AT THE ADDRESS BELOW, as I do not
regularly read these groups.

--
Milo Chan, chan@fractl.tn.cornell.edu
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Self Deletion
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.20 $
Organization: Trumphurst Ltd.
Date: Mon, 23 Nov 1992 13:13:41 +0000

In article <By1Hwt.22p@cs.uiuc.edu> pjl@cs.uiuc.edu (Paul Lucas) writes:
> *****>	Self-deletion is (will-be) a no-no; static members are another
> 	work-around.
Really ? 

Tell me more !

There is no reason at present, with any of the C++ compilers I have used, 
to prohibit self-deletion, provided that it is only done in certain 
places, viz at a point after which no members will be accessed.

I expect Paul knows better - perhaps he would care to explain ?

-- 
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: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
Subject: Re: Need Yacc & Lex retargeted to C++
Date: Tue, 17 Nov 1992 12:44:50 GMT
Organization: TU Darmstadt

In article <1992Nov13.154107.21091@murdoch.acc.Virginia.EDU>, cgh6m@darwin.clas.Virginia.EDU (Craig G. Hocker) writes:
> This seems to be a topic of some interest, so I will mention a 
> C++ Parser Class Kit I came across by accident yesterday while
> downloading another file. Nobody has mentioned it.
> 
> anonymous ftp to  export.lcs.mit.edu
> 
>     contrib/yacc.shar.Z

I have mentioned it a few times already. And here is my warning again:

(1) Users outside the U.S.A., keep your fingers off this file.
    Why? I cite from a file in this shar archive:

	Export of this software from the United States of America is assumed
	to require a specific license from the United States Government.
	It is the responsibility of any person or organization contemplating
	export to obtain such a license before exporting.

    I don't assume that you have a license...

(2) Ftp adminstrators outside the U.S.A., if you mirror export (it's
    the X11 contrib area!!!!), be aware that you might do illegal actions.


I have asked already in public postings and in private mail, why this
restriction is in this small package. No answer. I consider it ridiculous.

Btw, in addition the shar is corrupt.


Last, but not least: A perl script which does something similar is
available via anonymous ftp from the C++ archive at Darmstadt:

	ftp.th-darmstadt.de [130.83.55.75]
	directory pub/programming/languages/C++/tools/
        file yacc+.pl

Without such silly restrictions...

--
Joachim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
Newsgroups: comp.lang.c++
From: mazz@mars (Richard Mazzaferri)
Subject: Re: Can someone please help me with streams?
Organization: Uni of Newcastle, Australia
Date: Sun, 22 Nov 1992 14:47:16 GMT

andy@federation.gatech.edu (Andy Register) writes:

>In article <1992Nov18.033505.1617@lugb.latrobe.edu.au> ECSC9120802J@LUST.LATROBE.EDU.AU (GRANT,David) writes:
>|>
>|>I a new programmer to c++, and at the moment I am having trouble with streams.
>|>I have overloaded the istream operator >>, to read in character by charater and
>|>copy into an array. (It does a few other things as well.) The trouble I am
>|>having is that I can't get it to recognise spaces or carrage returns. It just
>|>seems to ignore them totally. I was wondering how I can get it to recognise
>|>these characters, as it is inportant to my program. 
>----------------------------------------------------------
>Yep, istream ignores whitespace (blank, tab, newline, formfeed, cr).

>Try cin.get() instead.  Stroustrup, The C++ programming language, 2nd
>ed., pp. 330-333 has examples.

Actually, this is only the default behaviour for istreams.  You can ask for
white space not to be skipped by clearing the ios::skipws flag.  This
can be achieved by 'cin.setf(0, ios::skipws)', and turned back on again
via 'cin.setf(ios::skipws,ios::skipws)'.  Alternately you can use 
manipulators to achieve the same effect in mid-input.

    char c;
    cin >> resetiosflags(ios::skipws) >> c >> setiosflags(ios::skipws);


   

    Mazz.

--
Richard Mazzaferri        Ph.D. student          Uni. of Newcastle 
  Ph (049) 216254   mazz@faceng.newcastle.edu.au     Australia.
From: exubern@exu.ericsson.se (Bernie Meier)
Newsgroups: comp.lang.c++
Subject: Need info: C++ obj & shared libraries
Keywords: shared libraries, C++ objects
Date: 23 Nov 92 18:16:41 GMT
Reply-To: exubern@exu.ericsson.se
Organization: Ericsson Network Systems, USA
X-Disclaimer: This article was posted by a user at Ericsson.
              Any opinions expressed are strictly those of the
              user and not necessarily those of Ericsson.

I have heard that it is very difficult to use the full capabilities of C++
(virtuals, static instantiation, con/destruction) when designing shared
object libraries. 

My questions are as follows:

1. Is there adequate support for C++ shared libraries? (e.g. C++ objs are
   hard to use efficiently in shared mem, thus by extension in shared code)

2. Is there a way to ensure correct initialization of statically declared
   C++ objects in shared code?

3. Do virtual members cause any problems in shared libraries?

4. Why does the SunOS debugger, dbx(1), not properly allow debugging of
   programs using shared code? I get an error message like:
   "dbx: internal error: assertion failed at line 2443 in file ../common/object.c"
   At other times the shared objects seem to be nil pointers but the
   program still runs correctly.

5. Is there any good documentation addressing C++ and shared libraries, or 
   something more detailed than the standard SunOS manuls?

Thanks for any help.

-Bernie

---
=================================================================
|| exubern@exu.ericsson.se   || "Do they speak swedish in      ||
|| Ericsson Network Systems  ||  Switzerland?"   - R.U.Serious ||
|| Richardson, TX, USA       ||(Don't let the .se fool you...) !!
=================================================================


---
=================================================================
|| exubern@exu.ericsson.se   || "Do they speak swedish in      ||
|| Ericsson Network Systems  ||  Switzerland?"   - R.U.Serious ||
=================================================================
From: sdm91r@ecs.soton.ac.uk (Stuart Maclean)
Newsgroups: comp.lang.c++
Subject: Re: Printer Source
Date: 17 Nov 92 11:09:26 GMT

In <RKOHLBUS.9.0@jennifer.umd.edu> RKOHLBUS@jennifer.umd.edu (Robert C. Kohlbus) writes:


>	I'm looking for some good source code on how to handle writing to a 
>printer that does error checking and code on how to check to see if the
>printer is off line or out of paper.  Any help would be great and as a side
>note I'm using Borland C++ 3.1 in dos environment (5.0).

I've done a bit of that myself. I can remember that there are no printer code
standards whatsoever, so each different printer responds with its own codes.
In effect, some of your code is hard wired to a specific printer. Even the
Out of Paper bit isn't standardised if I recall.

Stuart.
Newsgroups: comp.lang.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: Compiler Bug (AT&T 2.1) ?
Date: Tue, 17 Nov 1992 21:26:13 GMT
Organization: University of Birmingham

In article <1992Nov17.181306.8081@lut.ac.uk>, J.March@lut.ac.uk writes:
> Consider:
> class Elt { public: Elt(int*); };
> class List { public: List(const Elt&); }; 
> void main() { List L(new int(1)); }
  ^?^
   [example cut down to relevant bits ]
>
> Shouldn't this fail because the declaration of L doesn't match any of 
>         the constructors for class List?
No, the complier is allowed to insert up to one user-supplied type
conversion for each parameter in any parameter matching situation
(except templates).

Since the type conversion constructor (aka one parameter constructor)
Elt::Elt(int*) has been declared the complier can compile main() as:

main() { List L(Elt(new int(1))); }

This is now an exact match.

A tempoary Elt is created to satisfy the need for a reference to an Elt.
-- 
    \\   ( )    No Bullshit!     |  Email: B.A.McCauley@bham.ac.uk   
 .  _\\__[oo        from         |  Voice: +44 21 471 3789 (home)
.__/  \\ /\@    /~)  /~[   /\/[  |    Fax: +44 21 625 2175 (work)
.  l___\\      /~~) /~~[  /   [  |  Snail: 197 Harborne Lane,
 # ll  l\\    ~~~~ ~   ~ ~    ~  |         Birmingham, B29 6SS, UK
###LL  LL\\   (Brian McCauley)   |   ICBM: 52.5N 1.9W
Newsgroups: comp.lang.c++