Inspired Code

Moore's Law

2021-05-08T17:52:00.001-07:00

I think many people interested in technology are familiar with Moore's law.

It's basically the observation that the number of transistors that can be fitted on chips doubles about every two years. This density of transisters per square millimeter is related to the process size, for example the latest generation of high end CPUs and GPUs are using 7 nanometer technology, with 5 nm in development.

The assumption or perhaps implied implication of Moore's Law is that you would expect that this means the price per transistor would be proportionally getting less. For every square millimeter of silicon wafer you have, you are over time able to make more and more transistors on there. It was as if Moore's Law was a proxy for the price per transistor.

You could be forgiven for thinking that it means that year after year for a given amount of money you can buy an ever more powerful computer. I previously thought that was what it meant in practice.

However shinking the process size has slowly been getting more and more expensive to do. This has been the case since 28 nm. Since then the price per transistor has been going up for smaller and smaller process sizes. Let that sink in for a moment, the price per transistor has been going up, not down.

So for a 7nm chip, with more transistors, and with a higher price per transistor, it is no wonder newer CPUs and GPUs are costing more. And add to that some inflation happening in the economy as well as some supply chain issues due to COVID, it's no wonder that various products are seeing some pretty high prices at the moment.

Also it's worth trying to appreciate the supply side. One of the main suppliers is TSMC, based in Taiwan. There are fewer and fewer fabrication facilities for the smaller and smaller process sizes as the required investment increases. There are constraints on finding large enough areas of industrial land with ready access to the large amounts of water and electricity, this requires years of planning with consultation with government to have these facilities.

With fewer places able to make the newer process size chips, obviously supply is an issue. There is more fagility with fewer suppliers. https://en.wikipedia.org/wiki/Antifragility This makes the production sensitive to any stressors/failures leading to high volitility. And there have been stressors in the form of COVID and also crypto mining demand.

Intel announced recently that they will create a new plant in Arizona:

https://newsroom.intel.com/wp-content/uploads/sites/11/2021/03/Intel-Arizona-manufacturing-15073363.pdf

It will probably be several years until it will be able to produce anything, but they did this with consultation and cooperation from the Arizona government and also the Biden administration. It's a $20 billion dollar investment that will help provide production security for the US and US companies like Intel, Nvidia and Apple.

Ranges, views, pipes

2019-12-05T05:00:00.012-08:00

Something I've always liked about UNIX systems is the idea of a collection of tools which can be combined together using pipes to do all kinds of interesting things relatively easily.

For example:

cat wordlist.txt | sort | uniq | wc -l

This takes a list of words on each line from the input file, pipes it through a command to sort the input and then filters out any repeated lines and finally counts the number of lines, which will tell you the number of unique words/lines in the input file. You can also filter these with commands like grep and sed, as well as use sed and tr to translate the input and so on.

Under the hood, UNIX starts a process for each of these commands. Each process reads from stdin and writes to stdout, however when piped, these are joined together where the output of ones becomes the input of the next in the chain. When they are waiting for input and none is currently available, the OS will not schedule that process and schedule another which is ready to run. One that is ready will read from its stdin and write to its stdout which will then have the effect of making another process ready to run again because it now has input that can be read. So it is actually the scheduler of the OS which is making some of the magic happen. A not so smart OS implementation might allow the first process to run to completion and buffer all of its output to then start the next process and feed it all of the buffered output from the first command in to it. This obviously will work for simple cases, but doesn't scale to long running chains of commands or ones where there is a very large amount of data processed which can not all fit in memory.

I've often thought, it would be neat to do something like this in C++ code to express how a chain of processes could be linked up together. You can always chain up function calls in C++, and it has always been possible to override the pipe operator. Chaining function calls together is something you can do with an API designed for being used in that way such as this example using Qt:

QString("Format : %1 %2 %2").arg(1).arg(2).arg(3);

This though is along the lines of the 2nd type of OS implementation strategy for pipes where each command is run to completion one at a time without doing the smart thing. Examples where the pipe operator are used can also be found in Qt, such as how flags are combined. See the documentation for https://doc.qt.io/qt-5/qflags.html#Q_DECLARE_OPERATORS_FOR_FLAGS which generates the operator for combining flags.

Putting it together, and it should be possible to define a pipe operator which joins together things which are iterable, and have something similar to UNIX style pipes in C++ code, for example:

cat("wordlist.txt") | sort() | uniq()

More idiomatic for C++ would be:

cat("wordlist.txt").sort().uniq();

And that is the way you would join up things in C# also when using LINQ and iterables.

However if really want to push onwards towards replicating UNIX pipes and adding syntactic sugar to replicate the syntax of a UNIX shell, then it may be even possible to drop the round braces in places, such as from the sort and uniq:

cat("wordlist.txt") | sort | uniq > out;

Where 'sort', 'uniq' and 'out' would need to be objects instead of functions. But the pipe operator for the particular pair of types can be made to call specific functions on the objects, which is then how these can be glued together. Specifically:

// A class which does sorting

class SortClass { public: SortClass(); };

// An object called 'sort'

SortClass sort;

// A class which does uniq

class UniqClass { public: UniqClass(); };

// An object called 'uniq'

UniqClass uniq;

// A pipe operator to combine these

operator|(SortClass&, UniqClass&);

sort | uniq;

And it seems like something like this is coming to C++ in the form of the Ranges Library:

https://en.cppreference.com/w/cpp/ranges

Co-routines immediately come to mind as something else which would be nice, such as having the yield feature that exists in C#. This would make it easier to have something more similar to the first type of smart OS implementation strategy for pipes, but without necessarily using threads/processes.

Some other things I've seen in other contexts that I've liked are the map/reduce/filter types of expressions in languages like javascript and python. It's more the syntax and ways in which these easily combine that is nice about them, much like what it is I like about UNIX pipes.

It seems like with the Ranges Library it will be possible to have map/reduce/filter kinds of operations such as is given on the cppreference web page for the ranges library:

int main()
{
    std::vector<int> ints{0,1,2,3,4,5};
    auto even = [](int i){ return 0 == i % 2; };
    auto square = [](int i) { return i * i; };
 
    for (int i : ints | std::views::filter(even) | std::views::transform(square)) {
        std::cout << i << ' ';
    }
}

The yield keyword in C# for expressing iteration over something and returning the elements without having to turn the code inside out to make it an iterator is nice, and the general way iterables and LINQ can be used in C# to do interesting things. This is along the lines of co-routines, and C++ looks to be adding them. From what I understand of how yield is implemented in C#, using threads isn't required for making yield work.

If a language is designed to support co-routines, essentially the execution of a function can be suspended by jumping to another location if the state of the stack is preserved, and then the function resumed by jumping back if the stack and execution continues where it was previously. Typically you would think a thread is how you might do this because each thread has its own stack. If manually turning a function inside-out to make it in to a co-routine, the manual procedure is to turn all stack allocations in to something contained in a structure which represents the state to be preserved. This state also needs to track where in the function it was, so when it resumes being executed, it can jump to the previous location. When recursion is involved, the solution is that this structure is an array of this state to the maximum recursion depth and the current depth is also tracked. You can manually convert a function in C/C++ to be able to be used this way, but it is ugly and the resulting code is not as elegant when compared to the same code in C# written using yield. And it looks like in C++20 this will become an option which is quite exciting:

https://en.cppreference.com/w/cpp/language/coroutines

It appears as though the state which is preserved which would have otherwise been on the stack is dynamically allocated using new. I wonder how it deals with recursive functions. Possibly dynamically allocating the state isn't always needed, if hand rolling a conversion of a function to act similar to a co-routine, it is possible to allocate that state on the stack at the call-site and pass that down to the call of the co-routine as an input parameter, and then what you want is the language which supports co-routines to do that for you, and if not possible to allocate it from the stack to otherwise allocate it from the heap, but this is a pretty minor issue compared with the bigger problem which will be solved. Compared with the ranges library, I'm more excited about the addition of the coroutines, as trying to emulate coroutines without actual language support for them is hacky at best, or if not hacky, very inelegant.

About emulating the ranges library, that is something I've attempted with my own flavour on things. For example, the example given using ranges is this:

    for (int i : ints | std::views::filter(even) | std::views::transform(square)) {
        std::cout << i << ' ';
    }

Why is there the need to expose the for loop, and why isn't there a terminal print object to pipe in to which can do the output as above. My take on this would be to have a syntax like this:

    ints | filter(even) | transform(square) | print;

So below is my implementation of my flavour of something similar to the C++20 ranges library that will however work with C++14 now, or with some effort could be made to work with C++11 if you don't mind making the code more verbose. I'm personally happy to target C++14 as my minimum, so have designed this code to require C++14. Here it is:

// C++ Views and Pipes

// by John Ryland

///////////

// BRIEF //

///////////

Requires C++14, but would not be impossible to support C++11 with effort.

Compile with:

g++ --std=c++14 pipe-tests.cpp -o pipe-tests

Examples of what it can do:

to_array({"one","two","three","four","five"}) | reverse
| filter([](std::string a){ return a == "two"; }) | print;

This is C++ code, and it takes the list of strings and turns them in to a
std::array, then pipes it through a reverse function which causes the
iteration to happen in reverse, then pipes this through a filter which

is defined with an inline lambda which removes any items which equal "two",
and finally it prints out the result.

The lambdas don't need to be inline, it can be nicer to define a function
like this:

auto odd = [](int x) -> bool { return (x & 1) == 1; };

Then it can be used like this:

std::vector v = {1,2,3,4,5};

container_view(v) | match(odd) | print;

This takes as input a std::vector of items, and wraps it in a view which is
piped to a matching function which will only pass through items where the
lambda returns true for the item. Internally the vector is not copied, simply

the iteration is what is varied. Next it prints out the result.

More complicated examples can be made:

range(1,101) | reverse | filter(odd) | first(5) | print;

This one uses the range function which generates items. At no point is an
actual list or vector of numbers made in memory. However it will print the
last 5 odd numbers working backwards from 101 as might be expected from
the commands.

//////////////

// INCLUDES //

//////////////

#include <cstdio>

#include <cstring>

#include <vector>

#include <iostream>

#include <sstream>

#include <array>

#include <regex>

#include <functional>

/////////////////

// TYPE TRAITS //

/////////////////

// Container Traits ///////////////////////////////////////////////////////////

template <typename T, typename _ = void>

struct has_container_traits : std::false_type {};

template <typename... Ts>

struct has_container_traits_helper {};

template <typename T>

struct has_container_traits<T, std::conditional_t<false, has_container_traits_helper<

// Const Container Trails:

typename T::value_type,

typename T::const_iterator,

typename T::const_reverse_iterator,

decltype(std::declval<T>().crbegin()),

decltype(std::declval<T>().crend()),

decltype(std::declval<T>().cbegin()),

decltype(std::declval<T>().cend())

>, void>> : public std::true_type {};

template <typename Container,

typename std::enable_if<has_container_traits<Container>{}, bool>::type = true>

struct is_container

{

using type = bool;

};

template <typename Container>

using is_container_t = typename is_container<Container>::type;

// View Traits ////////////////////////////////////////////////////////////////

template <typename T, typename _ = void>

struct has_view_traits : std::false_type {};

template <typename... Ts>

struct has_view_traits_helper {};

template <typename T>

struct has_view_traits<T, std::conditional_t<false, has_view_traits_helper<

// View Traits:

typename T::element_type,

decltype(std::declval<T>().first()),

decltype(std::declval<T>().last()),

decltype(std::declval<T>().next()),

decltype(std::declval<T>().previous()),

decltype(std::declval<T>().current())

>, void>> : public std::true_type {};

template <typename View,

typename std::enable_if<has_view_traits<View>{}, bool>::type = true>

struct is_view

{

using type = bool;

};

template <typename View>

using is_view_t = typename is_view<View>::type;

////////////////

// VIEW TYPES //

////////////////

// Container View /////////////////////////////////////////////////////////////

template <typename Container, typename BaseType, is_container_t<BaseType> = true>

class container_wrapper_view

{

public:

container_wrapper_view(Container a_container)

: m_container(a_container)

{

}

// implements View

using element_type = typename BaseType::value_type;

bool first() { m_it = m_container.cbegin(); return !m_container.empty(); }

bool last() { m_it = std::prev(m_container.cend()); return !m_container.empty(); }

bool next() { m_it = std::next(m_it); return m_it != m_container.cend(); }

bool previous() { if (m_it != m_container.cbegin()) { m_it = std::prev(m_it); return true; } return false; }

const element_type& current() { return *m_it; }

private:

Container m_container;

typename BaseType::const_iterator m_it;

};

// Range View /////////////////////////////////////////////////////////////////

template <typename T>

class range_view

{

public:

range_view(T start, T end)

: m_start(start)

, m_end(end)

{

}

// implements View

using element_type = T;

bool first() { m_current = m_start; return m_start <= m_end; }

bool last() { m_current = m_end; return m_start <= m_end; }

bool next() { ++m_current; return m_current <= m_end; }

bool previous() { --m_current; return m_current >= m_start; }

const T& current() { return m_current; }

private:

T m_current;

T m_start;

T m_end;

};

// Match View ////////////////////////////////////////////////////////////////

template <typename ParentView, typename Functor, is_view_t<ParentView> = true>

class match_view

{

public:

using element_type = typename ParentView::element_type;

match_view(const ParentView& a_parentView, const Functor& a_match)

: m_parentView(a_parentView)

, m_match(a_match)

{

}

// implements View

bool first() { if (!m_parentView.first()) return false; return nextValid(); }

bool last() { if (!m_parentView.last()) return false; return previousValid(); }

bool next() { if (!m_parentView.next()) return false; return nextValid(); }

bool previous() { if (!m_parentView.previous()) return false; return previousValid(); }

const element_type& current() { return m_parentView.current(); }

private:

bool nextValid() { while (!m_match(m_parentView.current())) { if (!m_parentView.next()) return false; } return true; }

bool previousValid() { while (!m_match(m_parentView.current())) { if (!m_parentView.previous()) return false; } return true; }

ParentView m_parentView;

Functor m_match;

};

// Filter View ////////////////////////////////////////////////////////////////

template <typename ParentView, is_view_t<ParentView> = true>

class filter_view : public match_view<ParentView, std::function<bool(typename ParentView::element_type)>>

{

public:

// inherits View

using element_type = typename ParentView::element_type;

using function_type = std::function<bool(element_type)>;

filter_view(const ParentView& a_parentView, const function_type& a_filter)

: match_view<ParentView, function_type>(a_parentView, [a_filter](element_type a_item) { return !a_filter(a_item); })

{

}

};

// Transform View /////////////////////////////////////////////////////////////

template <typename ParentView, typename Functor, typename ReturnType, is_view_t<ParentView> = true>

class transform_view

{

public:

using parent_element_type = typename ParentView::element_type;

transform_view(const ParentView& a_parentView, const Functor& a_transform)

: m_parentView(a_parentView)

, m_transform(a_transform)

{

}

// implements View

using element_type = ReturnType;

bool first() { return m_parentView.first(); }

bool last() { return m_parentView.last(); }

bool next() { return m_parentView.next(); }

bool previous() { return m_parentView.previous(); }

element_type current() { return m_transform(m_parentView.current()); } // NOTE: Transformed elements are returned by value

private:

ParentView m_parentView;

Functor m_transform;

};

// Reverse View ///////////////////////////////////////////////////////////////

template <typename ParentView, is_view_t<ParentView> = true>

class reverse_view

{

public:

reverse_view(const ParentView& view)

: m_parent(view)

{

}

// implements View

using element_type = typename ParentView::element_type;

bool first() { return m_parent.last(); }

bool last() { return m_parent.first(); }

bool next() { return m_parent.previous(); }

bool previous() { return m_parent.next(); }

const element_type& current() { return m_parent.current(); }

private:

element_type m_current;

ParentView m_parent;

};

// Skip View //////////////////////////////////////////////////////////////////

template <typename ParentView, is_view_t<ParentView> = true>

class skip_view

{

public:

using element_type = typename ParentView::element_type;

skip_view(const ParentView& a_parentView, size_t a_count)

: m_parentView(a_parentView)

, m_count(a_count)

{

}

// implements View

bool first() { if (!m_parentView.first()) return false; return nextValid(); }

bool last() { if (!m_parentView.last()) return false; return previousValid(); }

bool next() { return m_parentView.next(); }

bool previous() { return m_parentView.previous(); }

const element_type& current() { return m_parentView.current(); }

private:

bool nextValid() { while (m_count >= 1) { if (!m_parentView.next()) return false; m_count--; } return true; }

bool previousValid() { while (m_count >= 1) { if (!m_parentView.previous()) return false; m_count--; } return true; }

ParentView m_parentView;

size_t m_count;

};

// Take View //////////////////////////////////////////////////////////////////

template <typename ParentView, is_view_t<ParentView> = true>

class take_view

{

public:

using element_type = typename ParentView::element_type;

take_view(const ParentView& a_parentView, size_t a_count)

: m_parentView(a_parentView)

, m_count(a_count)

{

}

// implements View

bool first() { return m_parentView.first(); }

bool last() {

size_t count = m_count - 1;

if (count <= 0 || !m_parentView.first()) return false;

while (count)

{

if (!m_parentView.next()) return false;

count--;

}

return true;

}

bool next() { m_count--; return (m_count > 0) ? m_parentView.next() : false; }

bool previous() { m_count--; return (m_count > 0) ? m_parentView.previous() : false; }

const element_type& current() { return m_parentView.current(); }

private:

ParentView m_parentView;

size_t m_count;

};

//////////////

// WRAPPERS //

//////////////

// Container Wrapper //////////////////////////////////////////////////////////

// creates a const reference container view

template <typename Container, is_container_t<Container> = true>

auto container_view(const Container& a_container)

{

return container_wrapper_view<const Container&, Container>(a_container);

}

// creates a container view by value

template <typename Container, is_container_t<Container> = true>

auto container_copy_view(const Container& a_container)

{

return container_wrapper_view<Container, Container>(a_container);

}

// Range Wrapper //////////////////////////////////////////////////////////////

template <typename T>

auto range(T start, T end)

{

return range_view<T>(start, end);

}

// Array Wrapper //////////////////////////////////////////////////////////////

template <class T, std::size_t N, std::size_t... I>

constexpr auto to_array_impl(T (&a)[N], std::index_sequence<I...>)

{

return std::array<std::remove_cv_t<T>, N>{ { a[I]... } };

}

template <class T, std::size_t N, std::size_t... I>

constexpr auto to_array_impl(T (&&a)[N], std::index_sequence<I...>)

{

return std::array<std::remove_cv_t<T>, N>{ { std::move(a[I])... } };

}

template <class T, std::size_t N>

constexpr auto to_array(T (&a)[N])

{

return to_array_impl(a, std::make_index_sequence<N>{});

}

template <class T, std::size_t N>

constexpr auto to_array(T (&&a)[N])

{

return to_array_impl(std::move(a), std::make_index_sequence<N>{});

}

// Print Wrapper /////////////////////////////////////////////////////////////

class print_class

{

// No state, just the class as a tag

};

// Reverse Wrapper ////////////////////////////////////////////////////////////

class reverse_class

{

// No state, just the class as a tag

};

// Match Wrapper //////////////////////////////////////////////////////////////

template <typename Functor>

class match_class

{

public:

match_class(Functor&& a_m)

: m_m(a_m)

{

}

Functor m_m;

};

// Filter Wrapper /////////////////////////////////////////////////////////////

template <typename Functor>

class filter_class

{

public:

filter_class(Functor&& a_f)

: m_f(a_f)

{

}

Functor m_f;

};

// Transform Wrapper //////////////////////////////////////////////////////////

template <typename Functor>

class transform_class

{

public:

transform_class(Functor&& t)

: m_t(t)

{

}

Functor m_t;

};

//////////////

// COMMANDS //

//////////////

// Print Command //////////////////////////////////////////////////////////////

print_class print;

// Reverse Command ////////////////////////////////////////////////////////////

reverse_class reverse;

// Match Command //////////////////////////////////////////////////////////////

template <typename Functor>

auto match(Functor&& a_m)

{

return match_class<Functor>(std::forward<Functor>(a_m));

}

// Grep Command ///////////////////////////////////////////////////////////////

// Match a regular expression

auto grep(const std::string& a_re)

{

std::regex re(a_re);

auto f = [re](const std::string& a_s) { return std::regex_search(a_s, re); };

return match_class<decltype(f)>(std::move(f));

}

// Filter Command /////////////////////////////////////////////////////////////

template <typename Functor>

auto filter(Functor&& a_f)

{

return filter_class<Functor>(std::forward<Functor>(a_f));

}

// Take Command ///////////////////////////////////////////////////////////////

class take

{

public:

take(size_t a_count)

: m_count(a_count)

{

}

size_t m_count;

};

// Head Command ///////////////////////////////////////////////////////////////

using head = take;

// First Command //////////////////////////////////////////////////////////////

using first = take;

// Last Command ///////////////////////////////////////////////////////////////

class last

{

public:

last(size_t a_count)

: m_count(a_count)

{

}

size_t m_count;

};

// Tail Command ///////////////////////////////////////////////////////////////

using tail = last;

// Skip Command ///////////////////////////////////////////////////////////////

class skip

{

public:

skip(size_t a_count)

: m_count(a_count)

{

}

size_t m_count;

};

// Drop Command ///////////////////////////////////////////////////////////////

using drop = skip;

// Transform Command //////////////////////////////////////////////////////////

template <typename Functor>

auto transform(Functor&& a_f)

{

return transform_class<Functor>(std::forward<Functor>(a_f));

}

// Convert Command ////////////////////////////////////////////////////////////

template <typename Functor>

auto convert(Functor&& a_f)

{

return transform_class<Functor>(std::forward<Functor>(a_f));

}

// Join Command ///////////////////////////////////////////////////////////////

class join

{

public:

join(const std::string& s)

: m_s(s)

{

}

std::string m_s;

};

// Split Command //////////////////////////////////////////////////////////////

class split

{

public:

split(const std::string& a_delimiters)

: m_delimiters(a_delimiters)

{

}

std::string m_delimiters;

};

///////////

// PIPES //

///////////

// Container Pipe /////////////////////////////////////////////////////////////

template <typename Container, typename View, is_container_t<Container> = true>

auto operator|(const Container& c, const View& v)

{

return container_view(c) | v;

}

// Array Pipe /////////////////////////////////////////////////////////////////

template <typename ArrayT, std::size_t ArrayN, typename View>

auto operator|(const ArrayT (&a)[ArrayN], const View& v)

{

auto c = to_array(a);

return container_view(c) | v;

}

// Reverse Pipe ///////////////////////////////////////////////////////////////

template <typename View, is_view_t<View> = true>

auto operator|(const View& v1, const reverse_class& r)

{

return reverse_view<View>(v1);

}

// Match Pipe ////////////////////////////////////////////////////////////////

template <typename View, typename Functor, is_view_t<View> = true>

auto operator|(const View& v1, const match_class<Functor>& m)

{

return match_view<View, Functor>(v1, m.m_m);

}

// Filter Pipe ////////////////////////////////////////////////////////////////

template <typename View, typename Functor, is_view_t<View> = true>

auto operator|(const View& v1, const filter_class<Functor>& f)

{

return filter_view<View>(v1, f.m_f);

}

// Take Pipe //////////////////////////////////////////////////////////////////

template <typename View, is_view_t<View> = true>

auto operator|(const View& v1, const take& t)

{

return take_view<View>(v1, t.m_count);

}

// Last Pipe //////////////////////////////////////////////////////////////////

template <typename View, is_view_t<View> = true>

auto operator|(const View& v1, const last& l)

{

return v1 | reverse | take(l.m_count) | reverse;

}

// Skip Pipe //////////////////////////////////////////////////////////////////

template <typename View, is_view_t<View> = true>

auto operator|(const View& v1, const skip& s)

{

return skip_view<View>(v1, s.m_count);

}

// Transform Pipe /////////////////////////////////////////////////////////////

template <typename View, typename Functor, is_view_t<View> = true>

auto operator|(const View& v1, const transform_class<Functor>& t)

{

return transform_view<View, Functor, decltype(t.m_t(typename View::element_type()))>(v1, t.m_t);

}

// Join Pipe //////////////////////////////////////////////////////////////////

std::string operator|(const std::string& s, const join& j)

{

return s;

}

std::string operator|(const char* s, const join& j)

{

return s;

}

template <typename View, is_view_t<View> = true>

std::string operator|(const View& c, const join& j)

{

std::stringstream ss;

std::string deliminator = j.m_s;

apply(c, [&ss, deliminator](const auto& a, bool f, bool l) { ss << a; if (!l) ss << deliminator; } );

return ss.str();

}

// Split Pipe /////////////////////////////////////////////////////////////////

template <typename View, is_view_t<View> = true>

auto operator|(const View& v1, const split& s)

{

// https://stackoverflow.com/questions/236129/how-do-i-iterate-over-the-words-of-a-string

std::string str = v1 | join("");

std::string delimiters = s.m_delimiters;

std::vector<std::string> tokens;

std::size_t start = 0, end, length = str.length();

while (length && start < length + 1)

{

end = str.find_first_of(delimiters, start);

if (end == std::string::npos)

{

end = length;

}

std::string token = std::string(str.data() + start, end - start);

tokens.push_back(token);

start = end + 1;

}

// Unfortunately we need to make a copy here as 'tokens' is on the stack. Possibly this

// could be improved if have a string_spans implementation as a 'view' in to the original data.

return container_copy_view<std::vector<std::string>>(tokens);

}

// Print Pipe /////////////////////////////////////////////////////////////////

template <typename View, is_view_t<View> = true>

void operator|(const View& v1, const print_class& r)

{

apply(v1, [](const auto& a, bool f, bool l) { std::cout << a; if (!l) std::cout << ","; } );

std::cout << std::endl;

}

void operator|(const std::string& s, const print_class& r)

{

std::cout << s << std::endl;

}

// Apply Pipe /////////////////////////////////////////////////////////////////

template <typename View, typename Functor, is_view_t<View> = true>

void for_each(const View& a_iterable, Functor&& f)

{

View it = a_iterable; // takes a copy of the view, views should be cheap to copy

if (it.first())

{

f(it.current());

} while (it.next());

}

template <typename View, typename Functor, is_view_t<View> = true>

void apply(const View& a_iterable, Functor&& f)

{

bool first = true;

bool last = false;

View it = a_iterable; // takes a copy of the view, views should be cheap to copy

if (it.first())

{

auto current = it.current();

last = !it.next();

f(current, first, last);

first = false;

} while (!last);

}

template <typename View, is_view_t<View> = true>

void operator|(const View& v, const std::function<void(typename View::element_type)>& f)

{

for_each(v, f);

}

template <typename Container, is_container_t<Container> = true>

void operator|(const Container& c, const std::function<void(typename Container::value_type)>& f)

{

std::for_each(c.begin(), c.end(), f);

}

///////////

// DEMOS //

///////////

void demo1()

{

std::cout << "Demo" << std::endl;

auto strings = to_array({"one","two","three","four","five"});

std::cout << "Printing strings" << std::endl;

strings | print;

std::cout << "Reversing strings" << std::endl;

strings | reverse | print;

std::cout << "Matching strings with 'o'" << std::endl;

strings | match([](std::string a){ return a.find("o") != std::string::npos; }) | print;

std::cout << "Grepping strings for 'one|two|four'" << std::endl;

strings | grep("one|two|four") | print;

std::cout << "Filtering strings without 'o'" << std::endl;

strings | filter([](std::string a){ return a.find("o") == std::string::npos; }) | print;

std::cout << "Taking 3 strings" << std::endl;

strings | take(3) | print;

std::cout << "Head 3 strings" << std::endl;

strings | head(3) | print;

std::cout << "First 3 strings" << std::endl;

strings | first(3) | print;

std::cout << "Last 3 strings" << std::endl;

strings | last(3) | print;

std::cout << "Tail 3 strings" << std::endl;

strings | tail(3) | print;

std::cout << "Skipping 2 strings" << std::endl;

strings | skip(2) | print;

std::cout << "Dropping 2 strings" << std::endl;

strings | drop(2) | print;

std::cout << "Transforming strings to lengths" << std::endl;

strings | transform([](std::string a) { return a.length(); }) | print;

std::cout << "Converting strings to lengths" << std::endl;

strings | convert([](std::string a) { return a.size(); }) | print;

std::cout << "Joining strings with '.'" << std::endl;

strings | join(".") | print;

std::cout << "Splitting strings with '.'" << std::endl;

strings | join(".") | split(".") | print;

}

void demo2()

{

// Functions

auto printer = [](auto x) { std::cout << x << ","; };

auto newline = []() { std::cout << std::endl; };

// Input

std::vector<int> v = {1,2,3,4,5};

// Normal way

for (auto i : v)

printer(i);

std::cout << std::endl;

// C++11 functional way

std::for_each(v.begin(), v.end(), printer);

std::cout << std::endl;

// Improved way

v | printer;

newline();

// Best way

v | print;

// More interesting options

v | reverse | print;

}

//////////

// MAIN //

//////////

int main()

{

demo1();

demo2();

std::stringstream ss;

auto printer = [](auto x) { std::cout << x << ","; };

auto newline = []() { std::cout << std::endl; };

auto odd = [](int x) -> bool { return (x & 1) == 1; };

auto as_string = [](auto x) -> std::string { return std::to_string(x); };

int v2[] = {1,2,3,4,5};

v2 | print;

int v3[]{1,2,3,4,5};

v3 | print;

auto v4 = to_array<int>({1,2,3,4,5});

v4 | print;

to_array({1,2,3,4,5}) | print;

std::string("13,15,66,42,23") | split(",") | join(".") | print;

"13,15,66,42,23" | split(",") | join(".") | print;

"13,15,66,42,23" | split(",") | grep("3") | join(".") | print;

auto sl = "13,15,66,42,23,123" | split(",");

auto s = sl | join(".");

std::cout << s << std::endl;

newline();

range(10,15) | print;

std::cout << (range(10,15) | transform(as_string) | join(",")) << std::endl;

for_each(range(10,15), printer);

newline();

for_each(reverse_view<range_view<int>>(range(10,15)), printer);

newline();

for_each(range(10,14) | reverse | filter(odd), printer);

newline();

std::vector<int> v = {1,2,3,4,5};

container_view(v) | print;

container_view(v) | match(odd) | print;

container_view(v) | filter(odd) | print;

container_view(v) | reverse | print;

container_view(v) | reverse | reverse | print;

container_view(v) | reverse | filter(odd) | reverse | print;

container_view(v) | filter(odd) | reverse | print;

container_view(v) | reverse | filter(odd) | print;

range(10,14) | reverse | filter(odd) | print;

range(10,15) | reverse | print;

range(10,15) | reverse | reverse | print;

range(10,15) | filter(odd) | print;

range(10,15) | reverse | filter(odd) | print;

range(10,15) | reverse | filter(odd) | reverse | print;

range(10,14) | reverse | filter(odd) | print;

range(1,101) | reverse | filter(odd) | take(5) | print;

range(1,101) | reverse | filter(odd) | head(5) | print;

range(1,101) | reverse | filter(odd) | first(5) | print;

range(1,101) | reverse | first(5) | reverse | print;

range(1,101) | last(5) | print;

range(1,101) | tail(5) | print;

range(1,6) | print;

range(1,6) | skip(3) | print;

auto filt = [](std::string a){ return a == "BAD"; };

to_array({"five","BAD","four","three","BAD","two","one"}) | reverse | filter(filt) | print;

to_array({"one","two","three","four","five"}) | reverse | filter([](std::string a){ return a == "two"; }) | print;

}

C++11 and some efficiency improvements

2017-06-27T08:16:00.000-07:00

I recently learnt a few new things.

shared_ptr

First is that using std::make_shared is actually not only good because of it's better exception safety (the primary reason I hear people promoting it), but it is actually better because it is infact more efficient and saves space.

To understand this, first lets explain what a shared_ptr is. It is basically a wrapper around a raw pointer. What the wrapper provides is reference counting. So a shared_ptr is two things, the raw pointer and a reference count associated with that raw pointer. Actually this is a slight simplification, because of weak pointers, the reference count is two counts, a weak count and a strong count, and both these are put in a structure called the control block for the shared_ptr, but conceptually this is the reference count part of it (in fact there is a bit more than this too, including the deleter etc, and this gets hidden via type eraser, but that is far more detail than is needed for discussion here). So a shared_ptr is two pointers, one to the object being managed, and another to the reference count (or control block). The reference count needs to be a pointer so that multiple shared_ptr instances can be referring and updating the one shared reference count associated with the object. Because shared_ptr has a constructor that takes a raw pointer, when constructed this way, there is only one choice and that is to dynamically allocate the reference count. Hence two dynamic allocations with this strategy, one for the allocation of the object that is passed in this way, and a second for the reference count. More allocations can mean memory fragmentation. What std::make_shared does is to essentially create a struct of T and reference count together and allocate this with one allocation. So one less dynamic memory allocation. Makes the deletion simpler too. And so that is why using make_shared to create a shared_ptr is better.

Whilst thinking about this, I realised a few things too. Firstly, unqiue_ptr obviously doesn't require a reference count and therefore doesn't require a second dynamic memory allocation ever. I did always scratch my head as to why in C++11 there was make_shared but no make_unique (although added later), but it kind of makes sense that is doesn't add quite as much, the only thing is the exception safety which to be honest I don't lose sleep over as much as the efficiency of these things in the common case compared with the exceptional cases. The provision of make_shared is far more valuable that adding make_unique from this point of view. And thinking about it even more, whist I do know that implementations are in fact doing this make_shared optimisation, another optimisation I'm not so sure about which can be done is that in the case make_shared is not used, that second dynamic memory allocation for the reference count / control block, could be deferred until time as there is a second reference. This practically makes the cost of shared_ptr equal to that of unique_ptr when they are used equivalently. You would obviously for semantic reasons choose appropriately, but I think there is little need to chose from a performance point of view.

So the main take away should be always use make_shared to construct your shared_ptrs when you can, there is no extra dynamic memory allocation, the cost is that of allocating a minimal bit of extra house keeping information together with your object (assuming your object is not of some trivial size like < 32 bytes, consider making a copy of the object instead when it is small, obviously consider your individual situation when evaluating if shared_ptr is right for you). For that second dynamic memory allocation when it is needed, I have imagined there could possibly be schemes in which it is possible to do away with it with a more complex strategy. The idea I had was something like a doubly linked list between active shared_ptr objects to a shared object. As a shared_ptr object goes out of scope, it removes itself from the doubly linked list, patching the other ones to keep it all chained together. The last one removed will know it is because it's prev and next pointers will become null. I'm not sure if anyone has implemented a reference counting scheme doing this. It obviously gets more complex when dealing with weak and strong references, and also it much more maintenance work making this more complex and more likely to break and also isn't so nice from a memory access pattern point of view, jumping about too much.

Final

The next thing I learnt recently is the keyword in C++11 'final'. It is possible similar to in Java to be able to mark implementations of interfaces as final. You can do this on the class or on a specific virtual member function. What the semantics of this means is that you can not override it further in the inheritance hierarchy. When a class is marked final, it can not be inherited from, and when a member function is marked final, a subclass can not override it. This is great from a semantics point of view, you can protect an implementation from being overridden as you are marking it as intended to be the final and last in that chain of inheritance, this lets you write it in a way that you don't need to design for unintended uses. But really the thing that makes me interested about final isn't so much being able to express some kind of semantic intent in your implementation, whilst that is important and cool, what I like is that it allows the compiler to do some things to make the code more efficient, and that is actually how I came across this, I theorised that when you have virtual functions and a vtable, you wouldn't need to do a virtual dispatch if you had knowledge that in the context of the pointer you have and the function being called that it wasn't further derived. And from this realisation that I thought that a final keyword actually would mean that you could make things more efficient that I searched about this and found that not only did C++11 add this, that in fact from more research that implementations are doing this optimisation already and avoid the virtual dispatch when final is used and your pointer is of the type where final was declared.

What does it mean from a practical point of view? Well it may change they way you might structure and write code involving virtuals. Firstly you will want to start decorating your classes with final. That is the first step. Next you will want to defer casting to a base pointer as late as possible, but also after you have done so, what you may then prefer to do after this if doing multiple dispatches with a given object, you might find that it will be faster to dynamically cast the object to the derived cast it is and do the multiple virtual calls with this pointer than to use the base pointer to speed up special fast path cases. I don't think you would have been able to as easily sped up a fast path like this without removing the general purpose virtual functions or without more intrusive changes.

String literals

Something that annoys me about C/C++ is that there is no distinction between literal objects and other objects in the types for them. For example take string literals, such as "blah" in the code, this is a string of bytes, 'b', 'l', 'a', 'h', 0 which is const, and exists in the statically initialised section of the program and exists for the duration of the execution. But generally its type is "const char *". If I new an array of chars, I'll get a "char *" which is readily convertible to a "const char *". This is mutable. It exists only as long as I say it exists. It is quite a different beast to a string literal. What I really want is to be able to provide APIs which can distinguish between these and do something different depending on how it was called, either with an immutable string literal or with a mutable array or chars. Sometimes you want to know that it is a string literal so you don't need to make a copy so can make an optimisation. Other times it can be for better security so you have tighter control over what and where something can be passed in to a function.

So how can it be done. It can be done using templates, the only downside is that generally this will expose the implementation to the header, although this could just be used as a shim.

For example:

template <size_t N>
void DoSomethingWithLiteral(const char (&a_str)[N])
{
// a_str is a string literal
}

Basically that is it. A function that looks like that will only accept string literals. Beware that providing other functions with the same name that the overloading doesn't resolve to the call with a string literal ending up going to the overload instead of the intended one. Obviously always test, and then more template magic can be used to disambiguate the calls, that is doable now.

A few more things about string literals.

String literal operators. New in C++11 is user defined literal operator overloads. This is neat and basically allows for defining units to scalar values in a natural way. In English when talking about values in certain units, the way it is expressed is such as 50kmh, or 10kg, or 5s or 10days etc. The pattern is a scalar value (e.g. integer value) followed by a suffix which is an abbreviation for the units. So in traditional C++ the typical way would be to make a type, for example a type called kilograms or kg, e.g.: class kg {}; and you could make a constructor that took an int (or float) so then you could express it something like: kg(50); And could do "kg(50) + kg(10);" etc. And could provide conversion operators to convert from the type kg to the type g so you could do "kg(1) + g(500)" etc. But this is not so natural. a literal operator essentially lets you define a conversion operator from int to your type but expressed like 1kg or 500g, so you can write instead "1kg + 500g". It kind of reminds me a bit of python how you can express things like: "some string".split() where you can call methods on literals. And in C++ it is also not limited to ints, you can do this for string literals too, so could convert a string literal to a std::string for example with something like "blah"_s.

One more thing about string literals.

I wrote about logging not long ago here: Avoiding heap allocation with strings

Something I realise that I didn't mention is that you can forward the arguments using templates better than what I demonstrated. The use of va_list isn't needed if you pass via templates. Obviously though the issue with that is then you need to expose everything in the header file, so the demonstrated method is fine if you want to hide the implementation details.

Here is a slightly improved way:

template <size_t N, typename ...Ts>

void Logger(enum LogLevel a_level, const char (&a_fmt)[N], Ts&& ...a_args)

{

  size_t msgSiz = std::snprintf(nullptr, 0, a_fmt, a_args...) + 1;

  char msg[msgSiz];

  ::snprintf(msg, msgSiz, a_fmt, a_args...);

...

}

You'll notice it is slightly less lines of code than the original. It perfectly forwards the arguments, and does so without all the fuss of using va_lists. Also another subtle change is the way in which a_fmt is passed in. Instead of being passed as a const char*, it is passed and preserved as a string literal. This has some benefits, security and efficiency. First is the compiler at compile time can make checks as to the arguments match with the format provided, it also forces the a_fmt that is passed to be a string literal so there is no possibility that at runtime a maliciously formed a_fmt string will be passed to this.

It may not be appropriate in the above case, but in some cases it is possible to forward declare a template without providing the body in the header and declaring the body of the template in the source file. In the above case there are too many varying parameters to the template to be able to instantiate all the required uses of it in a single cpp file. But there are cases where templates can be used where it is reasonable that each expansion of the template for each type can be anticipated and hidden but provided in a cpp file. This is generally preferable if it can be done, which leads to the next thing I learnt recently which is a good things to know.

Headers and forward declarations

I was reading "Effective C++" by Scott Meyers, the books are over 20 years old, but there is still value to be gained from them. Obviously some advice is dated and a reading of any older text book needs to be made in context, but sometimes there are things you just didn't realised and somehow missed, in fact it seems a lot of people have missed this particular point which I will elaborate on, as I have rarely seen this practised if ever.

It involves the forward declaration of types, and then defining functions in terms of them not just by pointer or reference, but also by value.

The example from the book goes something like this:

#pragma once // Perhaps another blog post about using pragma once ?
#ifndef BIRTHDAY_H
#define BIRTHDAY_H

class Date; // this is the forward declaration

Date getMyBirthday(); // return the date of my birthday
void setMyBirthday(Date a_date); // set the date of my birthday

#endif // BIRTHDAY_H

I didn't realise this was possible, but I tried it and it is indeed possible. I don't know why, but I thought that you would at least need to make the Date used in the function prototypes need to be references or pointers when you don't yet know the details of what the Date class is. But this is great that this actually works.

It works if you think about it, because you only need to know the details of what Date is when you go to implement those functions or when you go to call those functions, so you can defer inclusion of date.h until that time rather than forcing it in to the header.

I think that was my confusion, if not including date.h inside birthday.h, then I could neither implement birthday.cpp nor make use of the functions in birthday.h that depended on Date (say e.g. in main.cpp for sake of simplicity), and logically assumed that the fix was to include date.h inside of birthday.h. But that is the fallacy. That actually isn't the fix you are looking for. The fix you really want is to include date.h in both birthday.cpp and main.cpp. This seems to contravene the DRY principle (don't repeat yourself). But it is really what is better. As much as possible, you want to not include headers in your headers, it only leads to more headers being included and so on which leads to longer compile times. This chain of headers including headers means that 1000s of function prototypes are pulled in, when in fact in a given cpp file, it may only use 100s or less of external functions to itself. Being more explicit inside the cpp files of what is included is preferable to implicitly including much more from headers including other headers.

I think this is something I am going to try to adopt more if I can.

Some gotchas and possible solutions. Where you do need to know the details of an object and its size is when you use it as a member variable. e.g.:

class Date;
class Birthday {
public:
int dayOfMonth();
int month();
private:
Date date;
... other members
};

Now this won't work. You can't figure out the sizeof(Birthday) without knowing the sizeof(Date). You can't do "new Birthday". I'm pretty sure this won't compile as is.

If you really don't want to include date.h or if Date was a bit more of a heavy weight object, a workaround would be to wrap it in a shared_ptr or unique_ptr, and this goes back to one of the original points in this blog about the efficiency of such.

Anyway, possibly exposing all the private member variables in a class is not great if you can avoid it, and if you do go the route of wrapping in unqiue_ptr or shared_ptr any of the members, why not then combine all the private members together in to a struct and wrap that entire struct in a smart pointer. This is essentially what is called a pimpl. Once you do that, you can hide all of that implementation detail in the cpp file. It looks like this in the header:

#pragma once

class Birthday {
public:
int dayOfMonth();
int month();
private:
struct Pimpl;
std::shared_ptr<Pimpl>;
};

In the cpp file you can then do what ever you like:

#include "Birthday.h"

struct Birthday::Pimpl
{
// put anything you like in here
// change it as often and as much as you like
};

Make sure the Birthday constructor (not shown) uses make_shared for efficiency!

I might write more in another blog about this pattern of pimpl in a shared_ptr.

Array of Structures and Structures of Arrays

2017-06-07T04:43:00.001-07:00

It can be time consuming and painful to recode data structures in a program to better improve efficiency by optimising the data layout to group data together which will be accessed together.

The goal is to improve cache utilisation. You don't want to iterate an array of structures where you are only accessing some of the members of each item. Say each item in the array is a struct of 32 bytes in size, but we only access 4 bytes of each one as we loop. We have loaded up our cache lines with loads of data we aren't even going to touch resulting in sub-optimal efficiency. An alternative approach in this scenario is to re-arrange the data in to a structure holding arrays for each member. When accessing the one member at a time when iterating, the cache will be used more efficiently as the cache lines will be filled up with only the data we are accessing. Alternatively re-writing the code to work on each item as a whole at a time might be an option, but it also might not be possible or be sub-optimal.

Conversely if the data is arranged as structures of arrays and when iterating multiple members are accessed at the same time, there might be related problems, but it is less likely. You still may want to try both approaches to see what works best for given data structures and their access patterns.

But it's not trivial in C/C++ to rearrange the data like this without having to re-write any code which deals with this data. You can't simply flick a switch and the compiler automagically figures out how to re-arrange the code generation to access the data in the alternative layout. Being able to do that would be pretty cool. Jonathan Blow claims in his Jai programming language to have the ability to do just that. Currently Jai isn't released so all we know is from presentations of this language, but it appears to work by decorating the declaration of the array with something which says how it will be laid out and the language generates the appropriate code without the programmer needing to change the code which is accessing it.

Now I would like to be able to do something similar in C/C++, so I had a bit of a think about it and have come up with this basic idea on how it might be possible to achieve something that comes close. Unfortunately to make it work requires some macros and templates, but nothing too fancy.

Here is the basic idea we want to arrive at:

template <size_t SIZE>

struct SomeStructure

{

  int     m_someMember[SIZE];

  float  m_someOtherMember[SIZE];

  // you could put anything in here, just each one needs to have "[SIZE]" added to the end

};

Then we can create arrays either way like this:

// As an array of structures

SomeStructure<1> AoS_array[1000];

// As a structure of arrays

SomeStructure<1000> SoA_array[1];

When we want to access them we do one of these:

int x = AoS_array[n].m_someMember[0];

int x = SoA_array[0].m_someMember[n];

Notice we need to swap the indexes. But we can do that easily with a macro if we know which type of array it is. One simple way I came up with was making a macro for when declaring an array which also sets a const bool which the accessing macro can use.

So here are the macros:

#define DECLARE_STRUCT_BEGIN(StructName) \

  template  \

  struct StructName \

{

#define MEMBER(t, name) \

    t name[SIZE];

#define DECLARE_STRUCT_END(StructName) \

};

#define MAKE_AOS(array, S, SIZE) \

     S<1> array[SIZE]; \

     const bool array##_isSOA = false;

#define MAKE_SOA(array, S, SIZE) \

     S array[1]; \

     const bool array##_isSOA = true;

#define GET(array, a, n) \

     ((array##_isSOA) ? array[0].a[n] : array[n].a[0])

Probably this could be tweaked and improved, but it gets the idea across as to how it could be possible. I think it is fairly self explanatory.

Usage example:

DECLARE_STRUCT_BEGIN(S)

  MEMBER(int, a)

  MEMBER(int, b)

  MEMBER(int, c)

DECLARE_STRUCT_END(S)

MAKE_AOS(array1, S, 100)

MAKE_SOA(array3, S, 100)

void test()

{

  MAKE_AOS(array2, S, 100)

  for (int i = 0; i < 100; i++)

{

    GET(array1, a, i) = i;

    GET(array2, a, i) = i;

    GET(array3, a, i) = i;

}

}

I think I may be able to improve on this with templates instead of macros to to make the syntax more appealing, but just having something that works is a start and makes it a synch to switch the data structures to and from AoS to SoA to try out different layouts without mammoth amounts of work.

Also referring to my other post about serialisation and de-serialization (http://inspired-code.blogspot.com.au/p/automating-object-serializationdeserial.html) you could work the macros together where I presented a DECLARE_CLASS and DECLARE_MEMBER macro to automagically generate the code for serialising and de-serializing a structure, it shouldn't be too hard to combine the macros to combine the two ideas of declaring a structure/class that generates the serialisation and deserialisation and also is easy to switch from SoA to AoS. That is another improvement direction that this could be taken.

Along the lines of using templates to reduce the use of macros, possibly this is one direction to take it to do the declaring of an SOA or AOS and the consistent accessing in to either without relying on the preprocessor:

template <typename T>

struct ArrayAccessor

{

  explicit ArrayAccessor(std::functionsize_t)> func) : m_getter(func) {}

  inline T& operator[](std::size_t idx) {

    return m_getter(idx);

}

  std::functionsize_t)> m_getter;

};

template <template<size_t> class t, size_t SIZE>

struct SOA

{

  template <typename T>

  ArrayAccessor get(T (t::*memberPtr)[SIZE]) {

    return ArrayAccessor([&](size_t idx)->T& { return (m_array[0].*memberPtr)[idx]; });

}

  t m_array[1];

};

template <template<size_t> class t, size_t SIZE>

struct AOS

{

  template <typename T>

  ArrayAccessor get(T (t<1>::*memberPtr)[1]) {

    return ArrayAccessor([&](size_t idx)->T& { return (m_array[idx].*memberPtr)[0]; });

}

  t<1> m_array[SIZE];

};

Then to declare an array as SOA or AOS you would do:

SOA<S,1000> array4;

AOS<S,1000> array5;

Access can be made to be the same:

#define ARRAY_MEMBER(array, member) \

    array.get(&std::remove_reference0])>::type::member)

Usage:

    ARRAY_MEMBER(array4, a)[i] = i;

    ARRAY_MEMBER(array5, a)[i] = i;

Ideally the templates could work out the type without needing so much typing or macros, but that is left as an exercise for the reader.

Avoiding heap allocation with strings

2017-05-30T06:59:00.001-07:00

I was wanting to debug my memory allocations and hit a problem. The logging code that prints out useful information to help debug and trace the program is itself allocating memory. This is particularly pronounced with the string manipulations it does and with creating formatted strings from a variable list of arguments.

It got me thinking. Firstly when one has a std::string object, particularly if that object itself was on the stack, it still allocates off the heap, it is too bad there is no way to allocate off the stack as the lifetime of the object is on the stack anyway. This is just how it is in C/C++. You can sort of do variable sized allocations off the stack, such as alloca or a variable sized array, such as:

size_t var = i * 10;
char array[var];

Depending on the compiler, that can work. But anyway, this is no good for a general kind of string class as the lifetime of this is the scope it is created in so won't persist when the function returns. The same applies for alloca.

But I really want to solve this and completely avoid making heap allocations while logging. The main culprit is formatting a string from a format argument and a variable list of arguments.

So the first thing to do is work out the required size for this variable sized array to format in to.

void Logger(enum LogLevel a_level, const char* a_fmt, va_list a_args)

{

  va_list args2;

  va_copy(args2, a_args);

  size_t msgSiz = std::vsnprintf(nullptr, 0, a_fmt, a_args) + 1;

  char msg[msgSiz];

  ::vsnprintf(msg, msgSiz, a_fmt, args2);

  va_end(args2);

...
}

Now msg contains the formatted string and without using the heap. The only tricky thing is having to make a copy of the va_list because it gets consumed in the first call to vsnprintf and we need a fresh copy to pass to the 2nd call to it we make.

That wasn't too hard :)

Reflection in C++

2016-03-24T07:10:00.001-07:00

Topics: C++, Serialization, Reflection, Templates, JSON, Visitor pattern

I've posted a new article here titled "Automating Object Serialization/De-serialization in C++":

http://inspired-code.blogspot.com.au/p/automating-object-serializationdeserial.html

Overview

Some languages support reflection better than others. C++ has its runtime type information system which is reasonably limited. It won't help you much if you are doing serialization and de-serialization, so you end up writing a lot of boiler-plate code which feels like you are repeating yourself a lot.

Serialization though is just one example. In the article I give a bit of a run down on some of the alternatives and present a solution which reduces how much you have to repeat yourself.
In the end, this is an example of all you should end up needing to write to define and declare a struct with members and the code needed for being able to serialize/de-serialize it:

    DECLARE_CLASS(Color)
       DECLARE_MEMBER(int, red)
       DECLARE_MEMBER(int, green)
       DECLARE_MEMBER(int, blue)
    END_DECLARE_CLASS

That is it. No duplicated info anywhere. I show how this isn't locked in to just serializing/de serializing too, and give examples of hashing and other uses. In follow up articles, I can elaborate on some of those other uses and the details of those.

Full article here:

http://inspired-code.blogspot.com.au/p/automating-object-serializationdeserial.html

Using C++ Template Meta-Programming to expose C functions in Lua

2016-03-21T04:41:00.001-07:00

I've written an article on auto-magical language bindings, which you can find here: http://inspired-code.blogspot.com/p/automagical-language-bindings-using-c.html

The specifics of the article shows how to expose C functions to lua.

The summary is, all you need to do to expose a function is add it to the list of exposed functions wrapped with the macro AUTO_BIND_C_FUNTION_TO_LUA such as in the following code snippet:

// Some function prototypes to expose
void someFunc(int arg1, int arg2, const char* arg3);
void anotherFunc(const char* arg1, double arg2, int arg2);
// ... etc ...

// Import table
static const struct luaL_Reg scriptCallableFunctions[] =
{
  AUTO_BIND_C_FUNTION_TO_LUA(someFunc)
  AUTO_BIND_C_FUNTION_TO_LUA(anotherFunc)
  // ... etc ...
};

// Register all the functions we want wrapped
void registerLuaBindings(lua_State* L)
{
  // Register all of our bindings
  for (luaL_Reg r : scriptCallableFunctions) {
    lua_pushcclosure(L, r.func, 0);
    lua_setglobal(L, r.name);
  }
}

That certainly simplifies the work of exposing a function to Lua. I believe the approach could be adapted relatively easily for possibly other languages, such as python also.

Hope you like it.

Idiomatic way in C++ to test debug/release etc

2016-03-20T05:26:00.000-07:00

Idiomatic way in C++ to test debug/release etc.

This is just a quick post on how one can improve their code by removing some #ifdefs and doing things a better way.

It is common to see this style of code:

void SomeFunction(int x)
{
      ...
#ifndef NDEBUG    // Double negative - if ! ! debug - eg: is debug
      ...
      // extra debug checks
      ...
#else
      ...
#endif
      ...
}

Usually NDEBUG is the define that is checked for release/debug checking as it is defined in the C standard in regards to assert.h. I don't know of any other defines the language specifies in relation to release/debug modes. So typically release builds will have NDEBUG defined, and non-release builds do not.

However using preprocessor checks is not very idiomatic C++. It also means the preprocessor hides part of the code from the compiler, skipping important compiler checks of the other half of the code, which means that if not regularly compiling all the permutations of defines that some sides of #if conditions can rot and then require additional maintenance when enabling them. Better is to have the compiler parse both sides and allow it to determine that one side of the branch is never taken and allow the compiler to eliminate it.

So what is a good way to formulate turning a define in to an idiomatic way to test this in C++?

One can do this in a header:

enum BuildType
{
#ifndef NDEBUG
 isRelease = 0,
 isDebug = 1
#else
 isDebug = 0,
 isRelease = 1
#endif
};

And then in code check the condition like this:

void SomeFunction(int x)
{
      ...
      if ( isDebug ) {
         ...
         // extra debug checks
         ...
      } else {
         ...
      }
      ...
}

Using an enum means that we don't need to create any variables to do this.

Obviously you can extrapolate this to testing for things besides debug/release. Also in the place where we declare the enum, if wanting to make it a runtime setting, instead of compile time setting, it becomes quite trivial to change that.
Where this doesn't work so well is if using #ifdef to choose between two options that will either work or not depending on the compiler or target platform, eg if one side is iOS code and the other Win32 code, obviously it may not be worth making the compiler able to accept both sides of the #if/#else. I believe in these cases where you have platform specific code, generally you want to hide that from the generic code and abstract the platform code and put platform specific implementations in their own separate files.

Hiring Staff

2011-09-06T03:50:00.000-07:00

There is a subtle or perhaps not so subtle distinction between "hiring staff / adding people" and "building a team".

I'm sure this doesn't just apply to software development teams but a broad range of areas. I guess you can just get a bunch of brilliant people and throw them together and hope for the best. You might get lucky. What I'm about to say I think many people should get if they have experienced working in a few different teams, so this blog is just for those that aren't quite up to speed with the distinction between "building a team" and "adding some new staff".

If you think about winning sports teams, it's not entirely a sum of the talent of each individual of the team that determines the result (in team oriented sports), but rather the way they work together as a team combined with what talents they bring in combination. In all A-league teams, I'm not saying the players can be B or C grade players and the team can win, the players do need to be top class, but might not all be the best within that class if they work harmoniously with the group as a whole to bring about a win.

The criteria for hiring someone should include their ability to do the job they are hired to do. That much should be obvious. But when selecting between candidates that can fulfill the basic requirements, I believe one should look to the candidate's ability to blend and complement the existing team and to compare that between the candidates. (hopefully with any luck you will have more than one candidate that fulfills the basic requirements of doing the job).

So how to test or evaluate the ability for the candidate to blend? Simply invite them to join in on a team activity. If the team has lunch together, invite them along to lunch. Ask them to sit in on a team meeting, or perhaps on Friday evenings the team gather for snacks and chatting before heading home, perhaps time the interview at a time to precede such an activity and ask if they mind staying for that if you feel the candidate is someone potentially worth hiring.

The idea is to disarm the candidate to feel relaxed enough to reveal more of the real them. Interviews are usually quite artificial situations. The idea is to step out from that and observe the way the candidate interacts with others in a more natural/genuine environment/situation. Then it will be possible to also ask the existing team what they think about the potential new person at a later time.

I can hear some saying/thinking "but we don't have any activity like that, what do we do, everyone has lunch separately and goes home early on a Friday evening". To which I would say that it doesn't sound like much of a team environment. Sounds like there are bigger problems to resolve before adding more people in to the mix. Perhaps adding staff is trying to solve the problem of poor efficiency with more hands on deck however often adding people causes initial inefficiencies and diminishing returns as the number of interacting staff increases. New trainees drag down the existing team with questions and effort getting them up to speed. Adjusting to a new team dynamic which is upset with the changing of staff is another factor. And there is a diminishing return as the amount of communication exponentially increases with the numbers of staff interacting.

Just to simply make the point if it is not clear, if it wasn't so, any project with say 5 people that takes 12 months if there was no diminishing return on more people on the project would take 10 people 6 months, 20 people 3 months, 40 people 1.5 months, 120 people 2 weeks, 240 people 1 week, 1280 people 1 day, etc. Unfortunately reality doesn't work that way, communication and coordinating over 1000 people to come together and do some task on a given day and divide the task up so the 1000 people don't spend as much time communicating with the 999 other people to ensure they do the right 0.1% of the task will take more than a day. Probably much more than a day just figuring all that out. And that's assuming a task that can be divided in to 1000 non-dependent little bits which is rarely if ever the case.

Building a team also involves getting the team to do stuff together. Perhaps in some work environments it is not necessary to have a team, it really is just a set of individual efforts. I can't really think of any real concrete examples where a company is formed and contains a set of non-cooperating individuals. It's kind of not really a company, if everyone's job is unrelated to each others, then surely they don't require being a member of a company and could each operate as individuals, eg as sole proprietors. However that sounds rather lonely. Having positive social interactions is an important aspect of a job and working with others and getting stuff done.

So what it comes down to is getting stuff done, and getting it done efficiently. When the team is working well together like a well oiled machine, stuff gets done, it's enjoyable and a positive environment. When there isn't any cohesion in the team, no one gets along, interactions are negative, it greatly impacts on getting stuff done. That is the bottom line.

Usually the idea of adding more staff is to get more stuff done. If you are in agreement with that statement then I hope I can finish here for you. Sometimes it's to build an empire for the aggrandizement of someone with ego issues in which case I guess the idea of "building a team" must seem like a strange concept when the idea of "adding staff" fulfills faster the aim of building an empire. If this is you, keep reading. Even empires can crumble, particularly when there is rebellion. You still need relatively happy workers to build an empire. I do think most people prefer being in situations with positive social interactions over negative ones or over having a lack of human interaction for prolonged periods so I think most people want to belong to a productive working team, rather than simply a minion for the aggrandizement of an ego maniac running around pretending to look busy. Even if empire building, you need to create a cohesive group, infuse culture, create positive attitudes, promote a rewarding and productive environment all to keep the empire from rebellion.

Good practise in use of source code control

2010-11-26T14:25:00.000-08:00

Generated files

Never check-in generated files, period. I mean it. I hope by the end of the article you will be convinced too. Really there should never be a need for revisioning of a generated file. You are doing it all wrong if you think you need to. It means you don't understand what SOURCE CODE control is, I'll spell it out, it is for SOURCE material. I'm not saying you can't save those generated files somewhere for later use (ie a file server that has backups), but they shouldn't need revision control because it is not logical to have different versions of something that was generated from source material unless there is a change or different version of the corresponding source material or scripts used to generate it. A source code control or revisioning system is not a backup system, don't abuse it for this. More on this later.

The source material needs versioning. Sure, if you recompile the same code 20 times you could get 20 different binaries if you do a binary diff, things like the date and time can work their way in to the binary, as too can the path from which the code was compiled depending on the compiler and flags. Which OS, compiler, version and flags was used will all have an effect. But really the scripts and makefiles used to control the compiling of the source code should be under source code control. The generated file that you were going to checkin really should be replaced with a script or equivalent that will check the pre-conditions and then run the precise commands with the precise flags that will result in that generated file being created. It should be reproducible, so there should be no need to check that generated file in. If it is not then you are doing something wrong. It might mean there is too much magic involved to reproduce compiling that code properly. That is a problem, it's a symptom that you might be doing something wrong. It might be someone wants to exercise some control over other developers or prevent others from compiling their code such that they must use their generated binaries that are checked in instead of everyone compiling from source. This means something is wrong.

Either the code is fragile, brittle and breaks easily or someone is trying to hide something or trying to protect their job or some combination of these.

It's not the way it should be. The code will only get better with more people compiling it and trying it with different compilers and different flags. Any code that needs a specific compiler on a particular persons computer compiled in some specific way with the magic scripts only on their computer or that only work on one persons computer setup or with some tool with restrictive licensing sounds like some funky shit that smells like something is off and you want to stay away from it because it will be a liability to you and your company. If the code you work on gets a dependency to such code, you'll be making yourself reliant on someone else, you will be giving them more power, feeding the beast. Work around the dependency, find alternatives, or try to work out the magic, ask to watch it get built. One does need to be pragmatic too, sometimes there might be no way around using critical 3rd party libraries. Obviously some stuff like Win32 API DLL dependencies can't be avoided on the windows platform, but there is a reasonable assumption MS and the DLLs won't disappear suddenly and there are alternatives like WINE that if MS went bust or decided to go 64bit only, there are fallbacks. Another strategy is design the code to be cross-platform in the beginning so no dependency on any particular OS or OS vendor. That's part of the problem of checking in generated binary files without a means to re-generate them, it limits the OS, toolchain, flags etc to just the set for which binaries were made available. Going cross-platform removes dependencies and gets developers in the mind-set of thinking about their dependencies. It's too bad that too often dependencies are only given thought after the fact when some code that works on one platform suddenly has a need to also work on other platforms. All those dependencies become painfully obvious. Digging around for a developer's old computer that worked at the company 5 years ago for his special tool he wrote in .NET that did some funky code generation for which the code to the tool wasn't checked in, only the generated code was, sounds like no one thought about the right source code control disciplines back then but now it is being paid for.

Merge vs exclusive check-out

Exclusive check-out model doesn't work. one user is working on something and needs other person to finish with their lock on the file. If in the office, they can just ask the person to check it in, but if that person is away, they might be stuck until they check-in their work, or they continue working in some compromised way. It just doesn't scale. Logically thinking about it and imagining if the locking was more granular down to function level or line level, one may be able to see some of the problems with the model, some concurrent changes between versions at the line or function level between users can create a non-working build. One really needs to check that the combination of changes, including the latest changes they have made and others have made, will work in combination. The exclusive check-out model doesn't magically solve that, it doesn't prevent incompatible changes happening concurrently to different files. I might remove all calls to a functions in all the code and then prepare to do the final step of removing the implementation of that function from the .h and .c files while simultaneously somewhere in the code (could be any file in the project) someone checks-in a change to call that function. The only way to prevent this is to check-out every file in the project and also lock other users from adding any files so they can't add a call to the function I am about to remove. Obviously one still needs to test the combination of the changes and correct for such types of problems when files are checked-in simultaneously. This really is a merge of sorts, but the granularity is different and the conflict is harder to detect, it's not really detected by the versioning software at all, its something that gets found by testing the latest code from the repository by compiling it and running it. Nothing substitutes testing, the versioning software can not solve incompatible changes. No, the real solution is to mark versions as working, merge in sets of changes, test the merged results, version it etc. And really the best is when the testing can be automated, but that is not always possible. There really is no merge free solution when you understand that every change needs to be checked it is compatible with all previous changes, irrespective of if it is in the same file or from a different file to one that has recently changed.

Exclusive check-out is really annoying too when also checking in generated files. That has to be the worst possible thing to do. When recompiling or doing anything that causes the generated files to change, the compile can fail because it can't overwrite the read-only generated file, or it automatically checks it out which blocks others compiling. It just causes all kinds of blocking or further bad practices with kludging the file permissions. It is just horrible.

Working with checked in generated files instead of generating them when the source is available is bad. It's worse when the source was available and someone takes it out of the repository to prevent others compiling it and just leaving the binaries and headers there to link with. How do people seriously think that is progress?

Particularly if they are compiled with one version of the toolchain, like VS9, it then forces everyone to switch to VC9 and can't do VC6 builds anymore even if there is some need to do so. Code would be better if it is compiled and tested with more toolchains. It stops compiling the code in other configurations, eg with flags for MBCS or UNICODE etc particularly if the API is not well written, it then can force the calling code that links with the checked in binary that was compiled in a particular way to also have to be compiled in the same way to be compatible with how the API was defined and the mangled types in the function symbols of the binary to get correct linkage with it. It then sucks more when other binaries are checked in that were compiled in incompatible ways also with similar braindead APIs. It may prevent the 2 libraries being used together with one application.

While the root of the problem is not just the use of the source code control system, it would be have been possible to generate the binaries as required in the correct form if the generated binaries weren't checked-in and things would be much nicer, one could make different versions of the binaries that one requires rather than being told how the binary should be generated with it in some fixed forms.

The term "source code control" is bad. It uses the word "control", which is I guess is how some people use it. But i think that's part of the problem.

People use it as a tool of power and control. It shouldn't be a restrictive system to inhibit changes or access. The real problem that needs solving is the one of versioning, what is needed is being able to mark versions of the software and to manage concurrent versions, merge them, branch etc.

Not a centralized control system. Of course with decentralized systems, there is the question of backups. And source code control/versioning systems are that, not backup systems.

Backup-proxy

Please stop using the repository as a backup system. Perhaps that is why there are all the generated files checked in? Maybe that is why the server is grinding to a halt and can't handle the load of the repository? Maintaining file histories of big binary files that change nearly completely each version is not really what source code control or versioning systems are designed to handle. Smart ones detect binary files and store them differently, but can seriously bloat the store. Normally version control systems store a series of diffs, either forward or backward or both. So there might be the earliest and latest version of the file stored, and a set of differences that you can apply to get to any other version of that file. That works great for most text based files, but falls apart completely for binary files. In the case of binary files which are usually lots bigger to begin with, the repository generally needs to store a complete copy of every version of that file. Rarely it makes much sense to do a diff between 2 big binary files. Most of the time when checking out the generated files, we would be interested in the latest version of the generated file if we were at all interested in checking out generated files.

VirtualMachines

Using a VirtualMachine is not an excuse to avoid using source code control. Don't just make backups of the virtual machine to a multi-spanning DVD collection.
Try to make the steps to setup the virtual machine repeatable or document it. VMWare and VirtualBox are scriptable, please check out the commandline commands.
When setting up the virtual machine, try to do that with scripts that can be version controlled.
Any files created and being edited inside the virtual machine are likely candidates to be version controlled too.
Preferably use a version control system that is cross-platfom supporting the host and client OSes of the VirtualMachine, but failing that, most

VirtualMachine applications and client OSes have means to share folders with the host OS which would made it possible to use the versioning control software from the host to version control the files being edited in the VM. Don't be lazy, using a VirtualMachine is not an excuse or easy way out, far from it, doing it right is hard work.

Best practice
1) never check-in anything generated. Make the steps to generate the output automated and as reproducible as possible
2) never modify generated files unless done via an automated process
3) do check-in the scripts and files that are part of the automated processes for generating the output
4) do check-in and automate anything related to setting up the assumed environment, other than what might be the companies standard developer machine setup, under which development happens
5) before check-in/commit changes, check-out the latest and merge changes, test, then repeat, then check-in when ready
6) don't use the repository as a backup location (find alternative and more direct means of doing backups, eg if save binary builds of past version, send them to a network drive in dated folders that will get backed up, not use the repo as a backup proxy, it's not designed for that)
7) do ensure there are backups of the source code control system, preferably there are backups of the repo stored off-site

Artifacts of Good Code

2010-11-23T09:44:00.000-08:00

An artifact is defined by one meaning as "any feature that is not naturally present but is a product of an extrinsic agent, method, or the like...". I'm interested in the method of coding. When coding, the obvious output or product is the code itself. But I want to talk about some of the other products of good coding.

If the code compiles, the binary output. The compiler messages during compilation. But these are products of compiling, not so much coding.

When you see good code you often know it. It looks inviting. It draws you in and lets you play with it.

The kind of characteristics or products of good coding I want to talk about are what you often see when you find good code, they are correlated but I am not claiming or trying to prove causality. They are indicators. Think of it like trying to judge the appearance of the inside of someone's house by looking at their yard. Well trimmed plants, neat lawn, no weeds.

So what kind of things might be in the yard of a piece of code. Some obvious things are documentation, test cases, a specification and/or requirements and/or user stories, bug tracking, use of a source code versioning system etc. Not all code has any or all of these things, but my observation is that more mature code tends to have most of these things.

Lets look at why. A number of these artifacts are to facilitate more than one person working on the code. They are a sign that the code wasn't developed by a single developer. More heads are better than one. It's immediately a good sign that the code hasn't been just looked at by one person, several people working on it means some review from different perspectives. It's like a house with a single occupant vs a share house.

Anyway we were talking about code. If the code is occupied by a few coders, some things probably will happen. Firstly some kind of source code versioning system if it isn't already being used will be introduced. It's quite hard without such systems for several people to work on the same code at the same time and expect anything to work without some kind of versioning system to mark a working version and way to combine the contributions of the coders to make and mark newer versions. Even if one person was writing the code alone, marking working versions and being able to go backwards and forwards between versions of the code is very useful, but it becomes much more necessary when several people start working on it.

Often the next thing that happens when more and more people start working on the code and using it is the need for documentation. The original author knew what the function or module was meant to do and what its limitations might be by design, but if the code doesn't do what was meant or the original limitations are not sufficient or assumptions about the limitations were wrong, then without documentation its hard for others to work with or use that code. One can't change or fix a function without knowing properly what the function is intended to correctly do. That needs documenting so one can verify the implementation of the class/module/function does what is intended and the uses of it are using it as intended.

Functions shouldn't be so complicated that the intention of what they do is hard to describe, so good code tends to have nicely named functions/classes/modules too. Good code uses sensible descriptive but concise naming of functions and variables. It shows thought went in to the slicing of the program in to functions in a logical way. Hair-brained code is easy to spot, just take a sample of some of the function/class names and if you can't really guess from the name what it does, it's probably because it's a function or class that is ill defined and conceived and exists to factorize the code a certain way that isn't well aligned with any semantic meaning. Another sign of this is many functions with very similar names doing almost the same thing but with very minor variations (I mean besides operator overloading convenience functions to pass in different types). Having 10 different functions to query the same value but in different ways is a bad sign. It is probably the result of insufficient documentation because as more coders worked on something, the lack of documentation resulted in more functions added that did similar things because the original functions weren't documented about their intentions and resultantly became hard to modify and the uses of those functions were too fragile to changes in the function that new coders created new similar functions to avoid the fragility breaking everything. You can more confidently fix a broken implementation of a given API if you know what the intent is from the documentation, and then it is the callers that are broken if they depended on the broken implementation. Without good API documentation you can not make this judgement as easily.

Someone on a project like this (perhaps one of the original coders if they are still around) will eventually notice how brain-dead it is all becoming. Perhaps something happens that brings to a front that the code was not documented so there was no way to know how it should have behaved compared to how the function actually behaved. Then begins the task of documenting. It's always interesting watching coders forced to write documentation for old crufty code they didn't originally write. Okay, next someone introduces a policy about swear words in the documentation, and then down a road of policies. But the point is, documentation is a sign of good code because it signifies that someone at sometime has had to stop and think for a moment about, what does this function do, what might be the limitations, what are the inputs, what are the outputs. And they'll look at the function name and hopefully stop to consider the design of it.

It's okay to document what a function is intending to do, it's another thing altogether to actually check it does what it intends to. That's what testing does. Having test cases is how one does that. Without testing, there is no way to really know that something does as intended. Tests don't need to be automated, but automated is better for lots of cases. Unit tests can test at a fine grained level, but any testing and test case is a start and a good sign that someone is trying to check that something does what it's meant to do. If given code with no test cases, no sample input files, no examples, it's a sign that the code might not be tested to do what is intended for it to do. Having unit tests or various test cases is going to make it heaps easier for the coders to fix bugs and get the code doing what it's documented it should do, so it's a good sign that the code is or on it's way to doing what it is documented to do.

Requirements or user stories are a step up from checking the code is doing what was intended, they check what the intentions of the code should be. That might evolve (or devolve) over time, but so too should the user stories or requirements. They are a statement about what is the need for the software, what purpose will it fulfil, it gives the context and meaning to the software. It doesn't turn the code in to good code, but if the code doesn't have a context and meaning then the coders might be producing something that will have little value to anyone but maybe themselves.

So these are some of the obvious ways to identify that potentially some good coding might be going on making some good code. Obviously in a company setting it is possible for managers to require that "software engineers" must use/produce the above mentioned artifacts as standard (but then they are no longer really by-products of good coding, they have been made in to the products of the output of the workers). This is a kind of cargo cult way of doing things (google cargo cult is you haven't heard of this before). This is not the way to "inspired code". In later blogs I want to write about other signs that code is good, or even inspired, not just some cargo cult coding dressing it up to look like good code.