High precision floating point arithmatic in C++

One of my friens had a need for a floating point type that would allow a precision level upto 9 decimal points. "long double" would have been our choice if not for the differences in implementation and VC++ not supporting it (in VC++, long double = double).

We opted for doubledouble which has a precision level upto 30 decimal points.

Some other options are available here.

Posix Threads and FT Handling

We have a set of stringent FT mechanisms at our company since failure of a single process might spell disaster for the whole system. Threre are multiple instances of the same process running as primary and mirror. And there are multiple "Sets" which hold copies of the whole system so if one set goes down, another could take over.

If a primary process goes down, an "FT_CHANGE" happens and the mirror becomes the primary.

I came across an instance where the mirror process was made to "Fail over" just as it became "Ready" (A process is "Ready" once it finishes the initialization process and sends a message to the controlling system). This has resulted some bizarre behaviour.

After having a look at the logs, we came to the conclusion that this was due to the fact that the process gave the "Ready" signal before some "pthread_create" calls have finished executing. I check the return types of the code but this does not guarantee that the threads are up and running at that moment.

The lesson: Wait till the child thread comes up and sends the main thread an acknowledgement before making any calls to that thread (like we do in most of the other processes)

Scaling - Technology vs. Services

I just read a blog post by Dare Obasanjo which focused on the importance (or lack of it) when dealing with rapid scaling. Here's and excerpt from it:

If someone tells you "technology X doesn't scale" without qualifying that statement, it often means the person either doesn't know what he is talking about or is trying to sell you something. Technologies don't scale, services do. Thinking you can just sprinkle a technology on your service and make it scale is the kind of thinking that led Blaine Cook (former architect at Twitter) to publish a presentation on Scaling TwitterFail Whale begs to differ. which claimed their scaling problems where solved with their adoption of memcached. That was in 2007. In 2008, let's just say the Fail Whale begs to differ.

If a service doesn't scale it is more likely due to bad design than to technology choice. Remember that.

You could find the full entry here.

I have to contradict. Choosing the right technology can have a significant impact on handling ever increasing data loads. Scaling one's service (as Dare has said) is simple if a proper design has been adopted at an early stage. But one has to take into consideration the cost factor. Hardware and bandwidth levy a recurring toll on the budget and in most instances it's not feasible to scale in terms of expanding your service horizontally.
Choosing the correct technology for a project is also a critical design decision and would aid in handling a bigger load on one's current infrastructure. Prot buffs are better than XML when you consider the bandwidth and overhead on processing. Big tables are supposed to be faster than relational data bases for in most common cases. Our company develops distributed systems which delas with massive amounts of data and we optimize our processes by adopting proper data structures, light-weight messaging protocols, minimal logginh etc. to achive the best performance numbers before we even think about scaling our services.
In conclusion, I think it's important to adopt lighter, faster technologies when designing a system as well as making it scalable at the service level.

Inheriting from a Template Class

A class could be derived from a template class simply as follows;

template class
class A
{
int i_A;
}

template class
class B : public A
{

}

But when accessing member variables of the base class, a compiler error is given if it's done in the following manner;

template class
class B : public A
{
void Init(int i)
{
i_A = i;
}
}

the solution is to use "this->i_A" instead of "i_A" as per the GCC 3.4 release.

template class
class B : public A
{
void Init(int i)
{
this->i_A = i;
}
}

The reason for this is as follows (taken from GCC 3.4.0 release notes):


In a template definition, unqualified names will no longer find members of a dependent base (as specified by [temp.dep]/3 in the C++ standard). For example,

template struct B {
int m;
int n;
int f ();
int g ();
};
int n;
int g ();
template struct C : B {
void h ()
{
m = 0; // error
f (); // error
n = 0; // ::n is modified
g (); // ::g is called
}
};

You must make the names dependent, e.g. by prefixing them with this->. Here is the corrected definition of C::h,

template void C::h ()
{
this->m = 0;
this->f ();
this->n = 0
this->g ();
}

As an alternative solution (unfortunately not backwards compatible with GCC 3.3), you may use using declarations instead of this->:

template struct C : B {
using B::m;
using B::f;
using B::n;
using B::g;
void h ()
{
m = 0;
f ();
n = 0;
g ();
}
};

Full release notes...

Google Protocol Buffers Released

Google has released it's protobuf API for data serialization/retrieval under open source license. So far it appears to be pretty good and would help to avoid alot of headaches over data persistence and managing countless numbers of object types. Performance values are yet to be determined...

protobuf home