Debugging
1. Debugging
Hey i am giving you a very cool piece of code which will be very much helpful in debugging.
Let me give you an example:
The output of the function
So what this following piece of code does is that it takes your variable and then by writing (#x)
it converts the name of the variable into a string and then obviously the variable x holds the value of x so the second half of the code <<x<<
will print the value of x;
I think you should try to run the code once and then you will understand the working of the code.
2. Commenting
In his book Clean Code, advocates using comments for the following purposes: 1.Explanation of Intent 2.Clarification 3.Warnings 4.Amplification 5.ToDo At a minimum, comments should describe what each public member does and how to use it, and explain all parameters and return values with acceptable ranges (e.g. between 1 and 1000) for each.
3. References to a Live Project
4. Awesome Resources on Web
Here are some awesome resources I like to go through as additional material for C++ OOP:
Here are a few additional resources you can look at it for more information on Object Oriented Programming:
You may also find the following reading material helpful:
5. Some Linux Exclusive Resources
Go Further
These resources can help you step up your game:
Tools for C++:
Go deeper into the Project:
CMake and Make
In the beginning, it is usually not very clear what those build systems or build system generators are and how they can be beneficial to us. I would like to share with you some resources to help with this.
Please note that CMake isn't a build system, it's a build system generator. This is why we need to invoke make after running cmake. Running cmake generates Makefiles with the appropriate platform dependencies, and running make actually uses them.
However we don't need to write Make files, as CMake does this for us, it is good to understand about build systems.
When you write a program, the compiler will check to ensure that you have followed the rules of the language in which you have written code. If you have done something that definitively violates the rules of the language, during compilation the compiler will emit an error, providing both line number containing the error, and some text about what was expected vs what was found. The actual error may be on that line, or on a preceding line. Once you’ve identified and fixed the erroneous line(s) of code, you can try compiling again.
In other cases, the compiler may find code that seems like it might be in error, but the compiler can’t be sure (remember the motto: “trust the programmer”). In such cases, the compiler may opt to issue a warning. Warnings do not halt compilation but are notices to the programmer that something seems amiss.
In most cases, warnings can be resolved either by fixing the error the warning is pointing out or by rewriting the line of code generating the warning in such a way that the warning is no longer generated.
In rare cases, it may be necessary to explicitly tell the compiler to not generate a particular warning for the line of code in question. C++ does not support an official way to do this, but many individual compilers (including Visual Studio and GCC) offer solutions (via non-portable #pragma directives) to temporarily disable warnings.
Some of the best practices about compiler warnings :
Don’t let warnings pile up. Resolve them as you encounter them (as if they were errors).
Turn your warning levels up to the maximum, especially while you are learning. It will help you identify possible issues.
It is also possible to tell your compiler to treat all warnings as if they were errors (in which case, the compiler will halt compilation if it finds any warnings). This is a good way to enforce the recommendation that you should fix all warnings (if you lack self-discipline, which most of us do).
For More Visit these links
Relationships among classes in object-oriented programming
GDB
Last updated