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

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

[Review][Game] 총망라…

그로우랜서 게임 리뷰를 하면서.. 갑자기… 그 동안 내가 즐겼던 게임들이 떠올랐다.
각각에 대해 리뷰를 쓸수는 없겠지만… 언급이라도 하고 싶어서… 이곳에 한꺼번에 적는다.
생각날때마다 update할 예정…

Diablo : 1, hellfire, 2, expansion [특히 2]
: 미친듯이 했다. 하드코어 아시아 랭킹 30위 귄이였었다는…-_-;

Baldur’s gate 1, 2, shadow of amn, throne of bhaal:
: 더 말해 무엇하랴. 생에 최고의 RPG중 하나. Dungeon and Dragons와 Forgotten Realms를 알게 해준 게임.

Never Winter Nights
: Bioware사랑해요~~

Icewind Dale
: 엔딩은 못 봤지만…

Might And Magic 6,7,8
: 3대 RPG는 아무나 가질 수 있는 title이 아니다!

Heros Of Might And Magic 2,3,4,5
: 미친듯이 했던 2 (블랙드래곤 짱.) 완전히 망했던 4. 그래도 역시 잼있음.

Kings Bounty – The Legend / Armored Princess
: HOMM의 원조격. 그렇지만 역시 재미는 HOMM이 더…

Startcraft
: 말이 필요없음! 쵝오~!

Civilization 2,3,4
: 악마게임…

Master Of Orion 2
: 이것도.. 악마.. (이것도 시드마이어 였던가???)

Final Fantasy 5,6,7,8,9
: 일본식 RPG의 정수! 특히 개인적으로 5, 7

Elder Scroll 1(Arena), 2(Dagger fall), 3, 4
: 이거야 말로… 자유도를 추구하는 RPG의 최고봉… 특히나, Daggerfall !! (베데사다 15주년으로 꽁짜로 풀렸어요~~)

삼국지 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
: 삼국지를 좋아하니까..

신장의야망 혁신
: 일본을 좋아하진 않으나 게임의 완성도 면에서는…

용의기사
: 단순하게 즐길수 있는 SRPG…

용기전승
: 역시 SRPG. 수작이긴 하나… 명작이라고 하기엔…

[Review] 삼국군영전5

삼국군영전(이하 군영전) 시리즈는 새로운 것을 시도하기 보다는 기존의 것을 보완하는 방향으로 버젼을 거듭해 온 느낌이다.
Koei의 삼국지 시리즈가 커다른 틀에서 여러가지 다른 것들을 시도해 보는 것과는 반대된다.
군영전5 에서도 4에 비해서 특별히 달라진 것은 없다. 그렇지만, 개인적으로 4에서 가장 큰 불만사항 중에 하나였던, “적장의 자동 레벨업”이 아군에도 적용되어서 어느 정도 밸런스가 맞아들어간 느낌이다.
4에서는 전투에 사용하지 않고 가만히 내정만 하고 있는 장수의 레벨은 절대 오르지 않았다. 그렇지만, 적진영의 장수들은 시간만 지나면 자동으로 레벨업을 했으니… 상당히 괴로웠었다..
그렇지만 여전히 반복되는 천인전투는 지루하다는…-_-;

[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__)
#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.)

[Essay] Sorry vs. Thank you.

내 생각에 대한민국은 ‘조언’의 문화보다는 ‘훈계’의 문화가 지배적인 것 같다.
‘조언’의 문화란, 대등한 관계에서 이루어지는 ‘제안’ 같은 것을 의미하고, ‘훈계’란 상하관계에서 가르침을 뜻한다.
대한민국에서 부모/자식 관계는 대등하기 보다는 상하관계에 가깝다.
따라서 부모는 자식을 ‘훈육’하게 되고, 자식입장에서는 가르침을 받게 된다.
‘조언’이든 ‘훈계’든 어떤 것이 낫고 나쁜지는 모르겠다.

그런데 재미있는 것은 ‘훈계’의 문화에서 사용되는 ‘가르침’이  ‘질책’의 의미로 사용되는 경우다.
사실 상당히 많은 경우, 상하관계에서의 ‘훈계’는 ‘가르침’보다는 ‘질책’의 의미를 가진다. ‘사랑’이 바탕이 되는 부모/자식 관계도 그러할진데, 다른 사회적인 관계에서는 말할 필요도 없겠다. 그래서 그런지, 대한민국이란 나라에서 (다른 나라의 경우는 잘 모르겠다.), 사회적인 관계를 형성하는 사람들 사이에서는 ‘감사합니다.’ 보다는 ‘죄송합니다.’가 더 익숙한 것 같다.

예를 들어, A 신입사원이 거래처와의 일을, 조금 어설프게 처리했고, 그래서 B대리는 A신입사원의 일처리에서 문제점들을 지적했다고 생각하자. 만약 A가 신입사원이 아니라 대리 혹은 과장이였다면, 위 사안은 ‘질책’이 될 가능성이 높다. 그렇지만, 신입사원이다. A가 일의 내용을 어설프게 처리할 것은 당연한 일이고, 아마 신입사원에게 맡긴 일이라면, 어느 정도의 실수는 용납될 일이 였을 것이다. 이런 경우, B대리가 A사원에게 하는 말은 ‘질책’처럼 들릴지라도 ‘훈계’에 가깝다. 그렇다면, A사원의 대답은 ‘죄송합니다.’ 보다는 ‘감사합니다.’가 옳지 않을까?
‘자신의 잘못된 부분을 지적해주고 가르쳐 주어서 감사합니다. ‘가 맡는 대답이 아닐까 말이다.
그렇지만, 우리들 대부분은 ‘죄송합니다.’가 먼저 튀어나온다. 자라온 환경에서 ‘훈계’보다는 ‘질책’을 받아왔던 탓이리라.
설사, ‘질책’이라 할지라도, ‘감사합니다.’는 여전히 유요한 반응이다.
‘질책’했다는 자체가, 관심의 표현이고, 더 잘되라는 뜻이기 때문이다. 그렇지만, 우리는 어김없이 ‘죄송합니다.’가 나온다.

어찌보면, 문화가 만들어낸 것인 것도 같다. 그리고 사실, 이것이 ‘잘못되었다!’라고 말할 근거도 용기도 없다.
그렇지만, 내 개인적인 생각으로는 ‘죄송합니다.’보다는 ‘감사합니다.’가 듣기도 좋고, 한결 부드러운 것 같다. 아닌가?
‘조언’이든 ‘훈계’든 아니면 그것이 ‘질책’이든, ‘죄송합니다.’보다는 ‘감사합니다.’가 먼저 생각나고 떠오를 수 있는 문화, 그런 문화는 과연 어떨까?