euamts@eua.ericsson.se (Mats Henricson) (02/12/91)
Hi!
I wonder if Symantec is walking the same path as Stroustroup for evolving C
to C++, i.e. Does Think C 4.0 look like as if the code written in it might
be possible to run through a C++ compiler ??
To be very clear: do you think that:
Think_C_5 == C++;
Mats Henricsonrgonzal@elbereth.rutgers.edu (Ralph Gonzalez) (02/13/91)
With a little conditional compilation you can make Think C 4 programs compile under C++, but I was under the impression that Symantec does not intend to make Think C the same as C++... -Ralph
perry@key.COM (Perry The Cynic) (02/13/91)
In article <1991Feb12.075322.1877@eua.ericsson.se> euamts@eua.ericsson.se (Mats Henricson) writes: > Hi! > > I wonder if Symantec is walking the same path as Stroustroup for evolving C > to C++, i.e. Does Think C 4.0 look like as if the code written in it might > be possible to run through a C++ compiler ?? > > To be very clear: do you think that: > > Think_C_5 == C++; > > Mats Henricson To the first question: Yes, THINK C 4.0 is designed to look like a C++ subset, so that THINK C code should go through a C++ compiler without major modifications. Perhaps that protects your investment into Object C code. Of course, in my not so humble opinion, writing true C++ code requires a different design concept. To the second question: Not unless someone at Symantec has made a 180 degree turn-about. When THINK C version 4 came out, several people at Symantec were adamant about how ugly a language C++ is, and how much better "Object C" is for Macintosh programming. Rich Siegel in particular told me to stop "whining for C++" (that's a quote) and take what they have to offer. One could speculate when the people at Symantec will realize the drift of their market, and revise their opposition to C++. Your guess is as good as mine there. I wouldn't mind using a hypothetical THINK C++ with the new C++ MacApp, but I don't see that happening soon. Pity, too. -- perry -- -------------------------------------------------------------------------- Perry The Cynic (Peter Kiehtreiber) perry@arkon.key.com ** What good signature isn't taken yet? ** {amdahl,sgi,pacbell}!key!perry
pbuck@tcs.com (Peter Buckner) (02/20/91)
In a casual conversation with a Symantec employee at MacWorld in January, I was told that if Symantec were to come out with C++, it would be as a separate product-line. He would not (officially) speculate on when/if such a product would be delivered, but he remarked that *many* people had been asking about a C++ product...
jspencer@p510.f22.n282.z1.mmug.edgar.mn.org (Jim Spencer) (02/22/91)
Perry The Cynic writes in a message to All
PTC> To the first question: Yes, THINK C 4.0 is designed to look like
PTC> a C++ subset, so that THINK C code should go through a C++ compiler
PTC> without major modifications. Perhaps that protects your investment
PTC> into Object C code. Of course, in my not so humble opinion, writing
PTC> true C++ code requires a different design concept.
Its also a little misleading. Because Think C doesn't use the virtual keyword, if you don't go through your code and put them in, in C++ they will be treated as non-virtual functions.
--
Jim Spencer (jspencer@mmug.edgar.mn.org)
UUCP: ...jhereg!tcnet!vware!edgar!mmug!jspencer
FidoNet: 1:282/22.510
--rgonzal@elbereth.rutgers.edu (Ralph Gonzalez) (02/26/91)
As mentioned in the Think C manuals, you can get Think C/C++
compatibility as far as "virtual" is concerned by using "virtual" in
all method declarations, and saying:
# ifdef THINK_C
# define virtual
# endif
A few other requirements:
C++ doesn't support Think C's method of avoiding multiple inclusion of
header files. So you must use the usual C++ approach for all headers:
# ifndef filename_h
# define filename_h
(body of header file)
# endif
"direct" and "indirect" specifiers are not used in C++, so you should
use something like this in your root class:
# ifdef THINK_C
struct Generic_Class:indirect
# else
struct Generic_Class
# endif
{
virtual boolean init(void);
.
.
.
};
Since "new" and "delete" are implemented as functions in Think C and
operators in C++, you need this in any file using them (or in a common
header):
# ifdef THINK_C
# include <oops.h>
# endif
Since it is not supported in C++, you can't use Think C's "inherited"
keyword. You should instead use the name of the base class
explicitly.
I've had good luck in Think C/C++ portability by following the above
rules.
There are also a couple of bugs in Think C which you have to work
around, but these don't come up too often...
-Ralph
rgonzal@chowder.rutgers.eduml27192@uxa.cso.uiuc.edu (lanett mark) (02/27/91)
rgonzal@elbereth.rutgers.edu (Ralph Gonzalez) writes: >Since it is not supported in C++, you can't use Think C's "inherited" >keyword. You should instead use the name of the base class >explicitly. C++ from Apple has 'inherited' to provide Object Pascal support. It also works for non-TObject objects, and I use it rather than the base name (for single-inheritance) because then I don't get screwed up when I change the base class (which I wouldn't have to do if I thought a little bit ahead :-)) Format: inherited::foo (); >-Ralph >rgonzal@chowder.rutgers.edu -- //----------------------------------------------------------------------------- Mark Lanett ml27192@uxa.cs.uiuc.edu NCSA address: Coming soon!