[💬] 그냥 메소드 매개변수 object 로 받아도 되나?

[익명(117.111)]

캐스팅 자주하면 성능하락 좀 있다던데

솔직히 인디게임이면 걱정 안해도 되는수준 아님?

[익명(61.97)]

일단 해보고 느린거같으면 하나씩 바꿔봐 업데이트 루프안에서 총 합 몇백개씩 캐스팅 하는거 아니면 문제 없을듯

[익명(117.111)]

업데이트 루프에서는 안쓰고 그냥 이벤트 전용 함수에만 쓸거임

[익명(61.97)]

ㄱㅊ을듯 나중에 인터페이스로 분리할 수 있게 염두만 해놓고 설계하면 좋을듯

[익명(211.250)]

무슨 상황이길래 object가 필요한거임

[익명(211.250)]

뭐 근데 써야 하는 상황이면 써야지 당장 여기 애들 내부적으로 object로 받는거인줄도 모르고 쓰는거 많을걸

[익명(125.181)]

내부적으로 object 받는다는게 무슨뜻임?

[익명(211.250)]

그냥 언어 공부 안하고 유니티만 하는 사람들 코드 보면 object 타입으로 넘어가게끔 코드 짜는 사람들 있음

[익명(211.250)]

자기가 만든거 말고 표준 라이브러리나 언어 자체의 특성때문에

[익명(218.52)]

간단한 예시 하나 들어주면 List 에서 호출되는 Remove는, 내부에서 Equals가 호출되는데, 이 때 인자가 object라 리스트에서 뭐 뺄 때 마다 박싱언박싱 나옴

[익명(roslyn1021)]

List.Remove(T item) 함수는 완전 예전 버전 아닌 경우에 EqualityComparer에서 박싱 안할텐데 버전이 언제껀진 모르겠지만 내부적으로 EqualityComparer.Default.IndexOf 이런식으로 동작할걸?

[익명(218.52)]

아 바뀌었나? 꽤 최근까지도 여전히 object.Equals 타는 걸로 알고 있었는데

[익명(roslyn1021)]

https://source.dot.net/#System.Private.CoreLib/List.cs,db8cdd552a0bb10c

[익명(roslyn1021)]

.NET Core 까지 안가고 .NET Framework 쪽만 봐도 제네릭버전 List 는 문제없어보이는데

[익명(218.52)]

EqualityComparer.Default.IndexOf 도 타고 들어가면 object.Equals 구만

[익명(roslyn1021)]

아니 소스 보고도 모름 제네릭 버전 EqualityComparer인데?

[익명(roslyn1021)]

유니티 예전 버전에서 Enum 을 Dictionary Key로 사용했을때 박싱일어난다는건 봤어도 List Remove 메서드는 못들어봤는데

[익명(218.52)]

https://source.dot.net/#System.Private.CoreLib/EqualityComparer.cs,0a059518e815968d
제네릭으로 받아서 또 박싱하는걸로 보이는데

[익명(roslyn1021)]

GenericEqualityComparer 에 구현부를 보면 객체의 IEquatable T 를 이용해서 비교하는데

[익명(roslyn1021)]

상속구조로 밑에 각 클래스가있음

[익명(roslyn1021)]

논제네릭 인터페이스 IEquatable 은 박싱이 일어나는게 맞는데 호출 타고들어가면 IEquatable T 로 감

[익명(218.52)]

아 그러네 ㅋㅋㅋㅋ 밑에 있었구나; IEquatable 구현한 애들 살펴보고 왔는데 결국 == 오버로딩 하는거랑 의도는 같은게 약간 웃기긴 한데 돌고 돌아서 수정하긴 했구나

[익명(218.52)]

덕분에 정보 최신화됨 ㄳㄳ

[익명(roslyn1021)]

굿

[익명(roslyn1021)]

박싱/언박싱 개념 아는 상태에서 매 루프 함수같은것만 아니면 문제없지

[익명(112.145)]

ㄹㅇ 값타입 업데이트에서 받는순간 메모리 살살녹을듯

[익명(usnned)]

개인적으로는 구조 설계 상 진짜 편해진다 할때만 잘 포장해서 접근 막아놓고 쓰긴 하는데

[익명(usnned)]

벨류랑 레퍼런스에 대해 잘 이해하고 있고 캐스팅을 충분히 조심해서 쓰면 문제는 없음