|
| 1 | +# Contributing to fast-alloc |
| 2 | + |
| 3 | +Thank you for your interest in contributing to fast-alloc! This document provides guidelines and information for contributors. |
| 4 | + |
| 5 | +## Code of Conduct |
| 6 | + |
| 7 | +- Be respectful and constructive in all interactions |
| 8 | +- Focus on what is best for the community and the project |
| 9 | +- Show empathy towards other community members |
| 10 | + |
| 11 | +## How to Contribute |
| 12 | + |
| 13 | +### Reporting Bugs |
| 14 | + |
| 15 | +If you find a bug, please create an issue with: |
| 16 | +- A clear, descriptive title |
| 17 | +- Steps to reproduce the issue |
| 18 | +- Expected behavior vs actual behavior |
| 19 | +- Your environment (OS, compiler, version) |
| 20 | +- Minimal code example demonstrating the bug |
| 21 | + |
| 22 | +### Suggesting Enhancements |
| 23 | + |
| 24 | +Enhancement suggestions are welcome! Please include: |
| 25 | +- Clear description of the enhancement |
| 26 | +- Use cases and benefits |
| 27 | +- Potential implementation approach (if you have ideas) |
| 28 | +- Any trade-offs or considerations |
| 29 | + |
| 30 | +### Pull Requests |
| 31 | + |
| 32 | +1. **Fork and Branch**: Fork the repository and create a feature branch |
| 33 | + ```bash |
| 34 | + git checkout -b feature/your-feature-name |
| 35 | + ``` |
| 36 | + |
| 37 | +2. **Code Style**: |
| 38 | + - Follow existing code style and conventions |
| 39 | + - Use C++20 features appropriately |
| 40 | + - Keep functions focused and reasonably sized |
| 41 | + - Add comments for complex algorithms |
| 42 | + - Use descriptive variable names |
| 43 | + |
| 44 | +3. **Testing**: |
| 45 | + - Add tests for new features |
| 46 | + - Ensure all existing tests pass |
| 47 | + - Test on multiple platforms if possible (Windows, Linux, macOS) |
| 48 | + - Run with sanitizers to catch memory issues: |
| 49 | + ```bash |
| 50 | + # Address Sanitizer |
| 51 | + cmake -B build -DCMAKE_BUILD_TYPE=Debug \ |
| 52 | + -DCMAKE_CXX_FLAGS="-fsanitize=address -fno-omit-frame-pointer -g" |
| 53 | + cmake --build build |
| 54 | + ctest --test-dir build --output-on-failure |
| 55 | + |
| 56 | + # Thread Sanitizer (for thread-safe allocators) |
| 57 | + cmake -B build -DCMAKE_BUILD_TYPE=Debug \ |
| 58 | + -DCMAKE_CXX_FLAGS="-fsanitize=thread -g" |
| 59 | + cmake --build build |
| 60 | + TSAN_OPTIONS="second_deadlock_stack=1 suppressions=tsan.supp" \ |
| 61 | + ctest --test-dir build --output-on-failure |
| 62 | + ``` |
| 63 | + |
| 64 | +4. **Documentation**: |
| 65 | + - Update README.md if adding new features |
| 66 | + - Add Doxygen comments for public APIs |
| 67 | + - Update docs/architecture.md for architectural changes |
| 68 | + - Include usage examples for new allocators |
| 69 | + |
| 70 | +5. **Commit Messages**: |
| 71 | + - Use clear, descriptive commit messages |
| 72 | + - Start with a verb in imperative mood (e.g., "Add", "Fix", "Update") |
| 73 | + - Keep the first line under 72 characters |
| 74 | + - Add detailed explanation in the commit body if needed |
| 75 | + |
| 76 | +6. **Pull Request Process**: |
| 77 | + - Ensure CI passes (all tests, sanitizers) |
| 78 | + - Update documentation as needed |
| 79 | + - Reference any related issues |
| 80 | + - Wait for review and address feedback |
| 81 | + |
| 82 | +## Development Setup |
| 83 | + |
| 84 | +### Prerequisites |
| 85 | + |
| 86 | +- C++20 compatible compiler (GCC 10+, Clang 10+, MSVC 2019+) |
| 87 | +- CMake 3.14 or higher |
| 88 | +- Git |
| 89 | + |
| 90 | +### Building |
| 91 | + |
| 92 | +```bash |
| 93 | +# Configure |
| 94 | +cmake -B build -DCMAKE_BUILD_TYPE=Release |
| 95 | +
|
| 96 | +# Build |
| 97 | +cmake --build build --config Release |
| 98 | +
|
| 99 | +# Run tests |
| 100 | +ctest --test-dir build --output-on-failure |
| 101 | +
|
| 102 | +# Run benchmarks |
| 103 | +./build/alloc_benchmarks |
| 104 | +``` |
| 105 | + |
| 106 | +### Project Structure |
| 107 | + |
| 108 | +``` |
| 109 | +fast-alloc/ |
| 110 | +├── src/ # Source code |
| 111 | +│ ├── *_allocator.h/cpp # Allocator implementations |
| 112 | +├── tests/ # Unit tests (Catch2) |
| 113 | +├── benchmarks/ # Performance benchmarks (Google Benchmark) |
| 114 | +├── docs/ # Documentation |
| 115 | +└── .github/workflows/ # CI configuration |
| 116 | +``` |
| 117 | + |
| 118 | +## Code Guidelines |
| 119 | + |
| 120 | +### Memory Safety |
| 121 | + |
| 122 | +- Always validate pointers in debug builds using assertions |
| 123 | +- Use RAII for resource management |
| 124 | +- Avoid raw pointer arithmetic where alternatives exist |
| 125 | +- Test with sanitizers (ASan, TSan, UBSan) |
| 126 | + |
| 127 | +### Performance |
| 128 | + |
| 129 | +- Profile before optimizing |
| 130 | +- Benchmark any performance-related changes |
| 131 | +- Document performance characteristics |
| 132 | +- Consider cache locality and alignment |
| 133 | + |
| 134 | +### Assertions |
| 135 | + |
| 136 | +Use assertions for preconditions that should never fail in correct usage: |
| 137 | +```cpp |
| 138 | +assert(size > 0 && "Size must be positive"); |
| 139 | +assert(memory_ && "Allocator not initialized"); |
| 140 | +``` |
| 141 | + |
| 142 | +### Thread Safety |
| 143 | + |
| 144 | +- Document thread-safety guarantees in headers |
| 145 | +- Use appropriate synchronization primitives |
| 146 | +- Test concurrent operations under ThreadSanitizer |
| 147 | +- Consider lock-free alternatives for hot paths |
| 148 | + |
| 149 | +## Testing Guidelines |
| 150 | + |
| 151 | +### Unit Tests |
| 152 | + |
| 153 | +- Test one thing per test case |
| 154 | +- Use descriptive test names |
| 155 | +- Cover edge cases (nullptr, zero size, exhaustion) |
| 156 | +- Test move semantics for movable types |
| 157 | +- Verify alignment requirements |
| 158 | + |
| 159 | +### Benchmark Tests |
| 160 | + |
| 161 | +- Compare against standard allocation (malloc/new) |
| 162 | +- Test realistic usage patterns |
| 163 | +- Run multiple iterations to reduce variance |
| 164 | +- Document platform and compiler used |
| 165 | + |
| 166 | +## Release Process |
| 167 | + |
| 168 | +Maintainers will: |
| 169 | +1. Review and merge pull requests |
| 170 | +2. Update version numbers |
| 171 | +3. Create release notes |
| 172 | +4. Tag releases |
| 173 | + |
| 174 | +## Questions? |
| 175 | + |
| 176 | +Feel free to: |
| 177 | +- Open an issue for questions |
| 178 | +- Start a discussion for general topics |
| 179 | +- Contact the maintainer directly |
| 180 | + |
| 181 | +## License |
| 182 | + |
| 183 | +By contributing, you agree that your contributions will be licensed under the MIT License. |
0 commit comments