Bitmasks - use when you want to save some space when using variables
Can use a field of bits to pass many arguments to a function without the need for a struct
Can also save parameter space, imagine a function which has to take 20 different booleans, you'd have to pass many true/false declarations
Instead just take a single int and then call the function with the options enabled
Can return something like status&aliveFlag - when using &, both things must be true
Vector creates a container of bits - it is not standard (sometimes causes issues)
for (auto& v : bools) is an easy way to iterate through a vector, checking if true
std::bitset<sizeOfBitset> bitsetName (hex value for which bit you want enabled)
can use .set, .flip, .reset with a bitset
Custom allocators
Deleting an already deleted object breaks the program, so making a custom deleter can be a good way to circumvent that problem
Customised new and delete functions, if done properly, will almost always be as fast as or faster than the default new and delete functions
Can lead to a significant speed up!!!!!
Compiler automatically adds padding to the size of variables (bit size) to make sure that each new variable starts on an even number in its memory location
To summarise, bitmasks are good to save space and make code more legible. Custom made functions and such to overwrite stock compiler ones are usually not worth the effort especially for amateur programmers. Automatic padding can be helpful but when it isn't, it can be manipulated
Tuesday, 15 March 2016
8th March
Exceptions
Exceptions allow you to react to strange behaviour
Throw - throws an exception when a problem shows up
Catch - catches an exception with a handler where you want
Try - helps you identify the code that is wrong and tries something
Ellipsis catch (...) is default handler, like a switch statement default
Try blocks can be nested (try in try in try...) and throwing can pass a try back up
We can use try/catch to stop division by zero so that our program doesn't break (only if we try to catch though)
Look for exception, throw error, handle it.
c++ has many exceptions like bad_alloc built in
But you need to include <exception> to catch them, and you have to use try
We can make our own exceptions by overriding (eg use struct)
When to use - empty disk drive, etc: external issues that we cannot control, so we can send an error message
There is a cost, sometimes dramatic, for using exceptions so use them sparingly
Also don't use for code that has to run as fast as possible
There is a no cost method, a table that maps out where in your code an exception might be required so that it only runs when it is needed, and thus only slows the program using memory when needed (which is unlikely as it is usually a failsafe)
Exception-safe code is where even if an exception is made, it won't affect the program at all
Basic guarantee leaves code valid, strong guarantee guarantees the code will be the same
Assertions
Allows you to abort program if something is true
Simply, assertion is to make sure of something, if that thing is false then stop immediately
Program will terminate with no cleanup, may create a dump
If a bug is unable to be found you can assert if you know what is wrong, break into when the bug is after time
Final release versions of program will usually have asserts cut out via the compiler to allow for a smaller executable
Both happen during runtime, exceptions are for outside of your control issues, assertions are for inside.
Exceptions allow you to react to strange behaviour
Throw - throws an exception when a problem shows up
Catch - catches an exception with a handler where you want
Try - helps you identify the code that is wrong and tries something
Ellipsis catch (...) is default handler, like a switch statement default
Try blocks can be nested (try in try in try...) and throwing can pass a try back up
We can use try/catch to stop division by zero so that our program doesn't break (only if we try to catch though)
Look for exception, throw error, handle it.
c++ has many exceptions like bad_alloc built in
But you need to include <exception> to catch them, and you have to use try
We can make our own exceptions by overriding (eg use struct)
When to use - empty disk drive, etc: external issues that we cannot control, so we can send an error message
There is a cost, sometimes dramatic, for using exceptions so use them sparingly
Also don't use for code that has to run as fast as possible
There is a no cost method, a table that maps out where in your code an exception might be required so that it only runs when it is needed, and thus only slows the program using memory when needed (which is unlikely as it is usually a failsafe)
Exception-safe code is where even if an exception is made, it won't affect the program at all
Basic guarantee leaves code valid, strong guarantee guarantees the code will be the same
Assertions
Allows you to abort program if something is true
Simply, assertion is to make sure of something, if that thing is false then stop immediately
Program will terminate with no cleanup, may create a dump
If a bug is unable to be found you can assert if you know what is wrong, break into when the bug is after time
Final release versions of program will usually have asserts cut out via the compiler to allow for a smaller executable
Both happen during runtime, exceptions are for outside of your control issues, assertions are for inside.
Sunday, 6 March 2016
29th Feb
A crash dump works similar to a normal debugging does. It has break points, but once it is paused, it cannot be resumed - it is simply a dump, a frozen instance of the program's current state (rather, the state it was in when the dump happened).
Depending on the type of the dump, symbol files may be required. There are modules in Visual Studio that can load symbol files, so symbol files are readily compatible with Visual Studio.
Symbols are like placeholders (or mappings) of variable names and function names, linked to their memory address. Symbols are used during the linking part of compilation, so when a symbol problem occurs, the program should still compile and build... This might end up being harder to spot and fix for someone unfamiliar with symbols.
Symbols are placed in a table. This table is found within an Object file (.obj) within the current project.
PDB files (program database files) are linked to and only compatible with the version of Visual Studio that they were built against. They are a collection of symbol information which is stored to save time later.
PDB files are created whenever you build a solution, created by the compiler. These files allow for incremental updates.
These are both very useful debugging tools if used properly.
Depending on the type of the dump, symbol files may be required. There are modules in Visual Studio that can load symbol files, so symbol files are readily compatible with Visual Studio.
Symbols are like placeholders (or mappings) of variable names and function names, linked to their memory address. Symbols are used during the linking part of compilation, so when a symbol problem occurs, the program should still compile and build... This might end up being harder to spot and fix for someone unfamiliar with symbols.
Symbols are placed in a table. This table is found within an Object file (.obj) within the current project.
PDB files (program database files) are linked to and only compatible with the version of Visual Studio that they were built against. They are a collection of symbol information which is stored to save time later.
PDB files are created whenever you build a solution, created by the compiler. These files allow for incremental updates.
These are both very useful debugging tools if used properly.
Subscribe to:
Posts (Atom)