끔찍하다
방금 글 관리하다가 예전에 적어놓은 글 삭제했다
그 글.. 되게 공들여서 적었는데..하...
요즘 정말 사람이 정신이 없다
정신 차려 제발
4주차 강의 내용을 초안으로 적어놓은 글이 비공개로 등록되어 있어서 그걸 지우려고 했는데...
아...
근데 더 끔찍한 건 이후에 그것도 지울 뻔 했다는 거다
질문 받은 내용도 날라갈 뻔 했다
앞으로는 절대 글 안 지워야지.. 그냥 비공개로 놔둬야겠다...
가끔 무언가를 잘 해보려는 게 지나치게 작용하여 일이 터지는 경우가 있는데
오늘 터졌구나.
지금이 새벽 시간이라서 그런걸수도.
새벽에는 자야 한다.
5월 5일에 학회 스터디에서 Stack, Queue, Deque에 대해 강의했다.
(YouTube 설명란에서 강의자료 확인하실 수 있습니다.)
끝나고 한 분이 질문해주셨는데
스택과 덱 큐를 처음 배워 세 가지에 대해 잘 몰라 이렇게 생각 하는 걸 수도 있는데, 마치 덱이 큐와 스택을 모두 포함하는 것이라 느껴졌습니다. 헤더? 가 나누어 져있지만 덱 헤더만을 이용하여 스택과 큐처럼 이용 할 수 있겠다는 생각이 들었습니다. 메소드들도 딱히 스택과 큐에 있는게 특별해 보이는것도 없어보이고, 문제를 푸는 과정에서도 오늘 예문으로 푸신것 들 다 덱으로 풀 수 있을것 같았습니다. 오히려 마지막 문자열 폭발과 같은 경우 뒤집과 과정이 필요 없어 더 편리 해 보이기도 하였습니다. 혹시 제가 이직 모르는 스택과 큐만이 가지는 놀랍고도 신비한 기능이 있는 것인가요? 아니라면 왜 덱이 아닌 두 가지 자료 구조를 추가로 사용하는 것인가요?
deque이 stack과 queue의 기능을 모두 갖고 있으니 항상 deque을 사용하면 되지 않는지가 질문이었는데, 이에 대한 나의 답변은 크게 두 가지였다.
1. stack, queue가 갖는 상징적 의미
2. 코드 구현 과정에서 실수 방지
stack은 LIFO, queue는 FIFO 자료구조이다. 그렇기 때문에 어떤 문제를 풀 때 누군가 '이 문제는 stack을 사용해서 풀면 될거 같아'라고 한다면 Last In First Out의 방식으로 문제 풀이가 전개될 것임을 내포한다. queue의 경우도 마찬가지이다.
그리고 두 번째는, queue을 사용해야 할 때 그 대신 deque을 사용하면서 push_back으로 값을 삽입하고 pop_front로 값을 빼낸다고 가정해보자. 이때 만약 실수로, 혹은 고의로 push_front나 pop_back 하게 된다면, 이건 설계한대로 코드를 작성한 게 아니므로 잘못 작성한거다. 그렇지만 컴파일 에러나 런타임 에러는 발생하지 않기 때문에 의도와 다른 결과가 나올 때 그 이유를 찾는 게 힘들어진다.
만약 이것이 실수가 아니라 기존 계획과 다르게 갑자기 해당 메소드가 필요해져서라면, 이렇게 기존에 구상한 것과 다르게 코드를 작성하는 것은 별로 좋은 코딩 습관이라고 볼 수 없다. 이런 경우, 코드를 처음부터 잘 설계하여 처음부터 deque을 사용하면 됐을 것이다.
작년 겨울 기초 스터디에서 다른 친구가 이 주제로 강의 했을 때, 어떤 분이 vector에 erase 메소드가 있는데 굳이 stack을 사용하는 이유가 무엇인지 질문하신 적이 있다.
그 당시에는 그 질문을 보고 약간 충격을 받았는데, 그것을 계기로 다양하게 생각해본 결과 위 두 결론에 다다랐다.
이렇게 글이 끝나고
다음 스터디가 마지막이 될 것 같으니 잘 준비해야겠다,
강의는 하고 나면 항상 아쉬운 것 같다
이런 얘기를 했는데
이미 마지막 강의에 대한 이야기를 적은 뒤라
이런 이야기를 하는 게 이상하네.
에효.. 정신 차리자 진짜