GCC macro with variable number of argument

#define pr(a, b...) printf(a, b) /* (*A) */
#define pr(a, b...) printf(a, ##b) /* (*B) */

pr("Hello\n"); /* (*1) */
pr("Hello %s\n", "World"); /* (*2) */ 
pr("Hello %s %s\n", "My", "World"); /* (*3) */

Above two kinds of macros looks like same at first look. But, there is difference.
In case of (*2) and (*3), (*A) and (*B) both work well.

In terms of (*1), it doesn't have second arguement. That is, it doesn't have arugment 'b'.
So, let's guess result of preprocessing.
Logically, in both case - (*A) and (*B) - "printf(a, )" should be a result, and GCC should complain about this syntax.
But, actual result is, (*A) doesn't work, but (*B) works well.

I didn't check GCC Spec. for this case but, it's interesting enough to leave post :-).

[C/C++/JAVA] 변수를 block중간에 선언하는 방법에 대한 단상.

변수는 사용하기 직전에 선언하는 것이 원칙인데.. 문제는 scope다.
C/C++/JAVA에서 명시적으로 ‘{ }’를 통해서 scope를 잡아주지 않으면, 이후에도 계속 해당 변수가 살아있는 상태가 되어서 좋지 못하다.
그래서 ‘{ }’를 사용해서 scope를 제한해 주는 것이 좋은데, 그렇게 하면, indentation에서 괜시리 한칸 들여쓰여지게 되어 미관상 – 개인적으로 – 마음에 안든다…
음…
변수의 scope를 위한 이~~쁜~~ syntax가 있었으면 좋았을텐데… 라는 생각이 그냥 들어서…

[C/C++] enable/disable function/macro with define switch.

There are two simple examples for this.

#ifdef A
#define xxx(...) BBBB(__VA_ARGS__)
#else
#define xxx(...)
#endif

vs.

#ifdef A
#define xxx(...) BBBB(__VA_ARGS__)
#else
static inline void xxx(){}
#endif

I preferred the second one because at the first case, sometimes unexpected problems are issued. (Just personal opinion/preference...)

[C/C++] Fail to build Android with g++/gcc-4.6 (Ubuntu-11.10)

[ g++ issue ]

g++-4.4 / g++-4.5 doesn’t detect following case, but, g++-4.6 does.

< a.cpp >
---------

class P {
public:
    void a();
};

class A : public P {
public:
    void p();
};

void
P::a() {
    // 'const' quailifier' is discard here!
    static_cast<const A*>(this)->p();
}

void
A::p() {
    ;
}

int
main() {
    return 0;
}

=================== Test ======================
$ g++-4.5 a.cpp   <= OK.
$ g++-4.6 a.cpp
a.cpp: In member function ‘void P::a()’:
a.cpp:13:33: error: passing ‘const A’ as ‘this’ argument of ‘void A::p()’ discards qualifiers [-fpermissive]

The problem is some of Android codes still have above bugs in its code – ex. frameworks/base/libs/utils/RefBase.cpp.
So, even if Android source code was successfully compiled at g++-4.4 or g++4.5, it may be failed at g++-4.6 (for example, upgrading host OS)

[ cc/gcc issue ]

Compiling with gcc-4.6 raises following warings.

<command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default]

In some component which uses ‘-Werror’ option, this warning stops compilation.

[ Conclusion ]

So, you would better to use gcc/g++-4.4 instead of 4.6 when building Android, until above issues are resolved on Android baseline.
(ex. Ubuntu 11.10 as an Android host OS.)

[Linux][Shell] Cleaning PATH environment variable.

With using terminal for a long time, PATH variable tends to be longer and longer due to duplicated path.
Here is simple sample script – with Perl – to resolve this.

# remove duplication at give PATH-format-string
unique_path() {
perl -w -e '
    my %path_hash;
    exit unless (defined $ARGV[0]);
    foreach $p (split (/\:/, $ARGV[0])) {
        unless (defined $path_hash{$p}) {
            $path_hash{$p} = 1;
            push @newpath, $p;
        }
    }
    print join ":", @newpath;
' $1
}
...(skip)...
PATH=$(unique_path "$PATH")
...(skip)

Done :-).

[C/C++] func() vs. func(void)

In C, func() and func(void) have different function signature.
(But, in C++, these two are same.)

‘func()’ means ‘this function can have any number of arguments (0 ~ infinite)’.
But, ‘func(void)’ means ‘this function doesn’t have argument.’
See following example.

#ifdef CASE1
void func(void); /* (1) */
#else
void func();     /* (2) */
#endif

void
func(int i) {
        ; /* do something */
}

If ‘CASE1’ is defined, compiling this file complains error like “error: conflicting types for ‘func'”.
But, ‘CASE1’ is not defined, this is well-compiled.
Now, you can clearly understand difference.

So, using ‘func(void)’ is better for readibility if ‘func’ really doesn’t have any arguement, instead of just ‘func()’.

*** One more. ***
In C, ‘extern’ for function is default visibility.
So, in function declaration, ‘extern void func(void);’ is exactly same with ‘void func(void);’.
Therefore any of them is OK.
( [ omitting ‘extern’ for simplicity ] vs. [ using ‘extern’ to increase readability ] )
But, default visibility of function depends on compiler.
For portability reason, using macro is usually better instead of using explicit directive – especially at shared library header.
(Ex. ‘EXTERN void func(void)’)

[C/C++] Tips for OOP – module initialization.

OOP SW design is usually compose of one main control routine (henceforth MCR) and lots of sub modules.
But, MCR don’t need to (must not need to) know inside implementation of every sub modules.
Sometimes, MCR don’t need to know even existence of some sub modules.
The problem is, most sub modules require initialization.
How can sub modules whose existence is now known, be initialized.
Due to this issue, principle of information hiding is sometimes broken.
Let’s see below example.

FILE : main.c
-------------
int main(int argc, char* argv[]) {
        ...

}

FILE : moduleA.c
----------------
...

FILE : moduleB.c
----------------
...

Assume that, each module requires initialization and main.c don’t need to know existence of each module.
How can we resolve this issue?
Easiest way is calling initialization function of each module with damaging principle of information hiding little bit, like mentioned above.

FILE : main.c
-------------
extern void moduleA_init();
extern void moduleB_init();

int main(int argc, char* argv[]) {
        ...
        moduleA_init();
        moduleB_init();
        ...
}

FILE : moduleA.c
----------------
...
void moduleA_init() { ... }

FILE : moduleB.c
----------------
...
void moduleB_init() { ... }

At above code, main.c becomes to know existence of moduleA and moduleB.
That is, in terms of modules, principle of information hiding is damaged although it’s very little.
Additionally, global symbol space is dirtier.
Regarding maintenance, whenever new module is added, modifying main.c is unavoidable.
But, main.c doesn’t have any dependency on newly added module.
With this and that, this way is uncomfortable.
How can we clean up these?
Using constructor leads us to better way.

Functions in constructor are executed before main function.
So, it is very useful for this case.
Easiest way is setting every initialization function as constructor.
But, in this case, we cannot control the moment when module is initialized at.
Therefore, it is better that each module’s initialization function is registered to MCR, and MCR calls these registered function at right moment.
Following pseudo code is simple implementation of this concept.

FILE : main.c
-------------
void register_initfn(void (*fn)()) {
        list_add(initfn_list, fn);
}

int main(int argc, char* argv[]) {
        ...
        /* initialize modules */
        foreach(initfn_list, fn)
                (*fn)();
        ...
}

FILE : module.h
---------------
extern void register_initfn(void (*fn)());
#define MODULE_INITFN(fn)                               \
        static void __##fn##__() __attribute__ ((constructor)); \
        static void __##fn##__() { register_initfn(&fn); }

FILE : moduleA.c
----------------
...
#include "module.h"
...
static void _myinit() { ... }
MODULE_INITFN(_myinit)

FILE : moduleB.c
----------------
...
#include "module.h"
...
static void _myinit() { ... }
MODULE_INITFN(_myinit)

Now, MCR don’t need to know existence of each modules.
And, MCR can also control the moment of each module’s initialization.
In addition, adding new module doesn’t require any modification of MCR side.
It is closer to OOP’s concept, isn’t it?

We can improve this concept by customizing memory section.
Here is rough description of this.

* Declare special memory section for initializer function.
    - In gcc, ld script should be modified.

* Put initializer function into this section.
    - __attribute__ ((__section__("xxxx"))) can be used.

* MCR can read this section and call these functions at appropriate moment.

Actually, this way is better than using constructor in terms of SW design.
Linux kernel uses this concept in it’s driver model.
(For deeper analysis, kernel source code can be good reference.)
But, in many cases, using this concept may lead to over-engineering.
So, if there isn’t any other concern, using constructor is enough.