2015 EOY Goals

I’m setting some goals for myself. For those who wonder why I’m doing this when it’s almost the last month of the year: I don’t believe in new year resolution and I start a goal whenever I think I’m ready. Sometimes I give up, sometimes I persist through. The most important thing about goals is to track the progress and evaluate oneself accordingly. In this post, I set out to list a number of things to do by the end of the year and how I will evaluate my performance.

From now and until new year 2016, I will closely monitor my performance in the following five goals:

  1. Sleep better.
  2. Build a sustainable and manageable budget.
  3. Actively listen to one person a day.
  4. Record two current events a day, of which one must be a new event.
  5. Each day, find one interesting thing or fact that I didn’t know before.

The above are meant to help me work on these two areas: interpersonal communication and an understanding in what goes on around me. In order to effectively achieve this, the very first thing I must do is to get better rest. When I’m sleepy, I can’t think of anything but to get through the day and go home to sleep. A sustainable budget, at first glance, doesn’t have to do with communication or knowledge of what goes around. But it puts me at ease. I have a tendency to overspend, which often makes me really nervous and takes away precious energy that I could otherwise make good use of. Point 3 – 5 are three concrete actions I will be doing. I intend to monitor them in the following way.

  1. On a daily basis, track any progress I make along the way. Jot down notes or save the news I have come across that I think will be useful to come back later.
  2. On a daily basis, engage in meaningful conversations. Try to understand what the other person is trying to say and what his/her feelings are. The goal here is to be a good listener. Jot down notes about each meaningful encounter right afterwards.
  3. On a weekly basis, look back on the notes I have made in the past week. Organize and reflect upon them. Ask myself the following questions:
    • What did I achieve in the past week
    • Where did I fall short?
    • What are the reasons that I fell short?
    • What can I do to further my strong points and to work on my weaknesses? (Long-term and short-term)
    • What are the immediate actionable items for next week?

Around new year 2016, I will update with a one-month review regarding to these goals.

The Danger of the Concentration of Power

Some thoughts from what I read recently.

Quintus Catalus (Consul of 78 BC) once said, in front of a popular gathering in 67 BC, “I admit that Gnaeus Pompeius rightfully deserves all the honors you have bestowed or intend to bestow upon him. However, with all the powers rested in one man, what would you do if that man is no longer to serve you?”

His warning was not heeded. Unprecedented power was granted to Pompey, and soon popular favor was bestowed instead upon Caesar. It was not long before the Republic came to a disastrous halt.

Some one hundred and fifty years had since passed, when the historian Cornelius Tacitus (Consul of 97 AD) wrote, “When all the powers had rested with Caesar Octavianus, when he had become Augustus, peace was finally restored to the Roman world. But it was not for long. Imperial succession became a source of gravest danger and one man’s life weighed heavier than the whole of the Empire”.

Stability at the cost of liberty was destined not to last for long.

Should I throw an exception in my destructor?

The following is the work of Marshal Cline @ C++ FAQ.


Write a message to a log-file.  Or call Aunt Tilda.  But do not throw an exception!

Here’s why (buckle your seat-belts):

The C++ rule is that you must never throw an exception from a destructor that is being called during the “stack unwinding” process of another exception. For example, if someone says throw Foo(), the stack will be unwound so all the stack frames between the throw Foo() and the } catch (Foo e) { will get popped.  This is called stack unwinding.

During stack unwinding, all the local objects in all those stack frames are destructed.  If one of those destructors throws an exception (say it throws a Bar object), the C++ runtime system is in a no-win situation: should it ignore the Bar and end up in the } catch (Foo e) { where it was originally headed?  Should it ignore the Foo and look for a } catch (Bar e) { handler?  There is no good answer — either choice loses information.

So the C++ language guarantees that it will call terminate() at this point, and terminate() kills the process.  Bang you’re dead.

The easy way to prevent this is never throw an exception from a destructor.  But if you really want to be clever, you can say never throw an exception from a destructor while processing another exception.  But in this second case, you’re in a difficult situation: the destructor itself needs code to handle both throwing an exception and doing “something else”, and the caller has no guarantees as to what might happen when the destructor detects an error (it might throw an exception, it might do “something else”).  So the whole solution is harder to write.  So the easy thing to do is always do “something else”.  That is, never throw an exception from a destructor.

Of course the word never should be “in quotes” since there is always some situation somewhere where the rule won’t hold.  But certainly at least 99% of the time this is a good rule of thumb.

Favorite 10-Liner

shared_ptr< widget > get_widget( int id ) {

    static map< int, weak_ptr< widget > > cache;
    static mutex m;

    lock_guard< mutex > holder( m );
    auto sp = cache[ id ].lock();
    if ( !sp ) cache[ id ] = sp = load_widget( id );
    return sp;

// credit to Herb Sutter @ Going Native 2013

Isn’t this awesome?


Well, let’s see…

  • Is this thread-safe?
  • What’s the lifetime of the objects in the cache?
  • What happens if you ask for an object not in the cache?

And so… Isn’t this awesome?



P.S. the other 3 lines:

Widget &instance() {
    static Widget w;
    return w;
// credit to Herb Sutter @ Going Native 2013

Who Doesn’t Want Optimization? (Part One)

When it comes to optimization, C is often regarded as the ultimate language. Simple and efficient, C encourages programmers to write customized, often lightweight, though sometimes obscure, routines as opposed to its feature-richer alternatives. But is C always better at efficiency than other mainstream alternatives?

Ever since its birth, C++ has frequently been the subject of criticism for being overly bloated and complicated. Some of its higher-level, fancier features such as virtual functions and RTTI, although nice to have otherwise, more often than not impose unwanted performance penalties. The new C++ 11 standard has introduced a slew of new features, among which many aim to improve the performance. This post is going to look at constexpr and how its uses can provide a kind of optimization that is difficult, if not impossible, to achieve in C.

Continue reading Who Doesn’t Want Optimization? (Part One)