오후 10:21 [구여운갤러] 코세님

오후 10:21 [구여운갤러] 안녕하세요

오후 10:21 [나] 응~

오후 10:21 [구여운갤러] 다름이 아니라 용어에 관련해서 많은 도움을 얻던 게 기억나서 이번에도 조언을 구하고자.. 

오후 10:21 [나] ㅇㅇ

오후 10:21 [나] 좋아~

오후 10:21 [구여운갤러] 멀티스레드 프로그래밍을 할 때에는 

오후 10:21 [구여운갤러] 해당 객체가 있는지 판단하고, 없으면 추가하려는데

오후 10:21 [구여운갤러] 이 없으면 추가하려는 시점이 겹칠 수 있잖아요?

오후 10:22 [구여운갤러] 그래서 저는 코어 부분을 만들때 get<Object>() 이런식으로 하면

오후 10:22 [구여운갤러] 해당 객체가 있으면 그대로 반환하고,  없으면 생성 후 반환하려는 동작을 하려고 해요

오후 10:22 [나] 응

오후 10:23 [구여운갤러] 근데 일반적으로 가지는 get에 의미에 비해 행동하는 게 너무 많다보니 get이란 함수로 퉁치기가 좀 찜찜해서요

오후 10:23 [나] 앙~

오후 10:23 [구여운갤러] 저런 경우는 어떤 용어를 쓰면 좋을까요? 있으면 반환하고, 없으면 생성 후 반환. 마치 싱글톤의 get_instance()는 아무렇지 않게 쓰고있긴 하지만요 -_-;;

오후 10:24 [나] reduce / remove / delete 의 의미 차이가 뭐라고 생각해?

오후 10:25 [구여운갤러] 리듀스는 컨테이너 안에 있는 개체 개수를 n개 (임의로)줄일 때 쓸 거 같고요, 리무브는 어떤 컨테이너에 있는 "특정" 개체 자체를 삭제할 때 

오후 10:26 [구여운갤러] 딜리트는 컨테이너 또는 개체를 통째로 제거할 때 쓸 거 같네요

오후 10:26 [나] 앙

오후 10:27 [나] 그럼 니 말인즉

오후 10:27 [나] 저 세 단어는 어차피 인자가 다를거란거네

오후 10:27 [구여운갤러] 네 reduce는 갯수를, remove는 조건을, delete는 무인자를 쓸 거 같네요 

오후 10:27 [나] 앙

오후 10:27 [나] 그러면 셋을 구별하는게 의미가 있을까?

오후 10:27 [구여운갤러] 네 전 있다고 생각합니다 미묘하게 동작이 다르니까요

오후 10:27 [나] 젤 쉬운 단어 하나를 쓰는게 낫겠지?

오후 10:28 [구여운갤러] 그런가요?

오후 10:28 [나] 인자가 다른데

오후 10:28 [나] 인자가 곧 함수명인게 C++인데

오후 10:28 [나] 굳이 뭐 구차하게

오후 10:28 [나] 중언부언할 필요 없잖.

오후 10:28 [나] 내가 보기엔,

오후 10:28 [구여운갤러] 어

오후 10:28 [나] 어차피 인자에 대한 설명이 필요하니까

오후 10:28 [나] 동작을 구체화하는데 이름만으론 부족하고

오후 10:28 [구여운갤러] 인자가 곧 함수명인게 c++이죠

오후 10:29 [구여운갤러] 네

오후 10:29 [나] ㅇㅇ

오후 10:29 [나] 그럴거면 부를때라도 쉽게 불러야

오후 10:29 [나] 경제성있는거 아니겠어?

오후 10:29 [구여운갤러] 그렇죠

오후 10:29 [나] 파일을 여는데

오후 10:29 [나] file_create 가 있고

오후 10:29 [나] file_open 이 있잖아?

오후 10:29 [나] Create

오후 10:29 [나] Open

오후 10:29 [나] 말야.

오후 10:29 [구여운갤러] 네

오후 10:29 [나] Open 이 하는일은

오후 10:29 [구여운갤러] 맞다 저 중 없으면 생성하는 게 있었죠.

오후 10:29 [나] 있으면 열고 없으면 만든다지?

오후 10:30 [구여운갤러] 네

오후 10:30 [나] Open 이란 네이밍이 잘못된걸까?

오후 10:30 [구여운갤러] 결과적으로 open이란걸 하기 위한 추가적인 동작 자체를 함으로

오후 10:30 [구여운갤러] 철학에 따라서 이상하다고 할 사람은 있을 거라 생각해요

오후 10:30 [나] 그렇지

오후 10:31 [나] 불만은 있을수 있지

오후 10:31 [나] 하지만, 사용하긴 편하지?

오후 10:31 [구여운갤러] 네.. 저도 그렇게 써서

오후 10:31 [나] 네이밍의 정책 문제지?

오후 10:31 [구여운갤러] 정책

오후 10:31 [나] 과도한 디테일은 함수명을 복잡하게 만들고

오후 10:31 [구여운갤러] 사용하기 어렵게 만들죠

오후 10:31 [나] 컨텍스트를 끌고 다니는 함수명이 될 뿐.

오후 10:31 [나] 좋은 이름이 아니다.

오후 10:31 [구여운갤러] 그렇군요..

오후 10:32 [나] ㅇㅇ 나도 오래 고민한거임

오후 10:32 [나] 쓰기 편한게 왔다야~

오후 10:32 [구여운갤러] ㅋㅋ

오후 10:32 [나] 씨는 넘 디텔해~

오후 10:32 [나] 충분히 디텔하니까

오후 10:32 [구여운갤러] 네

오후 10:32 [나] 더 거들면 씨++ 의 단점이 커짐

오후 10:33 [나] 자 그럼 get 으로 돌아가서

오후 10:33 [구여운갤러] 넵

오후 10:33 [나] 난 get 으로도 충분하다고 생각해

오후 10:33 [구여운갤러] 예 저도 얘기를 듣다보니..

오후 10:33 [나] 가지고 오랬더니

오후 10:33 [나] 빈손으로 온다?

오후 10:33 [구여운갤러] 없어 빼애앵

오후 10:33 [구여운갤러] ㅋㅋ

오후 10:33 [나] 것도 웃기잖

오후 10:33 [나] ㅋㅋㅋ

오후 10:34 [나] 무조건 가져오려면?

오후 10:34 [나] 군대에서 처럼

오후 10:34 [나] 없으면 만들어서 가져와!

오후 10:34 [구여운갤러] 없으면 만들엇허!

오후 10:34 [구여운갤러] ㅋㅋ

오후 10:34 [나] 가 기본정책일 수 있는거지

오후 10:34 [나] open 처럼~

오후 10:34 [구여운갤러] 아 좋네요 ㅎㅎ

오후 10:34 [나] dd

오후 10:34 [나] ㅇㅇ

오후 10:34 [구여운갤러] 감사합니다. 이런 어떻게 보면

오후 10:34 [나] 확실한 한가지 장점은 갖잖아 그지?

오후 10:34 [구여운갤러] 모호한 문제때 코세님 말이 참 더 와닿네요 

오후 10:34 [구여운갤러] 넵

오후 10:34 [나] 일반화와 구체화의 장단점을 이야기 하는거쥬~

오후 10:35 [나] 일반화된 네이밍은 해당 라이브러리나 프레임웍의 사용을 쉽게 합니다.

오후 10:35 [나] 하물며 해당객체가 함부로 사용될 소지가 있는지,

오후 10:35 [나] 그리고 이미 만들어져 있으면 바로 리턴을 하는데 매번 만들고 부수는지

오후 10:36 [나] 그런게 더 고민해야 할 문제라고 봐요.

오후 10:36 [나] 얼마나 자주 만들고 부서지고

오후 10:36 [나] 그걸 사용자가 알게 해야하느냐

오후 10:36 [구여운갤러] 넵

오후 10:36 [나] 만약 생명주기가 길다면

오후 10:36 [나] 걍 막 써도 무관할테고

오후 10:36 [나] 수명이 무척 짧아서

오후 10:36 [나] 맨날 만들고 부서진다면

오후 10:36 [나] 그 말 자체가 오버헤드를 이야기 하는거쥬

오후 10:37 [나] 만약 니가 루프 안에서 get 을 무분별하게 사용했다.

오후 10:37 [나] 상관없잖아.

오후 10:37 [나] 어차피 부수면 만들어져야하고

오후 10:37 [나] 안부쉈다면

오후 10:37 [나] 계속 걍 리턴이니

오후 10:37 [나] 그취?

오후 10:37 [구여운갤러] 네

오후 10:37 [나] 응

오후 10:37 [나] 괜한 걱정을 하신거죠?

오후 10:38 [구여운갤러] 네 하지만 조언을 들을 수 있어서 괜한 생각을 했다는 생각은 안 듭니다 ㅎㅎ

오후 10:38 [구여운갤러] 좋은 말씀 감사합니다 _ _

오후 10:38 [나] ㅋㅋㅋㅋ 응.