개인적으로는 지나치게 비효율적으로 구현하지 않는 이상
효율성보단 가독성이 중요하다고 생각해서 시간 복잡도만 맞추는 편인데
종종 잔기술 써서 상수 커팅해야 하는 문제 보면 힘빠진다...
그런 문제들은 알고리즘 자체를 공부한다기보다 그냥 잔기술 갖고 기교 부리는 것 같아서 안 좋아함
비슷한 맥락으로 cpp에서 sync_with_stdio나 자바에서 스트링 빌더로 입력 받는 것도 꼭 필요한 경우가 아니면 안 씀
효율성보단 가독성이 중요하다고 생각해서 시간 복잡도만 맞추는 편인데
종종 잔기술 써서 상수 커팅해야 하는 문제 보면 힘빠진다...
그런 문제들은 알고리즘 자체를 공부한다기보다 그냥 잔기술 갖고 기교 부리는 것 같아서 안 좋아함
비슷한 맥락으로 cpp에서 sync_with_stdio나 자바에서 스트링 빌더로 입력 받는 것도 꼭 필요한 경우가 아니면 안 씀
루비 아닌 이상에야 상수 커팅 해야하는 문제가 있긴 한가
그리고 입출력도 개발할 땐 라이브러리 쓰긴 하지만 최적화 대상 1순위라 잔기술이라 하기엔 그냥 글쓴이가 알고리즘만 판거 아닐까 싶다
ㅇㅇ 그건 맞음 애초에 알고리즘이란 게 로직을 보는 거지 IO를 보는 건 아니니까
동의하는 부분인데 ios는 쓰는게 맞는듯 ㅋㅋㅋ
넌 그렇게 영원히 상수커팅 하지말고 시험코테 다 떨어져라 ㅋㅋ
시험코테 수준은 상수커팅 안해도 다 되는데
그냥 구현이 약한거임
그런건 기본 소양이고 상수 커팅이라 안 부름. 심지어 스트링 빌더는 실무에서도 문자열 조작을 많이하면 쓰라고 할 정도인데 너무 곡해하는 것 같음. 상수 커팅이라 부르려면 비트셋으로 / 32를 한다던지 SIMD를 동원하는 정도가 나와야 하는데 저정도는 그냥 징징거리는 것으로 보임
비트셋 같은건 보통 상수커팅이라 안 부름 그리고 기본소양이라는 건 동의하기 힘듦 문제 많이 풀어봤으면 쓰레기 시간제한에 당해본적이 있을 수 밖에 없음
입출력은 비슷한 맥락이라고 했지 상수 커팅이라고 안 했다 게이들아...