(Row-1, Col), (Row-1, Col-1), (Row-1, Col+1)
(Row-2, Col), (Row-2, Col-2), (Row-2, Col+2)
...
(Row-k, Col), (Row-k, Col-k), (Row-2, Col+k)

이렇게 지금까지 놓인 Queen의 위치 리스트를 역으로 올라가면서 테스트를 하고 싶어서 이런 코드를 만들었다.

bool validate(in uint[] cur, in uint c) { uint l=c, r=c; foreach(uint _c; cur.reverse) { if (_c&c | _c&(l<<=1) | _c&(r>>=1)) return false; } return true; }

cur.reverse 가 뒤집힌 녀석을 리턴하는건지, 스스로를 뒤집는건지 잘 모르겠지만 cur 에 변화가 있다면 저기 달아놓은 in qualifier 가 못한다고 말해주겠지 - 라고 생각했다. in 은 const 를 강제하니까. 그리고 이녀석은 컴파일이 된다. 헤헤 안심 ~하고 다음으로 넘어가보자 했는데 ... 계속 테스트가 실패하네?

알아보니 reverse는, 1. 스스로를 뒤집고, 2. 그 뒤집은걸 리턴, 도 하는 녀석이다. 배열의 property 를 참조하면 배열 자체가 뒤집혀 버리는 상황. -_-; 뭐 이래? 거기까지면 괜찮은데 왜 컴파일이 된거야?. 어이가 없어서 위의 in 을 immutable 로 고치고 테스트 했는데, 역시 컴파일이 되고 실행도 된다. 아놔... ;; 결국 side-effect가 있는 property는 immutable, const 를 그냥 씹어 드신다는 뜻.

짧게 정리하면, 

import std.stdio; int main() { immutable uint[] a=[1,2,3]; writeln(a); a.reverse; writeln(a); return 0; }

이 코드가 컴파일+실행된다는 사실을 발견. ... 실행하면 [1, 2, 3] [3, 2, 1] 을 차례로 찍는다. 뭐라굽쇼? property 에 대해서는 수정 불가 조건을 검사하지 않는 것 같은데, 그 property가 side-effect 만땅 ... 이라는 암울한 상황이다. IRC에 가서 물어봤더니 돌아오는 대답은,

1. Looks like a bug
2. Those properties like reverse, sort will be deprecated.

였다. 으으, 아직 D 두번째 스펙이 불안정하다고는 하지만 이건 좀 지나친 거 아닌가 싶기도 하고.

-----
D 2.053, 2.054 에서 확인.

Very promising. David Nadlinger라는 똑똑한 친구가 Google Summer of Code 에서 삽을 뜨려고 준비중인 듯 하다. D 포럼에서도 이름이 자주 보이는 친구이며, 홈페이지에서 볼 수 있는 몇몇 코드 조각으로 볼 때 무난히 (잘) 만들어 낼 것 같다.

2. 못기다리겠다.

훌륭한 사람이 삽을 떠서 결과가 곧 나올 것 같은 경우에 이렇게 조바심을 내는 것은 부질없겠다. 하지만 그래도 급하다거나, 연습삼아 해보거나 할 수도 있으니 잠깐 생각만 해보자. 사용하기 위해 보는 thrift 라이브러리는 크게 runtime 과 compiler 로 나눌 수 있다.

compiler는 protocol definition파일을 읽어서 목적 언어로 쓰여진 "코드" 를 뱉어주는 일을 한다. 이렇게 생성된 코드가 해당 언어로 준비된 "런타임 환경" 에서 돌아간다.

D는 C 혹은 C++과는 어느 정도 인터페이싱이 가능하다. 그렇다면, 무임승차 혹은 거기까진 안되더라도 코드 재사용을 생각해볼 수 있다. thrift 의 여러 생성 옵션 중에서 c_glib, cpp 정도가 살펴볼 만 하다. 어느 쪽이건 간에 D쪽에서 만지기 위해서는 interface를 만들어야 한다. 최소한 *.h -> *.di 로의 컨버팅이 필요한 것.

c, c++ 양쪽은 별도의 런타임 환경이 준비되어 있으며 include 되는 헤더도 다르다. 어느 쪽에 손을 대더라도 해야 하는 일은 별로 달라지지 않는다.

a. Runtime environment

ㄱ. Make custom environment with D
그냥 C 혹은 C++쪽 코드를 보고 D로 구현해버린다. 직관적으로, 여기서 API를 잘 설계하면 Compiler 쪽 작업이 대단히 쉬워질 것 같다.

ㄴ. Make interface to c_glib or cpp runtime

c_glib 혹은 cpp 를 위해 준비된 환경으로 인터페이스를 만들어서 가져다 쓴다. 이 경우 손으로 *.h -> *.di 컨버팅을 해주는게 좀 귀찮은 작업이 될 수 있다. ... 하지만 그냥 새로 만드는거에 비하면( .. )

b. Compiler

t_c_glib_generator, t_cpp_generator 이런 애들이 있다. runtime 쪽에서 직접 구현한다를 선택한 경우에는 그냥 t_d_generator 를 만들면 된다. 다른 생성기를 참조하고, 런타임 API가 잘 설계되어 있으면 그렇게 어렵진 않을듯 하다. 만약 runtime을 가져다 쓴다는 결정을 했다면, t_d_generator를 직접 만들 수도 있지만 다른 선택도 가능하다. 기존 Compiler 에 끼어들어서 *.di/*.d 파일을 *.h/*.cpp 파일과 함께 만들어 버리는 것. 지저분하지만, 런타임을 공유한다면 API도 같기 때문에 이렇게 작업할 수도 있다. 하지만, 이건 thrift 버전업이 있거나, 혹은 contribute를 하고 싶다면 심각한 문제가 된다. 다른 사람과 공유하지 못하는 삽이라니 가슴 아프지 않은가. dirty and quick.

David Nadlinger의 제안에서는 Free-riding없이 직접 구현을 택했다. CTFE(Compile Time Function Execution)도 고려중인 듯. 이 경우 일반적인 타입의 serialize/deserialize는 별 문제가 아닌데, rpc server/client implementation 에서 비동기를 구현할 때 곤란할 수 있다(포기하고 그냥 스레드 만세 할 수도 있지만). 현재 latest인 D2.053 epoll|kqueue|iocp 등이 core.sys.posix|osx|windows 에 없다. D1을 고려한다면 tango를 볼 수도 있지만, 미래를 생각한다면 볼때 D1+Tango로 새 프로젝트를 시작하는건 삽질 ( ... )이라는게 중론이다. libevent의 D port도 아직은 없어뵈고... 그렇게 어렵진 않겠지만, 역시 이런 인터페이스를 뚫는 작업이 좀 지루할 수 있겠다.

결론적으로 무임승차는 못할 듯. 어느 쪽으로 가더라도 손이 가는 작업이 필요하다.

core.sys.posix.poll 도 있는데 core.sys.posix.epoll 정도 있어주면 어디가 덧나나. 이미 삽이 준비되지 않았으면 github 에 자리 하나 차리고 해보려 했으나 일단 기다리기로 결정함. 크릉크릉. thrift 와는 별도로 libevent 헤더들을 D interface 파일로 만들어 두는건 해볼만 할듯. 어렵지도 않고, 시간만 들이면 되는거고, 써먹을 데도 많다. 이미 있는데 못찾는건가 ... ... ...