vist, any, union, xor updated

Author: behnamasadi

CMakeLists.txt

@@ -293,6 +293,11 @@ add_executable(core_dump src/core_dump.cpp)
 
 #add_executable(packaged_task src/packaged_task.cpp)
 
+add_executable(std_visit src/std_visit.cpp)
+
+add_executable(error_code src/error_code.cpp)
+
+
 if(${CMAKE_GNU_COMPILER_ID} ${CMAKE_CXX_COMPILER_VERSION} GREATER_EQUAL 13)
     add_executable(printing_with_format src/printing_with_format.cpp)
 endif()

README.md

@@ -223,7 +223,8 @@ This change ensures that VSCode uses the "Ninja Multi-Config" generator by defau
    * [Typedef, Type alias (using keyword)](docs/typedef.md)
    * [type_dispatch, integral_constant, true/false type](src/type_dispatch_integral_constant_true_false_type.cpp)    
    * [Unions](docs/union.md)  
-   * [Variant](docs/std_variant.md)     
+   * [Variant](docs/std_variant.md)  
+   * [Visit](docs/std_visit.md)  
    * [Variadic Templates Function](docs/variadic_templates.md)  
    * [Volatile Keyword](docs/volatile.md)  
 - [C++ Classes](#)

docs/any.md

@@ -97,3 +97,83 @@ This method is useful when you want to write code that depends on whether a type
 
 ### 3. Attempt Compilation
 As a quick-and-dirty method, you can write a small piece of code that attempts to copy an instance of the class. If the code fails to compile, it's likely that the class is not `CopyConstructible`. However, this method is less precise and should be used cautiously.
+
+## std::any vs templates
+
+In C++, both `std::any` and templates serve different purposes and have different use cases. Understanding the differences and when to use each is important for effective C++ programming.
+
+### **1. `std::any`:**
+
+- **Type Erasure:** `std::any` is a type-erased container that can hold an instance of any type. This means that the type of the object stored in `std::any` is not known at compile time, only at runtime. It can store any type, but type information is erased, and you need to know the type to retrieve the stored object.
+
+- **Runtime Polymorphism:** Since `std::any` works with any type, it provides a form of runtime polymorphism. You can store different types in the same container or pass around different types using `std::any`.
+
+- **Performance:** Using `std::any` incurs runtime overhead. This includes type checks, storage management, and potential dynamic memory allocations. This makes it less efficient compared to templates, which are resolved at compile time.
+
+- **Usage Example:**
+
+    ```cpp
+    #include <any>
+    #include <iostream>
+
+    int main() {
+        std::any value = 10;  // Storing an int
+        value = std::string("Hello");  // Storing a string
+        
+        try {
+            std::cout << std::any_cast<std::string>(value) << std::endl;
+        } catch (const std::bad_any_cast& e) {
+            std::cout << "Bad cast: " << e.what() << std::endl;
+        }
+        
+        return 0;
+    }
+    ```
+
+- **Use Case:** `std::any` is useful when you need to store or pass around objects of different types without knowing the type in advance or when working with APIs that require handling various types generically.
+
+### **2. Templates:**
+
+- **Compile-Time Polymorphism:** Templates provide compile-time polymorphism, meaning the code is generated at compile time based on the types provided. This allows for type-safe and efficient code generation.
+
+- **Type Safety:** Templates are type-safe, as the types are known at compile time. This allows the compiler to catch type errors before the program runs.
+
+- **Performance:** Templates are generally more performant than `std::any` because the compiler generates specialized code for each type, eliminating the need for runtime type checks and dynamic allocations.
+
+- **Usage Example:**
+
+    ```cpp
+    #include <iostream>
+
+    template<typename T>
+    void print(T value) {
+        std::cout << value << std::endl;
+    }
+
+    int main() {
+        print(10);          // Prints an integer
+        print("Hello");     // Prints a string literal
+        print(3.14);        // Prints a double
+
+        return 0;
+    }
+    ```
+
+- **Use Case:** Templates are ideal when you want to write generic and efficient code that works with different types but where the types are known at compile time.
+
+### **Comparison Summary:**
+
+| Feature         | `std::any`                          | Templates                        |
+|-----------------|-------------------------------------|----------------------------------|
+| Type Handling   | Runtime type erasure                | Compile-time type resolution     |
+| Type Safety     | Type safety only at runtime         | Type safety at compile-time      |
+| Performance     | Slower, with potential overhead     | Generally faster, optimized code |
+| Flexibility     | Can hold any type, very flexible    | Generic, but types must be known at compile time |
+| Usage Scenario  | Heterogeneous type containers, APIs | Generic programming, containers, algorithms |
+
+### **When to Use Which:**
+- **Use `std::any`** when you need to store or pass around objects of unknown types at runtime and are willing to accept the associated performance costs.
+  
+- **Use templates** when you need to write type-safe, efficient, and generic code where types are known at compile time.
+
+Choosing between `std::any` and templates depends on whether you need runtime flexibility (`std::any`) or compile-time efficiency and type safety (templates).

docs/bitset_bit_field_bitwise_operations.md

@@ -168,5 +168,33 @@ std::cout <<result<<std::endl;
 std::cout <<(a >>= 2) <<std::endl;
 ```
 
+
+### std::bit_xor
+The `std::bit_xor` function in C++20 offers several advantages over the traditional `^` operator:
+
+**1. Generic Type Support:**
+
+- `std::bit_xor` can operate on a wider range of integer types, including custom integral types.
+- This provides more flexibility and type safety in your code.
+
+**2. Potential Performance Improvements:**
+
+- While the performance difference between `std::bit_xor` and `^` might not be significant in most cases, the `std::bit_xor` implementation could potentially benefit from compiler optimizations or hardware-specific instructions.
+
+**3. Consistency with Other Bitwise Operations:**
+
+- `std::bit_xor` is part of the `std::bit` namespace, which also includes other bitwise operations like `std::bit_and`, `std::bit_or`, `std::bit_not`, and `std::bit_count`.
+- Using these functions consistently can improve code readability and maintainability.
+
+**4. Future Enhancements:**
+
+- As the C++ standard evolves, `std::bit_xor` might gain additional features or optimizations in the future.
+
+**In summary:**
+
+While the `^` operator is generally sufficient for most XOR operations, `std::bit_xor` provides a more generic, type-safe, and potentially performant alternative. If you need to work with custom integer types or prefer a more consistent approach for bitwise operations, `std::bit_xor` is a good choice. However, in most cases, the performance difference between the two methods will be negligible.
+
+
+
 Refs: [1](https://www.geeksforgeeks.org/bitwise-algorithms/)
 

docs/error_code.md

@@ -0,0 +1,114 @@
+## std::error_code
+`std::error_code` in C++ is a part of the `<system_error>` header and represents an error condition in a program, typically used to report and handle error situations in a more flexible and extendable way compared to traditional methods like using integer error codes or exceptions.
+- It combines error codes with an error category, making it possible to understand and manage errors across different domains and libraries.
+- It is particularly useful in performance-critical code or when working in environments where exceptions are not suitable.
+
+### Key Concepts:
+
+1. **Error Code and Error Category**:
+   - `std::error_code` consists of two parts: an error value (an integer) and an error category (`std::error_category`).
+   - The error value represents the specific error.
+   - The error category represents the domain or context in which the error value is meaningful, such as system errors, application-specific errors, etc.
+
+2. **Error Handling**:
+   - `std::error_code` provides a way to handle errors without throwing exceptions. This is particularly useful in contexts where exceptions are either not allowed or not preferred, such as in real-time systems or performance-critical code.
+
+3. **Comparison**:
+   - You can compare `std::error_code` objects directly to check if two error codes represent the same error.
+
+4. **Conversion to `std::error_condition`**:
+   - `std::error_code` can be converted to a more generic `std::error_condition`, which represents a portable error condition, independent of the platform-specific error codes.
+
+### Example:
+
+Let's walk through an example to understand how `std::error_code` can be used in practice.
+
+#### Example 1: Basic Usage
+
+```cpp
+#include <iostream>
+#include <system_error>
+#include <fstream>
+
+void open_file(const std::string& filename, std::error_code& ec) {
+    std::ifstream file(filename);
+    if (!file) {
+        ec = std::make_error_code(std::errc::no_such_file_or_directory);
+        return;
+    }
+    // Process file...
+    ec.clear();  // No error
+}
+
+int main() {
+    std::error_code ec;
+    open_file("non_existent_file.txt", ec);
+    
+    if (ec) {
+        std::cout << "Error opening file: " << ec.message() << " (Error code: " << ec.value() << ")\n";
+    } else {
+        std::cout << "File opened successfully.\n";
+    }
+
+    return 0;
+}
+```
+
+#### Explanation:
+
+1. **`std::errc::no_such_file_or_directory`**:
+   - This is an enumerator from the `std::errc` enumeration, which contains platform-independent error codes.
+
+2. **`std::make_error_code`**:
+   - This function converts the `std::errc` value to a `std::error_code`.
+
+3. **Error Message**:
+   - `ec.message()` returns a human-readable error message corresponding to the error code.
+   - `ec.value()` returns the actual error value.
+
+In this example, if the file `"non_existent_file.txt"` does not exist, the function `open_file` sets the `std::error_code` to indicate that the file was not found, and the error is reported in `main`.
+
+#### Example 2: Using `std::system_category`
+
+`std::system_category()` represents the operating system's error codes, allowing you to work directly with native error codes.
+
+```cpp
+#include <iostream>
+#include <system_error>
+#include <cerrno>
+#include <cstdio>
+
+void delete_file(const std::string& filename, std::error_code& ec) {
+    if (std::remove(filename.c_str()) != 0) {
+        ec = std::error_code(errno, std::system_category());
+    } else {
+        ec.clear();  // No error
+    }
+}
+
+int main() {
+    std::error_code ec;
+    delete_file("non_existent_file.txt", ec);
+    
+    if (ec) {
+        std::cout << "Error deleting file: " << ec.message() << " (Error code: " << ec.value() << ")\n";
+    } else {
+        std::cout << "File deleted successfully.\n";
+    }
+
+    return 0;
+}
+```
+
+#### Explanation:
+
+1. **`errno`**:
+   - This global variable is set by certain system calls and library functions in the C standard library when an error occurs.
+
+2. **`std::system_category()`**:
+   - It is used here to associate the error code with the system's error category.
+
+In this example, if the file `"non_existent_file.txt"` does not exist, `std::remove` sets `errno` to `ENOENT`, and we set the `std::error_code` accordingly. This code is then used to report the error.
+
+
+[code](../src/error_code.cpp)

docs/std_visit.md

@@ -0,0 +1,109 @@
+## std::visit
+
+`std::visit` is a powerful utility in C++ that is primarily used to work with `std::variant`, a type-safe union introduced in C++17. A `std::variant` can hold a value from a set of specified types, but only one at a time. The challenge with `std::variant` is accessing the value it holds safely, without resorting to unsafe type casts or multiple `std::get` calls. This is where `std::visit` comes into play.
+
+### Why Do We Need `std::visit`?
+
+`std::variant` encapsulates multiple types, and to handle the value it holds, we need a way to determine its current type and execute the corresponding logic. Using `std::visit`, we can apply a visitor (a callable object like a lambda, function, or functor) to the currently held value in the `std::variant`. This provides a clean, type-safe way to access the variant's value without manually checking the active type.
+
+Without `std::visit`, we'd have to manually inspect the `std::variant`'s active type using `std::holds_alternative<T>()` or by trying multiple `std::get<T>()` calls, which can lead to code that's difficult to maintain and prone to errors.
+
+### What Does `std::visit` Do?
+
+`std::visit` applies a callable (often referred to as a visitor) to the value stored in a `std::variant`. The key benefit is that the visitor is automatically invoked with the correct type, eliminating the need for explicit type checking and handling.
+
+**Key points about `std::visit`:**
+- It ensures that the visitor is called with the correct type from the `std::variant`.
+- The visitor can be a lambda function, a regular function, or a functor.
+- If the `std::variant` can hold multiple types, `std::visit` allows you to handle each type case in a unified, readable manner.
+- It can be used with multiple `std::variant` arguments simultaneously, where the visitor will handle combinations of the types.
+
+### Syntax of `std::visit`
+
+The basic syntax is as follows:
+
+```cpp
+#include <variant>
+#include <iostream>
+
+std::variant<int, float, std::string> myVariant = 42;
+
+auto visitor = [](auto&& arg) {
+    std::cout << arg << std::endl;
+};
+
+std::visit(visitor, myVariant);
+```
+
+Here's a breakdown of the syntax:
+- `std::visit(visitor, variant)` is how you call `std::visit`.
+- `visitor` is the callable object that you want to apply to the variant's currently held value.
+- `variant` is the `std::variant` you want to inspect.
+
+### Example: Using `std::visit`
+
+Let's look at a more detailed example:
+
+```cpp
+#include <iostream>
+#include <variant>
+#include <string>
+
+int main() {
+    std::variant<int, float, std::string> myVariant = 10;
+
+    auto visitor = [](auto&& arg) {
+        using T = std::decay_t<decltype(arg)>;  // Get the type of the argument
+        if constexpr (std::is_same_v<T, int>)
+            std::cout << "It's an int: " << arg << std::endl;
+        else if constexpr (std::is_same_v<T, float>)
+            std::cout << "It's a float: " << arg << std::endl;
+        else if constexpr (std::is_same_v<T, std::string>)
+            std::cout << "It's a string: " << arg << std::endl;
+    };
+
+    std::visit(visitor, myVariant);  // Output: It's an int: 10
+
+    myVariant = "Hello";
+    std::visit(visitor, myVariant);  // Output: It's a string: Hello
+
+    myVariant = 3.14f;
+    std::visit(visitor, myVariant);  // Output: It's a float: 3.14
+
+    return 0;
+}
+```
+
+### Explanation:
+- **Variant Initialization**: `myVariant` is a `std::variant` that can hold an `int`, `float`, or `std::string`.
+- **Visitor**: The visitor is a lambda function that checks the type of the argument using `if constexpr` and `std::is_same_v`, and prints out a message based on the type.
+- **`std::visit` Call**: `std::visit` applies the visitor to the current value of `myVariant`. Depending on what type is stored in `myVariant`, the corresponding branch of the lambda is executed.
+
+### What `std::visit` Does That Can't Be Done Easily Without It
+
+Without `std::visit`, you would have to manually manage type handling in `std::variant`, which can lead to verbose and error-prone code. For example:
+
+```cpp
+#include <variant>
+#include <iostream>
+#include <string>
+
+int main() {
+    std::variant<int, float, std::string> myVariant = 42;
+
+    if (std::holds_alternative<int>(myVariant)) {
+        std::cout << "It's an int: " << std::get<int>(myVariant) << std::endl;
+    } else if (std::holds_alternative<float>(myVariant)) {
+        std::cout << "It's a float: " << std::get<float>(myVariant) << std::endl;
+    } else if (std::holds_alternative<std::string>(myVariant)) {
+        std::cout << "It's a string: " << std::get<std::string>(myVariant) << std::endl;
+    }
+
+    return 0;
+}
+```
+
+This approach requires separate type checks (`std::holds_alternative<T>`) and then fetching the value (`std::get<T>`), making the code less elegant and harder to extend or maintain.
+
+[code](../src/std_visit.cpp)
+