뭔가 저 in out 이런게 잘 시각화 되는게 보기 좋은데,저게 아직 끝나지 않은게... 씨발그니까 나는 내부의 변동같은거는 이제 알아서 캡슐화되어있을거라고 상정하는거거든?즉, 저 in out 은 전부 내가 인자로 받아온 포인터들에 대해서만 먹히는거임.뭐가 헬이냐하면struct A *b 가 사실상 struct A *const b 의 의미로 쓰이는건데,
딱국(118.235)2021-05-07 15:41
답글
내부변수 b가 const 가 아니라 변동 가능한 경우, (즉 이거는 외부 인풋이나 아웃풋이 아님. 내부의 이동임)
내부의 이동이 발생한 경우에는, b_out 을 쓰면 안돼.
그때는.... ㄴㅇ멯ㄴㅁ에ㅐ헌메 씨발... 그때는 또 다른 회로를 그려야함
딱국(118.235)2021-05-07 15:42
답글
근데 사실 또 그녀석이 어떤 in / out 버스던지 간에,그것도 결국 저 회로들의 조합일거거든?그래서 직접 계산해야할거야.내부변수에 대한 포인터참조는 in / out 이 아님.외부변수에 대한 포인터 참조만 전부 in 이랑 out 걸어서 쓰는건데,문제는 저게 또.... 아니다 ㄴㅁ에ㅐㅑ허ㅑㄴㅁ에ㅐㅓㅎ ㅐㅔㄴㅁ헌ㅇ매ㅔㅎ;ㅁㄴ
딱국(118.235)2021-05-07 15:42
답글
대충, 선언을 해서, 에러체크로 코드를 검증하는게 러스트의 방식이면, 나는 거꾸로다.
이미 쓰여진 코드를 보고
선언문을 그리는거다.
그걸 왜하냐고??? 코드를 좀 비쥬얼라이제이션을 해야지 동시성이 보이겠음.
어떤 인풋 아웃풋을 가진지 싹다 규명하지 않으면 concurrency가 안보여
딱국(118.235)2021-05-07 15:43
답글
코드를 적을때 에러검출하라고 만든 선언문이 아니야.
코드는 고정되어있고, 에러검출을 통해서
선언문을 그려나가는거야...
딱국(118.235)2021-05-07 15:44
답글
아 씨발 이게 근데 뭐 먹히는 소린진 모르겠다.
쓰잘데기 없는 고민만 한세월 하고있다 씨발. 좀 쉬러간다
딱국(118.235)2021-05-07 15:45
답글
귀찮아서, 일부러 단순한 경우만 했는데,
인풋의 경우에는 move_in 의 x 필드를 막은거 빼고는 막은거 없음.
그래서 잘 보면 move_in 만 x필드자리에 z필드넣어놨음. x넣으면 에러라서그래.
그리고 아 x를 넣으면 안되는구나 하는게 아니야
코드가 이미 x를 안넣었고, 그렇기 때문에 위의 선언문에서 x를 unused로 바꿀수 있는거야.
딱국(118.235)2021-05-07 15:46
답글
내가 리눅스 코드를 쓰는 입장이 아니라 읽는 입장이라서 이런식의 접근법을 쓰는걸거야
딱국(118.235)2021-05-07 15:46
아 씨발 코드중에 병신같은 실수 있음.
c 는 내부변수이기때문에, c의 필드를 변경하는것은 out 이 아님.
근데 그걸 c_out 을 써놨네. 존나 운좋게도 에러가 발생하지 않는 이유는 ㅅㅂ 저게 out으로 나가는 회로라서 그럼
뭔가 저 in out 이런게 잘 시각화 되는게 보기 좋은데,저게 아직 끝나지 않은게... 씨발그니까 나는 내부의 변동같은거는 이제 알아서 캡슐화되어있을거라고 상정하는거거든?즉, 저 in out 은 전부 내가 인자로 받아온 포인터들에 대해서만 먹히는거임.뭐가 헬이냐하면struct A *b 가 사실상 struct A *const b 의 의미로 쓰이는건데,
내부변수 b가 const 가 아니라 변동 가능한 경우, (즉 이거는 외부 인풋이나 아웃풋이 아님. 내부의 이동임) 내부의 이동이 발생한 경우에는, b_out 을 쓰면 안돼. 그때는.... ㄴㅇ멯ㄴㅁ에ㅐ헌메 씨발... 그때는 또 다른 회로를 그려야함
근데 사실 또 그녀석이 어떤 in / out 버스던지 간에,그것도 결국 저 회로들의 조합일거거든?그래서 직접 계산해야할거야.내부변수에 대한 포인터참조는 in / out 이 아님.외부변수에 대한 포인터 참조만 전부 in 이랑 out 걸어서 쓰는건데,문제는 저게 또.... 아니다 ㄴㅁ에ㅐㅑ허ㅑㄴㅁ에ㅐㅓㅎ ㅐㅔㄴㅁ헌ㅇ매ㅔㅎ;ㅁㄴ
대충, 선언을 해서, 에러체크로 코드를 검증하는게 러스트의 방식이면, 나는 거꾸로다. 이미 쓰여진 코드를 보고 선언문을 그리는거다. 그걸 왜하냐고??? 코드를 좀 비쥬얼라이제이션을 해야지 동시성이 보이겠음. 어떤 인풋 아웃풋을 가진지 싹다 규명하지 않으면 concurrency가 안보여
코드를 적을때 에러검출하라고 만든 선언문이 아니야. 코드는 고정되어있고, 에러검출을 통해서 선언문을 그려나가는거야...
아 씨발 이게 근데 뭐 먹히는 소린진 모르겠다. 쓰잘데기 없는 고민만 한세월 하고있다 씨발. 좀 쉬러간다
귀찮아서, 일부러 단순한 경우만 했는데, 인풋의 경우에는 move_in 의 x 필드를 막은거 빼고는 막은거 없음. 그래서 잘 보면 move_in 만 x필드자리에 z필드넣어놨음. x넣으면 에러라서그래. 그리고 아 x를 넣으면 안되는구나 하는게 아니야 코드가 이미 x를 안넣었고, 그렇기 때문에 위의 선언문에서 x를 unused로 바꿀수 있는거야.
내가 리눅스 코드를 쓰는 입장이 아니라 읽는 입장이라서 이런식의 접근법을 쓰는걸거야
아 씨발 코드중에 병신같은 실수 있음. c 는 내부변수이기때문에, c의 필드를 변경하는것은 out 이 아님. 근데 그걸 c_out 을 써놨네. 존나 운좋게도 에러가 발생하지 않는 이유는 ㅅㅂ 저게 out으로 나가는 회로라서 그럼