Multi Type Vector

Quick start

The following code demonstrates a simple use case of storing values of double and std::string types in a single container using multi_type_vector.

#include <mdds/multi_type_vector.hpp>
#include <mdds/multi_type_vector/trait.hpp>
#include <iostream>
#include <vector>
#include <string>

using std::cout;
using std::endl;

using mtv_type = mdds::multi_type_vector<mdds::mtv::element_block_func>;

template<typename _Blk>
void print_block(const mtv_type::value_type& v)
{
    // Each element block has static begin() and end() methods that return
    // begin and end iterators, respectively, from the passed element block
    // instance.
    auto it = _Blk::begin(*v.data);
    auto it_end = _Blk::end(*v.data);

    std::for_each(it, it_end,
        [](const typename _Blk::value_type& elem)
        {
            cout << " * " << elem << endl;
        }
    );
}

int main() try
{
    mtv_type con(20); // Initialized with 20 empty elements.

    // Set values individually.
    con.set(0, 1.1);
    con.set(1, 1.2);
    con.set(2, 1.3);

    // Set a sequence of values in one step.
    std::vector<double> vals = { 10.1, 10.2, 10.3, 10.4, 10.5 };
    con.set(3, vals.begin(), vals.end());

    // Set string values.
    con.set(10, std::string("Andy"));
    con.set(11, std::string("Bruce"));
    con.set(12, std::string("Charlie"));

    // Iterate through all blocks and print all elements.
    for (const mtv_type::value_type& v : con)
    {
        switch (v.type)
        {
            case mdds::mtv::element_type_double:
            {
                cout << "numeric block of size " << v.size << endl;
                print_block<mdds::mtv::double_element_block>(v);
                break;
            }
            case mdds::mtv::element_type_string:
            {
                cout << "string block of size " << v.size << endl;
                print_block<mdds::mtv::string_element_block>(v);
                break;
            }
            case mdds::mtv::element_type_empty:
                cout << "empty block of size " << v.size << endl;
                cout << " - no data - " << endl;
            default:
                ;
        }
    }

    return EXIT_SUCCESS;
}
catch (...)
{
    return EXIT_FAILURE;
}

You’ll see the following console output when you compile and execute this code:

numeric block of size 8
 * 1.1
 * 1.2
 * 1.3
 * 10.1
 * 10.2
 * 10.3
 * 10.4
 * 10.5
empty block of size 2
 - no data -
string block of size 3
 * Andy
 * Bruce
 * Charlie
empty block of size 7
 - no data -
_images/mtv_block_structure.png

Logical structure between the primary array, blocks, and element blocks.

Each multi_type_vector instance maintains a logical storage structure of one primary array containing one or more blocks each of which consists of type, position, size and data members:

  • type - numeric value representing the block type.

  • position - numeridc value representing the logical position of the first element of the block.

  • size - number of elements present in the block a.k.a its logical size.

  • data - pointer to the secondary storage (element block) storing the element values.

In this example code, the type member is referenced to determine its block type and its logical size is determined from the size member. For the numeric and string blocks, their data members, which should point to the memory addresses of their respective element blocks, are dereferenced in order to print out their element values to stdout inside the print_block function.

Use custom event handlers

It is also possible to define custom event handlers that get called when certain events take place. To define custom event handlers, you need to define either a class or a struct that has the following methods:

  • void element_block_acquired(mdds::mtv::base_element_block* block)

  • void element_block_released(mdds::mtv::base_element_block* block)

as its public methods, specify it as type named event_func in a trait struct, and pass it as the second template argument when instantiating your multi_type_vector type. Refer to mdds::mtv::empty_event_func for the detail on when each event handler method gets triggered.

The following code example demonstrates how this all works:

#include <mdds/multi_type_vector.hpp>
#include <mdds/multi_type_vector/trait.hpp>
#include <iostream>

using std::cout;
using std::endl;

class event_hdl
{
public:
    void element_block_acquired(mdds::mtv::base_element_block* block)
    {
        (void)block;
        cout << "  * element block acquired" << endl;
    }

    void element_block_released(mdds::mtv::base_element_block* block)
    {
        (void)block;
        cout << "  * element block released" << endl;
    }
};

struct trait
{
    using event_func = event_hdl;

    constexpr static mdds::mtv::lu_factor_t loop_unrolling = mdds::mtv::lu_factor_t::none;
};

using mtv_type = mdds::multi_type_vector<mdds::mtv::element_block_func, trait>;

int main() try
{
    mtv_type db;  // starts with an empty container.

    cout << "inserting string 'foo'..." << endl;
    db.push_back(std::string("foo"));  // creates a new string element block.

    cout << "inserting string 'bah'..." << endl;
    db.push_back(std::string("bah"));  // appends to an existing string block.

    cout << "inserting int 100..." << endl;
    db.push_back(int(100)); // creates a new int element block.

    cout << "emptying the container..." << endl;
    db.clear(); // releases both the string and int element blocks.

    cout << "exiting program..." << endl;

    return EXIT_SUCCESS;
}
catch (...)
{
    return EXIT_FAILURE;
}

You’ll see the following console output when you compile and execute this code:

inserting string 'foo'...
  * element block acquired
inserting string 'bah'...
inserting int 100...
  * element block acquired
emptying the container...
  * element block released
  * element block released
exiting program...

In this example, the element_block_acquired handler gets triggered each time the container creates (thus acquires) a new element block to store a value. It does not get called when a new value is appended to a pre-existing element block. Similarly, the element_block_releasd handler gets triggered each time an existing element block storing non-empty values gets deleted. One thing to keep in mind is that since these two handlers respond to events related to element blocks which are owned by non-empty blocks in the primary array, and empty blocks don’t store any element block instances, creations or deletions of empty blocks don’t trigger these event handlers.

The trait also allows you to configure other behaviors of multi_type_vector. Refer to mdds::mtv::default_trait for all available parameters.

Get raw pointer to element block array

Sometimes you need to expose a pointer to an element block array especially when you need to pass such an array pointer to C API that requires one. You can do this by calling the data method of the element_block template class . This works since the element block internally just wraps std::vector (or std::deque in case the MDDS_MULTI_TYPE_VECTOR_USE_DEQUE preprocessing macro is defined), and its data method simply exposes vector’s own data method which returns the memory location of its internal array storage.

The following code demonstrates this by exposing raw array pointers to the internal arrays of numeric and string element blocks, and printing their element values directly from these array pointers.

#include <mdds/multi_type_vector.hpp>
#include <mdds/multi_type_vector/trait.hpp>
#include <iostream>

using std::cout;
using std::endl;
using mdds::mtv::double_element_block;
using mdds::mtv::string_element_block;

using mtv_type = mdds::multi_type_vector<mdds::mtv::element_block_func>;

int main() try
{
    mtv_type db;  // starts with an empty container.

    db.push_back(1.1);
    db.push_back(1.2);
    db.push_back(1.3);
    db.push_back(1.4);
    db.push_back(1.5);

    db.push_back(std::string("A"));
    db.push_back(std::string("B"));
    db.push_back(std::string("C"));
    db.push_back(std::string("D"));
    db.push_back(std::string("E"));

    // At this point, you have 2 blocks in the container.
    cout << "block size: " << db.block_size() << endl;
    cout << "--" << endl;

    // Get an iterator that points to the first block in the primary array.
    mtv_type::const_iterator it = db.begin();

    // Get a pointer to the raw array of the numeric element block using the
    // 'data' method.
    const double* p = double_element_block::data(*it->data);

    // Print the elements from this raw array pointer.
    for (const double* p_end = p + it->size; p != p_end; ++p)
        cout << *p << endl;

    cout << "--" << endl;

    ++it; // move to the next block, which is a string block.

    // Get a pointer to the raw array of the string element block.
    const std::string* pz = string_element_block::data(*it->data);

    // Print out the string elements.
    for (const std::string* pz_end = pz + it->size; pz != pz_end; ++pz)
        cout << *pz << endl;

    return EXIT_SUCCESS;
}
catch (...)
{
    return EXIT_FAILURE;
}

Compiling and execute this code produces the following output:

block size: 2
--
1.1
1.2
1.3
1.4
1.5
--
A
B
C
D
E

Traverse multiple multi_type_vector instances “sideways”

In this section we will demonstrate a way to traverse multiple instances of multi_type_vector “sideways” using the mdds::mtv::collection class. What this class does is to wrap multiple instances of multi_type_vector and generate iterators that let you iterate the individual element values collectively in the direction orthogonal to the direction of the individual vector instances.

The best way to explain this feature is to use a spreadsheet analogy. Let’s say we are implementing a data store to store a 2-dimensional tabular data where each cell in the data set is associated with row and column indices. Each cell may store a value of string type, integer type, numeric type, etc. And let’s say that the data looks like the following spreadsheet data:

_static/images/mtv_collection_sheet.png

It consists of five columns, with each column storing 21 rows of data. The first row is a header row, followed by 20 rows of values. In this example, We will be using one multi_type_vector instance for each column thus creating five instances in total, and store them in a std::vector container.

The declaration of the data store will look like this:

using mtv_type = mdds::multi_type_vector<mdds::mtv::element_block_func>;
using collection_type = mdds::mtv::collection<mtv_type>;

std::vector<mtv_type> columns(5);

The first two lines specify the concrete multi_type_vector type used for each individual column and the collection type that wraps the columns. The third line instantiates the std::vector instance to store the columns, and we are setting its size to five to accommodate for five columns. We will make use of the collection_type later in this example after the columns have been populated.

Now, we need to populate the columns with values. First, we are setting the header row:

// Populate the header row.
const char* headers[] = { "ID", "Make", "Model", "Year", "Color" };
size_t i = 0;
for (const char* v : headers)
    columns[i++].push_back<std::string>(v);

We are then filling each column individually from column 1 through column 5. First up is column 1:

// Fill column 1.
int c1_values[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 };

for (int v : c1_values)
    columns[0].push_back(v);

Hopefully this code is straight-forward. It initializes an array of values and push them to the column one at a time via push_back(). Next up is column 2:

// Fill column 2.
const char* c2_values[] =
{
    "Nissan", "Mercedes-Benz", "Nissan", "Suzuki", "Saab", "Subaru", "GMC", "Mercedes-Benz", "Toyota", "Nissan",
    "Mazda", "Dodge", "Ford", "Bentley", "GMC", "Audi", "GMC", "Mercury", "Pontiac", "BMW",
};

for (const char* v : c2_values)
    columns[1].push_back<std::string>(v);

This is similar to the code for column 1, except that because we are using an array of string literals which implicitly becomes an initializer list of type const char*, we need to explicitly specify the type for the push_back() call to be std::string.

The code for column 3 is very similar to this:

// Fill column 3.
const char* c3_values[] =
{
    "Frontier", "W201", "Frontier", "Equator", "9-5", "Tribeca", "Yukon XL 2500", "E-Class", "Camry Hybrid", "Frontier",
    "MX-5", "Ram Van 1500", "Edge", "Azure", "Sonoma Club Coupe", "S4", "3500 Club Coupe", "Villager", "Sunbird", "3 Series",
};

for (const char* v : c3_values)
    columns[2].push_back<std::string>(v);

Populating column 4 needs slight pre-processing. We are inserting a string value of “unknown” in lieu of an integer value of -1. Therefore the following code will do:

// Fill column 4.  Replace -1 with "unknown".
int32_t c4_values[] =
{
    1998, 1986, 2009, -1, -1, 2008, 2009, 2008, 2010, 2001,
    2008, 2000, -1, 2009, 1998, 2013, 1994, 2000, 1990, 1993,
};

for (int32_t v : c4_values)
{
    if (v < 0)
        // Insert a string value "unknown".
        columns[3].push_back<std::string>("unknown");
    else
        columns[3].push_back(v);
}

Finally, the last column to fill, which uses the same logic as for columns 2 and 3:

// Fill column 5
const char* c5_values[] =
{
    "Turquoise", "Fuscia", "Teal", "Fuscia", "Green", "Khaki", "Pink", "Goldenrod", "Turquoise", "Yellow",
    "Orange", "Goldenrod", "Fuscia", "Goldenrod", "Mauv", "Crimson", "Turquoise", "Teal", "Indigo", "LKhaki",
};

for (const char* v : c5_values)
    columns[4].push_back<std::string>(v);

At this point, the content we’ve put into the columns variable roughly reflects the tabular data shown at the beginning of this section. Now we can use the collection type we’ve declared earlier to wrap the columns:

// Wrap the columns with the 'collection'...
collection_type rows(columns.begin(), columns.end());

We are naming this variable rows since what we are doing with this wrapper is to traverse the content of the tabular data in row-wise direction. For this reason, calling it rows is quite fitting.

The collection class offers some flexibility as to how the instances that you are trying to traverse orthogonally are stored. That being said, you must meet the following prerequisites when passing the collection of vector instances to the constructor of the collection class:

  1. All multi_type_vector instances that comprise the collection must be of the same logical length i.e. their size() methods must all return the same value.

  2. The instances in the collection must be stored in the source container either as

    • concrete instances (as in this example),

    • as pointers, or

    • as heap instances wrapped within smart pointer class such as std::shared_ptr or std::unique_ptr.

Although we are storing the vector instances in a std::vector container in this example, you have the flexibility to pick a different type of container to store the individual vector instances as long as it provides STL-compatible standard iterator functionality.

Additionally, when using the collection class, you must ensure that the content of the vector instances that it references will not change for the duration of its use.

Finally, here is the code that does the traversing:

// Traverse the tabular data in row-wise direction.
for (const auto& cell : rows)
{
    if (cell.index > 0)
        // Insert a column separator before each cell except for the ones in the first column.
        std::cout << " | ";

    switch (cell.type)
    {
        // In this example, we use two element types only.
        case mdds::mtv::element_type_int32:
            std::cout << cell.get<mdds::mtv::int32_element_block>();
            break;
        case mdds::mtv::element_type_string:
            std::cout << cell.get<mdds::mtv::string_element_block>();
            break;
        default:
            std::cout << "???"; // The default case should not hit in this example.
    }

    if (cell.index == 4)
        // We are in the last column. Insert a line break.
        std::cout << std::endl;
}

It’s a simple for-loop, and in each iteration you get a single cell node that contains metadata about that cell including its value. The node contains the following members:

  • type - an integer value representing the type of the value.

  • index - a 0-based index of the multi_type_vector instance within the collection. You can think of this as column index in this example.

  • position - a 0-based logical element position within each multi_type_vector instance. You can think of this as row index in this example.

In the current example we are only making use of the type and index members, but the position member will be there if you need it.

The node also provides a convenient get() method to fetch the value of the cell. This method is a template method, and you need to explicitly specify the element block type in order to access the value.

When executing this code, you will see the following outout:

ID | Make | Model | Year | Color
1 | Nissan | Frontier | 1998 | Turquoise
2 | Mercedes-Benz | W201 | 1986 | Fuscia
3 | Nissan | Frontier | 2009 | Teal
4 | Suzuki | Equator | unknown | Fuscia
5 | Saab | 9-5 | unknown | Green
6 | Subaru | Tribeca | 2008 | Khaki
7 | GMC | Yukon XL 2500 | 2009 | Pink
8 | Mercedes-Benz | E-Class | 2008 | Goldenrod
9 | Toyota | Camry Hybrid | 2010 | Turquoise
10 | Nissan | Frontier | 2001 | Yellow
11 | Mazda | MX-5 | 2008 | Orange
12 | Dodge | Ram Van 1500 | 2000 | Goldenrod
13 | Ford | Edge | unknown | Fuscia
14 | Bentley | Azure | 2009 | Goldenrod
15 | GMC | Sonoma Club Coupe | 1998 | Mauv
16 | Audi | S4 | 2013 | Crimson
17 | GMC | 3500 Club Coupe | 1994 | Turquoise
18 | Mercury | Villager | 2000 | Teal
19 | Pontiac | Sunbird | 1990 | Indigo
20 | BMW | 3 Series | 1993 | LKhaki

which clearly shows that the code has traversed the content of the tabular data horizontally across columns as intended.

Now, one feature that may come in handy is the ability to limit the iteration range within the collection. You can do that by calling either set_collection_range() to limit the column range or set_element_range() to limit the row range, or perhaps both.

Let’s see how this works in the current example. Here, we are going to limit the iteration range to only columns 2 and 3, and rows 2 through 11. The following code will set this limit:

rows.set_collection_range(1, 2); // only columns 2 and 3.
rows.set_element_range(1, 10);   // only rows 2 through 11.

Then iterate through the collection once again:

for (const auto& cell : rows)
{
    if (cell.index > 1)
        // Insert a column separator before each cell except for the ones in the first column.
        std::cout << " | ";

    switch (cell.type)
    {
        // In this example, we use two element types only.
        case mdds::mtv::element_type_int32:
            std::cout << cell.get<mdds::mtv::int32_element_block>();
            break;
        case mdds::mtv::element_type_string:
            std::cout << cell.get<mdds::mtv::string_element_block>();
            break;
        default:
            std::cout << "???"; // The default case should not hit in this example.
    }

    if (cell.index == 2)
        // We are in the last column. Insert a line break.
        std::cout << std::endl;
}

This code is nearly identical to the previous one except for the index values used to control when to insert column separators and line breaks at the top and bottom of each iteration. When executing this code, you’ll see the following output:

Nissan | Frontier
Mercedes-Benz | W201
Nissan | Frontier
Suzuki | Equator
Saab | 9-5
Subaru | Tribeca
GMC | Yukon XL 2500
Mercedes-Benz | E-Class
Toyota | Camry Hybrid
Nissan | Frontier

which clearly shows that your iteration range did indeed shrink as expected.

Performance Considerations

Select SoA or AoS storage types

If you instantiate a multi_type_vector instance via mdds::multi_type_vector, which is an alias type for mdds::mtv::soa::multi_type_vector, you will be using the structure-of-arrays (SoA) variant of its implementation which is new in 2.0. Prior to 2.0, multi_type_vector used the array-of-structures (AoS) layout which is still available post 2.0 via mdds::mtv::aos::multi_type_vector in case you need it.

Note, however, that the SoA variant generally yields better overall performance since it can make more efficient use of CPU caches. It is therefore highly recommended that you stick with the SoA variant unless you have a specific reason not to.

Also note that both variants are API compatibile with each other.

Use of position hints to avoid the cost of block position lookup

Consider the following example code:

using mtv_type = mdds::multi_type_vector<mdds::mtv::element_block_func>;

size_t size = 50000;

// Initialize the container with one empty block of size 50000.
mtv_type db(size);

// Set non-empty value at every other logical position from top down.
for (size_t i = 0; i < size; ++i)
{
    if (i % 2)
        db.set<double>(i, 1.0);
}

which, when executed, may take quite sometime to complete especially when you are using an older version of mdds. This particular example exposes one weakness that multi_type_vector has; because it needs to first look up the position of the block to operate with, and that lookup always starts from the first block, the time it takes to find the correct block increases as the number of blocks goes up. This example demonstrates the worst case scenario of such lookup complexity since it always inserts the next value at the last block position.

Fortunately, there is a simple solution to this which the following code demonstrates:

using mtv_type = mdds::multi_type_vector<mdds::mtv::element_block_func>;

size_t size = 50000;

// Initialize the container with one empty block of size 50000.
mtv_type db(size);
mtv_type::iterator pos = db.begin();

// Set non-empty value at every other logical position from top down.
for (size_t i = 0; i < size; ++i)
{
    if (i % 2)
        // Pass the position hint as the first argument, and receive a new
        // one returned from the method for the next call.
        pos = db.set<double>(pos, i, 1.0);
}

Compiling and executing this code should take only a fraction of a second.

The only difference between the second example and the first one is that the second one uses an interator as a position hint to keep track of the position of the last modified block. Each set() method call returns an iterator which can then be passed to the next set() call as the position hint. Because an iterator object internally stores the location of the block the value was inserted to, this lets the method to start the block position lookup process from the last modified block, which in this example is always one block behind the one the new value needs to go. Using the big-O notation, the use of the position hint essentially turns the complexity of O(n^2) in the first example into O(1) in the second one if you are using an older version of mdds where the block position lookup had a linear complexity.

This strategy should work with any methods in multi_type_vector that take a position hint as the first argument.

Note that, if you are using a more recent version of mdds (1.6.0 or newer), the cost of block position lookup is significantly lessoned thanks to the switch to binary search in performing the lookup.

Note

If you are using mdds 1.6.0 or newer, the cost of block position lookup is much less significant even without the use of position hints. But the benefit of using position hints may still be there. It’s always a good idea to profile your specific use case and decide whether the use of position hints is worth it.

One important thing to note is that, as a user, you must ensure that the position hint you pass stays valid between the calls. A position hint becomes invalid when the content of the container changes. A good strategy to maintain a valid position hint is to always receive the iterator returned from the mutator method you called to which you passed the previous position hint, which is what the code above does. Passing an invalid position hint to a method that takes one may result in invalid memory access or otherwise in some sort of undefined behavior.

Warning

You must ensure that the position hint you pass stays valid. Passing an invalid position hint to a method that takes one may result in invalid memory access or otherwise in some sort of undefined behavior.

Block shifting performance and loop-unrolling factor

The introduction of binary search in the block position lookup implementation in version 1.6 has significantly improved its lookup performance, but has also resulted in slight performance hit when shifting blocks during value insertion. This is because when shifting the logical positions of the blocks below the insertion point, their head positions need to be re-calculated to account for their new positions.

The good news is that the switch to the structure-of-arrays (SoA) storage layout in 2.0 alone may bring subtle but measurable improvement in the block position adjustment performance due to the logical block positions now being stored in a separate array thereby improving its cache efficiency. In reality, however, this was somewhat dependent on the CPU types since some CPU’s didn’t show any noticeable improvements or even showed worse performance, while other CPU types showed consistent improvements with SoA over AoS.

Another factor that may play a role is loop unrolling factor which can be configured via the loop_unrolling variable in your custom trait type if you use version 2.0 or newer. This variable is an enum class of type mdds::mtv::lu_factor_t which enumerates several pre-defined loop-unrolling factors as well as some SIMD features.

The hardest part is to figure out which loop unrolling factor is the best option in your runtime environment, since it is highly dependent on the environment. Luckily mdds comes with a tool called runtime-env which, when run, will perform some benchmarks and give you the best loop-unrolling factor in your runtime environment. Be sure to build this tool with the same compiler and compiler flags as your target program in order for this tool to give you a representative answer.

Debugging

Tracing of public methods

When using multi_type_vector to handle a series of data reads and writes in an non-trivial code base, sometimes you may find yourself needing to track which methods are getting called when following a certain code path during a debugging session. In such a situation, you can enable an optional trace method which gets called whenever a public method of multi_type_vector is called.

First, you need to define a preprocessor macro named MDDS_MULTI_TYPE_VECTOR_DEBUG before including the header for multi_type_vector:

#define MDDS_MULTI_TYPE_VECTOR_DEBUG 1
#include <mdds/multi_type_vector/soa/main.hpp>
#include <mdds/multi_type_vector/trait.hpp>

#include <iostream>

to enable additional debug code. In this example the value of the macro is set to 1, but it doesn’t matter what the value of the macro is, as long as it is defined. You can also define one as a compiler option as well.

Once defined, the next step is to add a trace method as a static function to the trait type you pass as a template argument of multi_type_vector:

namespace mtv = mdds::mtv;

struct mtv_trait : public mtv::default_trait
{
    static void trace(const mtv::trace_method_properties_t& props)
    {
        std::cout << "function:" << std::endl
                  << "  name: " << props.function_name << std::endl
                  << "  args: " << props.function_args << std::endl;
    }
};

using mtv_type = mtv::soa::multi_type_vector<mtv::element_block_func, mtv_trait>;

Here, we are simply inheriting our trait type from the default_trait type and simply adding a static trace function to it, and passing this trait type to the mtv_type definition below. This trace function must take one argument of type mdds::mtv::trace_method_properties_t which includes various properties of the traced call. In this example, we are simply printing the properties named function_name and function_args each time a traced method is called. Both of these properties are printable string types.

Note that this trace function is entirely optional; the code will compile fine even when it’s not defined. Also, it must be declared as static for it to be called.

Let’s instantiate an object of mtv_type, call some of its methods and see what happens. When executing the following code:

mtv_type db(10);
db.set<int32_t>(0, 12);
db.set<int8_t>(2, 34);
db.set<int16_t>(4, 56);

You will see the following output:

function:
  name: multi_type_vector
  args: init_size=10
function:
  name: set
  args: pos=0; value=? (type=5)
function:
  name: set
  args: pos=2; value=? (type=1)
function:
  name: set
  args: pos=4; value=? (type=3)
function:
  name: ~multi_type_vector
  args:

The function_name property is hopefully self-explanatory. The function_args property is a single string value containing the information about the function’s arguments and optionally their values if their values are known to be printable. If the value of an argument cannot be printed, ? is placed instead. For some argument types, an additional information is displayed e.g. (type=5) in the above output which indicates that the type of the value being passed to the function is element_type_int32.

If you want to limit your tracing to a specific function type or types, you can make use of the type property which specifies the type of the traced method. Likewise, if you want to only trace methods of a certain instance, use instance to filter the incoming trace calls based on the memory addresses of the instances whose methods are being traced.

Note that this feature is available for version 2.0.2 and newer, and currently only available for the SoA variant of multi_type_vector.

Note

This feature is only available for version 2.0.2 and newer, and only for the SoA variant.

API Reference

Core

mdds::multi_type_vector

Warning

doxygentypedef: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

mdds::mtv::soa::multi_type_vector

Warning

doxygenclass: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

mdds::mtv::aos::multi_type_vector

Warning

doxygenclass: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

mdds::mtv::empty_event_func

Warning

doxygenstruct: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

mdds::mtv::default_trait

Warning

doxygenstruct: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Element Blocks

Warning

doxygenclass: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenclass: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenstruct: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenclass: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenclass: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenstruct: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenstruct: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenstruct: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Types

mdds::mtv::element_t

Warning

doxygentypedef: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Warning

doxygenvariable: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

mdds::mtv::lu_factor_t

Warning

doxygenenum: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

mdds::mtv::trace_method_t

Warning

doxygenenum: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

mdds::mtv::trace_method_properties_t

Warning

doxygenstruct: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Exceptions

Warning

doxygenclass: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml

Collection

Warning

doxygenclass: Cannot find file: /tmp/B.2oghecep/BUILD/mdds-2.0.3/doc/_doxygen/xml/index.xml