쑥갓재배기

가장 쉽게 생각할 수 있는 기본적인 방법으로는
bool로 플래그를 두고
함수에 들어가면 true로 세팅하고
매 루프마다 clear를 해주는 방법이 있다.

그러나 이게 영 비효율적으로 보이는지라.
timeGetTime()으로 시간을 기억해두고 ( 물론 매번 호출하진 않고 루프마다 한번 호출해서 전역에 저장해둔다 )
시간이 다르면 first time이므로 멤버 변수로 현재의 time값을 저장해둔다..
라는 생각이었는데

api에서는 잘돌아가는게 mfc에선 정상적이지 않는 현상이 발견되었다.
timeGetTime()의 한계-_-(실제로 timeGetTime은 밀리세컨드 단위이기때문에 1000프레임 이상의 수치는 처리할 수 없다.. 그 이하의 수치 일때 도 같은 Time이 들어올 수 있다. )일수도 있겠지만 IDLE메세지가 들어왔을때 함수 호출을 하게 해놔서 idle이 한번의 메세지루프에 여러번 들어올수 있다(라는 생각은 전혀 안해봤었는데-ㅅ-)

어쨋건 그런 연유로 그냥 DWORD로 매 루프마다 1씩 올려주는 카운터를 만들고 카운터를 기억하게 했다.

애매한 time보다야 확실하긴 하다만
왠지 쓸데없는 전역변수가 늘어난거같은 느낌은 지울 수 없다-ㅅ-;;

컨텐츠라는 단어가 조금 맞지 않을지도 모르겠다.

프로그래머가 요구 받는건 어떤식으로 작동을 했으면 좋겠다. 어떤 인터페이스로 어떤 기능을 사용할 수 있었으면 좋겠다...라는 다소 추상적인 내용이다.

그럼 프로그래머는 그 내용에 대해 가장 맞는 기술을 찾아서 사용하게 된다.
하지만 그렇게 구미에 딱 맞는 시스템이 있는 경우는 좋으나 그렇지 않으면 양자 택일로 빠지게 된다.
우리 시스템상에서는 이렇게 밖에 안되니 이렇게 해야한다...와
아니면 삽질이다-ㅅ-;

가능하면 이렇게 밖에 안된다...라는 말은 피하고 싶지만 그렇게 밖에 갈수 없는 상황들이 종종 있다.
시간과 인력은 한정되어 있으니 어느걸 포기해야하거나 아니면 능력부족이거나..

요구를 하는 사람이 정확하게 요구를 해주고 자신이 무엇을 원하는지 구체적으로 생각을 해본다면
삽질이 좀 쉬워질 수도 있지만....

보통은 실제 기능을 만드는 시간보다 어떻게 사용하고 어떻게 보여질지를 고민하는 시간이 더 많이 들어가는 경우가 많다.

글을 쓰다보니 무슨 말을 하고 싶었던건지는 기억이 나지 않지만
분명한 것은 나는 지금도 삽질을 하고 있고, 삽질을 선택하는 경우가 너무 많지 않은가 하는 기분이라는 것이다.

프로젝트라는것은 어찌됐든 개발되고 서비스 되는것이 더 중요할 수도 있는데.
내 삽질이 과연 가치있는것인지는 시간이 평가해주려나-ㅅ-a

shared_ptr.hpp 한 구석에

operator size_t() const { return (size_t)px; }

를 넣어준다-ㅅ-;