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가 있었으면 좋았을텐데… 라는 생각이 그냥 들어서…

[SW] 확~ 다가오는 각종 명언들…

<출처를 기억할 수 없는 것은 생략했습니다. 혹시 문제가 되는 부분이 있다면 알려 주시기 바랍니다.>

  • 좋은 코드는 변경하기 쉽고, 나쁜 코드는 변경하기 어렵다. 그러므로 좋은 코드는 나쁜 코드가 될 때까지 변경된다.
  • “Provide mechanism not policy” : about interface design. (From the UNIX)
  • 또 뭐가 있지??? — 당장은 생각이 안나는 관계로…

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

There are two simple examples for this.

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


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

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 {
    void a();

class A : public P {
    void p();

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

A::p() {

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
PATH=$(unique_path "$PATH")

Done :-).

[Android] Developing Android-native-library on 64bit build machine

Most Android device is 32bit machine. So, many application assumes that host machine is 32bit system.
And in general, there is no difference developing Android-natvie-library between 64bit and 32bit build machine.

But, here is usual step for developing Android-native-library.
(1) Developing and verifying code at build machine.
(2) Porting to NDK build system.

Most developers turns on full-warning-option at compile to detect bugs at early stage.
But, building and verifying codes assuming 32bit host machine at 64bit machine always issues type casting warning due to different type size.
Especially, between pointer and integer.

For example, many Android JAVA application uses intjint – as a type to contain native pointer with assumption of 32bit-host-system.
Building this code at 64bit build system to verify code issues type casting warning, even if code itself is built perfectly at NDK build system.
And it is worse that this code doesn’t work at 64bit Android host machine, even though it is not popular.

To reduce this warnings (for easy-verifying of library code at build machine), in my opinion, using longjlong – instead of jint as a type for containing native pointer is better unless memory space is extremely critical.
And to make compiler be happy, using macro can be a good choice.
Here is example of macro for type-casting between pointer and integer – jlong.
(This sample works well without warning at 32bit/64bit build/host system).

#define ptr2jlong(v) ((jlong)((intptr_t)(v)))
#define jlong2ptr(v) ((void*)((intptr_t)(v)))

This is just simple example for portability issues.
Making portable code is always very difficult…