[{"_1":2,"_126":-5,"_127":-5},"loaderData",{"_3":4,"_38":-5,"_39":40,"_107":108,"_124":-5,"_125":-5},"root",{"_5":-5,"_6":-5,"_7":8,"_22":23,"_24":25,"_26":27,"_30":31,"_36":37},"user","shoppingCartId","shoppingCart",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20,"_21":14},"id","no-cart","count",0,"free",true,"updatedAt","2026-02-20T01:34:16.509Z","paymentGateway","STRIPE","cartItems",[],"loading","locale","en","readerTheme","light","constants",{"_28":29},"paypalClientId","AX53Cwz8jR6rVVzzZiZNWWXl0dGagi-GZrjG-S3Ua14E5nrKMn7DxDQ730O4R8LusLPp49ALn6aRVaEy","publishers",{"_32":33,"_34":35},"companies",[],"universities",[],"needsLocaleCookieSync",false,"routes/_store+/_readers+/read_/route","routes/_store+/_readers+/read_.$slug/route",{"_41":42,"_67":68,"_100":101,"_105":37,"_106":-7},"book",{"_43":44,"_45":46,"_47":48,"_49":50,"_53":54,"_56":57,"_65":66},"title","C++ for dinosaurs","slug","cpp_for_dinosaurs","metaText","Learn how to use C++ to produce more readable code, faster than C, and simpler to write. No object oriented programing. Explains how to reduce cache misses.","coverFeatured",{"_51":52},"url","https://d2sofvawe08yqg.cloudfront.net/cpp_for_dinosaurs/s_featured?1620419010&1620419010","coverFeatured2x",{"_51":55},"https://d2sofvawe08yqg.cloudfront.net/cpp_for_dinosaurs/s_featured2x?1620419010&1620419010","authors",[58],{"_9":59,"_60":61,"_5":62},"Z2lkOi8vbGVhbnB1Yi9TdG9yZTo6UHJvZHVjdEF1dGhvci8xMTM4MQ","name","Nick Economidis",{"_63":64},"username","nickeconomidis","showReadLinkString","sample","parts",[69,79],{"_43":70,"_71":72,"_73":74,"_75":76,"_77":78},"Preface","description","","fileCount",1,"path","#leanpub-auto-preface","chapters",[],{"_43":80,"_71":72,"_73":74,"_75":81,"_77":82},"Learning the details","#leanpub-auto-learning-the-details",[83],{"_84":85,"_43":86,"_75":87,"_73":74,"_88":89,"_96":-5},"level",2,"Avoid using low-level strings","#leanpub-auto-avoid-using-low-level-strings","subsections",[90,97],{"_84":91,"_43":92,"_71":-5,"_75":93,"_73":74,"_94":-5,"_95":-5,"_96":-5},3,"Problem description","#leanpub-auto-problem-description","quizType","sectionNum","youtubeId",{"_84":91,"_43":98,"_71":-5,"_75":99,"_73":74,"_94":-5,"_95":-5,"_96":-5},"The solution","#leanpub-auto-the-solution","toc",[102,103,104,90,97],{"_84":74,"_43":70,"_71":-5,"_75":76,"_73":74,"_94":-5,"_95":-5,"_96":-5},{"_84":74,"_43":80,"_71":-5,"_75":81,"_73":74,"_94":-5,"_95":-5,"_96":-5},{"_84":85,"_43":86,"_71":-5,"_75":87,"_73":74,"_94":-5,"_95":-5,"_96":-5},"isUnavailableOnline","unavailableMessage","routes/_store+/_readers+/read_.$slug.$chapterId/route",{"_43":44,"_109":-5,"_41":110,"_121":-5,"_122":123},"content",{"_111":112,"_43":44,"_47":48,"_45":46,"_65":66,"_113":114,"_120":-5},"previewContent","

\n Preface\n
- \n
  - \n Who is this book for\n
  - \n How to read this book\n
  - \n Why this book was written\n
  - \n Acknowledgements:\n
  - \n Step 4: Algorithms should read like pseudocode\n
  \n
\n
\n Learning the details\n
- \n Avoid using low-level strings\n
  - \n Problem description\n
  - \n The solution\n
  \n
\n

Preface

\n\n

Habits are the brain’s actions in power-saving mode.\nExperienced programmers evolve habits so that they can save energy in common tasks,\nand spend it in solving difficult problems.

\n\n

Dinosaurs are the experienced programmers in the company who have\nevolved a style of programming featuring a certain pattern of habits.\nThe older the dinosaurs are, the more obstinate they are. \nThey aren’t willing to break these habits, because they work fine for them.

\n\n

From the development’s point of view, this argument is actually right;\ndevelopment is usually faster when you use habits and don’t stand to think for simple things.\nFor the whole program though, development only accounts for about 15% of \nthe temporal effort, while maintenance accounts for nearly 80%.\nThere are habits, especially old ones, \nthat have a serious impact in reading, understanding, and therefore maintaining code.\nThis includes both other people’s code, or even one’s own, 2-month-old code.

\n\n

In this book I am addressing such habits, and provide alternative ones,\nbased on contemporary instruments provided by C++.

\n\n

This book is not about teaching for a paradigm-shift.\nIt is about writing C++ using native idioms, not like C, Java, or Fortran.

\n\n

The book makes use of features in C++03 and C++ Technical Report 1 libraries (tr1). \nSo, any compiler after 2005 should support the contents of this book.\nCertain features of C++11 are also discussed as an alternative, where applicable.

\n\n

Who is this book for

\n\n

This book was originally aimed for engineers and programmers who strongly believe in C. \nMost of the bad habits stem from practices developed by the low-level nature of C. \nThe problems of these habits are demonstrated and alternatives are offered.\nThe book contains all the necessary material, so that C programmers can get the kickstart they need to embrace C++.
\nC++ programmers will benefit from the style described in this book. \nTheir style is often filled with impurities inherited from Java and C books.
Students will find a guide to creating professional looking coding style. \nColleges very rarely provide any incentive for writing quality code.\nThis book bridges the gap between knowing C++ and writing good code.

If you care about software quality but fear that it takes huge organisational changes to achieve it, \nthis book is the missing link towards your goal.

\n\n

I am describing steps that you can take to write clear code. This is an important quality because:

\n\n

Clear code increases readability.
Readable code allows your partner to have an opinion about your code.
Readable code is the prerequisite for code reviews.
It is other people’s eyes that spot bugs, not tests¹.
Clear code also promotes maintenance.

Prerequisite knowledge

\n\n

This book will not teach you C++. \nI expect that you can write C or C++ without much difficulty. \nI suppose that at least six months of working experience or \na couple of years of exercises at college should be enough for appreciating this book.
You do not need to know C++, but you should be able to write in C.
\nNo object oriented programming knowledge is required.

How to read this book

\n\n

The first half of the book can be read sequentially. \nI demonstrate the characteristics of poor code that I am addressing. \nThen I describe the common arguments of those who resist adopting C++ and explain how I am going to invert them. \nFinally, I describe the six steps that you can take to write clearer code.

\n\n

Throughout the first chapters, there are references to the second part of the book. \nAll examples and demonstrations are studied in separate chapters. \nThis gives me enough space to go into greater depths. \nIt makes reading the whole concept smoother, too.

\n\n

Why this book was written

\n\n

I studied Electrical Engineering in the mid 90’s, and I was taught C and Matlab for problem solving.\nI only used C for production code.

\n\n

I have worked on programs that already had a lifetime of more than 10 years. \nThis means that they carried a lot of legacy code. \nThe features had to be delivered fast, and there was hardly ever enough time for proper programming.

\n\n

Most of my career I had to use C and C++. \nHowever, there was always an underlying rule that C was to be preferred.\nThere was not enough trust that C++ had a significant advantage – C++ was thought of as an object-oriented language. \nIndeed, I have made a lot of regrettable errors in my projects, \nas a result of experimenting with features of C++, especially object-oriented programming. \nBut I always felt a strong distaste whenever I had to switch to C.

\n\n

Finally after ten years, through the advancements of C++ and some experts’ ideas, \nI feel that I can present (without remorse) some ways C programmers can use \nto create elegant, readable, yet traditional programs.

\n\n

These ways involve the use of certain C++ features to make good old-fashioned C code read and work better. \nThey have nothing to do with object oriented programming. \nIt is not the most suitable solution for most problems anyway.

\n\n

I presented these advancements through a series of lectures to my colleagues,\nand it was the first time that I managed to change the dinosaurs’ attitude towards C++.\nIn fact, they were so interested that they encouraged me to write this book.

\n\n

In this book I will demonstrate how C-style makes code unreadable, buggy and slow. \nI will show the features of C++ that deter people from adopting it, and how to fix this issue. \nI will present a few basic rules, that will change how you write, not how you think. \nUltimately, with this style shift, your code will read nicer, \nyou will reduce the bug count, and your program may even run faster.

\n\n

Acknowledgements:

\n\n

This book collects the best ideas and suggestions about readable code, presented recently by\nSean Parent, Bjarne Stroustup, James Coplien and Trygve Reenskaug. \nTheir presentations were so inspiring I felt I had to test, present and write about them.\nThis book serves as a testimonial that their proposals actually work for production code,\nand are also easy to learn and adhere to.

\n\n

The cover of this book was painted by Chrysa Malama.

\n\n\n

Step 4: Algorithms should read like pseudocode

\n\n

When an algorithm is described like pseudo-code, there is hardly ever any mention about the underlying data-structures. No statement is made on whether a list, a dynamic array, or a binary tree should be used.

\n\n

With C++, it is possible to code in such a way.

\n\n

Let’s compare how you would write an algorithm in C, that accumulates numbers in an array:

\n\n

int accumulate (int numbers[], int sz, int sum)\n{\n    int i;\n    for (i=0; i<sz; i++) {\n        sum += numbers[i];\n    }\n    return sum;\n}\n

\n\n

Now, what would you do if you had to accumulate the entries of a binary tree? or a linked list?

\n\n

would you re-write a version of accumulate() for the tree or the list? or
would you copy the tree or list into an array and then call accumulate()?

well, people usually choose the path of least pain:

\n\n

if you’re in a hurry, you copy the data into suitable data structure, and then move to the next task.
if you have time, you rewrite the algorithm, find a clumsy name, like accumulate_list(), or accumulate2(), taking the risk of introducing bugs.
If the algorithm is simple enough, you rewrite it in-place, where you need it.

a really conscious programmer might even consider writing a macro for it–for reuse. Try writing a macro for as simple an algorithm as this one! Then, try to provide a nice API to call it!

\n\n

Done that? Now what would you do if you needed to accumulate over a container of doubles?

\n\n

But really, if you wanted to describe the algorithm to your colleague, you would write it like:

\n\n

T accumulate (IT from, IT to, T sum) \n{\n    foreach entry in [from:to]\n        sum += entry;\n    return sum\n}\n

\n\n

well, the equivalent in C++ is:

\n\n

template <typename T, typename IT>\ninline\nT accumulate (IT from, IT to, T sum) \n{\n    for (IT iter = from; iter != to; ++iter)\n        sum += *iter;\n    return sum;\n}\n

\n\n

Look how you can call it:

\n\n

vector<int>  v;   int    sum = 5;   sum = accumulate (v.begin(), v.end(), sum);\nlist<double> v;   double sum = 5;   sum = accumulate (v.begin(), v.end(), sum);\nset<float>   v;   float  sum = 5;   sum = accumulate (v.begin(), v.end(), sum);\n

\n\n

this allows you to replace the container types without changing user code.

\n\n

How does that compare to a C function ?

\n\n

readability

apart from the first line that declares the template types, the rest is good-old C/C++ code – there is no special syntax, or characters like \\, # or ## that you see in macros.

speed

execution speed is definitely much faster than copying the container to an array. The function is marked as inline, allowing the optimiser to decide whether it should be inlined, or not. In C,

if accumulate() was an extern function, the optimiser would not be able to optimise.

if a macro was used, the function would have forcefully be inlined, but that might not be the best action to take, especially for functions longer than 2-3 lines.

size of executable

if accumulate() is implemented as an extern function:

in C, the code remains in the executable, even if it is not called.

in C++, the template function is instantiated only when it is used.

if accumulate() is implemented as macro:

in C, the code is copied in every macro use.

In C++, some calls of the template function may be inlined, while others will share a single instance of the function.

code reuse

only by using a macro (a well known bad practice) can you reuse an algorithm. Template provides a much better option.

Learning the details

\n\n

Avoid using low-level strings

\n\n

C-style strings require too much housekeeping. Code is susceptible to bugs and memory leaks.

\n\n

Problem description

\n\n

You do not know when a function returns a pointer to a string, or to a copy of the string. \nYou simply cannot trust the return value of a function.

\n\n

Consider the following code, that uses a function, change_working_directory().

\n\n

const char *old_dir;\nconst char *new_dir;\n\nchange_working_directory (\"~/books/literature\");\nold_dir = get_working_directory();\n\nchange_working_directory (\"~/books/comics\");\nnew_dir = get_working_directory();\n...\n

\n\n

What is the string for old_dir and new_dir ?

\n\n

It should be that old_dir is \"~/books/literature\" and new_dir is \"~/books/comics\". \nBut it actually depends on the implementation of get_working_directory().

\n\n\n\n \n

\n \n

typically, you can get the current working directory using this method.

\n\n

   int sz = A_FILENAME_MAX; \n   char *cwd = malloc(sz);\n   if( !getcwd( cwd, sz ) ) {\n       if (errno == ERANGE) {\n           do {\n               sz *= 2;\n               cwd = realloc(cwd, sz);\n           } while (getcwd(cwd, sz) == NULL && errno == ERANGE);\n       }\n       else {\n       }\n   }\n

\n \n

\n\n\n

If get_working_directory() is implemented as:

\n\n

const char* get_working_directory()\n{\n    int sz = A_FILENAME_MAX; \n    static char *cwd = malloc(sz);   // static, to avoid allocations\n    ...\n    return cwd;\n}\n

\n\n

then old_dir and new_dir will be the same, namely \"~/books/comics\".\nWhich is totally counter intuitive!

\n\n

If this is the way that get_working_directory() is implemented, you would have to write

\n\n

const char *old_dir;\nconst char *new_dir;\n\nchange_working_directory (\"~/books/literature\");\nold_dir = strdup (get_working_directory());\n\nchange_working_directory (\"~/books/comics\");\nnew_dir = strdup(get_working_directory());\n\n...\nfree(new_dir);\nfree(old_dir);\n

\n\n

We have guarded ourselves from unexpected behavior, taking a big hit in readability.

\n\n

Unfortunately, this is not a global solution against this type of problems: the code now runs the risk of memory leaks.

\n\n

What if get_working_directory() is implemented like this?

\n\n

const char* get_working_directory()\n{\n    int sz = A_FILENAME_MAX; \n    char *cwd = malloc(sz);   // non-static\n    ...\n    return cwd;\n}\n

\n\n

In this case, it is the user who is responsible of freeing the string.

\n\n

const char *old_dir;\nconst char *new_dir;\n\nchange_working_directory (\"~/books/literature\");\nold_dir = get_working_directory();\n\nchange_working_directory (\"~/books/comics\");\nnew_dir = get_working_directory();\n\n...\n\nfree (new_dir);\nfree (old_dir);\n

\n\n

As you can see, there’s no way you can compose the user code to guard against any kind of implementation of such functions. Even if one looks at the declaration of the function, he cannot tell whether he owns the string returned, or not.

\n\n

The solution

\n\n

The solution is to use C++’s string. In this case, we can implement get_working_directory() was so that it returns a string:

\n\n

string get_working_directory()\n{\n    int sz = A_FILENAME_MAX; \n    char *cwd = malloc(sz);\n    ...\n    return string(cwd);\n}\n

\n\n

This leads to a user code which is always safe, and easy to read.

\n\n

change_working_directory (\"~/books/literature\");\nstring old_dir = get_working_directory();\n\nchange_working_directory (\"~/books/comics\");\nstring new_dir = get_working_directory();\n\n...\n

\n\n

now, this code

\n\n

is easy to read
requires no housekeeping (no calls to free() are needed)
the strings returned can be changed - they are not const\n
there are no surprises when it comes to calling get_working_directory()\n

tests are written to spot bugs that you know they exist, so that they do not appear again. But tests do not discover bugs. ↩\n

\n\n","tocStructure",[115,116,117,118,119],{"_84":74,"_43":70,"_71":-5,"_75":76,"_73":74,"_94":-5,"_95":-5,"_96":-5},{"_84":74,"_43":80,"_71":-5,"_75":81,"_73":74,"_94":-5,"_95":-5,"_96":-5},{"_84":85,"_43":86,"_71":-5,"_75":87,"_73":74,"_94":-5,"_95":-5,"_96":-5},{"_84":91,"_43":92,"_71":-5,"_75":93,"_73":74,"_94":-5,"_95":-5,"_96":-5},{"_84":91,"_43":98,"_71":-5,"_75":99,"_73":74,"_94":-5,"_95":-5,"_96":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

Table of Contents

Preface

Who is this book for

Prerequisite knowledge

How to read this book

Why this book was written

Acknowledgements:

Step 4: Algorithms should read like pseudocode

How does that compare to a C function ?

Learning the details

Avoid using low-level strings

Problem description

The solution