어쨋든 메모리 통신량이 C++ move 처럼 O(1) 인게 아니고 O(N) 인거 아님? - return 0;
둘다 O(N)인데?
먼 소리임 vector받는 함수에 move로 넣는다고 vector 포인터 길이 용량해서 포인터 3개 크기만큼 복사 안할수가 있음?
아 move 생성자를 특별하게 정의하지 않으면 똑같은거구나 - return 0;
오히려 C++ move는 최적화 된다고 해도 이동 생상자 함수에서 원본 zeroing까지 하니까 더 많은일을 하는데
난 또 복사라길래 멤버까지 몽땅 복사한다는줄 - return 0;
zeroing 은 안 해도 됨 - return 0;
글고 control flow analysis 로 zeroing 이 완전히 redundant 한 경우에는 (대부분의 경우일테고) 최적화돼서 날라갈꺼라고 봄 - return 0;
그게 최적화가 대부분 되는데 일단 쓸데없는 작업이 추가되는건 맞자너http://m.dcinside.com/board/github/3671
zeroing 안 하는 경우도 많은데 뭐 ㅇㅅㅇ - return 0;
컴파일러권을 보장하라 ㅇㅅㅇ
뭐야 러스트는 move-constructor로 sink되고 스코프밖으로 나가면 destructor 호출 안하는게 표준임?
constructor 자체가 없음 소멸자는 소유권을 넘겨줬으니 그놈이 알아서 부르는거고
엥? 근데 destructor은 있음? 쨋든 move하고 destructor 날렸는지 안날렸는지 어셈으로 안까봐도되는건 부럽네
있음 Drop 구현한 타입하고 그걸 필드로 가지는 타입은 소멸자 부름
C++처럼 이동 생성자로 이동시킬 객체를 새로 만드는게 아니라 그냥 그대로 보내버리고 남은 값은 소유권이 사라져서 접근이 불가능해짐
아 소유권 때문이구만 - dc App
어쨋든 메모리 통신량이 C++ move 처럼 O(1) 인게 아니고 O(N) 인거 아님? - return 0;
둘다 O(N)인데?
먼 소리임 vector받는 함수에 move로 넣는다고 vector 포인터 길이 용량해서 포인터 3개 크기만큼 복사 안할수가 있음?
아 move 생성자를 특별하게 정의하지 않으면 똑같은거구나 - return 0;
오히려 C++ move는 최적화 된다고 해도 이동 생상자 함수에서 원본 zeroing까지 하니까 더 많은일을 하는데
난 또 복사라길래 멤버까지 몽땅 복사한다는줄 - return 0;
zeroing 은 안 해도 됨 - return 0;
글고 control flow analysis 로 zeroing 이 완전히 redundant 한 경우에는 (대부분의 경우일테고) 최적화돼서 날라갈꺼라고 봄 - return 0;
그게 최적화가 대부분 되는데 일단 쓸데없는 작업이 추가되는건 맞자너
http://m.dcinside.com/board/github/3671
zeroing 안 하는 경우도 많은데 뭐 ㅇㅅㅇ - return 0;
컴파일러권을 보장하라 ㅇㅅㅇ
뭐야 러스트는 move-constructor로 sink되고 스코프밖으로 나가면 destructor 호출 안하는게 표준임?
constructor 자체가 없음 소멸자는 소유권을 넘겨줬으니 그놈이 알아서 부르는거고
엥? 근데 destructor은 있음? 쨋든 move하고 destructor 날렸는지 안날렸는지 어셈으로 안까봐도되는건 부럽네
있음 Drop 구현한 타입하고 그걸 필드로 가지는 타입은 소멸자 부름
C++처럼 이동 생성자로 이동시킬 객체를 새로 만드는게 아니라 그냥 그대로 보내버리고 남은 값은 소유권이 사라져서 접근이 불가능해짐
아 소유권 때문이구만 - dc App