woody@nntp-server.caltech.edu (William Edward Woody) (11/29/90)
While we're on the topic, can I have THINK C++? I love the Think C environment, but I also love C++, and have been managing (somehow) in MPW instead. Just a christmas wish... -- William Edward Woody | Disclamer: USNAIL P.O.Box 50986; Pasadena, CA 91115 | EMAIL woody@tybalt.caltech.edu | The useful stuff in this message ICBM 34 08' 44''N x 118 08' 41''W | was only line noise.
jtt@cunixd.cc.columbia.edu (James T. Tanis) (11/30/90)
Hear Hear! I'd _love_ a real think c++. I'd immediately give up my job and follow the implementors slavishly! :-) Failing a real C++, it would be nice to have overloading at least, and optional argument initializers. On the other hand, the inherited:: fueature is _really_ nice. MPW C++ users may not realize this, but it is a feature absent from the draft standard and thus absent from _all_ the MS-DOS c++ that I must work with. Keep up the good work, think/symantec! -JT
ewright@convex.com (Edward V. Wright) (11/30/90)
davoli@natinst.com (Russell Davoli) writes: > >It would be really nice if there was a way to get "smarter" linking >out of THINK C. By this, I mean that the linker includes only the >functions called in the program. As I understand it, presently the >linker will link in all the functions from a file if even one of those >is called. Are you sure about that? I know that isn't true with THINK Pascal, so I would be fairly surprised to find out that is with THINK C.
nagel@wintermute.ics.uci.edu (Mark Nagel) (12/01/90)
In <1990Nov29.093024.16966@nntp-server.caltech.edu> woody@nntp-server.caltech.edu (William Edward Woody) writes: >While we're on the topic, can I have THINK C++? I love the Think C >environment, but I also love C++, and have been managing (somehow) >in MPW instead. Just a christmas wish... It is quite depressing to watch all those C++ compilers come out for the PC and then have to go back to our own bare cupboards, isn't it? I suspect that if Symantec doesn't hurry, some other company will see they could wrap up the Mac C++ market pretty quickly. Maybe someone out there could convince Borland there's money to be made from MacTurbo C++... Or maybe there isn't all that much money, after all. Of course, there's always MPW... -- Mark Nagel UC Irvine Department of ICS +----------------------------------------+ ARPA: nagel@ics.uci.edu | If you can read this, you're not using | UUCP: ucbvax!ucivax!nagel | the Hubble Space Telescope. |
woody@nntp-server.caltech.edu (William Edward Woody) (12/01/90)
>It is quite depressing to watch all those C++ compilers come out for >the PC and then have to go back to our own bare cupboards, isn't >it? I suspect that if Symantec doesn't hurry, some other company >will see they could wrap up the Mac C++ market pretty quickly. >Maybe someone out there could convince Borland there's money to be >made from MacTurbo C++... Or maybe there isn't all that much money, >after all. Yeah, I know. The IBM PC product Turbo C++ is *wonderful* (relatively speaking of course; it's as good as you can get on an IBM ;-), and it would be great if someone could do the same on the Macintosh. The logical choice would be Think C++, but they're not interested, apparently. And yeah, I'm using MPW C++. It seems to add a whole new meaning to the idea of going on a coffee break during compiles. (Read: I tend to fix dinner while waiting for a medium size compile... *sigh*) -- Bill >Of course, there's always MPW... >-- >Mark Nagel >UC Irvine Department of ICS +----------------------------------------+ >ARPA: nagel@ics.uci.edu | If you can read this, you're not using | >UUCP: ucbvax!ucivax!nagel | the Hubble Space Telescope. | -- William Edward Woody | Disclamer: USNAIL P.O.Box 50986; Pasadena, CA 91115 | EMAIL woody@tybalt.caltech.edu | The useful stuff in this message ICBM 34 08' 44''N x 118 08' 41''W | was only line noise.
Chris.Gehlker@p12.f56.n114.z1.fidonet.org (Chris Gehlker) (12/03/90)
> Despite all the flurry of THINK C "wish list" stuff that has passed > through this news group, I don't remember if this was ever mentioned. > It would be really nice if there was a way to get "smarter" linking > out of THINK C. By this, I mean that the linker includes only the > functions called in the program. As I understand it, presently the > linker will link in all the functions from a file if even one of those > is called. Kind of a bummer when you're using files common to a lot > of different projects in your project for only one or two of the > functions in those files. The only way to get the THINK C linker to be smart about this is to build your common files into a project and then include the common project into the particular projects that use those files and get rid of the source files. The linker in THINK Pascal now uses MPW.o files and it's a lot smarter than the C linker so maybe in the next release of C... -- Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!56.12!Chris.Gehlker Internet: Chris.Gehlker@p12.f56.n114.z1.fidonet.org
phils@chaos.cs.brandeis.edu (Phil Shapiro) (12/03/90)
In article <109545@convex.convex.com> ewright@convex.com (Edward V. Wright) writes: davoli@natinst.com (Russell Davoli) writes: > >It would be really nice if there was a way to get "smarter" linking >out of THINK C. By this, I mean that the linker includes only the >functions called in the program. As I understand it, presently the >linker will link in all the functions from a file if even one of those >is called. Are you sure about that? I know that isn't true with THINK Pascal, so I would be fairly surprised to find out that is with THINK C. THINK Pascal v3.0's linker "optimizes" on a function by function basis. THINK C v4.0's linker optimizes on a file by file basis. So in C, you can make "link-optimizing" library by placing each family of functions in a seperate .c file (for example, C's ANSI library). -phil -- Phil Shapiro Technical Support Analyst Language Products Group Symantec Corporation Internet: phils@chaos.cs.brandeis.edu
davoli@natinst.com (Russell Davoli) (12/03/90)
In article <109545@convex.convex.com>, ewright@convex.com (Edward V. Wright) writes: > davoli@natinst.com (Russell Davoli) writes: > > > >It would be really nice if there was a way to get "smarter" linking > >out of THINK C. By this, I mean that the linker includes only the > >functions called in the program. As I understand it, presently the > >linker will link in all the functions from a file if even one of those > >is called. > > Are you sure about that? I know that isn't true with THINK Pascal, so > I would be fairly surprised to find out that is with THINK C. I don't think that the kind of linking I'm talking about is possible with any THINK language system, but I'm no authority on their Pascal. MPW's linker does the kind of linking I'm talking about. That's why I think there should be a way to optionally turn on the "smarter" linking -- MPW's linker is SLOW, and it would be nice to have the ability to build quickly a version for testing then do a slower build for release.
wdh@well.sf.ca.us (Bill Hofmann) (12/05/90)
While we're on the issue of THINK C linking, is there any hope for an option to output MPW .SYM files? Since the built-in debugger doesn't debug XCMDs, and since it's not as versatile as it might be, I'd like to be able to use Jasik's debugger, with full symbolic debugging and type info. (I've been using Jasik's for a while, love it, but its interaction with THINK C could be better, or rather, you folks could maybe cooperate...) I'd be happy with a post-processor, or just about anything... -Bill Hofmann
phils@chaos.cs.brandeis.edu (Phil Shapiro) (12/06/90)
In article <1842@metaphor.Metaphor.COM> emg@jobone.metaphor.com (Mike Greenawalt) writes:
I would like to be sure that I understand this completely. For a
long time I have believed that Think C linked the entire library if
a "library" is used to contain the compiled code, but only linked
in a file if a "project" is used to contain the compiled code.
That's right.
You now seem to be saying that only the file`s worth of code
containing the referenced function is linked in if a "library" is
used. Does the "library" structure remember the file structure of
its contents?
No.
Please contrast using a "project" versus using a "library". In my
opinion the Think C docs are a bit weak in this area.
Sorry to futher confuse the issue... You are correct, only "nested"
projects (that is, projects that are added to other projects) support
this link optimization. I get in the habit of calling projects that
are used in this way "libraries" -- most programmers would never want
to use real libraries.
-phil
--
Phil Shapiro Technical Support Analyst
Language Products Group Symantec Corporation
Internet: phils@chaos.cs.brandeis.eduemg@jobone.metaphor.com (Mike Greenawalt) (12/08/90)
In article <PHILS.90Dec5144454@chaos.cs.brandeis.edu> phils@chaos.cs.brandeis.edu (Phil Shapiro) writes: [stuff deleted] > Please contrast using a "project" versus using a "library". In my > opinion the Think C docs are a bit weak in this area. > >Sorry to futher confuse the issue... You are correct, only "nested" >projects (that is, projects that are added to other projects) support >this link optimization. I get in the habit of calling projects that >are used in this way "libraries" -- most programmers would never want >to use real libraries. > > -phil I have to disagree rather strongly with that last comment. I think most programmers *would* want to use *real* libraries. When is Think C going to have some? -- Mike Greenawalt