HDTenEightyP/NetNews huggingface dataset:
From: qding@uoft02.utoledo.edu
Newsgroups: comp.lang.c++
Subject: Help: Pascal to C/C++ translator needed
Date: 30 Aug 92 04:44:33 EST
Organization: University of Toledo, Computer Services

Hi, there.

I am a C/C++ programmer. Recently I have a lot Pascal codes need to be 
translated to C/C++. Can anyone tell me where I can find any product 
which does Pascal --> C translating please? I downloaded one from 
simtel20. But it does not translate WITH. I would like to know anywhere
else I can download one better than this. 

Thanks in advance.
From: harrison@lclark.edu (Mark Harrison)
Newsgroups: comp.lang.c++
Subject: Re: Turbo C++, function prototypes
Date: 2 Sep 92 17:16:25 GMT
Article-I.D.: lclark.1992Sep2.171625.13525
Organization: Lewis & Clark College, Portland OR

In article <1992Sep2.162728.11201@taumet.com> steve@taumet.com (Steve Clamage) writes:
>harrison@lclark.edu (Mark Harrison) writes:
>
>>>main's correct return type is 'int'.
>
>>It should make no difference whether you try 'int' or 'void' as long as
>>main() returns the correct value (or doesn't with void.)
>
>It ought to make a difference, since the only valid definitions of
>main() have return type 'int' (explict or implied).  This is the case
>in both Standard C and in C++.  If you write, for example,
>	void main(){ }
>The compiler is obligated to diagnose an error in C and C++.
>
>The return value from main() is supposed to be supplied to the calling
>environment in some implementation-defined way.  Some systems appear not
>to care whether you return a value, but some report error conditions
>based on the garbage value which main() otherwise implicitly returns.

Well, I have since learned, that you should ALWAYS return a value.  But
still, I have Turbo C/C++ 3.0, and my compiler is NOT obligated to
diagnose an error.  I know because I've used 'void main()', and everything
compiles & runs just fine.  Of couse I've never thought of having others
run them who might want to put them in some kind of batch file that
expects a return value.


-- 
=============================================================================
Mark Harrison           |  "We are the Priests, of the Temples of Syrinx
harrison@sun.lclark.edu |   Our great computers fill the hallowed halls."
              -- Me     |                                    -- Rush
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 26 Aug 92 21:04:51 GMT

kevinl@tisdec.tis.tandy.com writes:


|	I have to paritally disagree.  Everytime you add a flag variable,
|you are doubling the number of states for your program.  The more states,
|the more possible paths, and the more paths, the more possible unforseen
|errors (if the paths are not anticipated and tested--something that is
|very hard to do).

No, the influence of state variables which control loops is limitted
to the loop condition, and possibly to tests at the completion of the
loop.  Thus, the "doubling" does not occur.

|	For experienced programmers, the goto is a legitamite tactic.
|There may not be any cases where a goto is absolutly necessary (I've
|heard that there are some, but I have yet to see any), but putting
|a goto instead of, say, another function call in a path that is called
|10,000 times each time the program is run, saves massive amounts of
|time.

Experience is not a license for abuse.  It is the code of the
inexperienced programmers that is hard to read.  The more experienced
the programmer, the easier his code ought to be to read and maintain,
even by the inexperienced.

I disagree that goto is a tool for the "experienced" instead I view it
as an error of the inexperienced.  

|	I agree that programs are generally easier to understand and
|debug when there are no goto statements, but, if well documented
|gotos are just another structured technique.

Oh, I agree that you can write "harmless" gotos.  But the point is
that you don't have to.  A goto is never truly necessary.
Occationally, (very very occationally) you might find a use for a goto
that is actually justified.  But in the last 15 years, I have found
only one, and that was at 2 in the morning after working a few 70 hour
weeks.  In retrospect, the justification might have been based more on
fatigue than fact.  

--
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: brennan@hal.com (Dave Brennan)
Newsgroups: comp.lang.c++
Subject: cfront, objectcenter bug?
Date: 3 Sep 92 06:36:46 GMT
Organization: HaL Computer Systems, Austin, TX
NNTP-Posting-Host: yosemite.hal.com

When the following program is run, both cfront and objectcenter print:

destruct derived
destruct base
destruct base
delete base

g++ won't compile this program.  I believe that the explicit call to
base::~base should not result in the derived destructor being called.
Can anyone confirm or deny this?


extern "C" void puts (char *);

class base
{
public:
  virtual ~base ()
    { puts ("destruct base"); }
  void operator delete (void *)
    { puts ("delete base"); }
  void destruct ()
    { base::~base (); }
};

class derived : public base
{
public:
  ~derived ()
    { puts ("destruct derived"); }
  void operator delete (void *)
    { puts ("delete derived"); }
};

int
main ()
{
  base *b = new derived;

  // This call to destruct wipes out the vtbl!
  b->destruct ();

  delete b;
}

--
Dave Brennan                                      HaL Computer Systems
brennan@hal.com                                         (512) 794-2855

Visit the Emacs Lisp Archive: archive.cis.ohio-state.edu:pub/gnu/emacs
From: rgp@mpd.tandem.com (Ramon Pantin)
Newsgroups: comp.lang.c++
Subject: Re: Tiny proposal for named loops.
Date: 27 Aug 92 03:56:12 GMT
Organization: Tandem Computers, Micro-Products Division

In article <rmartin.714863856@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>Again, I disagree.  I find this construct:
>   while (error == NO && done == NO)
>easier to understand than:
>   ...

(Don't mean to start another religious war :-)

I find this verbose and hard to read:
	while (error == NO && done == NO)
Thought process when I see this:
	"while error is equal to NO (what the heck is `NO'?)
	and done is equal to the same `NO'"

What is wrong with good old C code as the goods meant it to be?
	while (!error && !done)
Thought process when I see this:
	"while not error and not done"

You don't believe in boolean expressions either?  :-)

The same can be said for:
	if (flag & XXX)
which is easier to understand than:
	if ((flag & XXX) != 0)
Don't you find this kind of verbosity incredibly ugly ?

I'll be sure that the "end is near" when I see:  :-)
	if (((flag & XXX) != 0) == TRUE)

Ramon Pantin
Newsgroups: comp.lang.c++
From: arthur%Solomon.Technet.sg (Arthur Sombrito)
Subject: setting array size
Organization: National University of Singapore
X-Newsreader: Tin 1.1 PL5
Date: Fri, 28 Aug 1992 03:24:27 GMT
From: warsaw@nlm.nih.gov (Barry A. Warsaw)
Newsgroups: comp.lang.c++
Subject: External or internal linkage according to ARM?
Date: 2 Sep 92 20:30:03 GMT
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.


In the following example, should the symbol Singleton::OnlyOne have
external linkage or internal linkage?  Cfront 2.1 say external, but
g++ 2.2.2 gives only internal and the question of which is correct has
come up.

----single.h----
#include <iostream.h>
class Singleton
{
public:
	static const Singleton& const OnlyOne;
	void dosomething() { cout << "doing something" << endl; };
protected:
	Singleton( void ) {};
};


----single.cc----
#include "single.h"
class SingletonBuilder : public Singleton
{
public:
	SingletonBuilder( void ) {};
};


const SingletonBuilder secretlyBuiltByLibrary;
const Singleton& const Singleton::OnlyOne = secretlyBuiltByLibrary;


----main.cc----
#include "single.h"
int main( int, char** )
{
	Singleton::OnlyOne.dosomething();
	return( 0 );
};


Note that with g++ 2.2.2, if I change OnlyOne's definition to:

	static const Singleton& /* const */ OnlyOne;

(ie no second const), then it compiles fine under g++.  So who's
wrong, cfront or g++?

Thanks,
-Barry
From: gerry@cmu.edu (Gerry Roston)
Newsgroups: comp.lang.c++
Subject: Which c++ to buy for PC?
Date: 2 Sep 92 22:41:06 GMT
Article-I.D.: onion.GERRY.92Sep2174106
Reply-To: gerry@cmu.edu (Gerry Roston)
Organization: Field Robotics Center, CMU

I can purchase Turbo C++ for Windows through the university computer
store for a rediculously low price.  My questions are this:
1-Is this a good compiler?
2-Does this package include the linker and debugger?
3-My SO wants to learn C.  Is it possible to use this compiler as a
  standard ANSI C compiler?

Please respond by email and I will summarize.  Also, if there are
other appropriate newsgroups, would some kind soul please cross-post
this for me.  Thanx!

--
Gerry Roston (gerry@cmu.edu)    | II - A well regulated Militia, being
Field Robotics Center,          | necessary to the security of a free State,
Carnegie Mellon University      | the right of the people to keep and bear
Pittsburgh, PA, 15213           | Arms, shall not be infringed.
(412) 268-3856                  | 
                                | 
The opinions expressed are mine | 
and do not reflect the official | 
position of CMU, FRC, RedZone,  | 
or any other organization.      |
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 3 Sep 92 13:23:02 GMT

potts@itl.itd.umich.edu (Paul Potts) writes:

|I use "goto" sparingly as well, and agree that it can be very useful in
|cases, and even make code *more* readable. BASICally <grin> I use it 
|only to exit from loops where adding additional conditions to the loop
|would make the code much more obscure and slow, or to skip down past a
|piece of code to the end of the loop under some circumstances. 

|To make GOTO more readable, NEVER go backwards in your code, only
|forwards; use only one GOTO in a block, and comment explicitly. If GOTO
|is used only under certain conditions, the argument against writing
|spaghetti code really doesn't apply.

Paul, though you rail against the proscription of goto, you have
simply replaced it with several proscriptions and warnings of your own
making.  You tell us NEVER to do some things, and to "skip down" in
"some circumstances" and "use only one" in others.  

I am sure that there are others who might disagree with your "one goto
per block" rule.  Others may disagree with your "NEVER go backwards"
rule.

You don't have to make up your own rules.  Some other guys, who have
thought about it alot, have put together a pretty well thought through
set of rules.  Moreover, the industry has, for the most part, accepted
those rules as valid.  Moreover, it has been proven that those rules
are always workable, and it has been shown that they help to make code
more readable and maintainable.  

So, why invent your own?  

Now, granted, there are some cases where the rules of Structure
Programming do not create the most efficient possible code.  And in
cases where efficiency is of primary importance, then the rules should
be violated, without regret.

But in most cases, there is no good reason to invent your own, ad-hoc,
software methodology.

--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Distribution: world
Subject: Re: a few rookie questions about testing for CLASSS membersh
X-Mailer: cppnews $Revision: 1.14 $
Organization: Trumphurst Ltd.
Date: Wed, 2 Sep 1992 10:03:50 +0000


In article <17hdhdINNgjv@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe Buck) writes:

> In article <1992Aug25.204448.15682@cs.wisc.edu> roth@ordin.cs.wisc.edu (Bill Roth) writes:
> >
> >I'm a relative rookie to C++, though not to OOP (due to many moons of
> >programming in Objective-C).
[Other questions deleted].

> To understand the distinction between the C++ model of types and that of
> Smalltalk (which is very close to that of Objective-C), I suggest reading
> Chapter 12 of Stroustrup's "The C++ Programming Language, 2nd edition".

I would like to add that the C++ FAQ covers this sort of question in a 
friendly but thorough way. It is both free and highly valuable and I
recommend it to everyone who is interested in C++. 

Many thanks to Marshall Cline for compiling and maintaining it. 

It can be obtained ...

Via ftp - Anonymous ftp from sun.soe.clarkson.edu [128.153.12.3] :pub/C++/FAQ

Via mail - send mail 
To: archive-server@sun.soe.clarkson.edu
Subject: send C++/FAQ

---
Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
From: vkemp@niksula.hut.fi (Vesa KEMPpainen)
Newsgroups: comp.lang.c++
Subject: j = 8; table[j] != table[8] ???
Date: 26 Aug 92 01:48:45 GMT
Organization: Helsinki University of Technology, Finland


I tried to compile and run this under Borland C++:

// Hash.h

#ifndef _Hash_
#define _Hash_
#define HASH_TABLE_SIZE 11
#define NULL 0

class Hash
{
 protected:
  void insert(void *p);
  void *find(char *key);
  Hash();
  ~Hash();
 private:
  int hashValue(char *);
  struct Item
    {
      char *key;
      void *data;
    };
  Item *hashTable[HASH_TABLE_SIZE];
};
#endif


// Hash.C

#include "Hash.h"
#include <string.h>
#include <iostream.h>
#include <process.h>

Hash::Hash()
{
  for(int i = 0; i < HASH_TABLE_SIZE; i++)
    hashTable[i] = NULL;
}

int
 Hash::hashValue(char *s)
{
  unsigned hashnumber;
  for(hashnumber = 0; *s != '\0'; s++)
    hashnumber = *s + 31 * hashnumber;
  return (hashnumber % HASH_TABLE_SIZE);
}


void
 Hash::insert(void *p)
{
  Item *newItem = new Item;
  newItem = (Item *)p;
  int hashnumber = hashValue(newItem->key);
  
  for (int i=0; i < HASH_TABLE_SIZE; i++)
    {
      if (hashTable[(hashnumber+i)%HASH_TABLE_SIZE] == NULL)
	{
	  hashTable[(hashnumber+i)%HASH_TABLE_SIZE] = newItem; //!!!!!!!!
	  return;
	}
    }
  cerr << "FATAL ERROR: hashtable full. Exiting ... ";
  exit(1);
}


void *
 Hash::find(char *key)
{
  int hashnumber = hashValue(key);
  
  for (int i=0; i < HASH_TABLE_SIZE; i++)
    {
      if (hashTable[(hashnumber+i)%HASH_TABLE_SIZE] != NULL)
	{
	  if (key == (Item *)hashTable[(hashnumber+i)%HASH_TABLE_SIZE]->key)
	    return (Item *)hashTable[(hashnumber+i)%HASH_TABLE_SIZE]->data;
	}
      else return NULL;
    }
  return NULL;
}


 Hash::~Hash()
{
}


This compiles without errors but doesn't run correctly. There seems to be two
problems:

1) In Hash::Insert hashTable[hashnumber] != hashTable[8] even though 
int hashnumber == 8.

2) hashTable[hashnumber] = newItem doesn't do anything. At least not when 
tracing the program and monitoring hashTable[8] and hashTable[hashnumber].

hashTable[8] is always NULL and hashTable[hashnumber] is some address.


Any suggestions? I've run out of ideas. (I've read the FAQ I found at garbo.)

Please reply by email vkemp@silver-surfer.cs.hut.fi.

If someone else is interested in the same problem let me know - I'll
post my replies.




--
Vesa
Newsgroups: comp.lang.c++
From: adk@Warren.MENTORG.COM (Ajay Kamdar)
Subject: Re: copy ctor and inheritance
Organization: Mentor Graphics Corp. - IC Group
Date: Fri, 4 Sep 1992 14:36:44 GMT

In article <6143@taurus.cs.nps.navy.mil> skip@taygeta.oc.nps.navy.mil (Skip Carter) writes:
>
>	How do I get the copy constructor of a base class to get invoked
>	when I use a copy constructor for a base class ?
>
>	In the following example I get the behaviour I want (AT&T 2.1)
>	if I leave it up to the compiler to create the copy constructor for B,
>	but if I write my own, the copy constructor for the base class A never
>	gets invoked.  (It does not matter whether or not I define the copy constructor
>	for the base class, A).

>
>    // If the constructor below is commented out, A::val is copied
>	//    B(const B& b) { vv = b.vv; cout << "B(&B) invoked\n"; }

B's copy constructor should be written as:

	B(const B& b) : A(b) { vv = b.vv; cout << "B(&B) invoked\n"; }


- Ajay

-- 
I speak for none but myself.

Ajay Kamdar                               Email : ajay_kamdar@mentorg.com
Mentor Graphics, IC Group (Warren, NJ)    Phone : (908) 580-0102
Newsgroups: comp.lang.c++
From: sch@mitre.org (Stu Schaffner)
Subject: Re: Constructors in C++
Followup-To: comp.lang.c++
Organization: MITRE Corp.
Date: Thu, 27 Aug 1992 20:40:27 GMT

In article <1992Aug27.155652.11995@kakwa.ucs.ualberta.ca>,
jimmy@namao.ucs.ualberta.ca  wrote:
> 
> Does a constructor with parameters call the default constructor ? I am
> a novice, so please do not laugh.
> Thanks,
> Jimmy
> 
> jimmy@namao.ucs.ualberta.ca
> 
> --
> jimmy@namao.ucs.ualberta.ca

Nothing to laugh about ... there are a number of subtleties associated with
constructors.  The short answer is no, nor should you call the default
constructor explicitly in the nondefault constructor. Recall that a
constructor really does two things in sequence:  initialize the object
enough that methods can be called, then execute a constructor body. A call
in that body to another initializer would repeat the initialization.

There is a good explanation of all of this in Ellis & Stroustrup, "The
Annotated C++ Reference Manual", sometimes called "the ARM" (ISBN
0-201-51459-1.  In the 1990 version, at least, it starts on page 262. This
also gives an example of how to factor out code common to more than one
constructor.

Stu Schaffner, not speaking for
The MITRE Corp.
sch@mitre.org
From: harrison@lclark.edu (Mark Harrison)
Newsgroups: comp.lang.c++
Subject: Re: Turbo C++, function prototypes
Date: 1 Sep 92 16:08:16 GMT
Article-I.D.: lclark.1992Sep1.160816.10309
Organization: Lewis & Clark College, Portland OR

In article <2262@bigfoot.first.gmd.de> jh@first.gmd.de (Joerg Heuer) writes:
>zpvy0a@hou.amoco.com (Prasad Yalamanchi WWNV x4269 9.125) writes:
>
>>I am trying to compile a program on Turbo C++, 3.0 . It gives me the following
>>error.  main () , function prototype missing.  Do i need to put in the
>>'main' function's prototype.  >>void main();  was still giving me errors. 
>>Could someone help.
>
>main's correct return type is 'int'. Try it. It's always better to write
>the things You mean explicitly. (Though it should work with the implicit
>'int'.)
>
>J"org.

It should make no difference whether you try 'int' or 'void' as long as
main() returns the correct value (or doesn't with void.)  But I had this
same kind of problem recently.  It came from compiling a program from the
IDE.  In my project window, I listed the lib & obj files to link into the
project, but forgot to add my program.  If you are using the project
feature, make sure you have included your program that has main() in the
project window.


-- 
=============================================================================
Mark Harrison           |  "We are the Priests, of the Temples of Syrinx
harrison@sun.lclark.edu |   Our great computers fill the hallowed halls."
              -- Me     |                                    -- Rush
Newsgroups: comp.lang.c++
From: rbm@cbnewsb.cb.att.com (robert.murray)
Subject: Re: class browser engine for C++?
Organization: AT&T
Date: Tue, 1 Sep 1992 14:25:40 GMT

In article <65018@cup.portal.com> Lee_Robert_Willis@cup.portal.com writes:

>I'm looking for a C++ equivalent of Ada's DIANA ...
>

At the Advanced Topics Workshop of the 1992 USENIX C++ Conference in Portland
last month, several speakers described ongoing work on internal
representations for C++ programs.  I also presented a paper at the main
conference, ``A Statically Typed Abstract Representation for C++
Programs'' (see the Proceedings) that describes some of the work
being done in this area by a bunch of us at Bell Labs.

Lots of people are interested in this problem.
Hopefully a result of the workshop will be an increase
in the communication between the various parties, so that we end up
with a single widely accepted representation.

-Rob Murray
AT&T Bell Labs.
Xref: sparky comp.lang.c++:13252 comp.object:3406 comp.std.c++:1124
From: rhyspj@occs.cs.oberlin.edu (Rhys Price Jones)
Subject: Suggestions solicited for ACM/SIGCSE panelists
Organization: Oberlin College Computer Science
Distribution: comp.lang.c++ comp.lang.ada comp.lang.functional comp.lang.prolog comp.lang.pascal comp.lang.forth
Date: Wed, 2 Sep 1992 21:24:05 GMT
X-Posted-From: occs.cs.oberlin.edu
X-Posted-Through: sol.ctr.columbia.edu

I am looking for participants in a panel discussion  for next year's
SIGCSE to discuss issues affecting choice of language in CS1 - the
introductory CS course.  Please e-mail me suggested names for
advocates of your particular favorite introductory language.

Thanks

Rhys Price Jones                            
Cyd-athro Cyfrifiaduriaeth                   ____
Associate Professor Computer Science        /   / /
Oberlin College                            /   / /
King 223C                                 /___/ /__      __
Oberlin OH 44074 - USA - UDA             / \   /  / / / (
(216) 775 8697                          /   \_/  /_/_/ __)
<rhyspj@occs.cs.oberlin.edu>                      __/_/
--
Rhys Price Jones                            
Cyd-athro Cyfrifiaduriaeth                   ____
Associate Professor Computer Science        /   / /
Oberlin College                            /   / /
King 223C                                 /___/ /__      __
Oberlin OH 44074 - USA - UDA             / \   /  / / / (
(216) 775 8697                          /   \_/  /_/_/ __)
<rhyspj@occs.cs.oberlin.edu>                      __/_/
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: complex classes and temporary destruction.
Date: 30 Aug 92 02:41:36 GMT
Article-I.D.: alice.23592
Reply-To: ark@alice.UUCP ()
Distribution: world
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <64915@cup.portal.com> Aurelius@cup.portal.com (Mark Christian Barnes) writes:

>  If operator+(a,b) does, in fact, construct a temporary of type
> String, then the compiler could determine its storage class,
> perhaps based upon the storage class of the context to which
> it is applied.

Sorry, but I'm not going to tell you what operator+(a,b) does.
I'm compiling it separately and giving you the object code to link
in with your source code.

Now, how is the compiler going to determine its storage class when
it is compiling your program?
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++