Advanced.C.and.C++.Compiling.pdf

(29765 KB) Pobierz
For your convenience Apress has placed some of the front
matter material after the index. Please use the Bookmarks
and Contents at a Glance links to access them.
Contents at a Glance
About the Author �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½
xv
About the Technical Reviewers �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½
xvii
Acknowledgments �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½
xix
Introduction �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½
xxi
Chapter 1: Multitasking OS Basics �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½1
Chapter 2: Simple Program Lifetime Stages �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½9
Chapter 3: Program Execution Stages �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½43
Chapter 4: The Impact of Reusing Concept �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½53
Chapter 5: Working with Static Libraries �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½75
Chapter 6: Designing Dynamic Libraries: Basics�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½81
Chapter 7: Locating the Libraries �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½115
Chapter 8: Designing Dynamic Libraries: Advanced Topics �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½137
Chapter 9: Handling Duplicate Symbols When Linking In Dynamic Libraries �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½155
Chapter 10: Dynamic Libraries Versioning �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½187
Chapter 11: Dynamic Libraries: Miscellaneous Topics �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½233
Chapter 12: Linux Toolbox �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½243
Chapter 13: Linux How To’s �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½277
Chapter 14: Windows Toolbox �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½291
Index �½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½�½309
v
Introduction
It took me quite some time to become aware of an amazing analogy that exists between the culinary art and the art of
computer programming.
Probably the most obvious comparison that comes to mind is that both the culinary specialist and the programmer
have similar ultimate goals: to feed. For a chef, it is the human being, for which plenty of raw ingredients are used to
provide edible nutrients as well as gastronomic pleasure, whereas for the programmer it is the microprocessor, for
which a number of different procedures are used to provide the code that not only needs to produce some meaningful
actions, but also needs to be delivered in the optimum form.
As much as this introductory comparison point may seem a bit far-fetched or even childish, the subsequent
comparison points are something that I find far more applicable and far more convincing.
The recipes and instructions for preparing dishes of all kinds are abundant and ubiquitous. Almost every popular
magazine has a culinary section dedicated to all kinds of foods, and all kind of food preparation scenarios, ranging
from quick-and-easy/last-minute recipes all the way to really elaborate ones, from ones focusing on nutrition tables
of ingredients to ones focusing on the delicate interplay between extraordinary, hard-to-find ingredients.
However, at the next level of expertise in the culinary art, the availability of resources drops exponentially.
The recipes and instructions for running the food business (volume production, running the restaurant, or catering
business), planning the quantities and rhythm of delivery for food preparation process, techniques and strategies
for optimizing the efficiency of food delivery, techniques for choosing the right ingredients, minimizing the decay of
stored ingredients—this kind of information is substantially more hard to find. Rightfully so, as these kinds of topics
delineate the difference between amateur cooking and the professional food business.
The situation with programming is quite similar.
The information about a vast variety of programming languages is readily available, through thousands of books,
magazines, articles, web forums, and blogs, ranging from the absolute beginner level all the way to the “prepare for
the Google programming interview” tips.
These kinds of topics, however, cover only about half of the skills required by the software professional. Soon after
the immediate gratification of seeing the program we created actually executing (and doing it right) comes the next
level of important questions: how to architect the code to allow for easy further modifications, how to extract reusable
parts of the functionality for future use, how to allow smooth adjustment for different environments (starting from
different human languages and alphabets, all the way to running on different operating systems).
As compared to the other topics of programming, these kinds of topics are rarely discussed, and to this day
belong to the form of “black art” reserved for a few rare specimens of computer science professionals (mostly software
architects and build engineers) as well as to the domain of university-level classes related to the compiler/linker design.
One particular factor—the ascent of Linux and the proliferation of its programming practices into a multitude
of design environments—has brought a huge impetus for a programmer to pay attention to these topics. Unlike the
colleagues writing software for “well-cushioned” platforms (Windows and Mac, in which the platform, IDEs, and
SDKs relieve the programmer of thinking about certain programming aspects), a Linux programmer’s daily routine is
to combine together the code coming from variety of sources, coding practices, and in forms which require immediate
understanding of inner workings of compiler, linker, the mechanism of program loading, and hence the details of
designing and using the various flavors of libraries.
xxi
IntroduCtIon
The purpose of this book is to discuss a variety of valuable pieces of information gathered from a scarce and
scattered knowledge base and validate it through a number of carefully tailored simple experiments. It might be
important to point out that the author does not come from a computer science background. His education on
the topic came as a result of being immersed as electrical engineer in the technology frontier of the Silicon Valley
multimedia industry in the time of the digital revolution, from the late 90s to the present day. Hopefully, this
collection of topics will be found useful by a wider audience.
Audience (Who Needs This Book and Why)
The side effect of myself being a (very busy, I must say proudly) software design hands-on consultant is that I regularly
come in contact with an extraordinary variety of professional profiles, maturity, and accomplishment levels. The solid
statistic sample of the programmer population (of Silicon Valley, mostly) that I meet by switching office environments
several times during a work week has helped me get a fairly good insight into the profiles of who may benefit from
reading this book. So, here they are.
The first group is made of the C/C++ programmers coming from a variety of engineering backgrounds
(EE, mechanical, robotics and system control, aerospace, physics, chemistry, etc.) who deal with programming on
a daily basis. A lack of formal and more focused computer science education as well as a lack of non-theoretical
literature on the topic makes this book a precious resource for this particular group.
The second group is comprised of junior level programmers with a computer science background. This book
may help concretize the body of their existing knowledge gained in core courses and focus it to the operational level.
Keeping the quick summaries of Chapters 12–14 somewhere handy may be worthwhile even for the more senior
profiles of this particular group.
The third group is made of folks whose interest is in the domain of OS integration and customization.
Understanding the world of binaries and the details of their inner working may help “clean the air” tremendously.
About the Book
Originally, I did not have any plans to write this particular book. Not even a book in the domain of computer science.
(Signal processing? Art of programming? Maybe . . . but a computer science book? Naaah . . .)
The sole reason why this book emerged is the fact that through the course of my professional career I had to deal
with certain issues, which at that time I thought someone else should take care of.
Once upon a time, I made the choice of following the professional path of a high-tech assassin of sort, the guy
who is called by the citizens of the calm and decent high tech communities to relieve them from the terror of nasty
oncoming multimedia-related design issues wreaking havoc together with a gang of horrible bugs. Such a career
choice left pretty much no space for exclusivity in personal preferences typically found by the kids who would eat the
chicken but not the peas. The ominous “or else” is kind of always there. Even though FFTs, wavelets, Z-transform,
FIR and IIR filters, octaves, semitones, interpolations and decimations are naturally my preferred choice of tasks
(together with a decent amount of C/C++ programming), I had to deal with issues that would not have been my
personal preference. Someone had to do it.
Surprisingly, when looking for the direct answers to very simple and pointed questions, all I could find was a
scattered variety of web articles, mostly about the high-level details. I was patiently collecting the “pieces of the puzzle”
together, and managed to not only complete the design tasks at hand but also to learn along the way.
One fine day, the time came for me to consolidate my design notes (something that I regularly do for the variety
of topics I deal with). This time, however, when the effort was completed, it all looked . . . well . . . like a book. This book.
Anyways . . .
Given the current state of the job market, I am deeply convinced that (since about the middle of the first decade
of 21st century) knowing the C/C++ language intricacies perfectly—and even algorithms, data structures, and design
patterns—is simply not enough.
xxii
Zgłoś jeśli naruszono regulamin