HDTenEightyP/NetNews huggingface dataset:
From: sasha@ipm.msk.su (Alexander Kolbasov)
Subject: Re: Pascal to C Translator (sed script).
Reply-To: sasha@ipm.msk.su
Organization: unknown
Date: Thu, 23 Jul 92 22:09:16 +0400

This is a very simple `sed' script for Pascal->C translation. I used
it for rapid pre-translation. It doesn't produce compilable code but
is quite useful (at least for me). All improvements/suggestions are
greately encouraged.

--------------- Cut Here -------------------------------------
s/\([A-Za-z0-9\.\^_]*\) *= *[Aa]rray *\[\([A-Za-z0-9\._]*\)\] *[Oo]f *\([A-Za-z_]*\)/\3 \1 [\2]/g
s/\([A-Za-z0-9_\.\^]*\) *: *[Aa]rray *\[\([A-Za-z0-9_\.]*\)\] *[Oo]f *\([A-Za-z_]*\)/\3 \1 [\2]/g
s/{\$[A-Za-z+\-,]*/{/g
s/{}//g
s/\{/\/\*/
s/\}/\*\//
s/:=/></
/[Cc]onst/ s/:/ /
/[Tt]ype/ s/=/ /
s/ =/ ==/g
s/></=/g
s/<>/!=/g
/[Cc]onst/ s/==/=/
s/'/"/g
s/\^\./->/g
s/\([A-Za-z0-9_\[\]]*\)\^/*\1/g
s/ [Ii]f / if (/
s/ [Tt]hen/) /
s/ [Ww]hile/ while (/
/ [Ww]ith/ d
s/begin/\{/
s/end;/\}/
s/end\./\}/
s/\([$ ]\)end/\1}/
s/[Rr]ecord/struct {/
s/[Bb]oolean/bool/
s/[Ii]nteger/int/
s/[$ ][Tt]ype/typedef/
s/[Pp]rocedure/void/
/void/s/);/)/
s/[Ff]unction *\([A-Za-z0-9_ ,(:;]*)\) *: *\([A-Za-z0-9_]*\)/\2 \1/
s/\( *\)\([A-Za-z0-9_ ,]*\) *: *\([A-Za-z0-9_]*\)/\1\3 \2/g
s/( */(/g
s/ *)/)/g
s/[Vv]ar//
s/ *;/;/
s/[Ff]or *\([A-Za-z0-9_]*\) *= *\([A-Za-z0-9_\. +\-]*\) *[Dd]ownto *\([A-Za-z0-9_\. +\-]*\) *do/for (\1 = \2; \1 >= \3; \1--)/
s/[Ff]or *\([A-Za-z0-9_]*\) *= *\([A-Za-z0-9_\. +\-]*\) *[Tt]o *\([A-Za-z0-9_ +\-]*\) *do/for (\1 = \2; \1 <= \3; \1++)/
/[Ww]hile/ s/ [Dd]o/)/
s/ [Ii]nc(\([A-Za-z0-9_]*\))/\1++/g
s/ [Ii]nc(\([A-Za-z0-9_]*\), *\([A-Za-z_0-9+\- ]*\))/\1 += \2/g
s/ [Dd]ec(\([A-Za-z0-9_]*\))/\1--/g
s/ [Dd]ec(\([A-Za-z0-9_]*\), *\([A-Za-z_0-9+\- ]*\))/\1 -= \2/g
--------------- Cut Here -------------------------------------
__
.......................................................
. Alexander V. Kolbasov  |  INTERNET sasha@ipm.msk.su .
. Moscow, Russia         |  (095) 434-2031 (o)        .
.......................................................
Newsgroups: comp.lang.c++
Subject: Re: Efficient 64-bit integer arithmetic
From: khill@vax1.umkc.edu
Date: Sat, 25 Jul 1992 13:15:52 GMT
Organization: University of Missouri - Kansas City

In article <711997458snx@trmphrst.demon.co.uk>, nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
> I need to implement efficient 64-bit signed integer arithmetic in C++ (or C)
> on a machine with a 32-bit long (actually, 60 significant bits + sign
> would do fine). 
> 
> I need addition, subtraction, multiplication, division, remainder, and 
> efficient multiply and divide by 10 (for conversion to/from strings).
> 
> I have looked at the bignum package, which implements arbitrary precision,
> but I feel the extra constraint of having only 60 significant bits should 
> enable a much more efficient implementation to be possible.
> 
> Does anyone know of any such code available for anonymous ftp ? Or have 
> any suggestions ?

  I do not have any code to offer, at this time, but I do have a suggestion.
Isn't the idea of doing 64 bit arithmetic on a 32 bit machine the same question 
as doing 32 bit arithmethic on a 16 bit machine?  I mean, if you did a straight
search/replace on all the 16 bit instructions and replaced them with 32 bit
instructions would this not be a REASONABLY (not neccesarily the best)
efficient routine.  After all, the mathematics would not be changing, just the
base of the arithmetic.
-- 
===============================================================================
!        Ken Hill       ! This message is SHAREWARE.  You are authorized      !
!        --------       ! to use this message for up to 5 days.  If you       !
!  KHILL@VAX1.UMKC.EDU  ! like what you see please register it by sending     !
========================! a response.  This message may be freely distributed !
! Amateur Mathematician ! in its original and unmodified form.  Remember only !
! Professional Paperboy ! you can support SHAREWARE.  (c) 1992 Ken Hill  :>   !
===============================================================================
     This message has been brought to you by the letter Q and the number 7
Newsgroups: comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: New C++ type: boole
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 27 Jul 1992 05:26:51 GMT

In <DOUGM.92Jul26151240@titan.cs.rice.edu> dougm@titan.cs.rice.edu (Doug Moore) writes:

>Well, I am sorry for that.  To many people, the idea that a pointer to
>that character over there is also "true" and a pointer to no character
>at all is also "false" is counter-intuitive.  I don't claim to have
>data to support the assertion that one set of intuitions is more
>common than another.

*****>	Okay...one last time.  Zero, in whatever form, is False;
	anything else is true.  Any questions?  :)

	Realistically, if someone (not you!  This is *not* a personal
	flame...just thought I'd make that absolutely clear by explicity
	pointing this out) can't understand that or finds it counter-
	intuitive, I respectfully suggest another profession.  There are
	*much harder* things to learn in computer science than this.

	One is the seductively slick, way cool things about C(++) is
	that you can write nice "tight" expressions without having the
	apron-strings of something like: if ( <expr> == TRUE ) --or--
	if ( ptr != 0 ) ... Please, don't take that away.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: fedtmule@diku.dk (Jens Markussen)
Subject: Matrix manipulation library needed
Summary: I need a matrix manipulation library
Date: Wed, 22 Jul 1992 07:12:06 GMT
Organization: Department of Computer Science, U of Copenhagen
Keywords: matrix library c++ please

Hi You'all...

I am looking for a C++ class library, that will allow me to work with
matrixes, like multiply, add, transpose, invert and so on.

I anyone knows of such a library, PLEASE let me know (I would hate to
have to write it all myself)...


Bye, now

Jens Markussen.

------------------------
DIKU, Department of computer science at University of Copenhagen, Denmark.
Email: fedtmule@diku.dk


Newsgroups: comp.lang.c++
From: mat@uunet.uu.net!mole-end
Subject: Re: Language extensions for run-time type identification
Organization: :
Date: Fri, 24 Jul 1992 06:38:25 GMT

In article <rmartin.711829160@thor>, rmartin@thor.Rational.COM (Bob Martin) writes:
> shang@corp.mot.com (David (Lujun) Shang) writes:
 
> |In article <14ft2uINNjh4@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe  
> |Buck) writes:
> | 
> |> * ... it is trivial to force any class ...  to have a virtual function
> |> * table (simply add a virtual destructor).

> |Adding something virtual just for the purpose that has nothing to do with it?
 
> Posh!  Every class should have a virtual destructor.  It is insane not
> to declare the destructor virtual.  There is only one, small,
> exception to this rule, which has to do with structs placed in ROM...

I don't quite agree with you, Bob.  Any class for which polymorphic
behavior may be desirable should have a virtual destructor.  Polymoprhic
behavior is not tacked on; it must be designed in.  And there is a use
of classes for which run-time polymorphism makes little sense: classes
that represent quantity, quality, or selection.  Included in this
group are `arithmetic' and `geometric' types like Complex, Point,
Rectangle (or their templatized versions), types representing homogeneous
coordinates, transformations, etc., types which represent qualities in
multidimensional space (e.g. an RGB or CMYK description of a color),
and classes which are used as sophisticated versions of  enum .

There's another group of classes for which polymorphic behavior makes
little sense: those that are used to implement or provide data structures
(lists, trees, etc.)

Oh, and there's a difference between the classes which have `information'
nature (quantity, quality, selection) and classes which implement data
structures: the former are based in the problem domain and identified in
analysis; the latter are based in the solution (programming) domain and
introduced during design.

But that's another pot of pointer stew entirely.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: boolean (was: Re: typedef vs enum)
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 23 Jul 1992 14:08:54 GMT

In article <9220415.18737@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>>	While we're talking of a boolean type (which has two
>>values equivalent to 0 and 1), how about a ZERO type?
>>
>>	Type ZERO only has ONE value---0 of course.
>

	Thanks to those who suggested variants of how to do this
with the existing language, including

	enum ZEROTYPE {ZERO};

which wins as the shortest!

>We ALREADY have a type with only one value -- "void".

	Ohh, I thought void had NO values!

	{false,true} == boolean
	{false}      == ZERO
	{}           == void

>
>If you want a constructor which could only take one possible value value, you
>should use the void type. 

	Actually, I want to say

	T t;
	t=T();

more nicely.

>There *is* a problem in that C++ does not allow named
>constructors.

	Nasty problem too. And the auto-conversion is even nastier:

	class array { public:
		array(int) { ... } // array of n objects
	};

	array a;

	a=10;	// woops, didnt mean that!

>, and so you have to use the default constructor. One workaround is
>the following:
>
>	class Zero {
>	   public: operator int() const { return 0; }
>	} zero;
>

In fact, one might have instead

	class ZZZZ {} zzzz;

since the class is used for overloading, and we dont need, and mightnt
want, to be compatible with arithmetic types.

Just shows you what you CAN do in C++ with a bit of imagination :-)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++,comp.std.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
Organization: :
Date: Wed, 29 Jul 1992 21:00:19 GMT

In article <2TJ53BQ@netmbx.netmbx.de>, jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
> chip@tct.com (Chip Salzenberg) writes:
 
> >But once you've frozen a C++ object into a dead array of bytes, it's
> >no longer a C++ object, so the C++ type system is no longer operative.
 
> >...
> Unfortunately, the proposed standard will not provide enough info to
> do this, according to Mat Mol.  ...

I ain't Mat and I ain't nobody's moll!  I got a poifekly good .sig down
below and youse guys oughta loin ta read it.

> 			    ....  He referred to a second standard for
> extended type information that might have enough infor but which he
> suggests might not make it into the standard.  I am trying to get my
> hands on these proposals, but it may take a few weeks...

The Extended Type Information proposal is only in its formative stages now.
ETI will be done if it is practical.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Xref: sparky comp.lang.c++:11440 comp.windows.x:14294 comp.windows.x.motif:5179
From: sobol@cathedral.cerc.wvu.wvnet.edu (Michael Sobolewski)
Newsgroups: comp.lang.c++,comp.windows.x,comp.windows.x.motif
Subject: Naming collision of X11 Object and NIH Object class
Keywords: NIH Classes, X11
Date: 23 Jul 92 21:33:01 GMT
Followup-To: poster

Hi,

Today I have started to implement a NIH-based model (in model-view-controller
paradigm) of my GUI. I have ready a view-controller part in X11/Xt/Motif
(based on Young's MotifApp) and I got the error:  (X11) Object  of type struct 
_ObjectRec * redeclared as class, (X11) Object.h", line 275: error: 
two declarations of Object : struct _ObjectRec * and class.

Can you suggest the most practical solution how to solve this problem?
Is there a NIH class library with, for example, the prefix NIH?

Thanks in advance

Mike

-- 
Michael Sobolewski              How not to get lost in the complexities of our 
CERC/WVU, Drawer 2000           own making is still computing's core challenge.
Morgantown, WV 26506                                           Edsger Dijsktra
office: (304) 293-6961
e-mail: sobol@cerc.wvu.wvnet.edu
Newsgroups: comp.lang.c++
From: pjl@sparc13.cs.uiuc.edu (Paul Lucas)
Subject: Re: Having this=0, class-name: :main() and tasking in c++
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Mon, 27 Jul 1992 15:59:49 GMT

In <23318@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

>In article <1DDA4ACFA5BF800C41@ursula.lucas.lu.se> KOSU_MATSB@ROUTH.KOSUFY.LU.SE writes:

>> Question #1:	Having a 0 "this" pointer. Standard?

>No.  ARM page 176:

>	The effect of calling a nonstatic member function of a class X
>	for something that is not an object of class X is undefined.

>	For example,

>		((X*)0)->f();
>	
>	is not guaranteed to work.  In particular, this will not work for
>	virtual functions on any implementation since the information
>	needed to find the appropriate virtual function for an object
>	of type X is not found at location 0.  Even for nonvirtual
>	functions, one should expect this trick to fail eventually...

*****>	Oops!  I was in error about my previous post; sorry.  But _why_
	isn't guaranteed to work for nonstatic, nonvirtual member
	functions?

		C++			C-code
		===			======
		((X*)0)->f();	==>	f( /* this= */ 0 );
	
	So, for my Link class, I have:

		class Link {
			Link *prev, *next;
		public:
			// ...

			//
			// Cut() "cuts out" at most the specified number
			// of Links and returns the head of that list,
			// i.e., 'this' or null if you passed it zero.
			//
			Link* Cut( int at_most = 1 );

			//
			// DeleteAll() deletes all the Links in the
			// chain starting with 'this'.
			//
			void DeleteAll();

			//
			// Delete() deletes at most the specified number
			// of Links starting with 'this'.
			//
			void Delete( int at_most = 1 ) {
				Cut( at_most )->DeleteAll();
			}

			// ...
		};

	The thing to note is the implementation of Delete() in terms of
	Cut() and DeleteAll(); if Cut() returns null, DeleteAll() does
	nothing because the code for DeleteAll() is:

			void
		Link::DeleteAll() {
			for ( register Link *p = this, *q; p; p = q ) {
				q = p->next;
				delete p;
			}
		}
	
	It would seem that for cases like this, a null 'this' is
	perfectly reasonable.  So why can't it be _made_ to be guaranteed
	to work?
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++,comp.strd.c++
From: mat@uunet.uu.net!mole-end
Subject: Re: Language extensions for run-time type identification
Organization: :
Date: Sun, 26 Jul 1992 02:51:47 GMT

In article <1992Jul24.145147.19761@cadsun.corp.mot.com>, shang@corp.mot.com (David (Lujun) Shang) writes:
> In article <1992Jul24.070325.1597@uunet.uu.net!mole-end>  

> > And not to make you too happy: comparing vtable pointers could only be
> > a first step unless you are absolutely sure that the compilation and
> > linking system will never duplicate a vtable.  This is a hard assumption
> > to prove, especially with dynamic linking of new types.

> The compiler and linker should essure that the vtable for a particular
> class is unique. 

Yes, well, we may have to solve those problems to do templates well ...
but for right now we are stuck with existing linkers.

> Anyway, after a sencond thought, I still insist on my original opinion, that  
> is, it is not a good idea to use vtable pointer as the type-id.  Vtable
> pointer is environment-dependent, it cannot serve as a type identifier
> to communicate between two defferent environments.

Pointer comparison is an optimization; in a single memory space it's
worth trying ... but you are right; deep equality comparison is needed.
All the problems that arise (including source file identification for
static types--and THAT includes directory structure) get worse when you
do cross-environment stuff.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: wells@cdsmn.mn.org (Rich Wells)
Subject: Re: const on pass by value
Reply-To: wells@cdsmn.UUCP (Rich Wells)
Organization: Dicomed, Inc., Burnsville, MN
Date: Mon, 27 Jul 92 15:43:11 GMT

In article <9220801.5026@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>mat@uunet.uu.net!mole-end writes:
>
>>In article <1992Jul24.151010.11969@PacBell.COM>, pjcondi@lepton (Paul Condie) writes:
>>> Should pass by value arguments be declared as "const" for
>>> good coding style?  Or is that nit picking?
>> 
>>> For example:
>> 
>>> void foo (const int a);
>>> or
>>> void foo (int a);
>>
>>It's not nitpicking.  It's part of something called const correctness.
>>Your program has it or doesn't.  Programs that have it are almost immune
>>to a certain large family of errors.
>
>Huh? In this example, it IS just nitpicking.
>How could the presence or absence of const in the declaration for foo
>affect the program's const correctness?
>

Consider this case:

void bar(int & a)
{
}

void foo(const int a)
{
   bar(a);
}

Should the compiler allow the call to bar() from foo()?  I think not.
I'm still a relative newcomer to C++ but it seems to my this is an
example of where  the presence or absence of const in the declaration
of foo DOES affect the program's const correctness.

Granted, this is a contrived example, but replace the 'int' with
a 'struct' and it is no longer quite so contrived.

Richard Wells   wells@cdsmn.mn.org  or  ...!tcnet!cdsmn!wells
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Borland C++ 3.1 fails to conform to C++ Standard
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 25 Jul 1992 15:18:15 GMT

In article <1992Jul24.133738.597@mala.bc.ca> epp@mala.bc.ca (Lorne Epp) writes:

>>     "Reference initialized with 'double' requires lvalue of type 'double'"
>> which referred to the line I have indicated in the above class listing.
>> 
>
>Just a note:  I have received the same error message for similar code in
>Turbo C++ 3.0.

And I've had code like

	f(expr); 

fail to pass the value of expr to f, but the code

	double x=expr;
	f(x);

work just fine. IMHO Borlands floating point handling is suspect.

Furthermore I now add Zortech to the list of compilers that 
fails to implement abstract virtual bases correctly,
but in this case according to the report I received it
fails to implement sibling call too (OH DEAR).


// RE Abstract Classes
// some compilers work and others fail when #define KLUDGE is 
// commented out. Borlandc says D is abstract.
// CLEARLY it is not.
// However rewiting rules in ARM are not clear.
// It is essential for "mix-in" programming that D is concrete.
// as far as I know:
//  Broken: BorlandC (MY compiler), cfront (AT&T), Zortech
//  Work  : GNU++, MC7 (Microsoft)
//  Note: Zortech doesn't even work when KLUDGE is #defined!!
//
#define KLUDGE
#ifndef KLUDGE
class V {public: virtual void f()=0; virtual void g()=0;};
#else
class V {public: virtual void f(){printf("ERROR V::g\n");} 
	virtual void g(){printf("ERROR V::g\n");}};
#endif
class A1 : public virtual V {public: void f(){printf("A1::f\n");}};
class A2 : public virtual V {public: void g(){printf("A2::g\n");}};
class D : public A1, public A2 {};
int main()
{
	D* d=new D;
	A1 * a1=d;
	A2 * a2=d;
	V * v = d;
	d->f(); a1->f(); a2->f(); v->f();
	d->g(); a1->g(); a2->g(); v->g();
}
-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: rmr@deadmin.ucsd.edu (Robert Rother)
Newsgroups: comp.lang.c++
Subject: Help needed overloading "<<" with templates?
Date: 21 Jul 92 06:06:34 GMT
Organization: UCSD Division of Engineering

Ok I give up.  I have more or less copied the template code for the
Array class in Lippman's 2nd Edition C++ Primer (pg 380).  Using Turbo
C++ 3.1 for windows I have two problems with the overloading of the
"<<" operator.  First as noted before it won't compile without the
addition of an "&" and second the call to the print member works while
the use of the overloaded operator "<<" just prints a hex address.
It's obvious to me that my overloaded operator is not being used by why
is the mystery.

My sanity is more important than my ego at the moment so any help would
be more than appreciated!

Robert Rother
rmr@deadmin.ucsd.edu

P.S. I have no problem with the same code fragment minus the templates.
-----------------------------------------------------------------------
#include <assert.h>
#include <iostream.h>

const int ArraySize = 12;

template <class Type> class Array;

template <class Type> ostream &
	operator<<(ostream&, Array<Type>&);

template <class Type>
class Array {
public:
	Array(int sz = ArraySize);
	~Array() { delete [] ia; }
	void print(ostream& = cout);
private:
	void init(const Type *, Type);
	int size;
	Type *ia;
};

template <class Type>
Array<Type>::Array(int sz)
{
	size = sz;

 	init(0, sz);
}

template <class Type>
void
Array<Type>::init(const Type *array, int sz)
{
	ia = new Type[size = sz];
	assert(ia != 0);

	for (int ndx = 0; ndx < size; ndx++)
		ia[ndx] = (array != 0) ? array[ndx] : 0;
}

template <class Type> ostream&
operator << ( ostream& os, Array<Type>& ar)
{
	ar.print(os);
	return(os);
}

template <class Type>
void Array<Type>::print(ostream& os)
{
	const int linelen = 12;

	os << "(" << size << ")<";
	for (int ndx = 0; ndx < size; ndx++) {
		if ((ndx % linelen) == 0 && ndx)
			os << "\n\t";
                os << ia[ndx];
		if ((ndx % linelen) != linelen - 1 && ndx != size - 1)
			os << ", ";
	}
        os << " >\n";
}

template <class Type>
void try_it(Array<Type>& ar)
{
	cout << "Start\n";

	ar.print(cout);

        cout << "Middle\n";

// Note: the book shows the following but it wouldn't compile:
// ***  cout << ar << endl;
        cout << &ar << endl;

	cout << "Done!" << endl;
}

main()
{
	Array<int> iA;

	try_it(iA);
	return(0);
}
Xref: sparky comp.lang.c++:11699 gnu.gcc.help:1801 gnu.g++.help:1054
From: martin@oahu.cs.ucla.edu (david l. martin)
Newsgroups: comp.lang.c++,gnu.gcc.help,gnu.g++.help
Subject: porting to g++ (from other "dialects")
Date: 28 Jul 92 16:09:35 GMT
Followup-To: poster
Organization: UCLA Computer Science Department
To: gnu-gcc-announce@uunet.uu.net
Originator: martin@oahu.cs.ucla.edu

I am involved in a project in which we need to be able to use g++
(that is, the g++ component of the latest version of gcc) to compile*
existing source code which was developed for a variety of other
leading C++ compilers - including CFRONT, Borland, Zortech, and
Sabre.  I know there are still incompatibilities between g++ and
the other dialects, but I need to know just how bad they are.  For
example, if I take an average body of CFRONT-compilable code, what
percentage of it might be rejected by g++, in the sense of causing
a fatal error?

I would greatly appreciate the benefit of experience from anyone
who's ported to g++ from a different compiler.

(*To be more precise, I won't actually be generating executables from
the source code.  I'll be using g++ as a front-end to analyze
existing source code and produce an intermediate representation which 
describes it - essentially an attributed syntax tree.)

Thanks!

- Dave Martin
Newsgroups: comp.lang.c++,comp.std.c++