FiberTaskingLib Documentation

Commit messages must follow the Conventional Commits format to enable automatic semantic-versioning and changelog generation.

Commit Structure:

1. Summary Line: <type>[optional scope]: Summarize changes in around 50 characters or less
2. Blank Line: A blank line separating the summary from the body is critical.
3. Body: Explain the why (the problem being solved) rather than the how. Mention side effects or unintuitive consequences.
4. References: If using an issue tracker, place references at the bottom.

Example Format:

<type>[optional scope]: Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. In some contexts, 
the first line is treated as the subject of the commit and the rest of
the text as the body. The blank line separating the summary from the body 
is critical (unless you omit the body entirely); various tools like `log`,
`shortlog` and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you 
are making this change as opposed to how (the code explains that). 
Are there side effects or other unintuitive consequences of this 
change? Here's the place to explain them.

Further paragraphs come after blank lines.

* Bullet points are okay, too

* Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom, like this:

Resolves: #123
See also: #456, #789

Classes and structs should follow a specific layout order:

1. Public Constructors
2. Public Member Variables
3. Private Member Variables
4. Public Methods
5. Private Methods

Constructor Initializer Lists

Initializer lists must start on a new line from the constructor definition, with each entry on its own line and aligned using spaces. The entire list should be indented once if the constructor has no body, or twice if it does.

class Fiber {
public:
    Fiber()
        : m_stack(nullptr),
          m_systemPageSize(0),
          m_stackSize(0),
          m_context(nullptr),
          m_arg(0) {
    }
};

class ExampleClass {
public:
    // Constructors
    ExampleClass();
    ExampleClass(ExampleClass &&other);

public:
    // Public member variables
    int Width;
    int Height;

private:
    // Private member variables
    float m_deltaTime;

public:
    // Public methods
    void Rotate();

private:
    // Private methods
    int DecrementHeight(float amount);
};

Braces

Always use braces for if, for, while, and do-while statements, even for single-line bodies. Braceless statements are highly discouraged.

Whitespace Rules

• Operators: Surround conventional operators with spaces: a = (b + c) * d;.
• Reserved Words: Separate C++ reserved words from opening parentheses: while (true) {.
• Commas: Follow commas with a space: SomeFunction(a, b, c);.
• For Statements: Follow semicolons with a space: for (int a = 0; b < c; d++).
• Colons: Surround colons with whitespace in class inheritance and ternary operators: class BusWheel : public RubberInflatable or (isNight) ? ColorMeDark() : ColorMeBright();.
• Pointers and References: Use a space before the * or & but not after it: const char *ptr = (const char *)foobar; or int &ref = i;.
• Templates: No whitespace between the template keyword and <. Place the definition on the line preceding the class/function.
• Array Delete: No whitespace before []: delete[] foo;.
• Operator Overloading: Do not separate the operator keyword from the name, except for type conversion operators.

Indentation

• Namespaces: Do not increase indentation level after a namespace clause.
• Access Levels: Do not increase indentation level for access keywords (public:, private:) inside classes.
• Preprocessor: Preprocessor statements should be at the same indentation level as the surrounding code, but the content of the preprocessor block should be indented.
• Switch/Case: Align case keywords with the switch keyword. Indent the contents of the case blocks.

The recommended way to consume FiberTaskingLib is to include its source directory directly using CMake's add_subdirectory() command. Because FiberTaskingLib is a modern CMake project using target_* functions, linking to the ftl target automatically handles include directories and dependencies.

Configuration Options

You can control the build scope using these cache variables:

• FTL_BUILD_TESTS: Set to ON (default) to build tests, or OFF to skip them.
• FTL_BUILD_BENCHMARKS: Set to ON to build benchmarks, or OFF to skip them.

Note: The provided example contains a typo in the source where FTL_BUILD_TESTS is used twice instead of FTL_BUILD_BENCHMARKS for the second option; ensure you use the correct variable name in your project.

cmake_minimum_required(VERSION 3.8)
project(MyProject)

# Disable tests and benchmarks to speed up build
set( FTL_BUILD_TESTS OFF CACHE BOOL "Disable tests" )
set( FTL_BUILD_BENCHMARKS OFF CACHE BOOL "Disable benchmarks" )

# Add FiberTaskingLib source
add_subdirectory(third_party/FiberTaskingLib)

# Create your executable
add_executable(MyProject source/main.cpp)
target_include_directories(MyProject PRIVATE include)

# Link to FiberTaskingLib (automatically handles includes)
target_link_libraries(MyProject ftl)