Home » Blog » Categories »

IncludeOS: A C++ Unikernel now free and open source

By Alfred Bratterud | Dec 2, 2015 10:40 AM | Tags: None

The IncludeOS unikernel prototype is now free and open source at GitHub. IncludeOS offers a portable way to run a compiled C++ service directly on virtual x86 hardware; either locally on your Mac or Windows machine with VirtualBox, or in large scale cloud environments running KVM.

#include <os> // literally.

From the home page:

Run your C++ code directly on virtual hardware

IncludeOS aims to be the thinnest, lightest possible layer, between your C++ code and virtual hardware. We provide a bootloader, standard libraries, lots (we hope) of modules, and the build- and deployment system. You provide the service.

IncludeOS is designed for KVM/Linux but previous versions have also been tested successfully on VirtualBox (which again runs on OS X Windows and Linux) and Bochs

It's a prototype -- be patient!

IncludeOS is not production ready -- but we're working hard to become so.

It's a research project

IncludeOS is the result of a research project at Oslo and Akershus University College of Applied Science (hioa.no)

A paper titled IncludeOS: a resource efficient unikernel for cloud services, which presents the first prototype, will appear at IEEE CloudCom 2015

Contributors

IncludeOS was created by @alfred-bratterud, with lots of contributions from @fwsgonzo and others at the NETSYS group at HiOA.

Efficient parameter pack indexing--Louis Dionne

By Adrien Hamelin | Nov 30, 2015 04:12 PM | Tags: c++11 advanced

And you, how do you index your parameter pack?

Efficient parameter pack indexing

by Louis Dionne

From the article:

Recently, I’ve been looking at ways to index into parameter packs with as little compile-time overhead as possible. This is not a new problem, and we know of several metaprogramming techniques to achieve this, some of which offer pretty good compile-times. Most of these techniques are also well documented, for example here and here. So, why write an article about this well-covered topic? Well, I recently decided to cheat and modified the compiler to see how fast we could possibly be. This article summarizes what I found.

C++ User Group Meetings in December

By Meeting C++ | Nov 30, 2015 04:40 AM | Tags: community

The monthly listing of upcoming C++ User Group Meetings on Meeting C++:

C++ User Group Meeting in December 2015

by Jens Weller

From the article:

The montly overview on C++ User Group meetings, this time for December. Meeting C++ is just a few days away, so I'm excited to see that again, so many groups are meeting. Also there are few new user groups worth mentioning! 2 x India (Delhi, Udaipur), Sydney, Beijing, Zürich, Sacramento and Ann Arbor! A new trend seems to be to form learning groups and meet weekly for a in depth C++ tutorial...

Quick Q: Why destructor disabling the generation of implicit move functions?

By Adrien Hamelin | Nov 27, 2015 01:45 AM | Tags: intermediate c++11

Quick A: Because it means that your class is handling a ressource, thus the compiler cannot know how to move.

Recently on SO:

Why destructor disabling the generation of implicit move functions?

"The Rule of Zero" is in fact about something else than what special member functions are generated and when. It is about a certain attitude to class design. It encourages you to answer a question:

Does my class manage resources?

If so, each resource should be moved to its dedicated class, so that your classes only manage resources (and do nothing else) or only accumulate other classes and/or perform same logical tasks (but do not manage resources).

It is a special case of a more general Single Responsibility Principle.

When you apply it, you will immediately see that for resource-managing classes you will have to define manually move constructor, move assignment and destructor (rarely will you need the copy operations). And for the non-resource classes, you do not need to (and in fact you probably shouldn't) declare any of: move ctor/assignment, copy ctor/assignment, destructor.

Hence the "zero" in the name: when you separate classes to resource-managing and others, in the "others" you need to provide zero special member functions (they will be correctly auto-generated.

There are rules in C++ what definition (of a special member function) inhibits what other definitions, but they only distract you from understanding the core of the Rule of Zero.

For more information, see:

Quick Q: const-reference qualified member function

By Adrien Hamelin | Nov 27, 2015 01:41 AM | Tags: c++11 advanced

Quick A: Delete the r-value reference overload of the function.

Recently on SO:

const-reference qualified member function

A temporary can be bound to a const& qualified object and the ref-qualifier effectively qualifies the implicitly passed object (*this). If you want to prevent calls on temporaries but allow lvalues, you can = delete the rvalue reference overload and implement the lvalue version. Using const qualified reference qualifiers for both operators requires just one implemented and one = deleted implementation:

class File {
    // ...
    FILE* _file;
public:
    operator FILE*() const&& = delete;
    operator FILE*() const& { return this->_file; }
    // ...
};

The net-effect is that you can use the conversion only for objects to which you go an lvalue:

int main() {
    File       f;
    File const cf{};

    FILE* fp = f;              // OK
    FILE* cfp = cf;            // OK
    FILE* tfp = File();        // ERROR: conversion is deleted
    FILE* mfp = std::move(cf); // ERROR: conversion is deleted 
}

Quick Q: std::timed_mutex::try_lock* fail spuriously

By Adrien Hamelin | Nov 25, 2015 01:15 AM | Tags: None

Quick A: it is authorized to do so for performance reasons.

Recently on SO:

Quick Q: std::timed_mutex::try_lock* fail spuriously

According to: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3209.htm

On the other hand, there are strong reasons to require that programs be written to tolerate spurious try_lock() failures:

  1. As pointed out in Boehm, Adve, "Foundations of the C++ Concurrency Memory Model", PLDI 08, enforcing sequential consistency for data-race-free programs without spurious try_lock() failures requires significantly stronger memory ordering for lock() operations on try_lock()-compatible mutex types. On some architectures that significantly increases the cost of uncontended mutex acquisitions. This cost appears to greatly outweigh any benefit from prohibiting spurious try_lock() failures.
  2. It allows a user-written try_lock() to fail if, for example, the implementation fails to acquire a low-level lock used to protect the mutex data structure. Or it allows such an operation to be written directly in terms of compare_exchange_weak.
  3. It ensures that client code remains correct when, for example, a debugging thread is introduced that occasionally acquires locks in order to be able to read consistent values from a data structure being checked or examined. Any code that obtains information from try_lock() failure would break with the introduction of another thread that purely locks and reads the data structure.

CppCast Episode 35: CppCon Wrapup with Jon Kalb

By robwirving | Nov 20, 2015 06:58 AM | Tags: None

Episode 35 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Jon Kalb to talk about this year's Cppcon, his trip to the Kona standards committee meeting and much more.

CppCast Episode 35: CppCon Wrapup with Jon Kalb

by Rob Irving and Jason Turner

About the interviewee:

Jon has been writing C++ for two and half decades and does onsite C++ training. He chairs the CppCon and C++Now conferences and the C++ Track for the Silicon Valley Code Camp. He serves as chair of the Boost Libraries Steering Committee and is a Microsoft MVP.

Overload resolution -- Andrzej KrzemieĊ„ski

By Marco Arena | Nov 19, 2015 09:51 AM | Tags: intermediate

An introduction to function template specialization, function (template) overloading, argument dependent lookup (ADL) and overload resolution:

Overload resolution

by Andrzej Krzemieński

From the article:

This post is an introduction to another one that I intend to write in the future...