Thursday, February 25, 2016

Solarized dark color scheme for ancient konsole

Recently I was forced to use ancient konsole 1.6.4 (KDE 3.5.4). To increase a comfort I quickly ported solarized dark theme.

https://github.com/mandross/solarized-old-konsole

Wednesday, December 2, 2015

static_assert

The nice feature static_assert is available since C++11, what to do if your compiler is lacking this feature?
You can choose between two options:
In some of my previous projects BOOST was not available for production code. I ended up digging into BOOST, understanding the implementation and extracting it. Let's go through this process again.

Code

How it works?

The main idea is explained by boost members here.
The key feature is that the error message triggered by the undefined expression sizeof(STATIC_ASSERTION_FAILURE<0>), tends to be consistent across a wide variety of compilers. The rest of the machinery of BOOST_STATIC_ASSERT is just a way to feed the sizeof expression into a typedef.
The result of sizeof (let's call it X) is fed into following expression:
typedef static_assert::static_assert_test<X> JOIN(t_staticAssert, __LINE__)
If the condition passed to macro STATIC_ASSERT is false the compiler will not be able to evaluate sizeof operator. The attempt to make a typedef will fail. The JOIN macro is used to enable usage of static_assert many times in the same file. If the condition is true, every created typedef will have unique name. The macro has two layers to correctly evaluate __LINE__ macro. The typedef is used, because it will not impact memory map.

Alternatives

Different compilers behave a bit differently, thus I have two others ways to use sizeof.

enum

typedef for char array

Try all, choose the one for which yours compiler gives the most descriptive error.

Saturday, November 28, 2015

Pure virtual function call hadler

Handling pure virtual function call is compiler specific. Analysis is done for g++ 4.9.2.

How to call a pure virtual fucntion?

Output:
pure virtual method called
terminate called without an active exception
Aborted (core dumped)

What the heck just happened?

After leaving the scope object k of type Kido is destructed. Firstly, derived's class destructor is called. Secondly, the base class destructor is called, during the destruction method make() calls method outsource(). The derived class is already destroyed, thus we call the pure virtual method.

Why to do that?

The answer is: you shouldn't, but 'shit happens'. If you try to call pure virtual functions directly from destructor, g++ will warn you, and the linking will fail. Wrapping the call fulls the compiler.

How is pure virtual function call handled?

Once such call happens static function static int __cxa_pure_virtual() is fired, you see nice print and the application is terminated.

What to do about it?

If your are coding for PC: nothing more than finding the spot and fixing the bug. In embedded software universum you may want to implement your own handler.

Why?

  • the handler is not implemented at all, and you start getting strange, hard to hunt down bugs
  • you would like to implement your own assertion
  • leaving the default handler brings a lot of unnecessary symbols into you object e.g.: exceptions

How?


Thursday, November 26, 2015

C++ idioms - noncopyable

Quite often you do not want your objects to be copy-constructed or assigned to others. As there is more than one way to skin a cat, let's go through possible solutions.

Classic way

The one I have seen the most often. Leave copy constructor and assignment operator declared but not defined:
Compiler output:
noncopyable.cpp: In function ‘int main()’:
noncopyable.cpp:25:10: error: ‘Foo& Foo::operator=(const Foo&)’ is private
     Foo &operator = (const Foo&);
          ^
noncopyable.cpp:43:7: error: within this context
     A = B;
       ^
So far, so good.

Glitches  

The first glitch with this code will be visible, once we try to make a copy in member method. Lets add a method and change our main function:
/tmp/ccnMGbs7.o: In function `Foo::copy()':
noncopyable.cpp:(.text._ZN3Foo4copyEv[_ZN3Foo4copyEv]+0x31): undefined reference to `Foo::operator=(Foo const&)'
collect2: error: ld returned 1 exit status 
This time we are getting linker error. This is the glitch I dislike the most. IMHO you should get the error as soon as possible to save precious time. What is more, linker errors are not as clear to read as compiler errors.

Let's analyze what happened. 

In the first example the copying was done from outside of the class. The copy constructor and assignment operator are private, thus the outside world is not aware of their existence. Compiler throws an error immediately. In the second example the coping was done from inside. The copy constructor and assignment operator are visible. Once the linking is done, the linker can't find their definition and linking fails.  

The second glitch is self-descriptiveness. The declaration without definition is a bit tricky, and may be confusing. Some people argue, that this way is the best, because it is the oldest and most common, which means: well known by engineers. Following this way of thinking, we should stick to fireplaces as the heat sources in our homes. The technology is well known and proven to work, right?

The third glitch is the amount of code you have to write. You need two lines of code per noncopyable class plus some comment to lower the risk of confusion. Not too bad, but in large project cutting it down is worth consideration.

C++ 11 way

This time in both cases we are getting the same compiler error:
noncopyable.cpp:43:7: error: use of deleted function ‘Foo& Foo::operator=(const Foo&)’
noncopyable.cpp:25:10: note: declared here
     Foo &operator = (const Foo&) = delete
It is way nicer now, isn't it? The code is self descriptive, and we are getting the error early. Two birds hit with one stone. Unfortunately, we still have to deal with the glitch no. 3.

BOOST way

If you haven't heard about boost library, you should definitely check it out.
Short, nice and sweet. You have to include one header, inherit from boost::noncopyable and that's it. Let's check compiler output:
noncopyable.cpp: In function ‘int main()’:
noncopyable.cpp:8:7: error: use of deleted function ‘Foo& Foo::operator=(const Foo&)’
     A = B;
       ^
noncopyable.cpp:3:7: note: ‘Foo& Foo::operator=(const Foo&)’ is implicitly deleted because the default definition would be ill-formed:
 class Foo : private boost::noncopyable {};
       ^
noncopyable.cpp:3:7: error: use of deleted function ‘boost::noncopyable_::noncopyable& boost::noncopyable_::noncopyable::operator=(const boost::noncopyable_::noncopyable&)’
In file included from /usr/include/boost/utility.hpp:19:0,
                 from noncopyable.cpp:1:
/usr/include/boost/noncopyable.hpp:35:22: note: declared here
         noncopyable& operator=( const noncopyable& ) = delete;
Note that you will get a different error when compiling with c++98. Boost detects the standard version and provides different implementation. No matter which standard we use or from where we try to copy, there will be a nice, descriptive compiler error (good). Additionally, there is no need to type too much (lovely!).

Glitches  

We deal with inheritance here: what will happen if we have a class with two parents, both inheriting from boost::noncopyable?
Console: Mom/Dad/Junior 1/1/2
Why the Junior is so fatty? I will start answering by explaining why the parents are so lean. They both inherit from boost::noncopyable, if you check the implementation of the base you will notice that the class has no members.  C++ standards requires that the most derived object has not zero size, but the base can be optimized. This is called Empty Base Optimization (EBO) which is out of scope of this post. Ok, but why the size of the Junior is 2? Both Mom and Dad have common ancestor. The standard requires that both have distinct addresses to avoid ambiguity. As a result the EBO is prohibited.

The second issue is that we are bringing the implementation with the inheritance. Inheritance is a very strong coupling mechanism in C++. Usually, I try to use composition instead, but noncopyable is kind of special here (yes, I am too lazy to type when I don't have to). There are some people who threat the rule of bringing in the implementation only by composition as a dogma. If you have to cooperate with them you can:
  • give up on noncopyable
  • start religious war
  • unfriend them (rage quit)

Custom noncopyable

If, for some reason, you can't use boost (e.g.: hard to be configured for your exotic compiler, you are not allowed to) or you are dealing with small memory software and EBO glitch is too much, you may use your own idiom in Curiously Recurring Template (CRTP) version:
If we compare the sizes as previously: Mom/Dad/Junior 1/1/1, the EBO glitch is gone, we do not have the famous Diamond of Death any longer. Sadly, we still have to deal with inheritance, but life (at least for C++ programmers) is not perfect.

Summary

Personally I am using either the boost or custom option. Every single one will work. I hope, that after reading this pretty long post, you will be aware of pros and cons of every presented method. Choose the one which suits you best. Happy coding!

Links

Friday, November 6, 2015

XML auto indentation

According to my experience, XML is a very common format to keep meta-data all over the big corporations. Personally, I prefer either more advanced technology, like YAML, or plain text. Unfortunately, in a big corpo-environment you may not be empowered to use technology of your choice. Keeping xmls under version control may be a pain in the ass.
  • different tab sizes
  • different cases
  • personal formatting style
All of the above will lead to terrible conflicts, which you have to resolve manually.
To relief the pain you may consider using auto-indenting script added as a hook in your version control system.

Here is the script I was successfully using in a few projects: