HDTenEightyP/NetNews huggingface dataset:
From: pl2440@meibm10.cen.uiuc.edu (Paul Jay Lucas)
Newsgroups: comp.lang.c++
Subject: Re: return statement
Keywords: c++ return
Date: 13 Nov 92 21:16:40 GMT
Organization: University of Illinois at Urbana

In <kilitzir.721570017@news.forth.gr> kilitzir@antigone.csi.forth.gr (Xristos Kilitzirakis) writes:

> i wanted to do an example,so I wrote:
>int ff()
>{return int i;
>}

>g++ errors.
>Is that a correct statement?

	No; read a C book.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++,comp.std.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Calling pure virtual functions in base class constructor
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
Followup-To: comp.lang.c++
X-Mailer: cppnews $Revision: 1.20 $
Organization: Trumphurst Ltd.
Date: Thu, 5 Nov 1992 12:06:01 +0000

In article <miLRVB10w165w@csource.oz.au> david@csource.oz.au writes:
> I'm somewhat puzzled as to why the current rule on calling pure virtual
> functions from a base class does not simply prohibit them from being
> there (ie. by a compiler error) rather than defining the results as
> being 'undefined'. (ARM sec 12.7)
The reason is that it is quite legal to have a definition of a pure 
virtual function, thus ...

class A
  {
    // ...
      ~A() { purefunc(); }
      virtual void purefunc() = 0;
  };

void A::purefunc()
{
  cout << "You called a pure virtual function !\n";
}

This facility might be useful when you want your abstract base class to 
provide some kind of default behaviour, but you want to force derived 
classes to add additional behaviour (or, at least, hint strongly :-).

> What is interesting to note is how the various compilers handled it.
> MSC/C++ 7 calls a null function via the vtable (cute), resulting in
> a system crash or main() being re-entered depending on memory model,
> but even more interesting is gcc 2.2.2 (djgpp), which generated a call
> to abort() inline and threw out the original code completely! In other
> words, it clearly knew that the code was wrong, but it silently did
> this, even at -Wall.
It looks like g++ is being clever, and making undefined pure virtual 
function entries in the vtable point to a piece of code that does an 
abort. 

Good idea - are you listening Microsoft ? [Answer : Not officially :-]

Actually, it occurrs to me that it should be possible to do this yourself,
without adding to code size (probably) - just declare your virtual 
functions ...

class A
  {
    // ...
      ~A() { purefunc(); }
      virtual void purefunc() = 0;
  };

inline void A::purefunc() { assert(0); }

Pure virtual functions can only be called explicitly, under circumstances 
where the actual type can be deduced at compile time, which are the 
conditions allowing inline virtuals to be expanded inline. Then again, I 
could be wrong.

[This doesn't make you a smeg-head :-]
-- 
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: sailors@CS.ColoState.EDU (robert sailors)
Subject: Re: Explanation for "Null pointer assignment"
Date: Thu, 05 Nov 1992 15:34:22 GMT
Organization: Colorado State University, Computer Science Department

Borland supplies a HELPME!.DOC file, and somewhere there is mention of two addresses you
can watch.  Something like (char *)0,4m and some string.  You put these in your watch
screen, and step through the program until the values change.

Works great for me :)

From: karen@hpfcbig.SDE.HP.COM (Karen Sturgeon)
Date: Wed, 11 Nov 1992 22:00:51 GMT
Subject: SoftBench Users
Organization: HP SESD, Fort Collins, CO
Newsgroups: comp.lang.c++

SoftBench Family Users:

If you are interested in receiving a copy of a new quarterly newsletter for
SoftBench users from HP called SoftBench Insights, please respond to:

    softbench_insights@fc.sde.hp.com

Sincerely,
Denise Scruggs
Hewlett-Packard
Managing Editor
(303) 229-6773
Newsgroups: comp.lang.c++
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: where do templates go?
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Mon, 9 Nov 1992 17:44:01 GMT

In article 92Nov9082600@tohi.DMI.USherb.Ca, dechc00@tohi.DMI.USherb.Ca (CHRISTIAN DECHAMPLAIN) writes:
>
>I'm using g++.  Suppose I'm using many compilation modules.  Where do the
>templates go?  In the files with the declarations, in the files with the
>definitions or just everywhere?  G++ does not seem to put them anywhere!
>The ARM talks about a way to tell the compiler where you want them to be put,
>where you want your templates to be expanded.  How do you do that with g++
>specificaly.  I've searched for command line options and I've tried the
>definition and implementation pragmas but with no success.  I've even once
>managed to have some templates functions in my .o files but the linker still
>complained that they weren't there.  Now I think that templates don't realy
>work with g++ v2.3.1.

You have to put the template code in the header files.  The section of the ARM
you are referring to is part of the commentary and not the language definition.
I expect that CYGNUS will come up with better template handling features for
g++ in the future.

	Chris Flatters
	cflatter@nrao.edu
Newsgroups: comp.lang.c++
From: enewton@uucp (Eric C. Newton)
Subject: Re: Just what is so great about streams?
Reply-To: uunet.uu.net!srg!enewton
Organization: means "in a rut"
Date: 12 Nov 92 07:58:20


   This posting is a genuinely answer-seeking question,

     what _is_ so great about streams?

In our work we do a LOT of string formatting.  For the last few years
most of our developers have been coding the formatting like so:

	char buff[BIGBUFFSIZE];
	sprintf(buff,SOMEFORMAT,a,b,c,d);

and we had a LOT of memory overwrites.  BIGBUFFSIZE, is ususally some
arbitrarilly silly constant, like 80, 256, 1024, etc.  It is never
defined to be big enough for everyone.  Sure, all you have to do is
change the constant and recompile, but if that recompile takes the
better part of an afternoon, that is not very nice.  Besides, then we
have lots of extra-long buff's in all of the rest of the code.

I have been championing the use of strstream and String for string
formatting, and we have had a dramatic decrease in memory overwrites.

-Eric
--
Remember to mail to: 	uunet.uu.net!srg!enewton    "The more you complain,
<or>			enewton@oswego.oswego.edu    the longer God lets you
<or>			enewton@access.digex.com     live."
Newsgroups: comp.lang.c++
From: tim@gold.iss.nus.sg (Tim Poston)
Subject: Just what is so great about streams?
Originator: tim@gold
Organization: Institute of Systems Science, NUS, Singapore
Date: Thu, 12 Nov 1992 06:19:42 GMT

This posting is a genuinely answer-seeking question,

  what _is_ so great about streams?
  

The C++ books that I've learned from
all have strong explanations of why C++ is a better C,
and I am perfectly convinced about that.
C++ makes it easier to program the way that I think.

But I have never seen any discussion of the merits of streams,
versus functions like printf(),
or even a pointer to such discussion.
The books and manuals just described how to use them.
Flushed with the elegance of C++ in general,
I duly wrote my programs to use them.

The more I did that,
the less I've believed I should.

Let me present a negative case:
I stand ready to be corrected by those who know better.

From a coding standpoint,
the << operator seems to be a case of `user-friendly disease'.
Easier to write simple output
without worrying about data types,
and lesson 1 (the "hello, cruel world" program)
is definitely easier.
But when I want more output than that...?

I have to do
 x << " " << y
just to get a space between output numbers.

Typical user-friendliness:
"don't worry about type,
I'll look at it and do what's best",
with no judgement needed by the programmer.
But sometimes Mom does not know best.
For instance, if the output is PostScript code,
a number very near zero should _not_ be output as 1.472e-6
It should be 0.0, or PostScript will barf.

So I have to use a function call to say
"Please Mom, I want the next one decimal,"
pass a number,
say "Please Mom, I want the next one decimal,"
pass another number,
say "Please Mom, I want the next one decimal,"
pass another number,
say "Please Mom, I want the next one decimal,"
pass another number,
say "Please Mom, I want the next one decimal,"
pass another number,...

and what could have been one line using printf() 
becomes a far less readable slather of code.

That is typical user-friendliness.
Easy to start,
but painful and laborious to do things
that need discrimination and power.

Last but not least,
the stream stuff seems to be an absolute swarming
ground for compiler bugs.
I haven't (heaven forfend)
tried all compilers extant,
but the ones I have...
ugh.


All in all,
my inclination is to go back to stdio.h
and forget I ever heard about streams.
I'm puzzled, though.
If they don't have merits to balance
the discomfort I've found,
why are people using them at all?
Either I've been doing very dumb things
that brought the discomfort on myself,
or there are pluses (pluspluses?)
nobody has told me about.

I would welcome either
  flames that make clear to me how I've been dumb,
or
  an explanation of those merits.

Tim Poston


____________________________________________________________
 "Division is esteemed one of the busiest operations of
  Arithmetick, and such as requireth a mynde not wandering,
  or setled uppon other matters."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Newsgroups: comp.lang.c++
From: schwarzo@kirk.fmi.uni-passau.de (Oliver Schwarz)
Subject: library list wanted
Keywords: library list
Organization: University of Passau, Germany
Date: Thu, 12 Nov 1992 16:29:10 GMT

Hello all,

Can someone mail me a list of C++ libraries freely available ?
(I'm using g++ for Linux.)

Thanks, Oliver.



Newsgroups: comp.lang.c++
From: hansen@deci.cs.umn.edu (David M. Hansen)
Subject: Re: 'new' syntax?
Organization: University of Minnesota
Date: Fri, 13 Nov 1992 14:36:54 GMT

In article <1992Nov13.124612.1@vax1.bham.ac.uk>, mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
|> In article <1992Nov13.095152.26819@rs6000.bham.ac.uk>, pickerig@eee.bham.ac.uk (Mr. G. Pickering) writes:
|> > I want to create an array of 'size' long**, is the correct syntax:
|> > 
|> >   long*** new_blocks = new (long**[size]);
|> > 
|> > I am having memory corruption problems and suspect this is not doing
|> > what I really want.
|> I have trouble with the new operator myself I normally give up trying to
|> understand the syntax and use a local typedef.
|> {
|>   typedef long **longPtrPtr;
|>   longPtrPtr *new_blocks = new longPtrPtr[size];
|> }
|> Possibly not the most elegant solution but at least it works.

Hear, hear!  The trouble, I think, is not with the new operator, but with 
the C syntax of declaring variables, which was once descibed to me as "an
experiment that failed."  I almost always try to build complex types
from simpler ones using typedef.  This is nice because the new type names
are reusable, and are generally easier to read and understand than 'raw'
declarations (IMHO).  The only major problem that I see with typedef is that
it does not handle arrays very well (or is it vice versa...?).  If you
want a typedef'ed array, it is best to enclose the array in a struct.

					-=Dave
Newsgroups: comp.lang.c++
From: dkarr@sierra.com (David Karr)
Subject: Re: something nasty
Organization: Sierra Geophysics,  Kirkland WA
X-Newsreader: Tin 1.1 PL4
Date: Mon, 9 Nov 1992 17:17:15 GMT

syackey@ccscola.Columbia.NCR.COM (Steve Yackey) writes:
: In article <540@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
: >In article <1992Nov1.224626.771@BofA.com> dan@BofA.COM (Dan Brockman) writes:
: >>
: >>If you can explain this, please send me email and
: >>tell me how to fix my code so it runs.
: >>
: >>---------------- the big nasty --------------------
: >>
: >>
: >>"Dbasesw.c", line 1842: internal <<AT&T C++ Translator 
: >>2.1.03 08/31/90>> error: bus error (or something nasty
: >> like that)
: >
: >1) I have seen this (SCO ODT, HCR C++ compiler).  No rhyme or reason
: >	that we've ever been able to determine.  Sometimes just simple
: >	syntax errors.
: >
: >2) You did't give us the code w/ the problem (which may or may not
: >	have helped...)
: >
: 
: the magic fix (works here) is to take the entire function, i.e., stuff
: between the {}, that has the error, line 1842 in this case, yank it out
: and stick it at the top of the source file.
: 
: have no idea what this does, but it has always worked.
: 

(I have a suspicion we have a problem with our outbound news.  If you
read news frequently, could you indicate that you saw this note in
email?)

As I mentioned before, we only get that on the HP compiler, and only
if we compile with "-g".  I tried moving the function that got the
error to the "top" of the source file (first function after #include
section), but it didn't fix the error.  It did change the error
message, though.

This is the error I get before moving the function:

CC: "/tmp_mnt/sambu/people/dkarr/work/new2dm/ui/CrossSection.cc", line 593: internal error: bus error (or something nasty like that) (3058)

This is what I get after moving the function:

CC: "/tmp_mnt/sambu/people/dkarr/work/new2dm/ui/CrossSection.cc", line 575: internal error: (function: DbgPush::~DbgPush()) Optdriver: Instruction outside a procedure. (6731)

--
David M. Karr
Sierra Geophysics, Inc.
ARPA: dkarr@sierra.com, UUNET: uunet!sgihbtn!dkarr
Phone: (206) 822-5200 (x343)
From: eny@ermes.enea.se (Erik Nykvist)
Newsgroups: comp.lang.c++
Subject: Re: Linked Lists in Shared Memory:
Date: 10 Nov 92 11:44:35 GMT
Organization: Project ERMES, Teli Telecom Sweden

ameesh@lsil.com (Ameesh Desai) writes:
> In article 17760@ermes.enea.se, eny@ermes.enea.se (Erik Nykvist) writes:
> 
> [stuff deleted]
> 
> >
> >I have used a technique based on the new-operator with placement-syntax.
> >If we have objects that can only be accessed by one process at the time it
> >is possible to adjust the this-pointer using this operator.
> >
> >As long as the constructor used doesn't mutate the data members the affect of
> >using this operator is only adjustment of the vtbl-pointer.
> >
> 
> [ stuff deleted ]
> 
> >// We also use the placement syntax to allocate the shared object.
> >=========
> >PROCESS 1
> >=========
> >{
> >	Shared* sp = new (shared_mem) Shared;
> >	Lock lock(*sp);
> >	// Adjust vtbl
> >	new (shared_mem) Shared(IN_SHARED_MEMORY);
> 
> 
> I am confused ... do you plan to allow creation of the object in one process and
> its access in another. If so I am not sure what effect the above new statement
> has - how does it fix the vtbl ? How does it effect the 'this' ptr - which 'this' ?
> 
> [stuff deleted]
> >
> >Erik Nyquist, ENEA DATA AB, 	erny@enea.se
> >				eny@ermes.enea.se
> 
I understand that you are confused as I haven't delivered an example
program. 

The proposed technique uses the new-operator  with placement-syntax to
fix the vtbl-pointer in the object. 
I have not thought about this very much. I have written ONE example
program that uses this. 
My idea is that if you know the address of the object in shared memory
you could access it after having fixed the vtbl-pointer.
If you fork your process it is NOT necessary to fix the vtbl-pointer
because the forked process has the vtbl at the same address as the
parent process.

Erik Nyquist

> 
> Ameesh
> 
> ---
> ______________________________     o__            
> | _   /|     Ameesh Desai     \    ,>/_                              
> | \`O.o'     LSI Logic Corp.   \__(_)`(_)_              email: ameesh@lsil.com
> | =(_|_)=    MS E192, 1501 McCarthy Blvd. \             fax  : (408) 433-6802
> |____U_______Milpitas, CA 95035____________\____________voice: (408) 433-4097 
Newsgroups: comp.lang.c++
From: mazzucch@ghost.dsi.unimi.it (massimo mazzucchi)
Subject: FortranTOc
Organization: Computer Science Dep. - Milan University
Date: Wed, 11 Nov 1992 17:35:08 GMT


Hi 

i am Max from Milan

i will know if exist a traslator (for pc or unix machine)

fortran to c your name and price

Thanks for your help



--------------------------------------------------------------------------------
!  Massimo Mazzucchi                         address    e-mail                !
!  University of State                       mazzucch@ghost.dsi.unimi.it      !
!  Departement of Computer Science                                            ! 
!  Via Comelico, 41 -  20133 MILAN ITALY                                      !
 -------------------------------------------------------------------------------
From: lenzen@galaxy.fernuni-hagen.de (Frank Lenzen)
Subject: STILL LOOKING FOR EXPRESS-TOOLS
Organization: FernUniversitaet Hagen
X-Newsreader: Tin 1.1 PL5
Date: Mon, 9 Nov 1992 08:25:50 GMT


Information on EXPRESS tools wanted!

If you have any tools which are related to the upcoming ISO standard 
EXPRESS (e.g. parser, constraint checker, databases, EXPRESS-G tools, 
EXPRESS-G to EXPRESS translator and vice versa, etc.), we would be very 
happy to hear from you. 

We are using EXPRESS very intensively in our work on modelling the 
domain of CAD objects in electronic design. Furthermore, we are planning 
to establish a tutorial on EXPRESS in a European  context, and our 
interest is  
(1)	to give an overview on existing EXPRESS tools,
(2)	to demonstrate EXPRESS tools, and 
(3)	to provide some good tools to support the participants' 
first practical steps in modelling with EXPRESS. 

If you can provide some information on available EXPRESS tools (either 
about tools which have been implemented by yourself or about tools which 
you are using), please contact us at the following address:





++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ FernUniversitaet Hagen   +  Frank Lenzen                   +
+ Praktische Informatik I  +                                 +
+ Feithstr. 140            +                                 +
+ W - 5800 Hagen 1         +  EMail: lenzen@fernuni-hagen.de +
+ Germany                  +  Fax-No. :  +49.2331.987.314    +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Newsgroups: comp.lang.c++
From: arthur@solomon.technet.sg (Arthur Sombrito)
Subject: ARM grammar error?
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Wed, 11 Nov 1992 09:29:10 GMT




ARM grammar states that an assignment-expression IS
     unary-expression assignment-operator assignment-expression

However I see a lot of commercial code (such as USL library) wherein 
an assignment to a cast-expression is done.  Since a cast-expression
cannot reduce to a unary-expression, my parser gets a syntax error
on the "=" operator.  So shouldn't assignment-expression be
     cast-expression assignment-operator assignment-expression

Thanks for any replies.



Newsgroups: comp.lang.c++
From: simone@trace.eng.wayne.edu (Simone Douglas 577-0108)
Subject: FAQ
Reply-To: simone@trace.eng.wayne.edu (Simone Douglas 577-0108)
Organization: Wayne State University, Detroit
Date: Tue, 10 Nov 1992 18:14:06 GMT

Is there a C++ FAQ? and where can I get it.

Thanks, Doug
--
              | Wayne State University  
   o__        | Electrical & Computer Engineering 
   ,>/-       | Detroit, Michigan 48202 USA
   O \O       | simone@trace.eng.wayne.edu
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Info on IBM compatible C/C++ compiler needed!
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.20 $
Organization: Trumphurst Ltd.
Date: Thu, 5 Nov 1992 11:36:41 +0000

In article <1992Nov01.023540.106364@zeus.calpoly.edu> jhosee@zeus.calpoly.edu (Jeffrey Yang Ho-See [Ho! Now I See!]) 
asks for comments on IBM PC C++ compilers.
Here is my 2 cents worth ...

Borland - Pretty good. Has a few bugs (e.g. mixins with abstract virtual
bases unusable). Comes in a wide variety of flavours at various prices. 
Includes templates (but not exceptions). OWL (extensive Windows class
toolkit) excellent, except for the fact that it uses a non-standard 
language extension to handle Windows message passing, and it is a deep 
class heirarchy, based on an Object class, which some people don't like.
Good Integrated Development Environment (if you like that sort of thing).
The debugger is supposed to be good, though I have never felt comfortable 
with it myself. Updated regularly (which can be expensive if you keep up).

Microsoft - Also has bugs. Compiling MUCH slower than either of the others.
Comes with the official Windows SDK, and Microsoft Foundation Classes 
(shallow set of classes covering Windows stuff). No templates or 
exceptions (except via macro, which I don't count). No support on the 
Internet (yet :-). The CodeView debugger is O.K., except that it seems to
take up a lot of memory.Poor (IMHO) Integrated (NOT !) Development
Environment. First release, so I don't know about upgrades, or their cost.

Zortech - Was once the best. I have found more bugs in it than either of 
the others, but I've used it for MUCH longer. Mixins with abstract virtual
base classes will compile, but crash my machine ! Has all the stuff for 
Windows development, but bundled classes for Windows not as extensive. 
No templates or exceptions. The debugger is good, except for the 
occasional bug, and the fact that Symantec can't support it any more.
Integrated (slightly :-) Development Environment not as bad as
Microsoft's. There hasn't been a new release of Zortech since Symantec
took over (must be a year, now). Symantec say they won't do a new release
until they've got the bugs out, but lots of people have got fed up
waiting. 

My recommendation ? 
Borland if it is for personal use, Microsoft if you work for a large
company and want the "industry standard". 
-- 
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: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: comp.lang.c++ 
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 11 Nov 1992 18:35:20 GMT

In article <83366@ut-emx.uucp> jamshid@emx.utexas.edu writes:
>Followups have been directed to comp.os.msdos.programmer only (hint,hint).

	comp.lang.c++ is certainly getting flooded.

	There are many questions on

	a) PC technicalities (also others for Unix though!)
	b) compiler installation
	c) beginners language issues

that might be better elsewhere but I dount that comp.os.msdos is
appropriate. People using C++ want support from other C++ users,
comp.os.msdos is likely to be even more flooded.

	It might be appropriate to have a comp.newuser.c++
group or some other forum to soak up some of the postings 
that really have nowhere else to go.

	As more an more PC users have both PC's and Internet access,
and C++ becomes more and more popular, the number of postings
relating to the C++ language itself in this group is likely to 
diminish proportionally unless an appropriate new group is formed.

	Any comments?
 


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: csteeves@hpldsla.sid.hp.com (Carl Steeves)
Newsgroups: comp.lang.c++
Subject: FAQ request
Date: 4 Nov 92 20:09:46 GMT
Organization: HP Scientific Instruments Division - Palo Alto, CA

I have been unsuccessful at obtaining a copy of the FAQ for 
comp.lang.c++ by the standard methods described in this notestring.

Please email me a copy.

Thanks in advance, 

Carl Steeves	(csteeves@sid.hp.com)