Catalogue


C programming FAQs : frequently asked questions /
Steve Summit.
imprint
Reading, Mass. : Addison-Wesley Pub. Co., c1996.
description
xli, 389 p. ; 24 cm.
ISBN
0201845199
format(s)
Book
Holdings
More Details
imprint
Reading, Mass. : Addison-Wesley Pub. Co., c1996.
isbn
0201845199
catalogue key
932071
 
Includes bibliographical references and index.
A Look Inside
Excerpts
Introduction or Preface
PrefaceAt some point in 1979, I heard a lot of people talking about this relatively new language, C, and the book which had just come out about it. I bought a copy of K&R, otherwise known as The C Programming Language, by Brian Kernighan and Dennis Ritchie, but it sat on my shelf for a while because I didn't have an immediate need for it (besides which I was busy being a college freshman at the time). It proved in the end to be an auspicious purchase, though, because when I finally did take it up, I never put it down: I've been programming in C ever since.In 1983, I came across the Usenet newsgroup net.lang.c, which was (and its successor comp.lang.c still is) an excellent place to learn a lot more about C, and to find out what questions everyone else is having about C, and to discover that you may not know all there is to know about C after all. It seems that C, despite its apparent simplicity, has a number of decidedly non-obvious aspects, and certain questions come up over and over again. This book is a collection of some of those questions, with answers, based on the Frequently-Asked Questions ("FAQ") list which I began posting to comp.lang.c in May, 1990.I hasten to add, however, that this book is not intended as a critique or "hatchet job" on the C language. It is all too easy to blame a language (or any tool) for the difficulties its users encounter with it, or to claim that a properly-designed tool "ought" to prevent its users from misusing it. It would therefore be easy to regard a book like this, with its long lists of misuses, as a litany of woes attempting to show that the language is hopelessly deficient. Nothing could be farther from the case.I would never have learned enough about C to be able to write this book, and I would not be attempting to make C more pleasant for others to use by writing this book now, if I did not think that C was a great language or if I did not enjoy programming in it. I do like C, and one of the reasons that I teach classes in it and spend time participating in discussion about it on the Internet is that I would like to discover which aspects of C (or of programming in general) are difficult to learn or keep people from being able to program efficiently and effectively. This book represents some of what I've learned: these questions are certainly some of the ones people have the most trouble with, and the answers have been refined over a several-year period in an attempt to ensure that people don't have too much trouble with them.A reader will certainly have trouble if there are any errors in these answers, and although the reviewers and I have worked hard to eliminate them, it can be as hard to eradicate the last error from a large manuscript as it is to stamp out the last bug in a program. I will appreciate any corrections or suggestions sent to me in care of the publisher or at the e-mail address below, and I would like to offer the customary $1.00 reward to the first finder of any error. If you have access to the Internet, you can check for an errata list (and a scorecard of the finders) at the ftp and http addresses mentioned in question 20.40.As I hope I've made clear, this book is not a critique of the C Programming language, nor is it a critique of the book from which I first learned C, nor of that book's authors. I didn't just learn C from KR; I also learned a lot about programming. As I contemplate my own contribution to the C programming literature, my only regret is that the present book does not live up to a nice observation made in the second edition of K&R, namely that "C is not a big language, and it is not well served by a big book." I hope that those who most deeply appreciate C's brevity and precision (and that of K&R) will not be too offended by the fact that this book says some things over and over and over, or in three slightly different ways.Though my name is on the cover, there are a lot of peop
Introduction or Preface
Preface At some point in 1979, I heard a lot of people talking about this relatively new language, C, and the book which had just come out about it. I bought a copy of K&R, otherwise known as The C Programming Language, by Brian Kernighan and Dennis Ritchie, but it sat on my shelf for a while because I didn''t have an immediate need for it (besides which I was busy being a college freshman at the time). It proved in the end to be an auspicious purchase, though, because when I finally did take it up, I never put it down: I''ve been programming in C ever since. In 1983, I came across the Usenet newsgroup net.lang.c, which was (and its successor comp.lang.c still is) an excellent place to learn a lot more about C, and to find out what questions everyone else is having about C, and to discover that you may not know all there is to know about C after all. It seems that C, despite its apparent simplicity, has a number of decidedly non-obvious aspects, and certain questions come up over and over again. This book is a collection of some of those questions, with answers, based on the Frequently-Asked Questions ("FAQ") list which I began posting to comp.lang.c in May, 1990. I hasten to add, however, that this book is not intended as a critique or "hatchet job" on the C language. It is all too easy to blame a language (or any tool) for the difficulties its users encounter with it, or to claim that a properly-designed tool "ought" to prevent its users from misusing it. It would therefore be easy to regard a book like this, with its long lists of misuses, as a litany of woes attempting to show that the language is hopelessly deficient. Nothing could be farther from the case. I would never have learned enough about C to be able to write this book, and I would not be attempting to make C more pleasant for others to use by writing this book now, if I did not think that C was a great language or if I did not enjoy programming in it. I do like C, and one of the reasons that I teach classes in it and spend time participating in discussion about it on the Internet is that I would like to discover which aspects of C (or of programming in general) are difficult to learn or keep people from being able to program efficiently and effectively. This book represents some of what I''ve learned: these questions are certainly some of the ones people have the most trouble with, and the answers have been refined over a several-year period in an attempt to ensure that people don''t have too much trouble with them. A reader will certainly have trouble if there are any errors in these answers, and although the reviewers and I have worked hard to eliminate them, it can be as hard to eradicate the last error from a large manuscript as it is to stamp out the last bug in a program. I will appreciate any corrections or suggestions sent to me in care of the publisher or at the e-mail address below, and I would like to offer the customary $1.00 reward to the first finder of any error. If you have access to the Internet, you can check for an errata list (and a scorecard of the finders) at the ftp and http addresses mentioned in question 20.40. As I hope I''ve made clear, this book is not a critique of the C Programming language, nor is it a critique of the book from which I first learned C, nor of that book''s authors. I didn''t just learn C from K&R; I also learned a lot about programming. As I contemplate my own contribution to the C programming literature, my only regret is that the present book does not live up to a nice observation made in the second edition of K&R, namely that "C is not a big language, and it is not well served by a big book." I hope that those who most deeply appreciate C''s brevity and precision (and that of K&R) will not be too offended by the fact that this book says some things over and over and over, or in three slightly different ways. Though my name is on the cover, there are a lot of people behind this book, and it''s hard to know where to start handing out acknowledgments. In a sense, every one of comp.lang.c''s readers (today estimated at 320,000) is a contributor: the FAQ list behind this book was written for comp.lang.c first, and this book retains the flavor of a good comp.lang.c discussion. This book also retains, I hope, the philosophy of correct C programming which I began learning when I started reading net.lang.c. Therefore, I shall first acknowledge the posters who stand out in my mind as having most clearly and consistently articulated that philosophy: Doug Gwyn, Guy Harris, Karl Heuer, Henry Spencer, and Chris Torek. These gentlemen have displayed remarkable patience over the years, answering endless questions with generosity and wisdom. I was the one who stuck his neck out and started writing the Frequent questions down, but I would hate to give the impression that the answers are somehow mine. I was once the student (I believe it was Guy who answered my post asking essentially the present volume''s question 5.10), and I owe a real debt to the masters who went before me. This book is theirs as much as mine, though I retain title to any inadequacies or mistakes I''ve made in the presentation. The former on-line FAQ list grew by a factor of three in the process of becoming this book, and its growth was a bit rapid and awkward at times. Mark Brader, Vinit Carpenter, Stephen Clamage, Jutta Degener, Doug Gwyn, Karl Heuer, Joseph Kent, and George Leach read proposals or complete drafts and helped to exert some control over the process; I thank them for their many careful suggestions and corrections. Their efforts grew out of a shared wish to improve the overall understanding of C in the programming community. I appreciate their dedication. Three of those reviewers have also been long-time contributors to the on-line FAQ list. I thank Jutta Degener and Karl Heuer for their help over the years, and I especially thank Mark Brader, who has been my most persistent critic ever since I first began posting the comp.lang.c FAQ list five years ago. I don''t know how he has had the stamina to make as many suggestions and corrections as he has, and to overcome my continuing stubborn refusal to agree with some of them, even though (as I eventually understood) they really were improvements. You can thank Mark for the form of many of this book''s explanations, and blame me for mangling any of them. Additional assorted thanks: to Susan Cyr for the cover art; to Bob Dinse and Eskimo North for providing the network access which is particularly vital to a project like this; to Bob Holland for providing the computer on which I''ve done most of the writing; to Pete Keleher for the Alpha text editor; to the University of Washington Mathematics Research and Engineering libraries for access to their collections; and to the University of Washington Oceanography department for letting me borrow their tape drives to access my dusty old archives of Usenet postings. Thanks to Tanmoy Bhattacharya for the example in question 11.10, to Arjan Kenter for the code in question 13.7, to Tomohiko Sakamoto for the code in question 20.31, and to Roger Miller for the line in question 11.35. Thanks to all these people, all over the world, who have contributed to the FAQ list in various ways, by offering suggestions, corrections, constructive criticism, or other support: Jamshid Afshar, David Anderson, Tanner Andrews, Sudheer Apte, Joseph Arceneaux, Randall Atkinson, Rick Beem, Peter Bennett, Wayne Berke, Dan Bernstein, John Bickers, Gary Blaine, Yuan Bo, Dave Boutcher, Michael Bresnahan, Vincent Broman, Stan Brown, Joe Buehler, Kimberley Burchett, Gordon Burditt, Burkhard Burow, Conor P. Cahill, D''Arcy J.M. Cain, Christopher Calabrese, Ian Cargill, Paul Carter, Mike Chambers, Billy Chambless, Franklin Chen, Jonathan Chen, Raymond Chen, Richard Cheung, Ken Corbin, Ian Cottam, Russ Cox, Jonathan Coxh
First Chapter

Preface

At some point in 1979, I heard a lot of people talking about this relatively new language, C, and the book which had just come out about it. I bought a copy of K&R, otherwise known as The C Programming Language, by Brian Kernighan and Dennis Ritchie, but it sat on my shelf for a while because I didn't have an immediate need for it (besides which I was busy being a college freshman at the time). It proved in the end to be an auspicious purchase, though, because when I finally did take it up, I never put it down: I've been programming in C ever since.

In 1983, I came across the Usenet newsgroup net.lang.c, which was (and its successor comp.lang.c still is) an excellent place to learn a lot more about C, and to find out what questions everyone else is having about C, and to discover that you may not know all there is to know about C after all. It seems that C, despite its apparent simplicity, has a number of decidedly non-obvious aspects, and certain questions come up over and over again. This book is a collection of some of those questions, with answers, based on the Frequently-Asked Questions ("FAQ") list which I began posting to comp.lang.c in May, 1990.

I hasten to add, however, that this book is not intended as a critique or "hatchet job" on the C language. It is all too easy to blame a language (or any tool) for the difficulties its users encounter with it, or to claim that a properly-designed tool "ought" to prevent its users from misusing it. It would therefore be easy to regard a book like this, with its long lists of misuses, as a litany of woes attempting to show that the language is hopelessly deficient. Nothing could be farther from the case.

I would never have learned enough about C to be able to write this book, and I would not be attempting to make C more pleasant for others to use by writing this book now, if I did not think that C was a great language or if I did not enjoy programming in it. I do like C, and one of the reasons that I teach classes in it and spend time participating in discussion about it on the Internet is that I would like to discover which aspects of C (or of programming in general) are difficult to learn or keep people from being able to program efficiently and effectively. This book represents some of what I've learned: these questions are certainly some of the ones people have the most trouble with, and the answers have been refined over a several-year period in an attempt to ensure that people don't have too much trouble with them.

A reader will certainly have trouble if there are any errors in these answers, and although the reviewers and I have worked hard to eliminate them, it can be as hard to eradicate the last error from a large manuscript as it is to stamp out the last bug in a program. I will appreciate any corrections or suggestions sent to me in care of the publisher or at the e-mail address below, and I would like to offer the customary $1.00 reward to the first finder of any error. If you have access to the Internet, you can check for an errata list (and a scorecard of the finders) at the ftp and http addresses mentioned in question 20.40.

As I hope I've made clear, this book is not a critique of the C Programming language, nor is it a critique of the book from which I first learned C, nor of that book's authors. I didn't just learn C from K&R; I also learned a lot about programming. As I contemplate my own contribution to the C programming literature, my only regret is that the present book does not live up to a nice observation made in the second edition of K&R, namely that "C is not a big language, and it is not well served by a big book." I hope that those who most deeply appreciate C's brevity and precision (and that of K&R) will not be too offended by the fact that this book says some things over and over and over, or in three slightly different ways.

Though my name is on the cover, there are a lot of people behind this book, and it's hard to know where to start handing out acknowledgments. In a sense, every one of comp.lang.c's readers (today estimated at 320,000) is a contributor: the FAQ list behind this book was written for comp.lang.c first, and this book retains the flavor of a good comp.lang.c discussion.

This book also retains, I hope, the philosophy of correct C programming which I began learning when I started reading net.lang.c. Therefore, I shall first acknowledge the posters who stand out in my mind as having most clearly and consistently articulated that philosophy: Doug Gwyn, Guy Harris, Karl Heuer, Henry Spencer, and Chris Torek. These gentlemen have displayed remarkable patience over the years, answering endless questions with generosity and wisdom. I was the one who stuck his neck out and started writing the Frequent questions down, but I would hate to give the impression that the answers are somehow mine. I was once the student (I believe it was Guy who answered my post asking essentially the present volume's question 5.10), and I owe a real debt to the masters who went before me. This book is theirs as much as mine, though I retain title to any inadequacies or mistakes I've made in the presentation.

The former on-line FAQ list grew by a factor of three in the process of becoming this book, and its growth was a bit rapid and awkward at times. Mark Brader, Vinit Carpenter, Stephen Clamage, Jutta Degener, Doug Gwyn, Karl Heuer, Joseph Kent, and George Leach read proposals or complete drafts and helped to exert some control over the process; I thank them for their many careful suggestions and corrections. Their efforts grew out of a shared wish to improve the overall understanding of C in the programming community. I appreciate their dedication.

Three of those reviewers have also been long-time contributors to the on-line FAQ list. I thank Jutta Degener and Karl Heuer for their help over the years, and I especially thank Mark Brader, who has been my most persistent critic ever since I first began posting the comp.lang.c FAQ list five years ago. I don't know how he has had the stamina to make as many suggestions and corrections as he has, and to overcome my continuing stubborn refusal to agree with some of them, even though (as I eventually understood) they really were improvements. You can thank Mark for the form of many of this book's explanations, and blame me for mangling any of them.

Additional assorted thanks: to Susan Cyr for the cover art; to Bob Dinse and Eskimo North for providing the network access which is particularly vital to a project like this; to Bob Holland for providing the computer on which I've done most of the writing; to Pete Keleher for the Alpha text editor; to the University of Washington Mathematics Research and Engineering libraries for access to their collections; and to the University of Washington Oceanography department for letting me borrow their tape drives to access my dusty old archives of Usenet postings.

Thanks to Tanmoy Bhattacharya for the example in question 11.10, to Arjan Kenter for the code in question 13.7, to Tomohiko Sakamoto for the code in question 20.31, and to Roger Miller for the line in question 11.35.

Thanks to all these people, all over the world, who have contributed to the FAQ list in various ways, by offering suggestions, corrections, constructive criticism, or other support: Jamshid Afshar, David Anderson, Tanner Andrews, Sudheer Apte, Joseph Arceneaux, Randall Atkinson, Rick Beem, Peter Bennett, Wayne Berke, Dan Bernstein, John Bickers, Gary Blaine, Yuan Bo, Dave Boutcher, Michael Bresnahan, Vincent Broman, Stan Brown, Joe Buehler, Kimberley Burchett, Gordon Burditt, Burkhard Burow, Conor P. Cahill, D'Arcy J.M. Cain, Christopher Calabrese, Ian Cargill, Paul Carter, Mike Chambers, Billy Chambless, Franklin Chen, Jonathan Chen, Raymond Chen, Richard Cheung, Ken Corbin, Ian Cottam, Russ Cox, Jonathan Coxhead, Lee Crawford, Steve Dahmer, Andrew Daviel, James Davies, John E. Davis, Ken Delong, Norm Diamond, Jeff Dunlop, Ray Dunn, Stephen M. Dunn, Michael J. Eager, Scott Ehrlich, Arno Eigenwillig, Dave Eisen, Bjorn Engsig, David Evans, Clive D.W. Feather, Dominic Feeley, Simao Ferraz, Chris Flatters, Rod Flores, Alexander Forst, Steve Fosdick, Jeff Francis, Tom Gambill, Dave Gillespie, Samuel Goldstein, Tim Goodwin, Alasdair Grant, Ron Guilmette, Michael Hafner, Tony Hansen, Elliotte Rusty Harold, Joe Harrington, Des Herriott, John Hascall, Ger Hobbelt, Dexter Holland & Co., Jos Horsmeier, Blair Houghton, James C. Hu, Chin Huang, David Hurt, Einar Indridason, Vladimir Ivanovic, Jon Jagger, Ke Jin, Kirk Johnson, Larry Jones, James Kew, Lawrence Kirby, Kin-ichi Kitano, the kittycat, Peter Klausler, Andrew Koenig, Tom Koenig, Adam Kolawa, Jukka Korpela, Ajoy Krishnan T, Markus Kuhn, Deepak Kulkarni, Oliver Laumann, John Lauro, Felix Lee, Mike Lee, Timothy J. Lee, Tony Lee, Marty Leisner, Don Libes, Brian Liedtke, Philip Lijnzaad, Keith Lindsay, Yen-Wei Liu, Paul Long, Christopher Lott, Tim Love, Tim McDaniel, Kevin McMahon, Stuart MacMartin, John R. MacMillan, Andrew Main, Bob Makowski, Evan Manning, Barry Margolin, George Matas, Brad Mears, Bill Mitchell, Mark Moraes, Darren Morby, Bernhard Muenzer, David Murphy, Walter Murray, Ralf Muschall, Ken Nakata, Todd Nathan, Landon Curt Noll, Tim Norman, Paul Nulsen, David O'Brien, Richard A. O'Keefe, Adam Kolawa, James Ojaste, Hans Olsson, Bob Peck, Andrew Phillips, Christopher Phillips, FranAois Pinard, Nick Pitfield, Wayne Pollock, Dan Pop, Lutz Prechelt, Lynn Pye, Kevin D. Quitt, Pat Rankin, Arjun Ray, Eric S. Raymond, Peter W. Richards, Eric Roode, Manfred Rosenboom, J. M. Rosenstock, Rick Rowe, Erkki Ruohtula, John Rushford, Rutabaga, Kadda Sahnine, Matthew Saltzman, Rich Salz, Chip Salzenberg, Matthew Sams, Paul Sand, David W. Sanderson, Frank Sandy, Christopher Sawtell, Jonas Schlein, Paul Schlyter, Doug Schmidt, Rene Schmit, Russell Schulz, Dean Schulze, Chris Sears, Patricia Shanahan, Raymond Shwake, Peter da Silva, Joshua Simons, Ross Smith, Henri Socha, Leslie J. Somos, David Spuler, James Stern, Bob Stout, Steve Sullivan, my sweetie Melanie Summit, Erik Talvola, Dave Taylor, Clarke Thatcher, Wayne Throop, Steve Traugott, Ilya Tsindlekht, Andrew Tucker, G'ran Uddeborg, Rodrigo Vanegas, Jim Van Zandt, Wietse Venema, Tom Verhoeff, Ed Vielmetti, Larry Virden, Chris Volpe, Mark Warren, Alan Watson, Kurt Watzka, Larry Weiss, Martin Weitzel, Howard West, Tom White, Freek Wiedijk, Dik T. Winter, Lars Wirzenius, Dave Wolverton, Mitch Wright, Conway Yee, Ozan S. Yigit, and Zhuo Zang. I have tried to keep track of everyone whose suggestions I have used, but I fear I've probably overlooked a few; my apologies to anyone whose name should be on this list, but isn't.

Finally, I'd like to thank my editor at Addison-Wesley, Debbie Lafferty, for tapping me on the electronic shoulder one day and asking if I might be interested in writing this book. I was, and you now hold it, and I hope that it may help to make C programming as pleasant for you as it is for me.

Steve Summit
scs@aw.com

Seattle, Washington



0201845199P04062001
Reviews
This item was reviewed in:
SciTech Book News, February 1996
To find out how to look for other reviews, please see our guides to finding book reviews in the Sciences or Social Sciences and Humanities.
Summaries
Back Cover Copy
Summit furnishes you with answers to some of the most frequently asked questions in C. Extensively revised from his popular FAQ list on the Internet, more than 400 questions are answered to illustrate key points and to provide practical guidelines for programmers. C Programming FAQs is a welcomed reference for all C programmers, providing accurate answers, insightful explanations, and clarification of fine points along with numerous code examples. Highlights How-to-manual covering the C language in a practical, nuts-and-bolts way Concise answers to more than 400 most frequently asked questions with definitively correct answers Description of real problems that crop up when writing actual programs Clarification of widely misunderstood issues: subtle portability problems, proper language usage, system-specific issues. 0201845199B04062001
Back Cover Copy
Summit furnishes you with answers to some of the most frequently asked questions in C. Extensively revised from his popular FAQ list on the Internet, more than 400 questions are answered to illustrate key points and to provide practical guidelines for programmers. C Programming FAQs is a welcomed reference for all C programmers, providing accurate answers, insightful explanations, and clarification of fine points along with numerous code examples. Highlights How-to-manual covering the C language in a practical, nuts-and-bolts way Concise answers to more than 400 most frequently asked questions with definitively correct answers Description of real problems that crop up when writing actual programs Clarification of widely misunderstood issues: subtle portability problems, proper language usage, system-specific issues.0201845199b04762001
Bowker Data Service Summary
Summit furnishes programmers with answers to the most frequently asked questions in C. Extensively revised from his popular FAQ on the Internet, more than 400 questions are addressed with comprehensive examples to illustrate key points.
Main Description
Whenever you reach an impasse while programming, try reaching for this collection of the most frequently asked questions-with answers-to C programmers' most plaguing problems. Written by a respected voice on USENET and the author of the USENET C FAQ, the book addresses the real-world problems that are asked over and over again on the comp.lang.c newsgroup. You will find concise and accurate answers with insightful explanations, clarification of fine points, and extensive code examples to help you over stumbling blocks and speed your programming progress.
Unpaid Annotation
Written by the originator of the USENET C FAQ, this book addresses the real-world problems on C programming that are asked, again and again, on the "comp.lang.c" newsgroup. The book is aimed at C programmers who need quick, concise answers to the stubborn questions which invariably arise when programming in C. It provides accurate answers, insightful explanations, and extensive code examples.
Table of Contents
Declarations and Initializations
Basic Types
Pointer Declarations
Declaration Style
Storage Classes
Typedefs
The const Qualifier
Complex Declarations
Array Sizes
Declaration Problems
Namespace
Initialization
Structures, Unions, and Enumerations
Structure Declarations
Structure Operations
Structure Padding
Accessing Members
Miscellaneous Structure Questions
Unions
Enumerations
Bit-fields
Expressions
Evaluation Order
Other Expression Questions
Preserving Rules
Pointers
Basic Pointer Use
Pointer Manipulations
Pointers as Function Parameters
Miscellaneous Pointer Use
Null Pointers
Null Pointers and Null Pointer Constants
The NULL Macro
Retrospective
What's Really at Address 0?
Arrays and Pointers
Basic Relationship of Arrays and Pointers
Arrays Can't Be Assigned
Retrospective
Pointers to Arrays
Dynamic Array Allocation
How can I avoid fixed-sized arrays? Functions and Multidimensional Arrays
Sizes of Arrays
Memory Allocation
Basic Allocation Problems
Calling malloc
malloc Problems
Freeing Memory
Sizes of malloc'ed Blocks
Other Allocation Functions
Characters and Strings
Boolean Expressions and Variables
C Preprocessor
Macro Definitions
Header Files
Conditional Compilation
Fancier Processing
Macros with Variable-Length Argument Lists
ANSI/ISO Standard C
The Standard Itself
Function Prototypes
The const Qualifier
Using main()
Preprocessor Features
Other ANSI C Issues
Old or Non-Standard Compilers
Compliance
Stdio
printf Formats
scanf Formats
scanf Problems
Other stdio Function
Opening and Manipulating Files
Redirecting stdin and stdout
"Binary" I/O
Library Functions
String Functions
Sorting
Date and Time
Random Numbers
Other Library Functions
Floating Point
Variable-Length Argument Lists
Calling Varargs Functions
Implementing Varargs Functions
Extracting Variable-Length Arguments
Harder Problems
Strange Problems
Style
Tools and Resources
Tools
Lint
Resources
System Dependencies
Keyboard and Screen I/O
Other I/O
Files and Directories
Accessing Raw Memory
"System" Commands
Process Environment
Other System-Dependent Operations
Retrospective
Miscellaneous
Miscellaneous Techniques
Bits and Bytes
Efficiency
Switch Statements
Miscellaneous Language Features
Other Languages
Algorithms
Trivia
0201845199T04062001
Table of Contents provided by Publisher. All Rights Reserved.

This information is provided by a service that aggregates data from review sources and other sources that are often consulted by libraries, and readers. The University does not edit this information and merely includes it as a convenience for users. It does not warrant that reviews are accurate. As with any review users should approach reviews critically and where deemed necessary should consult multiple review sources. Any concerns or questions about particular reviews should be directed to the reviewer and/or publisher.

  link to old catalogue

Report a problem