Table of Contents for
Mastering C++ Programming

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Mastering C++ Programming by Jeganathan Swaminathan Published by Packt Publishing, 2017
  1. Mastering C++ Programming
  2. Title Page
  3. Copyright
  4. Mastering C++ Programming
  5. Credits
  6. About the Author
  7. About the Reviewer
  8. www.PacktPub.com
  9. Why subscribe?
  10. Customer Feedback
  11. Dedication
  12. Table of Contents
  13. Preface
  14. What this book covers
  15. What you need for this book
  16. Who this book is for
  17. Conventions
  18. Reader feedback
  19. Customer support
  20. Downloading the example code
  21. Errata
  22. Piracy
  23. Questions
  24. C++17 Features
  25. C++17 background
  26. What's new in C++17?
  27. What features are deprecated or removed in C++17?
  28. Key features in C++17
  29. Easier nested namespace syntax
  30. New rules for type auto-detection from braced initializer list 
  31. Simplified static_assert 
  32. The std::invoke( ) method
  33. Structured binding
  34. If and Switch local scoped variables
  35. Template type auto-deduction for class templates
  36. Inline variables
  37. Summary
  38. Standard Template Library
  39. The Standard Template Library architecture
  40. Algorithms
  41. Iterators
  42. Containers
  43. Functors
  44. Sequence containers
  45. Array
  46. Code walkthrough
  47. Commonly used APIs in an array
  48. Vector 
  49. Code walkthrough
  50. Commonly used vector APIs
  51. Code walkthrough
  52. Pitfalls of a vector
  53. List 
  54. Commonly used APIs in a list
  55. Forward list
  56. Code walkthrough
  57. Commonly used APIs in a forward_list container
  58. Deque
  59. Commonly used APIs in a deque
  60. Associative containers
  61. Set
  62. Code walkthrough
  63. Commonly used APIs in a set
  64. Map
  65. Code walkthrough
  66. Commonly used APIs in a map
  67. Multiset
  68. Multimap
  69. Unordered sets
  70. Unordered maps
  71. Unordered multisets
  72. Unordered multimaps
  73. Container adapters
  74. Stack
  75. Commonly used APIs in a stack
  76. Queue
  77. Commonly used APIs in a queue
  78. Priority queue
  79. Commonly used APIs in a priority queue
  80. Summary
  81. Template Programming
  82. Generic programming
  83. Function templates
  84. Code walkthrough
  85. Overloading function templates
  86. Code walkthrough
  87. Class template
  88. Code walkthrough
  89. Explicit class specializations
  90. Code walkthrough
  91. Partial template specialization
  92. Summary
  93. Smart Pointers
  94. Memory management
  95. Issues with raw pointers
  96. Smart pointers
  97. auto_ptr
  98. Code walkthrough - Part 1
  99. Code walkthrough - Part 2
  100. unique_ptr
  101. Code walkthrough
  102. shared_ptr
  103. Code walkthrough
  104. weak_ptr
  105. Circular dependency
  106. Summary
  107. Developing GUI Applications in C++
  108. Qt 
  109. Installing Qt 5.7.0 in Ubuntu 16.04
  110. Qt Core
  111. Writing our first Qt console application
  112. Qt Widgets
  113. Writing our first Qt GUI application
  114. Layouts
  115. Writing a GUI application with a horizontal layout
  116. Writing a GUI application with a vertical layout
  117. Writing a GUI application with a box layout
  118. Writing a GUI application with a grid layout
  119. Signals and slots
  120. Using stacked layout in Qt applications
  121. Writing a simple math application combining multiple layouts
  122. Summary
  123. Multithreaded Programming and Inter-Process Communication
  124. Introduction to POSIX pthreads
  125. Creating threads with the pthreads library
  126. How to compile and run
  127. Does C++ support threads natively?
  128. How to write a multithreaded application using the native C++ thread feature
  129. How to compile and run
  130. Using std::thread in an object-oriented fashion
  131. How to compile and run
  132. What did you learn?
  133. Synchronizing threads
  134. What would happen if threads weren't synchronized?
  135. How to compile and run
  136. Let's use mutex
  137. How to compile and run
  138. What is a deadlock?
  139. How to compile and run
  140. What did you learn?
  141. Shared mutex
  142. Conditional variable
  143. How to compile and run
  144. What did you learn?
  145. Semaphore
  146. Concurrency
  147. How to compile and run
  148. Asynchronous message passing using the concurrency support library
  149. How to compile and run
  150. Concurrency tasks
  151. How to compile and run
  152. Using tasks with a thread support library
  153. How to compile and run
  154. Binding the thread procedure and its input to packaged_task 
  155. How to compile and run
  156. Exception handling with the concurrency library
  157. How to compile and run
  158. What did you learn?
  159. Summary
  160. Test-Driven Development
  161. TDD
  162. Common myths and questions around TDD
  163. Does it take more efforts for a developer to write a unit test? 
  164. Is code coverage metrics good or bad?
  165. Does TDD work for complex legacy projects? 
  166. Is TDD even applicable for embedded or products that involve hardware?
  167. Unit testing frameworks for C++
  168. Google test framework
  169. Installing Google test framework on Ubuntu
  170. How to build google test and mock together as one single static library without installing?
  171. Writing our first test case using the Google test framework
  172. Using Google test framework in Visual Studio IDE
  173. TDD in action
  174. Testing a piece of legacy code that has dependency
  175. Summary
  176. Behavior-Driven Development
  177. Behavior-driven development
  178. TDD versus BDD
  179. C++ BDD frameworks
  180. The Gherkin language
  181. Installing cucumber-cpp in Ubuntu
  182. Installing the cucumber-cpp framework prerequisite software
  183. Building and executing the test cases
  184. Feature file
  185. Spoken languages supported by Gherkin
  186. The recommended cucumber-cpp project folder structure
  187. Writing our first Cucumber test case
  188. Integrating our project in cucumber-cpp CMakeLists.txt
  189. Executing our test case
  190. Dry running your cucumber test cases
  191. BDD - a test-first development approach
  192. Let's build and run our BDD test case
  193. It's testing time!
  194. Summary
  195. Debugging Techniques
  196. Effective debugging
  197. Debugging strategies
  198. Debugging tools
  199. Debugging your application using GDB
  200. GDB commands quick reference
  201. Debugging memory leaks with Valgrind
  202. The Memcheck tool
  203. Detecting memory access outside the boundary of an array
  204. Detecting memory access to already released memory locations
  205. Detecting uninitialized memory access
  206. Detecting memory leaks
  207. Fixing the memory leaks
  208. Mismatched use of new and free or malloc and delete
  209. Summary
  210. Code Smells and Clean Code Practices
  211. Code refactoring
  212. Code smell
  213. What is agile?
  214. SOLID design principle
  215. Single responsibility principle
  216. Open closed principle
  217. Liskov substitution principle
  218. Interface segregation
  219. Dependency inversion
  220. Code smell
  221. Comment smell
  222. Long method
  223. Long parameter list
  224. Duplicate code
  225. Conditional complexity
  226. Large class
  227. Dead code
  228. Primitive obsession
  229. Data class
  230. Feature envy
  231. Summary

Writing a simple math application combining multiple layouts

In this section, let's explore how to write a simple math application. As part of this exercise, we will use QLineEdit and QLabel widgets and QFormLayout. We need to design a UI, as shown in the following screenshot:

Figure 5.66

QLabel is a widget typically used for static text, and QLineEdit will allow a user to supply a single line input. As shown in the preceding screenshot, we will use QVBoxLayout as the main layout in order to arrange QFormLayout and QBoxLayout in a vertical fashion. QFormLayout comes in handy when you need to create a form where there will be a caption on the left-hand side followed by some widget on its right. QGridLayout might also do the job, but QFormLayout is easy to use in such scenarios.

In this exercise, we will create three files, namely MyDlg.h, MyDlg.cpp, and main.cpp. Let's start with the MyDlg.h source code and then move on to other files:

Figure 5.67

In the preceding figure, three layouts are declared. The vertical box layout is used as the main layout, while the box layout is used to arrange the buttons in the right-aligned fashion. The form layout is used to add the labels, that is, line edit widgets. This exercise will also help you understand how one can combine multiple layouts to design a professional HMI.

Qt doesn't have any documented restriction in the number of layouts that can be combined in a single window. However, when possible, it is a good idea to consider designing an HMI with a minimal number of layouts if you are striving to develop a small memory footprint application. Otherwise, there is certainly no harm in using multiple layouts in your application.

In the following screenshot, you will get an idea of how the MyDlg.cpp source file shall be implemented. In the MyDlg constructor, all the buttons are instantiated and laid out in the box layout for right alignment. The form layout is used to hold the QLineEdit widgets and their corresponding QLabel widgets in a grid-like fashion. QLineEdit widgets typically help supply a single line input; in this particular exercise, they help us supply a number input that must be added, subtracted, and so on, depending on the user's choice.

Figure 5.68

The best part of our main.cpp source file is that it remains pretty much the same, irrespective of the complexity of our application. In this exercise, I would like to tell you a secret about MyDlg. Did you notice that the MyDlg constructor is instantiated in the stack as opposed to the heap? The idea is that when the main() function exits, the stack used by the main function gets unwinded, eventually freeing up all the stack variables present in the stack. When MyDlg gets freed up, it results in calling the MyDlg destructor. In the Qt Framework, every widget constructor takes an optional parent widget pointer, which is used by the topmost window destructor to free up its child widgets. Interestingly, Qt maintains a tree-like data structure to manage the memory of all its child widgets. So, if all goes well, the Qt Framework will take care of freeing up all its child widgets' memory locations "automagically".

This helps Qt developers focus on the application aspect, while the Qt Framework will take care of memory management.

Figure 5.69

Aren't you excited to check the output of our new application? If you build and execute the application, then you are supposed to get an output similar to the following screenshot. Of course, we are yet to add signal and slot support, but it's a good idea to design the GUI to our satisfaction and then shift our focus to event handling:

Figure 5.70

If you observe closely, though the buttons are laid out on QBoxLayout in the right to left direction, the buttons aren't aligned to the right. The reason for this behavior is when the window is stretched out, the box layout seems to have divided and allocated the extra horizontal space available among all the buttons. So let's go ahead and throw in a stretch item to the leftmost position on the box layout such that the stretch will eat up all the extra spaces, leaving the buttons no room to expand. This will get us the right-aligned effect. After adding the stretch, the code will look as shown in the following screenshot:

Figure 5.71

Go ahead and check whether your output looks as shown in the following screenshot. Sometimes, as developers, we get excited to see the output in a rush and forget to compile our changes, so ensure the project is built again. If you don't see any change in output, no worries; just try to stretch out the window horizontally and you should see the right-aligned effect, as shown in the following screenshot:

Figure 5.72

Now since we have a decent-looking application, let's add signal and slot support to add the response to button clicks. Let's not rush and include the add and subtract functionalities for now. We will use some qDebug() print statements to check whether the signals and slots are connected properly and then gradually replace them with the actual functionalities.

If you remember the earlier signal and slot exercise, any Qt window that is interested in supporting signals and slots must be QObject and should include the Q_OBJECT macro in the MyDlg.h header file, as shown in the following screenshot:

Figure 5.73

In lines starting from 41 through 45, four slot methods are declared in the private section. Slot functions are regular C++ functions that could be invoked directly just like other C++ functions. However, in this scenario, the slot functions are intended to be invoked only with MyDlg. Hence they are declared as private functions, but they could be made public if you believe that others might find it useful to connect to your public slot.

Cool, if you have come this far, it says that you have understood the things discussed so far. Alright, let's go ahead and implement the definitions for the slot functions in MyDlg.cpp and then connect the clicked() button's signals with the respective slot functions:

Figure 5.74

Now it's time to wire up the signals to their respective slots. As you may have guessed, we need to use the connect function in the MyDlg constructor, as shown in the following screenshot, to get the button clicks to the corresponding slots:

Figure 5.75

We are all set. Yes, it's showtime now. As we have taken care of most of the stuff, let's compile and check the output of our little Qt application:

Figure 5.76

Oops! We got some linker error. The root cause of this issue is that we forgot to invoke qmake after enabling signal and slot support in our application. No worries, let's invoke qmake and make and run our application:

Figure 5.77

Great, we have fixed the issue. The make utility doesn't seem to make any noise this time and we are able to launch the application. Let's check whether the signals and slots are working as expected. For this, click on the Add button and see what happens:

Figure 5.78

Wow! When we click on the Add button, the qDebug() console message confirms that the MyDlg::onAddButtonClicked() slot is invoked. If you are curious to check the slots of other buttons, go ahead and try clicking on the rest of the buttons.

Our application will be incomplete without business logic. So let's add business logic to the MyDlg::onAddButtonClicked() slot function to perform the addition and display the result. Once you learn how to integrate the added business logic, you can follow the same approach and implement the rest of the slot functions:

Figure 5.79

In the MyDlg::onAddButtonClicked() function, the business logic is integrated. In lines 82 and 83, we are trying to extract the values typed by the user in the QLineEdit widgets. The text() function in QLineEdit returns QString. The QString object provides toInt() that comes in handy to extract the integer value represented by QString. Once the values are added and stored in the result variable, we need to convert the result integer value back to QString, as shown in line number 86, so that the result can be fed into QLineEdit, as shown in line number 88.

Similarly, you can go ahead and integrate the business logic for other math operations. Once you have thoroughly tested the application, you can remove the qDebug() console's output. We added the qDebug() messages for debugging purposes, hence they can be cleaned up now.