基本信息
源码名称：Advanced C and C++ Compiling - 2014.pdf
源码大小：29.91M
文件格式：.pdf
开发语言：C/C++
更新时间：2021-03-20
友情提示：（无需注册或充值，赞助后即可获取资源下载链接）
嘿，亲！知识可是无价之宝呢，但咱这精心整理的资料也耗费了不少心血呀。小小地破费一下，绝对物超所值哦！如有下载和支付问题，请联系我们QQ(微信同号)：813200300
本次赞助数额为： 4 元×
微信扫码支付：4 元
×
请留下您的邮箱，我们将在2小时内将文件发到您的邮箱
源码介绍
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.
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.