现代C编程实用技巧

需积分: 33 142 浏览量更新于2024-07-20 收藏 4.6MB PDF 举报

"21st Century C 是一本关于C语言编程的书籍，作者Ben Klemens探讨了如何在21世纪使用C语言进行更高效、更现代的开发。本书适用于初学者和有经验的程序员，旨在帮助读者了解并掌握最新的C语言技术和工具，包括调试、内存管理、编译过程组织以及源代码版本控制。" 21世纪的C语言已经不再是仅限于vi编辑器和cc编译器的时代，而是发展出了一系列现代化的工具来简化编程和提高效率。本书21st Century C关注的是C语言在新时期的演变，它不仅仅是一门编程语言的基础，更是一种适用于编写高效、前沿应用的现代语言。书中深入讨论了几个关键主题： 1. **调试技术**：C语言的调试不再仅限于传统的打印语句方法，现在有强大的调试器如GDB，可以帮助开发者跟踪程序执行、设置断点、检查变量状态等，从而更有效地定位和修复问题。 2. **内存管理**：内存泄漏是C语言程序员常见的痛点，但现代工具如Valgrind可以检测内存泄漏和不恰当的内存使用，帮助开发者优化内存管理，避免程序崩溃或性能下降。 3. **编译过程组织**：现代构建系统（如Make、CMake、SCons等）使得C项目管理更加规范，可以自动化依赖关系处理，加速编译过程，支持跨平台开发。 4. **源代码版本控制**：Git等版本控制系统已经成为现代开发的标准配置，它们允许团队协作，追踪代码历史，轻松回滚到任何版本，这对于大型项目的管理和维护至关重要。 5. **现代编程实践**：除了基本语法，21st Century C还可能涵盖现代编程实践，比如面向对象设计、泛型编程、单元测试和持续集成，这些都是使C语言适应复杂软件工程需求的关键。通过21st Century C，读者将了解到C语言如何与新的开发环境和技术相结合，如何利用这些工具和方法来提升开发效率和代码质量。无论你是初学者还是经验丰富的C程序员，这本书都能提供有价值的见解和指导，帮助你在21世纪的编程世界中更好地利用C语言。

bility used C, the people who wanted more and more features so they could wallow in

them like moist hundred dollar bills got C++, and everybody was happy.

ISO C99

The C standard underwent a major revision a decade later. Additions were made

for numeric and scientific computing, with a standard type for complex numbers

and some type-generic functions. A few conveniences from C++ got lifted,

including one-line comments (which originally came from one of C’s predecessor

languages, BCPL) and being able to declare variables at the head of for loops.

Using structures was made easier thanks to a few additions to the rules for how

they can be declared and initialized, plus some notational conveniences. Things

were modernized to acknowledge that security matters and that not everybody

speaks English.

When you think about just how much of an impact C89 had, and how the entire

globe was running on C code, it’s hard to imagine the ISO being able to put out

anything that wouldn’t be widely criticized—even a refusal to make any changes

would be reviled. And indeed, this standard was controversial. There are two

common ways to express a complex variable (rectangular and polar coordinates)

—so where does the ISO get off picking one? Why do we need a mechanism for

variable-length macro inputs when all the good code got written without it? In

other words, the purists accused the ISO of selling out to the pressure for more

features.

As of this writing, most compilers support C99 plus or minus a few caveats; the

long double type seems to cause a lot of trouble, for example. However, there is

one notable exception to this broad consensus: Microsoft currently refuses to add

C99 support to its Visual Studio C++ compiler. The section “Compiling C with

Windows” on page 4 covers some of the many ways to compile C code for Win‐

dows, so not using Visual Studio is at most an inconvenience, and having a major

establishment player tell us that we can’t use ANSI- and ISO-standard C only bol‐

sters the punk rock of it all.

C11

Self-conscious about the accusations of selling out, the ISO made few serious

changes in the third edition of the standard. We got a means of writing type-

generic functions, and things were modernized to further acknowledge that secu‐

rity matters and that not everybody speaks English.

The C11 standard came out in December of 2011, but support for the standard

has been implemented by compiler authors at a surprisingly rapid pace, to the

point that a number of major compilers already claim near-complete conform‐

ance. However, the standard defines behavior for both the compiler and the stan‐

dard library—and library support, such as for threading and atomics, is complete

on some systems but catching up on others.

xiv | Preface

The POSIX Standard

That’s the state of things as far as C itself goes, but the language coevolved with the

Unix operating system, and you will see throughout the book that the interrelation‐

ship matters for day-to-day work. If something is easy on the Unix command line, it

is probably because it is easy in C; Unix tools are often written to facilitate writing C

code.

Unix

C and Unix were designed at Bell Labs in the early 1970s. During most of the

20th century, Bell was being investigated for monopolistic practices, and one of

its agreements with the US federal government included promises that Bell

would not expand its reach into software. So Unix was given away for free for

researchers to dissect and rebuild. The name Unix is a trademark, originally

owned by Bell Labs and subsequently traded off like a baseball card among a

number of companies.

Variants of Unix blossomed as the code was looked over, reimplemented, and

improved in different ways by diverse hackers. It just takes one little incompatibility

to make a program or script unportable, so the need for some standardization quickly

became apparent.

POSIX (Portable Operating System Interface)

This standard, first established by the Institute of Electrical and Electronics Engi‐

neers (IEEE) in 1988, provided a common basis for Unix-like operating systems.

It specifies how the shell should work, what to expect from commands like ls

and grep, and a number of C libraries that C authors can expect to have available.

For example, the pipes that command-line users use to string together com‐

mands are specified in detail here, which means C’s popen (pipe open) function is

POSIX-standard, not ISO C-standard. The POSIX standard has been revised

many times; the version as of this writing is POSIX:2008, and that is what I am

referring to when I say that something is POSIX-standard. A POSIX-standard

system must have a C compiler available, via the command name c99.

This book will use the POSIX standard, though I’ll tell you when.

With the exception of many members of a family of OSes from Microsoft, just

about every current operating system you could name is built on a POSIX-

compliant base: Linux, Mac OS X, iOS, webOS, Solaris, BSD—even Windows

servers offer a POSIX subsystem. And for the hold-out OSes, “Compiling C with

Windows” on page 4 will show you how to install a POSIX subsystem.

Finally, there are two more implementations of POSIX worth noting because of their

prevalence and influence:

Preface | xv

BSD

After Unix was made available from Bell Labs for the public to dissect, the

researchers at the University of California, Berkeley, made major improvements,

eventually rewriting the entire Unix code base to produce the Berkeley Software

Distribution. If you are using a computer from Apple, Inc., you are using BSD

with an attractive graphical frontend. BSD goes beyond POSIX in several

respects, and we’ll see some functions that are not part of the POSIX standard

but are too useful to pass up (most notably the lifesaver that is asprintf).

GNU

It stands for GNU’s Not Unix, and is the other big success story in independently

reimplementing and improving on the Unix environment. The great majority of

Linux distributions use GNU tools throughout. There are very good odds that

you have the GNU Compiler Collection (gcc) on your POSIX box—even BSD

uses it. Again, the gcc defines a de facto standard that extends C and POSIX in a

few ways, and I will be explicit when making use of those extensions.

Legally, the BSD license is slightly more permissive than the GNU license. Because

some parties are deeply concerned with the political and business implications of the

licenses, one can typically find both GNU and BSD versions of most tools. For exam‐

ple, both the gcc and the BSD’s clang are top-notch C compilers. The authors from

both camps closely watch and learn from each other’s work, so we can expect that the

differences that currently exist will tend to even out over time.

The Legal Sidebar

US law no longer has a registration system for copyright: with few exceptions, as soon

as anybody writes something down, it is copyrighted.

Of course, distribution of a library depends on copying from hard drive to hard drive,

and there are a number of common mechanisms for granting the right to copy a

copyrighted work with little hassle.

The GNU Public License (GPL)

This allows unlimited copying and use of the source code and its executable

version. There is one major condition: If you distribute a program or library

based on the GPLed source code, then you must distribute the source code to

your program. Note well that if you use your program in-house and don’t distrib‐

ute it, this condition doesn’t hold, and you have no obligation to distribute

source. Running a GPLed program, like compiling your code with gcc, does not

in itself obligate you to distribute source code, because the program output (such

as the executable you just compiled) is not considered to be based on or a deriva‐

tive of gcc. Example: the GNU Scientific Library.

xvi | Preface

The Lesser GPL (LGPL)

The LGPL is much like the GPL, but it explicitly stipulates that if you are linking

to an LGPL library as a shared library, then your code doesn’t count as a deriva‐

tive work, and you aren’t obligated to distribute source. That is, you can distrib‐

ute closed-source code that links to an LGPL library. Example: GLib.

The BSD License

This license requires that you preserve copyrights and disclaimers for BSD-

licensed source code, but it doesn’t require that you redistribute source code.

Example: Libxml2, under the BSD-like MIT license.

Please note the usual disclaimer: I am not a lawyer, and this is a sidebar summary of

several rather long legal documents. Read the documents themselves or consult a law‐

yer if you are unsure about how the details apply to your situation.

Some Logistics

The Second Edition

I used to be a cynic and think that people just wrote second editions to disrupt all the

people selling used copies of the first edition. But this second edition actually could

not have happened without the first being published, and could not have happened

sooner (and most of the book’s readers are reading electronic copies anyway).

The big addition from the first edition is the chapter on concurrent threads, aka par‐

allelization. It focuses on OpenMP and atomic variables and structs. OpenMP is not

part of the C standard, but it is a reliable part of the C ecosystem, so it comfortably

fits into this book. Atomic variables were added in the December 2011 revision of the

C standard, so when this book came out less than a year later there were no compilers

that supported them. We are now far enough along that I could write this chapter

based both on the theory presented in the standard and the practice of a real-world

implementation and tested code. See Chapter 12.

The first edition was blessed with some wonderfully pedantic readers. They caught

everything that could be somehow construed as a bug, from the stupid thing I said

about dashes on the command line to sentences whose wording could be miscon‐

strued incorrectly in certain cases. Nothing in this world is bug-free, but the book is

much more accurate and useful as a result of so much great reader feedback.

Other additions to this edition:

•

Appendix A provides a basic C tutorial for readers coming from another lan‐

guage. I was reluctant to include it in the first edition because there are so many

C tutorials out there, but the book is more useful with it than without.

Preface | xvii

• By popular demand, I expanded the discussion of how to use a debugger signifi‐

cantly. See “Using a Debugger” on page 31.

•

The first edition had a segment on how to write functions that take in a list of

arbitrary length, so both sum(1, 2.2) and sum(1, 2.2, 3, 8, 16) would be

valid. But what if you want to send multiple lists, like writing a dot-product func‐

tion that multiplies two arbitrary-length vectors, like dot((2, 4), (-1, 1)) and

dot((2, 4, 8, 16), (-1, 1, -1, 1))? “Multiple Lists” on page 210 covers this.

•

I rewrote Chapter 11, on extending objects with new functions. The primary

addition is an implementation of virtual tables.

•

I wrote a little more on the preprocessor, with an intro to the morass of test mac‐

ros and their use in “Test Macros” on page 170, including a passing mention of the

_Static_assert keyword.

•

I stuck to a promise I made to myself to not include a tutorial on regular expres‐

sion parsing in this book (because there are hundreds online and in other books).

But I did add a demo in “Parsing Regular Expressions” on page 322 on the use of

the POSIX regular expression parsing functions, which are in a relatively raw

form compared to regex parsers in many other languages.

•

The discussion of string handling in the first edition relied heavily on asprintf,

a sprintf-like function that autoallocates the required amount of memory

before writing a string to the space. There is a version widely distributed by the

GNU, but many readers were constrained from using it, so in this edition I added

Example 9-3, showing how to write such a function from C-standard parts.

•

One of the big themes in Chapter 7 is that micromanaging numeric types can

cause trouble, so the first edition made no mention of the dozens of new numeric

types introduced in the C99 standard, like int_least32_t, uint_fast64_t, and

so on (C99 §7.18; C11 §7.20). Several readers encouraged me to at least mention

some of the more useful types, like intptr_t and intmax_t, which I now do

where appropriate.

xviii | Preface

剩余407页未读，继续阅读

libingchen

粉丝: 29
资源: 263

现代C编程实用技巧

21st Century C.pdf

[含随书源码]21st Century C 2nd Edition(C程序设计新思维 )

21世纪C语言教程（21st Century C, 2nd Edition）-2015年英文原版，0积分

21st Century C：现代C编程指南

《21st Century C》第二版：现代C语言编程指南

21st Century C - 信息技术新篇章

Compiler Contruction for the 21st Century

A View of 20th and 21st Century Software Engineering

21st-Century-Examples, _21st Klemens的世纪C_示例.zip

Jist.Works.Best.Jobs.for.the.21st.Century.3rd.Ed.eBook-DDU.pdf

最新资源