Mini-update on flatbuffers-with-spirit

There’s not a whole lot of news about flatbuffers-with-spirit since the last time I blogged about it, but I’ve followed up on some todo-items:

  • I have filed a few bugs for CLion based on my experience;
  • I have restructured the project to move tests into a separate Biicode block from the implementation (so that now, for example, I can “publish” my implementation block and anyone else can depend on it via Biicode);
  • I have updated dependencies of the block so that Catch framework would be also downloaded from Biicode rather than being stored in repo as a header file;
  • I have updated the instructions on how to download and build the repo;
  • I have played with Boost.Karma to see if it will be a good fit for the task and set up a very simple generator.

Now I’m going to cover the new structure of the project in more detail and also summarize what I’ve learned.
Read the rest of this entry »

My wish-list for yet another programming language

I’ve collected my notes on various language features and tools that I wish were more common in modern “general-purpose” languages. Some of them are already available in some languages, some of them are wild ideas that I’m not sure will ever work… this is more like a brain-stormed list of things that address some of the pain-points of the development process in my experience. Let me know what you think! Which ones would you like to see in your language?

  1. Support the whole range of memory management techniques. Stack, heap, ref counted heap, GC-collected heap objects as “first-class” citizens: simple syntax for declaring, passing and returning each of them.
  2. Design for concurrency.
    1. Data should be immutable by default. Except maybe local stack variables can be mutable by default, since they can’t be shared directly.
    2. Need some more restrictions and verifications around passing mutable data around — it should either be protected by a mutex, or it should somehow guarantee that writers always get exclusive access.
    3. Again, simple syntax for declaring something mutable/immutable, this concept should be “first-class” citizen too.

Read the rest of this entry »

Boost.Spirit + Flatbuffers + Catch + Biicode + CLion + Github

This weekend I’m test-driving several new technologies. OK, OK, maybe not so new for everyone else, but new for me. I’m trying to write a parser for the Flatbuffers IDL grammar using Boost.Spirit, I’m referencing Boost using Biicode, I’m testing the code using Catch, I’m editing the project in CLion, and I’m pushing the results to Github yacoder/flatbuffers-with-spirit!

This time I’m just going to summarize my impressions, and I’ll dive deeper into details in future posts.

CLion 1.0 RC. I very much like the quality of all products from JetBrains that I used, and I’m excited about CLion. CLion is a cross-platform IDE for C and C++, which understands CMake files directly as “project model”. It was available for free during the “alpha” development stages, but they’ve just shipped their first RC on April 1st (not a joke), so you can only use it for a 30-day trial now.

Unfortunately, my experience with it so far for this particular project wasn’t great. They warn about known perf and memory issues when working with large codebases (“especially using Boost”!). Though my project isn’t large per se, but it uses probably some of the nastiest templates and macros from Boost, which are difficult to parse, I can imagine. And it drives CLion crazy. Not only it shows false positive red squiggles, it also tries to enforce some weird tab indentation in some places, and from time to time freezes for 10-20 seconds, especially when I’m changing some includes or identifier namespaces… Again, CLion is a great direction overall for JetBrains, and I know they’ve improved CLion a lot during the alpha preview period, but for this project VS 2015 CTP experience was better so far.

Read the rest of this entry »

5 most interesting talks from Meeting C++ 2014

Meeting C++ 2014 conference was held in Berlin in December, and with support from Tableau I was able to attend it. The conference had 3 parallel tracks of talks, so I’ve seen a third of the talks at the time, plus I watched a few more recordings afterwards based on the talk descriptions. I think by now all the videos are published on this Youtube channel, you can also find a list of talks with short abstracts on the conference’s website. The conference was overall well-organized, and audio/video are high-quality.

Below is the list of the 5 most interesting talks from this conference, in my opinion. Most talks have the Youtube video embedded in their description, but for some talks I provide the link to the Youtube video separately.

1. “Plain threads are the ‘GOTO’ of today’s computing” by Hartmut Kaiser.

Maybe I liked it because it is so relevant to the performance areas I’m working on. The talk discusses important abstractions for describing parallelism in C++ code, including an overview of the proposed primitives for C++17, and is based on the open-source HPX runtime work.


2. “The Evolving Search for Effective C++” by Scott Meyers.

I especially recommend watching the part from approximately minute 14 till minute 60, where Scott describes the process of writing the Item 42 “emplace vs insert” guideline for his latest book “Effective Modern C++”. The rest of the talk is less technical, Scott gives a historical overview of his publications and talks about writing effective guidelines in general.

3. “The C++ Memory Model” by Valentin Ziegler.

Good quality overview of the Standard with regards to modern C++ memory model, multithreading, data races, atomics, memory ordering. But if you know all that, and can explain the SC-DRF model and how the Standard defines “synchronizes-with” and “happens-before”, then you don’t need to watch it :)

Read the rest of this entry »

C++ curiosities: move semantics is not about moving

C++ move semantics is not about moving, but about keeping as many things as possible where they already are. Yes, at a very high level of abstraction one can say that move semantics is about “moving ownership” of a resource from on object to another. But performance benefits of move semantics do not come from these high levels of abstraction, they come from the very earthly fact that a move operation usually needs to touch fewer bytes in memory than a copy operation. (If you’re new to C++ move semantics you might like to know that std::move isn’t about moving things either.)

Perhaps, a good analogy for explaining what move semantics moves and what it doesn’t move is the process of selling/buying some large property. Let’s say you need a skyscraper. And you know a guy, who sells a skyscraper which fits your needs exactly. It’s an existing building, it has a certain known address, and it’s huge. You want to buy it, but, alas, the legal system in the city (you live in the PlusPlusCity98) is a bit quirky: the ownership belongs to the person who constructed the skyscraper and the ownership is non-transferable. Then the only option you have (since you want exactly the same building, and have a distaste for bribing the city officials):

  1. Buy a piece of land nearby.
  2. Ask the owner of the skyscraper to give you the blueprints of the building, and to give you access inside to see every floor and office in the skyscraper.
  3. Construct a full replica of the existing skyscraper on your land.
  4. Inform the owner when the replica is done.
  5. The owner tears the original skyscraper down to sell the land underneath.

Technically, you could say that the skyscraper was moved: its address has changed, but not its internal structure. But this is in fact analogous to C++ copy semantics, not move semantics. This happens in C++98 when you pass a vector<T> by value into a function. Even if the original vector was a “temporary” value, it can not legally “sell” its data to another vector, that data has to be copied byte by byte to a new location.
Read the rest of this entry »