POCO C++ Libraries are now available in biicode

The POCO C++ Libraries are, like their own web recites, “Modern, powerful open source C++ class libraries and frameworks for building network- and internet-based applications that run on desktop, server, mobile and embedded systems“. They were created by Günter Obiltschnig in 2004 and have been extended by enthusiastic C++ developers from all over the world.

POCO C++ Libraries working fine in biicode

Now, you have the following versions available in biicode:

Continue reading

Maximum clique for massive sparse graphs

In a previous post we introduced the maximum clique problem (MCP) and reported performance of the efficient bit-parallel exact solver BBMC, implemented with BITSCAN and GRAPH libraries available in the Biicode repositories pablodev/bitscan and pablodev/graph respectively. BBMC is concerned with small and middle size graphs.

Also very challenging are real networks that arise from different fields such as social networks, infrastructure networks, scientific networks and so on. These graphs tend to have many thousands—even millions— of nodes but are usually very sparse —the Network Data Repository hosts more than 500 of such graphs—.  An open problem is finding the clique number (the cardinality of a maximum clique) of such networks to get an insight into their structure. Unfortunately the problem is NP-hard and no polynomial algorithm is expected to be found; tailoring and exact solver for this task is as yet an open question [1].

BBMCSP is the new application of BITSCAN and GRAPH libs available in biicode to solve the maximum clique problem.

Continue reading

Boost libraries are now supported in biicode

As a C++ developer I love the Boost libraries. They are one of the highest quality and best suited C++ libraries in the world, with the spirit and design of being fully compatible with the standard library and its practices.

However, Boost is not easy to love. It’s shipped with tons of inter-dependencies, even circular dependencies, and that’s only for header-only libraries (thankfully 80% of Boost is header-only). For non header-only libs, it’s a true pain. You should compile those and then link against, being careful about what you are doing.
Even if setting up Boost manually could be a bit hard, when it works it’s a pleasure to develop with it.

At biicode we have been working hard to simplify the process, to make Boost available for any C++ programmer with just an include. But this is only the start, the project has been released as open source to allow everyone contribute and help.

I hope you like it.
Boost libraries are finally supported in biicode

Continue reading

Raspberry PI cross building native (C/C++) graphical applications from Windows

Developing and testing C and C++ applications for the Raspberry can be inconvenient because of slow builds, so it is usually far more interesting to be able to develop in your own box, then just do the final checks in the target platform, in this case the Raspberry PI.

raspberry pi ++

This article shows how to develop an OpenGL based application (using the GLFW library), that will be first built and run in the desktop, then cross-built to the RaspberryPI, using biicode hooks and toolchains features to easily automate the process.

Continue reading

Lessons learnt adapting CppMicroServices to biicode

This post summarizes the lessons learnt from adapting the CppMicroServices framework to a biicode compatible format. It does not go into detail about the actual modifications, but focuses on the lessons learnt adapting the framework.


CppMicroServices is an implementation of the OSGi framework, which enables runtime dependency injection. Modules of code (bundles) can be loaded and unloaded at runtime. In the case of CppMicroServices, bundles are either shipped in the form of shared libraries, or statically linked into the executable.


Based on packaging principles, bundles should be packaged and released separately – so that they can be depended on individually. biicode’s dependency management through blocks is suitable as a dependency management tool that supports this flow.

Continue reading

Solving the maximum clique problem with BITSCAN

The maximum clique problem (MCP) consists in finding in a graph a clique—i.e., a complete subgraph, one such all vertices are pairwise adjacent— of maximum cardinality.  The term *clique* has its roots in the social sciences; in a social network, a clique refers to a group of individuals who all know—or are linked together by some relation such as friendship— each other. The first algorithm for the MCP can be traced back to Harary & Ross in the late 50s. The first modern enumerative algorithm is most probably the one from Bron & Kerbosch in the early 70s.

A retweet network can become a maximum clique problem solvable with BITSCAN

Figure 1. A retweet network


Continue reading

OpenSSL is now available in biicode!

The OpenSSL Project is an implementation of the SSL and TLS protocols written in C. It has multiple cipher algorithms (AES, Blowfish, Camellia…), cryptographic hash functions (MD5, SHA-1, SHA-2…) and public-key cryptography support.
It was born in 1998 and today about 66% of internet servers are using OpenSSL.

Secure connections can now be used from C/C++ source code with biicode and OpenSSL


UPDATE! [10-Feb-2015] OpenSSL last version 1.0.2 is ready on biicode!  We created a block track lasote/openssl(v1.0.2).
Remeber, you can switch between v1.0.1 and v1.0.2 just changing the requirements line in biicode.conf file.

Continue reading

A Tiny Metaprogramming Library: Boxing – Part 1

A Tiny Metaprogramming Library episode 3:

Last time we introduced the mathematical concept of function as an entity that takes an input, generating an output. In that process, the function does not change any external state.

We also talked about metafunctions, a way to represent functions operating on C++ types using C++ templates.

After the theory, we followed with some conventions about the specific implementation of metafunctions in our tiny metaprogramming library. We decided that:

  • Any type with a type public member type is considered a metafunction, where type represents the result of that metafunction.That means to take the result of a metafunction we should say typename F::type in most of the situations. We introduced a simple tool tml::eval to help a bit.
  • Our metafunctions are templates, but these are constrained to take type parameters only.

In this post we will learn how to use boxing to pass value parameters as type parameters for our metafunctions. This is not something new but a way to understand what std::integral_constant, one of the fundamentals of <type_traits>, is and what can be used for.
Tiny Metaprogramming library episode 3: boxing.

Continue reading