[Prog] Separating mechanism from policy (microscopical view) – function implementation.

Separating mechanism from policy is very important issue of SW design.
This is also true for microscopic area – implementing function.
Here is one of simplest example – function that calculates area of rectangle.

int rect_area(int left, int top, int right, int bottom) {
        return (right - left) * (bottom - top);
}

Simple, isn’t it?
But, this function doesn’t have any exception/error handling.
Let’s add some of them.

int rect_area(int left, int top, int right, int bottom) {
        if (left >= right)
                left = right;
        if (top >= bottom)
                top = bottom;
        return (right - left) * (bottom - top);
}

It’s seems good.
Soon after, another function that calculates area of rectangle is needed.
But, this function should return error value if input rectangle is invalid.
I think quick solution is

int rect_area2(int left, int top, int right, int bottom) {
        if (left > right || top > bottom)
                return -1;
        return (right - left) * (bottom - top);
}

But, in this solution, code for calculating area of rectangle is duplicated.
At above example, this is just one-line code. So, duplicating is not a big deal.
But, it’s not good in terms of code structure.
Why did this happen?
Calculating rectangle area is ‘Mechanism’.
But, exception/error handling is ‘Policy’ at this example.
So, above example should be implemented like below.

static inline int _rect_area(int left, int top, int right, int bottom) {
        return (right - left) * (bottom - top);
}

int rect_area(int left, int top, int right, int bottom) {
        if (left >= right)
                left = right;
        if (top >= bottom)
                top = bottom;
        return _rect_area(left, top, right, bottom);
}
int rect_area2(int left, int top, int right, int bottom) {
        if (left > right || top > bottom)
                return -1;        
        return _rect_area(left, top, right, bottom);
}

Can you know the difference?
‘_rect_area’ is implementation of pure ‘Mechanism’.
And policy is implemented at each interface function.
Even for simple function, developer should consider CONCEPT of separating Mechanism from Policy.

[C/C++] Encapsulation tip in C.

Usually, pointer of not-opened-structure is used to hide module’s information.
C dummies may use ‘void*’ to do this. But, it’s not good way.
Let’s see following example.
(Following codes are test in GCC4.4 with ‘-Wall’ option.

typedef void module_t;             /* <-- *1 */
typedef struct _sModule module_t;  /* <-- *2 */

module_t* create_module(int arg);
int       do_something(module_t* m, int arg);
...
do_something((int*)m, 1); /* <-- *a */

Pointer of any type can be casted to ‘void*’, and ‘void*’ can be casted to pointer of any type without warning.
So, in case of (*1), (*a) doesn’t generate any warning. That is, it is NOT TYPE SAFE (in compile time).
But, in case of (*2), GCC give warning like “… incompatible pointer type …”. It’s TYPE SAFE.
And, interestingly, compiler doesn’t complain anything about (*2) because, compiler doesn’t need to know size of ‘struct _sModule’.
Only pointer is used. So, knowing size of pointer type is enough and compiler already know it.
So, in terms of syntax, it’s ok too!

[C/C++] Tips and Memos

* Boolean to integer – C.

Let’s think about the function that return 0 if false, otherwise 1.

 => Naive way : return (e)? 1: 0;

C doesn’t support boolean type. Instead, 0 is false, non 0 is true in C.
There is no fixed value to represent TRUE.
But, as defined by 4.5/4, boolean true is promoted to 1, boolean false to 0.
So, we can improve this to

 => Better way : return !!(e);

And this way is also useful because we can get fixed integer value – integer 1 – for TRUE boolean value.

* The ORDER that function PARAMETERS are EVALUATED, is NOT SPECIFIED.
The only requirement is “Those should be fully evaluated before function is called.”

[Essay][Prog] Multi-Threading SW Programming 방법론에 대한 단상.

Multi-Threading(이하 MT)  SW Programming시 동기화는 무엇보다 중요한 이슈가 된다.
생각해보면, 동기화가 문제가 되는 이유는, Programming Language의 기본 전제가 “필요한 곳에 동기화를 한다.” 이기 때문이다.
이런 정책에 100% 동의한다. MT을 통해, HW 자원을 효율적으로 사용하고자 한다면 더더욱 그러하다.
그런데, 만약 상당히 많은 부분을 서로 공유하는 어떤 MT SW가 있다고 가정한다면 (그런 SW는 디자인 자체가 잘못된 것이라는 등의 이야기는 일단 접어두자.) 어떨까?
이런 경우 “필요한 곳에 동기화”란 개념으로 보면, 너무 많은 “필요한 곳”이 존재하게 되므로, 쉽지 않다.
이럴 경우, 차라리 개념을 “필요한 곳에서 rescheduling”이라는 걸로 개념을 바꾸어 보는건 어떻까?
일단 다른 측면들은 모두 차치하고서라도, Programming은 좀더 쉬워질 것 같지 않은가?
이런 식의 개념을 지원하도록 SW구조를 잡는 것은 그리 어려운 일은 아니다.
물론, HW 자원을 효과적으로 쓰도록 만들기는 앞의 개념에 비해서 상당히 더 어려울 것이다.
결국 아래와 같은 Trade-off가 발생한다.

“HW자원의 효율적인 사용 vs. Programming의 단순와”

너무 무식한 방법이라고 비판할 수도 있겠지만, Performance가 큰 문제가 되지 않고, Async한 동작자체가 중요한 경우라면, 충분히 한번 고려해 볼만하지 않은가? 일단 Bug는 많이 줄일 수 있으니…