HDTenEightyP/NetNews huggingface dataset:
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: Newbie Wants Advice on C-Programming
Date: 3 Jan 93 10:14:04 GMT
Followup-To: comp.lang.c++
Organization: AND Software BV Rotterdam

In article <24538@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
|
|jimlynch@netcom.com (Jim Lynch @ Netcom Online Communications Services (408-241-9760 login: guest)) wrote
|
| > >You should always start out with the official books:
| > >
| > >For C, it is _The_C_Programming_Langauge_ 2nd ed. by Kernighan & Ritchie
| > >For C++, it is _The_C++_Programming_Language 2nd ed. by Stroustrup
| > 
| > No no no no no no no no no no no no. These books are _unreadible_ to a beginner.
| > However, they can be quite valuable as a reference (whenever you get around to
| > learning how to read them...)

|It is worth remembering that `beginner' means different things in different
|contexts and what `unreadable' means depends critically on what kind of
|beginner we are talking about.
|
|If by `beginner' you mean `someone who approaches programming for the first
|time,' you are almost certainly right (though I have heard of exceptions to
|that rule). If, on the other hand, `beginner' means `experienced programmer
|who just happens never to have encountered C or C++ before,' you are with
|a high propability wrong (though again I suspect a few exceptions could be
|found).
|
|The backgrounds and expectations of want-to-be C or C++ programmers seem
|infinitely varied and textbooks, approaches to teaching, and advise must
|try to take that diversity into account. No one approach or one book can
|cover all angles.

I think there's a bit more to leaning C++ than there is in learning C.
C++ uses quite a different paradigm: the object oriented programming
approach. Here at my company, they made me volunteer (with a gun pointed
to my head ;-) to teach the programmers team the concept of object
oriented design and programming. My first attempt was using your book
along the line of explaining inheritance, polymorphism, data encapsulation
etc. etc. We ended up discussing the misty details of the C++ language.
I completely failed here. My second attempt was, not using any programming
language at all, but just a clear explanation of the object oriented
concepts and mechanisms. When all that was clear, we switched to C++.

This approach was much more fruitful: the C++ language became just
a mechanism to express these object oriented mechanisms. I kept on
convincing these people that it doesn't matter _how_ you express these
concepts, as long as the language offers you the building blocks to
express them. IMHO there are tree types of `beginners':

- First time programmers;
- Experienced programmers but still unaware of the OOD concepts;
- Experienced programmers aware of OOD concepts, but they don't know
  anything about the C++ language.

I think that one has to be a beginner of the third kind to be able
to learn the C++ language successfully.

kind regards and happy new year,

Jos aka jos@and.nl
From: chris.sokol@factory.com (Chris Sokol) 
Newsgroups: comp.lang.c++
Subject: Re: Converting EXE files
Date: 1 Jan 93 04:30:00 GMT
Distribution: world
Organization: Invention Factory's BBS - New York City, NY - 212-274-8298v.32bis
Reply-To: chris.sokol@factory.com (Chris Sokol) 

>>I was looking through some of my old disks and I came across some old C
>>programs I wrote 2 or 3 years ago.  I notice that some of the C source
>>codes were there also some EXE files.  I saw some EXE files that didn't
>>have any source code paired with it.  I was wondering if it was possible
>>to convert those EXE files back to it orginal source code?  Some of
>>those programs I written was quite interesting.

>No, it's not possible.

Sure it is.  Do it by hand.  Might take a little while though. <heh>
---
 . SLMR 2.1a . Taco Bell is NOT the Mexican phone company!
From: ralpht@meaddata.com (Ralph W. Trickey)
Newsgroups: comp.lang.c++
Subject: Re: "type safety" deemed essential
Date: 21 Dec 1992 20:25:37 GMT
Organization: Mead Data Central, Dayton OH
Distribution: world
NNTP-Posting-Host: retina.meaddata.com

In article <448@genie.UUCP>, roger@genie.UUCP (Roger H. Scott) writes:
|> In article <rmartin.724430168@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
|> >kocks@leland.Stanford.EDU (Peter Kocks) writes:
|> >
|> >>My $0.02.  Use Obj-C.  I have just spent a fair amount of time
|> >>comparing strong vs weak type casting systems [...]
|> >
|> >For any significant industrial application, I think strong typing is
|> >utterly essential.  It is just too easy to create horrible run time
|> >errors without type safety.  
|> 
|> This sounds like theory rather than practice speaking.  Let's hear from the
|> (net) C++ user community: who has written a non-trivial commercial C++ 
|> application *without* making significant use of either type casting [(T *)]
|> or run-time type checking [Bar *bar_p = foo_p->asBar();]?  I maintain that
|> C++ makes it *very* difficult to do without at least one or the other of these
|> (Eiffel-style "anchored" virtual function return types would go a long way to
|> alleviate this).  I'm hoping that templates will help in this regard, but they
|> haven't been available long enough to judge.

I have written several non-trivial commercial applications.
Type-casting was required for collection classes because I was writing
without templates, but it was used solely in accessor functions for
the collection class. Run-time type information was required for
persistency, and encapulated in it. I don't anticipate ever needing to
use these features for more than that. C++ requires a different design
methodology. If you have to query the object to find out what kind of
object it is, you may want to re-think your design to find out where
you lost that information.

I'm sorry, but I still remember the nightmares from programming in
BASIC and assembler. I don't program in Smalltalk, but from what I
have heard, it has the potential for the same problems. I want the
compiler to guarantee that the class can handle the message, and that
I won't spend days looking for w0rk.<G>

Ralph

-- 
Ralph Trickey       | (513) 865-6800                  |    	
Mead Data Central   | x4870                           |  Disclaimer
P.O. Box 933        | ralpht@meaddata.com             |  My opinions are my own
Dayton, Ohio  45401 | ...!uunet!meaddata!ralpht       |
Newsgroups: comp.lang.c++
From: burr@seas.gwu.edu (Timothy J. Burr)
Subject: Porting NIH C++ Class LIB to IRIS 4.0
Organization: George Washington University
Distribution: usa
Date: Tue, 22 Dec 1992 16:54:24 GMT

HI,

I you have done this I would sure appreciate some info on the process,
especially how to setup the nichl config file.

Tim

Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Is it possible to use 'delete this' ?
Organization: Rational
Date: Wed, 23 Dec 1992 16:47:48 GMT

bernd@bwhwob.escape.de (Bernd Wiegmann) writes:

>Hi,

>Is it possible to use 'delete this' as the last statement in a
>method of a class ?

In general, "delete this" is a bad idea.  I don't beleive you can
depend upon all the compiler vendors to generate code which is immune
to losing the object before the methods are complete.  Also, you run
into difficulties if the object was not allocated with new, or if you
overload new and delete and then allocate an array of objects.

In general, an object should not be privy to the method used to
allocate it.  It is the user of the object that decides whether it
should be dynamic, auto or static.  There is no good way for an object
to detect which of these allocation methods were used.  Morover, even
if you are absolutely certain that the object is dynamically
allocated, you still can't be absolutely sure which dynamic allocation
method was used.  Arrays of objects get deleted in a different way
than individual objects.  You cannot allocate an array and then delete
the individuals.

So, in short, avoid "delete this" where possible.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Indirect container classes
Date: 23 Dec 92 01:54:49 GMT
Article-I.D.: arolla.TMB.92Dec22175450
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: porum@county.oz.au's message of 20 Dec 92 23:20:25 GMT

In article <1992Dec20.232025.28984@county.oz.au> porum@county.oz.au (Peter Orum) writes:

   Could someone advise on what is the best method of
   having a collection of pointers to large objects. The
   large objects may appear on more than one list, but I
   only want one instance of each object  to be created.

	   a)	a list of pointers, eg List<String *>

	   b)	a list class that assumes its  data are pointers
		   eg Indirect_List<String *>

	   c)  use List<String>, but class String is implemented using
		   a pointer to a reference-counted String_rep.

   To  me,  method  a)  is  the easiest to implement but you lose
   the  ability  to  test  for  list  membership  by  content, as
   comparison is on absolute memory addresses.

   Method  b)  has  the  disadvantage  of (slightly) complicating
   the   List   class, requiring  overloading  of  the  comparison
   operators, search & copy functions.

   Method  c)  complicates the class definition, but means in the
   client  code  I  don't have to decide on which type of List to
   use, nor whether to use pointers or objects.

   What do other people do? 

Create a template class "Counted<T>" that gives you reference counted
semantics for arbitrary objects "T". Then, use "List< Counted<String> >".

This is pretty close to your suggestion (c), but I think giving
reference counted semantics to any type by default is a bad idea, so
"String" should not be reference counted (it should be copied on
assignment), while "Counted<String>" should be.

					Thomas.
From: suresh@argon.iss.nus.sg (Suresh Thennarangam - Research Scholar)
Newsgroups: comp.lang.c++
Subject: Re: How to call C++ functions in a C program?
Date: 22 Dec 92 10:36:10 GMT
Reply-To: suresh@iss.nus.sg (Suresh Thennarangam - Research Scholar)
Organization: Institute of Systems Science, NUS, Singapore

In article <1gqe3lINNs1v@eagle.natinst.com> banshee@natinst.com (Jeff Kellam) writes:
>In article <1gqbepINNt6s@function.mps.ohio-state.edu> ren@function.mps.ohio-state.edu (Liming Ren) writes:
>>I know we can call C functions inside a C++ program. Is there a way to
>>call a C++ function inside a C program? I tried to link  a C program with 
>>a C++ function as follows:
>>
>>Where f.o has a very simple C++ function inside and g.c is a simple C
>>program calling the function inside f.o. It dose not WORK!
>
>Basically, you can't.
>
>The C++ compiler mangles the name of the C++ function, thus the linker won't
>match it with the name you'd expect from C.  
>
>
>Of course, even if you get the name mangling taken care of, you'd still
>have to handle things like explicitly passing a pointer to the object and
>setting up virtual tables similar ugly things.  Thus my original answer,
>you can't.

You can really. 

You need to write a C wrapper for the C++ function and 
prevent the C++ compiler from mangling the wrapper name by encasing
it in an "extern C" declaration. Then you can call the wrapper and 
the linker will resolver the references correctly. For quick hacks 
you can dispense with the wrapper scheme and just encase the C++
function name in the aforementioned "extern C" declaration. However
wrappers are an elegant solution to other problems that may arise.
An earlier post of mine said a bit more about this subject in answer
to a very similar question. For a good detailed treatment please look
at "The Sun C++ programmers Guide" Appendix G.

Regards and Merry Christmas,


      __                  
     (_   / /  o_   o  o |_
     __)/(_( __) (_(_ /_)| )_


***************************************************************************
* Suresh Thennarangam               *  EMail: suresh@iss.nus.sg(Internet) *
* Research Scholar                  *         ISSST@NUSVM.BITNET          *
* Institute Of Systems Science      *  Tel:  (065) 772 2588.              *
* National University Of Singapore  *  Facs.: (065) 778 2571              *
* Heng Mui Keng Terrace             *  Telex: ISSNUS RS 39988             *
* Singapore 0511.                   *                                     *
***************************************************************************
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Undefined new and delete
Organization: Rational
Date: Wed, 23 Dec 1992 16:56:56 GMT

swk7@cbnewsk.cb.att.com (steven.w.koenig) writes:

|If one wanted to insure that no objects of a given type were ever created
|on the heap, it seems logical that one should be able to declare the
|new and delete operators as private but not define them.

Unfortunately, this does not insure that the objects will not be
allocated on the heap.  If an array is allocated, the operator new
member will not be invoked; the global operator new will be invoked
instead, and the objects will be on the heap.

If you REALLY want to insure that the objects cannot be allocated on
the heap, then make all the constructors private.  Create a helper
class which is a friend.  The helper class will ALWAYS create the
object on the heap, even though the helper itself may be allocated in
many different ways....



--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: jbuck@foucault.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: template disappointments ... (suggestions?)
Date: 29 Dec 1992 23:36:06 GMT
Organization: U. C. Berkeley
Distribution: world
NNTP-Posting-Host: foucault.berkeley.edu

In article <24508@alice.att.com> ark@alice.UUCP () writes:
>In article <DSCHIEB.92Dec29133556@muse.cv.nrao.edu> dschieb@muse.cv.nrao.edu (Darrell Schiebel) writes:
>> 		list<vector<int>> list_vec_int;
>
>Huh?? This works fine -- just remember to put a space between the
>two > characters so the >> won't be taken for a shift-right symbol.

This is such a common error (and is so ugly) that compiler writers
would be well advised to add productions to their grammar that catch
it, or magic that splits the >> token into two tokens in this case
if that fits in with the compiler's structure.

Yes, I know that the rules of lexical analysis force the >> to be one
token, but list<vector<int>> is a perfectly natural way of writing
this thing, so perhaps it should be permitted even at the cost of
adding an ugly rule to the grammar.



--
Joe Buck	jbuck@ohm.berkeley.edu
From: mike@istech.msk.su (Michael Korotkih)
Newsgroups: comp.lang.c++
Subject: Re: Death of Borland C++ Compiler
Date: Mon, 21 Dec 92 15:55:26 +0200
Distribution: world
Organization: Information Systems and Technologies
Reply-To: mike@istech.msk.su

> I recompile the same source code in Zortech.  It WORKS.

>  I wonder if anyone else has the same experiences with me?

    Yes. You may try turn on and off switches in Optimizations Dialog Box.
May be you can receive worked code. But if you want FAST code,
then compile only in Zortech - it creates more fast code.
I wonder, why Borland cannot write normal compiler ?
I like IDE, but if I need 32-bit code or fast code or worked code, then
I use Zortech.

    And at all, now I cannot buy BC++ 3.1 - my dealer cannot take
BC++ 3.1 from Borland. May be this problem exist only in Moscow ?

                                                        Mike.







Newsgroups: comp.lang.c++
From: bear@kestrel.fsl.noaa.gov (Bear Giles)
Subject: Re: Weird problem under Sun/C++
Organization: Forecast Systems Labs, NOAA, Boulder, CO USA
Date: Wed, 30 Dec 1992 18:21:56 GMT

Since several people have suggested a problem with specifying the
library, let me make it clear that this is _not_ the cause.

% cc -o pgm pgm.o sagebrush.a

causes the error

  TupleFile::find ([4 lines of parameters deleted]) not found

However, if we extract the object file containing TupleFile::find()
from the library and attempt to link:

% ar r sagebrush.a tuple.o
% cc -o pgm pgm.o sagebrush.a tuple.o

the "TupleFile::find () not found" error message goes away, although
we now get a large number of "multiply defined" errors.  

(The object file must follow the library since the object file is
pretty deep in the call tree of the RDBMS).

The fact that the link works with an object file but not with the
same object file embedded in a library is what worries us.  We could
make a workaround, but what else will break?  (BTW, I can link without
problems, but my coworker can't even though we are using the same
NSF-mounted compiler!)

FYI, The exact form of TupleFile::find() provided by nm++ is:

00002794 T   TupleFile::find(int(*)(unsigned const char* const,unsigned const
		char* const),unsigned const char* const,long&,DBStatus(*)
		(unsigned const char* const,unsigned const char* const,const
		long,const long,unsigned char*),unsigned char*)
             [_find__9TupleFileFPFCPCUcT1_iCPCUcRlPFCPCUcT1ClT3PUc_8DBStatusPUc]

	     (Note the mangled name!)


Bear Giles
bear@fsl.noaa.gov
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Converting EXE files back to C source code
Organization: Computer Science, University of Melbourne, Australia
Date: Mon, 28 Dec 1992 09:59:01 GMT

bucjet@uxa.ecn.bgu.edu (Jeffrey Terrell) writes:

>I was looking through some of my old disks and I came across some old C
>programs I wrote 2 or 3 years ago.  I notice that some of the C source
>codes were there also some EXE files.  I saw some EXE files that didn't
>have any source code paired with it.  I was wondering if it was possible
>to convert those EXE files back to it orginal source code?  Some of
>those programs I written was quite interesting.  

No, it's not possible.

-- 
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: 76336.3114@CompuServe.COM (Kevin Dean)
Subject: Standard library functions and macros
Date: 31 Dec 92 03:33:02 GMT

Date: 12-23-92 (20:14)              Number: 3022 of 3071
  To: ALL                           Refer#: NONE
From: JIM ADCOCK                      Read: (N/A)
Subj: STANDARD LIBRARY FUNCTION     Status: PUBLIC MESSAGE
Conf: U-COMPLANGC++ (3870)       Read Type: GENERAL (+)

In an article dated 12-23-92, Jim Adcock (jimad@microsoft.com) writes:

>I'd counterpropose why don't we all just *leave prior standards alone*
>unless we have overwhelming reasons to change them.  The standard library
>function names in C are reserved.  Leave them reserved, and leave them
>their C "meanings".  There is no more reason why C++ people ought to be
>dinking with these reserved words than any of the other reserved words
>from C, such as "for" "if" "else" "struct" etc.

Why should function names be reserved?  They are functions, after all, and
are thus outside the definition of the language.  If they have to be
overridden or defined as macros, can't they just be inlined?  Off the top
of my head, I can only think of the assert() macro that couldn't be
rewritten as an inline function because it has to dump context-sensitive
information like file and line number if it's to be of any use.

The reason I say this is that reserving the function names can make for
severe maintenance headaches.  Suppose I have a class that has member
functions read() and write() and the C-standard read() and write() have
been redefined as macros by the compiler.  What then?  The member
functions get replaced by the macros and my class goes out to lunch.  I
have now lost the use of two very useful and meaningful names (I've had
this happen, though not with read() and write()).

Kevin Dean

SNAG: acronym for Sensitive New-Age Goof, one who, without any relevant
experience, is always willing to enlighten the ignorant masses on the
social issue of the day.  Have you hit any SNAGs lately?


Newsgroups: comp.lang.c++,gnu.g++.help
From: zougas@me.utoronto.ca (Tom Zougas)
Subject: static member initialization
Organisation: U of Toronto, Dept. of Mechanical Engineering
Organization: UofT Mechanical Engineering
Distribution: comp
Date: Tue, 29 Dec 1992 18:42:44 GMT

I'm using gcc-2.3.2 on a Sparc, Sun OS4.1.1 and am having difficulties
with the following situation:

I declare a template class which contains a static member. When I try
to initialize the static member, it doesn't work unless I do it inside
the scope of 'main'. Static members of non-template classes can be
initialized outside the scope of 'main' and I would expect the same
for template classes. Is this how template classes work or is it a
bug in the gcc compiler? Please e-mail any responses. Thanks.

The following is the test code I used:

// beginning of included file: test.cc
////////////////////////////////////////////////////////////////
#include <iostream.h>

class Int {
public:
  Int( int i ) { _i = i; }
  void print() { cout << _i << endl; }
  int _i;
};

class _Test {
public:
  _Test() {}
  void print() { x.print(); }
  static Int x;
};

template <class Type>
class Test : public _Test {
public:
  void print() { _Test::print(); x.print(); }
  static Int x;
};

Int _Test::x(99);
//Int Test<int>::x(88);	// <=== this is where I want to initialize
			//	but doesn't work

main()
{
  Int Test<int>::x(88);	// <=== this is where I have to initialize
			//	to get it to work
  Test<int> ti;
  ti.print();
  test();
}

////////////////////////////////////////////////////////////////
// end of included file
-- 
===========================================================================
Tom Zougas					      zougas@me.utoronto.ca
Engineering Mechanics and Design Laboratory		       416-978-1281
Dept of Mechanical Engineering, University of Toronto,      Toronto, CANADA
Newsgroups: comp.lang.c++,comp.os.msdos.programmer
From: wlee@sales.GBA.NYU.EDU (Wai-Shing Lee)
Newsgroups: comp.lang.c++
Subject: Static global initialization outside of main() legal?
Date: 31 Dec 92 06:39:39 GMT
Organization: NYU


   I want to initialize a static global at run-time but I don't want to
have to have a programmer using my modules to have to call some init() funciton
at the begining of thier main().

I can get this to compile under Borland C++ 3.1, but only if it is compiled as
C++, it doesn't like it if it is compiled as plain Borland C.

extern "C"
{
#include <alloc.h>
}

static int *pointer ;
static int initialized=findvideomemory() ;

static int makepointer(void)
{
	pointer=(int*)calloc(10, sizeof(char)) ;
}

The variable "initialized" is junk, but I could just as easily return a value
from makepointer(), but I have more stuff going on in makepointer() than
appears here.

I've traced it and sure enough makepointer() is called and pointer is assigned
a value before main() even starts.  Is the portable, legal.  I didn't look
to hard in my C++ book, but there weren't any obvious answers.  Is this
C++, C or something I should stay away from?

Thanks
Newsgroups: comp.lang.c++