코세님이 wcsrnchr 만들어 주셨을 때 lptr = aptr - 2를 사용하셨는데이걸 왜 하셨는지 이해가 안됩니다. 말해주셨는데 까먹었네요wcschr은 저게 없어도 잘돌아가는데 말이에요--
얌마 감소방향에서 -2 를 했다는건 더 덜 돈단 뜻이지.
글구 뒤로 삐져나오면 어쩔래? (32비트 기준 8바이트가)
산수 안되냐 8바이트 단위 정렬된 주소 aptr 까지 wchar 단위 비교했지.
그럼 위에 있느 wcschr는 위험한 로직인가요?
(위에 32비트 기준 4바이트가 임)
그걸 왜 나한테 물어 니가 나한테 받아서 니가 수정해서 쓰는 코드 아님?
개념을 이해하라고
봐봐
-8L 이라고 해 놓은건 8바이트 정렬을 가정한건데, 아래코드에선 4바이트로 움직이고 있어
이것부터 개그임. 8바이트 정렬을 했음 8바이트 단위로 가든지.
012345670123 이런 주소가 있다쳐. lptr 이 마지막 3을 가리켜.
wptr 이 뒤의 0을 가리킨다 치자.
0123 을 wchar_t 단위로 체크했을것 아냐.
거기서 wchar_t 단위로 32비트를 내려오려면 -2 를 해줘야 4의 위치를 가리키겠지.
만약 -2를 안했다, 그러면 뒤부터 하겠지. 뒤에서 읽은 4바이트가 마지막 2바이트 위치를 지나 있을 수 있잖아?
위에 설명에서 wchar_t 니까 lptr 은 사실상 마지막 2를 가리키겠네. 여튼.
산수안되심?
아 ... 이해했습니다.
if (ptr[1] == ch) return ptr + 1; 도 틀렸네요,,, 4번을 써야되는거네요
요약하면 -2가 안정성과 성능 두 가지를 잡고 있는거고 8로 정렬했으면 8로 나가는게 맞고 4로 정렬할거면 4로 나가는게 맞음. 다만 내가 64비트 확장을 고려해서 8로 정렬해놓고 컴파일케이스를 안나눴을 순 있음. (둘 다 구현하는거 귀찮으니까)
너 인라인 함수 쓴거랑 풀어서 쓴거랑 속도비교 해봄?
차이 있든?
static inline i64u has_zero_wide( const i64u n )이거 말하시는 건가요?
ㅇㅇ
니가 32비트 단위로 움직이고 있으니 32비트 버전의 has_zero_wide 랑 비교해야지.
내생각엔 별로 인라인이 안느릴것 같은데 왜 해체했냐는거야.
함수하나에 다 포함하려고 만들었습니다 #define _WMAGIC checker_type(~0ULL/0xffff) 이런식으로 하면 컴파일러가 checker_type에 맞게 변환해줘서 굳이 inline함수 따로 안써도 구별가능하다고 생각했습니다.
물론 내가 첨 올린 타잎처럼 (size_t)0x0001..........0001ULL 을 써도 자동으로 다 됨.
그걸 하나에 구겨넣었단 자체가 네 코드는 가독성이 떨어졌고, 유지보수가 나빠졌음. 코드가 퇴보했단 소리.
그럼 통째로 #define해 놓으면 될려나요
#define 의 단점도 알면서 그러넹
디버깅 하기 좆같아. 그 안에 들어온 데이타 흐름을 추적하고 싶을때 매번 사용한 위치에 브렉 걸꺼임?
성능에 차이 없으니까 그런건 걍 inline 을 쓰도록 해~
넌 너무 코드에 다 때려박고 변조하려는 강박관념이 있는 것 같음.