1	비공개 손님 … 2019-02-09 15:12:04
	손코딩할때는 뭘로하는게 좋나요

2	비공개 손님 … 2019-02-09 16:21:53
	손은 그냥... 수도코드 하시는게!...

3	비공개 손님 … 2019-02-09 17:02:30
	왠만하면 같은 알고리즘이면 코드를 뭘로짜도 통과되게 하죠 대회라 할지라도 통과만 되면 실행시간이 길던 짧던 상관 없이 먼저낸 사람이 더 좋은거고요 저는 파이썬 지원되면 무조건 파이썬으로 풉니다

4	비공개 손님 … 2019-02-09 17:04:58
	kotlin 가즈아

5	비공개 손님 … 2019-02-09 20:04:13
	파이썬 좋아하시는군요 많은 문법설탕때문에 코딩하기 넘나 편이하죠

6	비공개 손님 … 2019-02-09 20:04:32
	코틀린 ㅎ ㅋ 요새뜨긴하는데 전 ㅎㅎ잘몰겠음요 ㅋ ㅋ

7	비공개 손님 … 2019-02-09 20:07:06
	알고리즘은 언어랑 무관한거니까 수도코드로 푸는 연습 하는게 젤 좋아요. 국내 입사용은 어느회사건 Java 모르면 안되구요. 근데 알고리즘을 특정 언어에 한정해서 묻는건 좀 병신같고, Java 를 묻는다면 언어의 가장 중요한 부분을 묻겠죠. Liskov problem 같은거라던지, GC 의 동작과 원리 같은것들요.

8	비공개 손님 … 2019-02-09 20:08:00
	음 그리고 Java 는 확실히 한물 간 언어인거 맞으니깐, Python 이나 Kotlin 도 곁다리로 해두는게 좋습니다. 솔직히 Java 만 할줄 알아선 요즘은 몸값 높이기 어렵습니다.

9	비공개 손님 … 2019-02-09 20:25:40
	정정하자면, Java 만 해도 몸값 높일 길이 없진 않은데 정말로 잘해야합니다. 잘한다는게, 프로그램 몇개 만들어봤고 이런 수준이 아니라 JVM Internals 까지 세세하게 다 알 정도의 수준이요. World scale problem 을 풀려면 그정도 지식이 필요하거든요.

10	비공개 손님 … 2019-02-10 20:46:47
	코멍님 // 댓글 감사합니다~ JVM internals 세세하게 다알정도면 java 개발자가아니라 jvm개발자라는 말이 어울리겟꾼요. 억대연봉가능합니까? 다음 공부로는 JVM하번 공부하고싶군요. 대통합 측면에서 유일무이하게 성공한 JVM.. 사실 덕분에 엄청편하죠. 흡수하고싶은 기술입니다. 자바는 취업시장에 뛰어들기위해 어쩔수없이 시작하는거고, 이왕하는거 arrayList 따위들하고도 친해질겸 알고리즘을 자바로 풀어보려구요.

11	비공개 손님 … 2019-02-10 22:06:02
	LSP / GC & GC Root / hashCode & equals / new String("") vs "" / auto(boxing & unboxing) data on heap vs on stack immuability & mutability / thread safety problem definition of pure virtual function // interface vs abstract class 이정도만 확실하게 대답할 수 있으면 자바로 밥벌어먹고 사는데 큰 문제 없습니다. 사실 경력 많은사람들도 저런거 대답 잘 못하는 경우 많아요. 그런분들이 만든 앱 1주일 이상 안끄고 계속 돌리면 메모리 터지고 문제 원인 못찾고 막 난리나죠...

12	비공개 손님 … 2019-02-10 22:17:21
	그 뭐 언어가 중요한가열 저한테 오퍼온 회사들 보면, 한가지 프로그래밍 언어만 할 줄 알면 포지션 상관없이 채용하더라구요 언어 보다는 그냥 논리적 사고능력을 중시했음. 그래서 인터뷰 제안 올때도 자기네 회사에서 쓰는 언어 몰라도 된다고, 그냥 주 사용언어 한개만 알려달라구, 인터뷰는 그걸로 진행할 거라고 하더라구요. 게다가 실제로 인터뷰 했던 회사들은 거의 수도 코드 작성으로 테스트 봤음.

13	비공개 손님 … 2019-02-11 11:06:30
	11 // 오 한번 써보겠읍니다. 재밌겠네요. 검토는 꼭 안해주셔도됩니다 ㅎㅎ - LSP 리스코프치환법칙이라는데 그냥 저에게는 상속받은거 boxing가능해야한다 이정도 느낌으로 들리네요. OOP 에서는 당연한걸 굳이 이름붙힌 느낌이랄까요. go처럼 interface based 라면 이름붙힐 필요가 있긴하겠지만요. - GC & GC Root GC 가비지캘릭터는 뜯어본적은 없지만 reference 기준으로 없앤다는건 알고있었습니다. ref cnt 가 0이되어서 이 객체를 참조하는게 없다는게 확실히되면 그때 메모리에서 지우는액션을하고 gc 동작 타이밍은 예측할수 없으며, 수동으로 부를 순 있겠찌만 이자체로 오버헤드를 불러일으키니 각별히 주의해 사용해야한다고 알고있읍니다. 그러고보니 primitive 자료형에 대한 GC의동작은 제가 명확히 모르겠네요. 공부해봐야겠읍니다. GCRoot은 아예모르는 첨들어보네요. - hashCode & equals 객체가 비교될때, equals는 value를 비교하는거고 hashcode는 object의 고유 값을 반환하니 실제로 같은 메모리상에 위치하는 값인지, 아니면 같은 값(represented value)를 갖는 객체인지 보통 모든게 object based인 자바같은 언어에 넘어왓을때 흔히 하는 실수죠. 덤으로 operator equal (==) 의 경우에도 실제 메모리 위치 값으로 비교하죠. - new String("") vs "" 하나는 객체고 하나는 리터럴인데, 더무서운것은 단수히 리터럴로 초기화되는게 아니라, 컴파일러가 함부로 최적화 시켜버리면 "" 로 초기화된 모든 변수가 같은 메모리 위치를 가르키고 있을수 있따는 거죠. 아주아주무서운. 이게 어느언어에서 흔히 일어나는 실수였는데 그게 무슨언어인지는 까먹엇네요 - auto(boxing & unboxing) 진짜 이걸 청므�f을때 너무 섹시하다고 생각했어요. T 인터페이스를 상속한 S의 경우, T로 S를 boxing(인지 unboxing인지 헷갈리네요 -_-^)해서 사용할수있�c. 구글링 찾아보면 바로나오겠는데 진짜 구글하나도안찾고 해보려구여.. 암튼. 둘중에 하나가 아마 상속 위로 올라가서 그 인터페이스(혹은 객체)로 다룰수 잇�뭅째풩� LSP때문에 가능한 일이라고 볼수있죠. 인터페이스(혹은 상속해준객체)의 경우 functino signature. 바이트코드뜯어봤을때 그대로 남아있던 그 signature.. 그걸 기준으로 메모리에 접근하니, (OOP에서 당연한말이죠) 상속된 객체도 그 signature를 그대로 유지하니 너무 당연한 말이죠. 당연히 박싱 언박싱이되어야하고. 근데 언박싱(혹은 S가 T 형인 변수를 강제로 캐스팅할때) 할때는 is instance of 를 �㎨杵峠求째�로 기억합니다. 상위객체로 가는것은 코딩중에도 컴파일러?인텔리센스?린터?가 알아서 검사해줄 수 있지만. 하위객체로 캐스팅하는것은 실제로 그게 가능한지 instanceof로 signature검사한번해줘야 안전하다고 생각합니다. 아니, 아하면 오류가났었나? 가물가물하네요. - date on heap vs. stack 하나는 동적이고 하나는 정적인 변수 를 관리할때 쓰이고. 힙이 동적으로 생성할때 하고 스택은 함수 scope와 따라다니며 다니는데 진짜 이것도 공부할때 재미났던게, return값은 사실 스택에서 popping되면서 유산으로 남겨놓는 그런느낌이라 되게 웃기기도하고 재밋엇네요. (싸실 더 웃겻던건 커널system하고 user process 왔따리갔따리할때 같은소스코드 위치에서 cpu 레지스터 싹다교환하면서) (마치.. 그 비모 인형에서 그 로보트, 자기 배터리 빼고 뚝 떨어지며 새ㅗㄹ운배터리로 교체되는 느낌? ㅋ) 스택오버플로우되어 code영역 침범하는건 구체적으로는 솔직히 잘모르겠읍니다. 이부분도 조만간 공부해야겠네요. - immutability, mutability, thread safety prob. 이뮤터블 뮤터블은 변경가능한거 말씀하시는것같네요. 파이썬에서 개념을 확실히 잡았었었는데요, 단순히 const 붙혀서 변수의 값이 변경되는걸 막거나 변수 자체에 다른 값이 할당되는걸 막는 것이 아닌, 변수에 해당ㄹ하느 ㄴ메모리구조, 객체 구조 자체가 변경불가능한 형태인거죠. 변경하게되면 새로운 메모리를 할당하여 그곳에서 새로 합성을 한뒤에 그 메모리 주소값을 반환해주는 로직을 가지고 있더라구요. 잘못사용하면 메모리 사용 남발 오질테니 이게 필요한 경우는. 이어서 나오는 multi thread / thread safety 가 가장 큰 예가 되겠네요. thread가 언제 어떻게 변수를 조작할지 모르는데, 어떤애는 새로 추가도시킬거고 어떤애는 사용만하는데 이때 불변성을 제공함으로써 누가 맘대로 쓰던간에 읽는건 문제없다는걸 보장하고 쓰기작업하는 thread는 자기만의 새로운 변수를 갖게되어 남하고 충동할일이없고. 이거외에도 synchronized 키워드 있떤데, 이건아마 세마포어로 락킹거는거겠죠. 뜯어보지않아 명확힌 모르겠네요. 세마포어 갯수도 정할수있으려나요? 아마가능하겠�c? 자바인데.. - definition of pure virtual function, interface vs abstract class 순수 가상 함수, pvf는 음.. abstract class안에 있는 내용은 싹비어있는 함수를 말하는걸로 알고있읍니다. interface하고 ab-가 다른것은. interface는 function의 signature, definition만 포함할수잇는반면에 abstract는 몇몇함수도 선언할수 있지요? 대신에 interface는 wrapping용, boxing/casting용으로 단독적으로 선언될 수 있느 ㄴ반면에 asbstract는 무조건 이를 상속하여 구현해야만 사용할 수 있지요 후 힘드네요. 이런거 면접에서 이야기하려면 아예 정형화된 문장으로 정리를 해놓아야겠네요. 핵심키워드 잘 짚어주셔서 감사드립니다 코멍님. 공부열심히하겠습니다.

14	비공개 손님 … 2019-02-11 11:11:11
	12 오 부자되겟습니다님은 근데 사실 한가지이상언어를 잘다루시지 않나요? ㅋㄷㅋㄷ 무튼 감�많募求�. 논리적인거 기르는 것도 중요하고.. 언어를 아주 잘 다루는것도 동일한 수준만큼 중요한거 같습니다. 제가 알고리즘�U으로 나갈건 절대아니다보니 언어로 실질적인걸 만들어내야하는데 api라던지 sugar syntax라던지 같은 hack? 느낌이 나면 좋겠어서요.

15	비공개 손님 … 2019-02-11 13:34:55
	오사방은 능력자니 기만질을 멈추시오

16	비공개 손님 … 2019-02-11 13:35:00
	로사장

17	비공개 손님 … 2019-02-11 15:02:51
	로사장 오사방이 누구시져 차단되서 안보이는건가...

18	비공개 손님 … 2019-02-12 14:18:43
	와 잔디님 개쩐다 ㅋㅋ 시험용이라면 모를까 저는 절대 저렇게 대답 못할거같은데

19	비공개 손님 … 2019-02-12 16:19:06
	boxing, unboxing 은 왜해요? 왜필요해요? 데이터 구조가 상속을 갖으면 무조건 boxing unboxing 구조에요? heap, stack은 왜 두개가 있어요? 뭐가 달라요? 다 heap or stack 으로 하면 안되요? 왜 동적이면 heap 이에요? 정적이면 모두 stack 이에요? 데이터가 heap 있는거랑 stack에 있는거랑 뭐가 달라요 아니면 같아요? heap과 stack 은 언어차원에서 관리하는건가요? 아니면 어디서 그렇게 구분지어서 관리하나요? 왜 그렇게 하는걸까요? ...

20	비공개 손님 … 2019-02-12 20:55:45
	18 앗,, 시험용...

21	비공개 손님 … 2019-02-12 22:01:35
	19 헉 글케 깊게 들어가니까 백지네요.. 감사하게도 덕분에 제가 많이 부족한 부분만 골라 공부할수있게�耆윱求�. boxing unboxing은 단순한 casting이 아니었네요. 제가 넘겨짚고있었읍니다. boxing과 unboxing은 primitive와 object간의 casting 이라고 보면 되겠네요. 필요한 이유는, object로 자료형을 획일화해서 다양한 함수와 컬렉션따위의 클래스 기능을 제공할 수 잇었기 때문이죠. 하지만 이는 .NET 2.0 이후로 generic 개념으로 자유로워진 문제라고 보여지네요. 예전 ArrayList는 Object를 받았는데, Generic 이 가능해지면서 굳이 boxing해서 object화 시키지 않아도 �耭鄕�. 아 결론을 말씀드리면, boxing/unboxing이 필요한이유는 primitive, object 가 필요한 이유와 같겠습니다. 가볍고빠르고, nullable하고 등.. 참고문헌 https://docs.microsoft.com/en-us/dotnet/framework/performance/performance-tips https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/boxing-and-unboxing heap과 stack은 사실 OS구조시간에 load되고 등등만 훑어봤지 제대로 왜 를 꼼꼼히 짚지 못한것같습니다. 과외받는거 같아 기분이 좋네요.. 모르는부분만 짚어주시니 감사할따름.. 우선, heap과 stack은 OS에서 관리하죠. OS개념은 나쁘지 않다고 자신합니다. code영역에 source 올려놓고 pc로 가르키며 하나씩 내려가며 stack을 통해 main() 부터 (혹은 진입점 함수부터) call chaining stack으로 흐름을 관리하고, call단위 즉, 함수가 사라지면 그 함수의 block(scope)에 함께 있던 local var는 register 혹은 간접 메모리 주소등에서 사라집니다. (퍼포먼스상의 이유로 실제로 0을 채우진않더라도 reference는 끊기죠) 이에 반면에 heap에 있는 변수는 (dynamic이라고해야하나요) 자신을 생성한 block(scope)가 끊겨도 사라지지 않습니다. reference만 남아있다면요. 당연히 가변형인건 언급하지 않겠습니다. 이게 가장 큰차이라 느껴졌습니다. static한데 global한것은 data에서 숨쉬죠. scope, 주기가 가장 길게 남아있어야 하니까요. 얘는 레퍼런스가 �M히 없어도 gc가 정리하지도, memory leak이라고도 생각하지 않죠. 제가 만약 apm을 만든다면 data영역에서의 변수 검사는 좀 대충해도되겠네요.. 그나저나 사실 잘모르겠습니다 OS공룡책에 써있으려나요. 한번 읽어볼겠습니다. 왜 굳이 data, heap, stack으로 나누었을까요? 정확히 계산된 필요에 의한것이 아니라, 하다보니 쌓아지고 확립된 룰 인것 같습니다. 마치 처음에는 스택만있다가, 동적으로좀해야겠다, 그러다가 생긴거같은데, 사실 스택의 block들이 각각 확장가능한 메모리를 선언할 수 있었으면 좋았을거같기도합니다. 굳이 메모리 반환 회수 수동으로 할 필요 없을거고... 왜 stack과 heap이 나뉘어졌어야 했느냐, 그 시초에 대한 실마리 주실수 있나요..?

22	비공개 손님 … 2019-02-12 22:06:42
	data/code, heap, stack으로 나뉜 이유는 그 사용처를 보면 명확합니다

23	비공개 손님 … 2019-02-12 22:19:47
	stack은 중간에 있는 메모리의 크기를 늘리거나 줄일 수가 없기 때문에 애초에 동적으로 사용 할 수가 없고 그렇기 때문에 heap을 만든거고 그것이랑 연계해서 생각해보면 stack에 쌓아둔건 spatial locality가 좋기 때문에 cache hit이 잘돼서 속도적으로 우세할 수도 있을테고 파편화를 관리해 줄 필요가 없기 때문에 오버헤드가 더 적고 이런 장점이 있을 것 같은데 heap에 쌓은건 가변적으로 메모리를 사용할 수 있다는 장점이 있을태구요 저도 이런거에 대해 자세히 생각해본적이 없어서 면접에서 물어보면 어떻게 답해야 할지 모르겠네요. 애초에 학부 전공시간 때 아무생각없이 하스스톤하면서 보냈기 때문에 ..

24	비공개 손님 … 2019-02-12 23:23:56
	요건 메모해뒀다가 다시 읽어야지

25	비공개 손님 … 2019-02-13 07:08:55
	감사합니다. 근데 그건 그렇게 나뉜후에 특징이라면 왜 스택은 정적인 구조가 되었죠? 스택에서 지역변수 관리하듯 동적 변수 관리하면 안됐었나요? 그냥 처음에 고정만 필요할거라 생각하고 만들고 배포하다가 후에 필요성을 느끼고 backward compatibility 를 위해 스택과 가장 멀리 떨어져있는 위치에서부터 힙을 만든건가요? 힙같은경우엔 변수 찾으려면 검색하는 시간이 있어 느리죠 스택의 단점은. 회수되면 영영 못찾고. 리턴으로 하나만 줄수있는게 단점이죠. 뭐 여러개를 묶어서 주는것도 가능한데 그건 어디까지나 간접 메모리 어드레싱이라서 레지스터에 값 그대로 남기고 떠나는거랑은 시간적 연산적 차이가 어마어마하겠죠 어마어마까진 아니려나...

26	비공개 손님 … 2019-02-14 21:48:10
	프로그램 카운터를 가장 효율적으로 쓸수 있는게 뭘까요? ㅋ

27	비공개 손님 … 2019-02-15 07:02:56
	와 프로그램 카운터를 “효율��” 으로 쓸 생각은 힌번도 해본적 없네요. 진짜 갈길이 멀군요 ㅠㅠ 프카는. 다음 인스트럭션을 가르키고있는데, JE나 JMP로 뛰어버리면 즉 고투 문이 있으면 안되는거니 최대한 일렬루 쭉 내려가게 만들어야 하려나요??? 혹시 가르쳐주실 수 있나요??

28	비공개 손님 … 2019-02-15 10:50:11
	사실 스택으로 할 수 있는 일은 힙으로도 다 가능하잖아요? '기능'만 보면 상위호환이죠. 그런데도 쓰는건 '기능' 외의 장점이 있다는거죠.

29	비공개 손님 … 2019-02-15 13:03:05
	28 // 스택으로 할 수 있는 일(FILO manner 등)은 힙으로 다 가능하죠. 그럼에도 힙을 쓰는 이유는 세가지 아닌가요? 1. 작업중인 현재 스택(current Thread)가 끝난 뒤에도 context에서 살아 숨쉴 수 있는 변수 2. 1로 말미암아 다른 Thread에서도 이를 이어서 사용할 수 있게. 3. 1이 data 영역에서도 물론 가능하지만, data영역은 동적이 아니기 때문에 효율적이지 못함. 만약 위보다 더 중요한 힙의 쓰임새가 있다면 알려주세요. 만약 위의 이유가 전부라면, 제가 물었떤 질문은 여전히 유효합니다. stack의 반환값을 1개 이상으로 했다면, data영역이 고정이 아니었떠라면. 그럼 heap은 쓸모 없어지는 거같습니다. 첨 개발할때 미처 염두못하고 개발했따가 뒤늦게 붙혔던것 아닐까 그래서 조심스레 생각해본 것 입니다... 마치 MS가 api에 항상 reserved param 두는것처럼.. 그거 넘맘에듬.. 마소진짜멋쟁이..

30	비공개 손님 … 2019-02-15 13:04:04
	28 // 말을 조금더 정리해드리면, 기능적인 한계로 스택에서 힙을 쓰게 되었고, 이외의 성능상의 이슈는 몇몇 스택이 가져야할 기능상의 책임을 벗어났기 때문에 가능한거라 생각합니다.

31	비공개 손님 … 2019-02-15 13:33:31
	> 스택으로 할 수 있는 일(FILO manner 등)은 힙으로 다 가능하죠. > 그럼에도 힙을 쓰는 이유는 세가지 아닌가요? 어법상 힙을 쓰는 이유가 아니라 스택을 쓰는 이유가 나와야 되는거 아닌가요 ㅁㄴㅇㄻㄴㅇ

32	비공개 손님 … 2019-02-15 15:37:03
	스택의 기능 말고 스택이 있어야 하는 이유 있나요? 설마 스페셜 로컬리티때문에요?

33	비공개 손님 … 2019-02-17 11:11:14
	폰노이만 구조 이야기까지 들어가야되는데 암튼 간단하게 말하자면 프로그램카운터는 스택구조가 제일 효율이 좋습니다. 그리고 스택 1프레임 크기랑 CPU 버스폭이 같으면 클럭낭비가 그만큼 줄어들테고요 그리고 heap 이 필요한 이유는 스택 프레임 크기 문제도 있고, 간접 어드레싱 때문에 필요하기도 합니다. 근데 보통 기업에서 이정도까지 물어보진 않아요. 삼성 반도체 부문이나 인텔 취업할거 아니면.

34	비공개 손님 … 2019-02-23 10:59:19
	Go 요