우선 답부터 말하자면, 어떤 수정을 행해야 하는지에 따라, 자료형을 정하고, 그 자료형을 생성하여, 주어진 데이터를 해당 자료형에 넣어서 해결한다. 우리가 다뤄야 할 문제는 이미 "과거에 일어난 일"을 수정 (By CRUD theorem, we could call this as "Update") 해야 하는가에 대한 문제이다. 예를들면 bracket problem, keylogger problem 등이 있다. 어떤 특정 String 이나 data를 받아서, 이를 "어떤식으로" 수정 해야하는 상황인데, 어떤 수정을 해야하는지에 따라, 주어 진 자료를 어떤 자료형에 넣어야하는지가 바뀐다, 예를들어, Keylogger problem의 경우, 주어진 자료형은 Doubly Linked List였다. 우선 해당 자료..

보다싶이 에러난다, parameter가 void인 constructor는 아예 인수없이 초기화해야한다.

이 내용은 를 참고해서 작성했습니다. 운영체제의 정의 User와 hardware의 interface 소프트웨어 ex) 예를 들어 내가 어떤 게임을 하고 있다 할 때(User가 User application program을 켠다), 이 프로그램은 OS에 의해 메모리로 올라와 프로세스화 되며, 이 프로세스는 당연하게도 어떤 연산을 필요로 할 것이다. 이런 연산은 CPU가 수행한다. 따라서 OS는 현재, 내가(User) 실행하는 프로그램(User application program이 프로세스화 된 것)이 필요로 하는 연산을 수행해야 하는데, 이때 CPU를 나(User)에게 할당해 준다. 따라서 정리하자면, 나는 OS를 통해 hardware를 할당받은 것이다. ex) OS는 여러 일을 하지만, 가장 근본적으론 ..

(*ob1).get(); ob1->get(); 두 statement는 같다. 다만 ob1은 포인터변수로 선언되었기에, 역참조를 해야 해당 메소드를 호출 할 수 있다. 따라서 -> operator는 역참조 연산자가 맞다.

파라미터로 const & 객체를 받을 경우, 해당 객체의 메소드 스코프는 const 메소드로 제한된다. 설령 const가 아닌 메소드를 호출하였을때, 정상적으로 호출 되더라도, 이는 컴파일러의 재량이기 때문에, explicit하게 코딩해야한다.

예시 함수 내부에서 stack memory binding을 한 변수는 레퍼런스로 반환해도 해제되고만다. 따라서 (heap에 할당한 포인터를 반환하는것이 아니라면) 파라미터로 레퍼런스 타입을 받았을때, 해당 객체나 변수를 반환하는 형태가 아니라면 레퍼런스 리턴은 주로 하지 않는다. 그니까 위에서 ostream 객체 레퍼런스로 받았으니까 , 그거 그대로 레퍼런스로 반환하는 형태 아니면 레퍼런스 반환같은거 안한다고 예를들어 객체끼리 +연산자 오버로딩할 때 반환을 레퍼런스로 하지않잖아