marcos@oravax.UUCP (Marcos Lam) (03/17/89)
I am looking for a good book on Microsoft C (version 5). Any recommendations will be welcome. Thanks in advance. Marcos ------ Odyssey Research 301A Dates Drive Ithaca, NY 14580-1313 (607) 277-2020 marcos%oravax.uucp@cu-arpa.cs.cornell.edu
Tim_CDC_Roberts@cup.portal.com (03/18/89)
In <754@oravax.UUCP>, marcos%oravax.uucp (Marcos Lam) asked for recommendations on a good book on Microsoft C 5. In my experience, the Microsoft C Compiler manuals themselves are a very good source. In particular, the discussion on creating and unwinding type definitions and type casting is the best I've ever seen. Tim_CDC_Roberts@cup.portal.com | Control Data... ...!sun!portal!cup.portal.com!tim_cdc_roberts | ...or it will control you.
beckman@dev386.UUCP (Zacharias Beckman) (03/21/89)
In article <754@oravax.UUCP>, marcos@oravax.UUCP (Marcos Lam) writes: > I am looking for a good book on Microsoft C (version 5). Any recommendations > will be welcome. Thanks in advance. I highly recommend "The Microsoft C Programmers Bible" (or a title very much like this) by the Waite Group. I find myself using the Bible more often than the reference manuals...
scs@adam.pika.mit.edu (Steve Summit) (03/26/89)
A while ago, someone wrote:
> I am looking for a good book on Microsoft C (version 5).
Why are there so many books on particular implementations of
languages? C is supposed to be, and can be, quite portable.
To be sure, there will always be compiler-specific details, which
are the proper province of the compiler user's manuals. Those
manuals are not always well-written, but they usually tell you
how to invoke the compiler, which ideally is the only compiler-
specific detail you'd need to know. All of the language
extensions inevitably provided should be avoided whenever
possible, not exploited.
It bugs me to glance into a technical bookstore and see shelf
after shelf of "Programming in Turbo C," "Graphics programming
for the IBM PC," etc. These books may be the only source of
important documentation, which the irresponsible vendors have
neglected to provide, but they also teach you (if only
implicitly) to write machine-, system-, compiler-, and device-
dependent code.
Steve Summit
scs@adam.pika.mit.eduejd@caen.engin.umich.edu (Edward J Driscoll) (03/26/89)
In article <10107@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >specific detail you'd need to know. All of the language >extensions inevitably provided should be avoided whenever >possible, not exploited. > >for the IBM PC," etc. These books may be the only source of >important documentation, which the irresponsible vendors have >neglected to provide, but they also teach you (if only >implicitly) to write machine-, system-, compiler-, and device- >dependent code. > > Steve Summit > scs@adam.pika.mit.edu I disagree with the notion that portability is necessarily the primary consideration. It very well may be in some cases, but a programmer who knows his software isn't going to be ported anywhere, or would require major work in any case (that is, if it was machine-dependant by nature), has every right to know about and use machine-, system-, compiler-, and device- dependant code. A simple case in point: A DOS programmer who wants fast screen IO will use the machine-specific trick of writing directly into the video RAM. Sure, this makes his program a little less portable, but it also makes it more attractive to the end user, who probably doesn't give a whit about portability, but WILL notice the speedup in screen IO. To claim that programs should always be written in the most portable way is like claiming that they should always be optimized for speed, rather than space. There are costs to take into account, and whether or not to use machine-specific code is something that should be decided on a case-by-case basis. Personally, I know how to write portable code, but I rarely need to. When I know ahead of time that portability isn't an issue, I'll go ahead and get as much as I can out of my hardware and compiler. If that means using machine-dependant code, big deal. -- Ed Driscoll The University of Michigan ejd@caen.engin.umich.edu
mcdonald@uxe.cso.uiuc.edu (03/27/89)
>A while ago, someone wrote: >> I am looking for a good book on Microsoft C (version 5). >Why are there so many books on particular implementations of >languages? C is supposed to be, and can be, quite portable. >To be sure, there will always be compiler-specific details, which >are the proper province of the compiler user's manuals. Those >manuals are not always well-written, but they usually tell you >how to invoke the compiler, which ideally is the only compiler- >specific detail you'd need to know. All of the language >extensions inevitably provided should be avoided whenever >possible, not exploited. >It bugs me to glance into a technical bookstore and see shelf >after shelf of "Programming in Turbo C," "Graphics programming >for the IBM PC," etc. These books may be the only source of >important documentation, which the irresponsible vendors have >neglected to provide, but they also teach you (if only >implicitly) to write machine-, system-, compiler-, and device- >dependent code. The answer is that if one wants to maufacture a competitive program, especially but not exclusively, a commercial one, one MUST must exploit machine specific features to the fullest. Portability is sometimes possible for the "inner works" of a program, but the outer parts, that a user sees, must be tailored for the machine at hand - to use its specific file formats, its specific method of getting keyboard and mouse input, its specific output format (both thext and graphics), use its most efficient method of IO, etc. Anything else is folly. Standard languages are, by fiat of the standards committees, crippled. For example, in C there is no official way to get keyboard input without blocking (i.e. see if a key has been hit.) You HAVE to use machine specific routines. "Portability" is a word seldom heard outside the academic discussions of Usenet. If it is (for example, in the inner sanctum of Lotus, inc, it generally in the context - Oh my God! why did we decide to do THAT - a year late and 50% as fast!!!!.) Doug McDonald
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/29/89)
In article <225800146@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >"Portability" is a word seldom heard outside the academic discussions >of Usenet. That's utter nonsense. Anyone concerned with getting his applications to work on a wide variety of unlike systems quickly learns to care about program and environment portability. That doesn't necessarily mean that code is ported with 0 adaptation, but rather that the changes needed are designed to be minimal and cleanly isolated from the bulk of the application. There are numerous commercial software vendors who rely on portable C programming practice as the basis for providing versions of their products on as many popular machines as possible.
henry@utzoo.uucp (Henry Spencer) (03/29/89)
In article <225800146@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >"Portability" is a word seldom heard outside the academic discussions >of Usenet... How remarkable. What system are you writing that on, pray? Is it, by chance, Unix? Are you writing it on a pdp11, or on some machine that Unix was ported to later? Please don't confuse the MSDOS world, where a wretchedly botched processor and dreadful support software makes machine-specific code inevitable, with the rest of the world. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
ejd@caen.engin.umich.edu (Edward J Driscoll) (03/29/89)
In article <9937@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <225800146@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >>"Portability" is a word seldom heard outside the academic discussions >>of Usenet. > >That's utter nonsense.[....] > >There are numerous commercial software vendors who rely on portable C >programming practice as the basis for providing versions of their >products on as many popular machines as possible. Sure, but there are also numerous developers who use all kinds of non-portable code in order to get the best performance they can. The majority of users probably only use a particular application on one particular system, so they're not going to be attracted by portability. They WILL be attracted to speed and a sophisticated interface. The original poster claimed that non-portable code should be avoided at all costs. This, too, is utter nonsense. -- Ed Driscoll The University of Michigan ejd@caen.engin.umich.edu
desnoyer@Apple.COM (Peter Desnoyers) (03/29/89)
In article <225800146@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > >The answer is that if one wants to maufacture a competitive program, >especially but not exclusively, a commercial one, one MUST must >exploit machine specific features to the fullest. Portability consists, among other things, of machine-to-machine and compiler-to-compiler portability. Just because your code is dedicated to one machine, be it a PC or a network controller, doesn't mean you want to re-write it when your vendor "upgrades" their non-standard features out of existence, or when the computer your cross-compiler runs on becomes obsolete and you have to get a different system. Peter Desnoyers
mcdonald@uxe.cso.uiuc.edu (03/29/89)
mcdonald@uxe.cso.uiuc.edu:
"Portability" is a word seldom heard outside the academic discussions
of Usenet.
gwyn@smoke.brl.mil (Doug Gwyn):
That's utter nonsense.[....]
ejd@caen.engin.umich.edu (Edward J Driscoll):
Sure, but there are also numerous developers who use all kinds of
non-portable code in order to get the best performance they can.
The majority of users probably only use a particular application
on one particular system, so they're not going to be attracted
by portability....
Fs@ernie.berkeley.edu (Jim Shankland):
Second, it's a canard that there is a direct tradeoff between portability
and performance. In most cases, the performance impact is unnoticeable,
and the (very) few cases where it makes a difference can be carefully
isolated. Learning to code portably can take a little extra programmer time
and discipline up front; even once the skill is learned, portable coding
*may* take a little extra development time. It's worth it.
Those are the facts. Flout them at your own (or your employer's) risk.
Me again:
It is silly to assume that there is no tradeoff between portability
and performance. It is true that in most cases it can be carefully
isloated. Portability things like not assuming sizeof(a) == sizeof(b),
coding in real ANSI C with full prototypes, are simply good
coding practice. And codeing in pure ANSI C guarantees a good
bit of portability ( :-( except to certain benighted systems with
only old-fashioned compilers.).
But, doing certain things portably can cost dearly. Graphics is
one area. Not using the full functionality of a machine's
special features is another. I was, and am, talking not so much
about the "core" functionality of a program as I am about
the user interface. And, I must emphasize most emphatically,
that a portable user interface MUST either be machine-specific
or be crippled by using the lowest common denominator (i.e.
a tty emulator text interface.) People who think that they can
get away with a (codewise) portable user interface are either
deluded or working in a sheltered market segment (accounting
programs for cookie shops?)
Doug McDonaldfriedl@vsi.COM (Stephen J. Friedl) (03/30/89)
In article <225800146@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > > "Portability" is a word seldom heard outside the academic discussions > of Usenet. Gasp! Portability is vitally important in the commercial world for those who don't want to reinvent the wheel. Sure, there will indeed be areas of non-portable code (machines *do* differ) but intelligent implementers know how to partition these out to minimize the conversion work. It's been my experience that "portability" is almost unheard of *within* the academic community (not the net.folks, just students in general). Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl "I do everything in software, even DMA" - Gary W. Keefe (garyk@telxon)
bill@twwells.uucp (T. William Wells) (04/01/89)
In article <9937@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: : In article <225800146@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: : >"Portability" is a word seldom heard outside the academic discussions : >of Usenet. : : That's utter nonsense. Anyone concerned with getting his applications : to work on a wide variety of unlike systems quickly learns to care : about program and environment portability. That doesn't necessarily : mean that code is ported with 0 adaptation, but rather that the changes : needed are designed to be minimal and cleanly isolated from the bulk of : the application. : : There are numerous commercial software vendors who rely on portable C : programming practice as the basis for providing versions of their : products on as many popular machines as possible. Damn right. We (Proximity Technology) are one of them. Basically, to us, if it isn't portable, it's a liability. Our code ports to many hundreds of machines/systems; did it not, we'd be out of business. And we might ask all those UNIX folks about portability. Where would UNIX be today if it wasn't relatively portable? Academic, indeed! --- Bill { uunet | novavax } !twwells!bill (BTW, I'm may be looking for a new job sometime in the next few months. If you know of a good one where I can be based in South Florida do send me e-mail.)