프로그래밍 700

언리얼에서 AnimNotify를 따로 생성해서, ABP의 스테이트머신을 통해 호출하고, 애니메이션을 바꾸어보자. 언리얼의 AnimNotify는 Animation의 실행중 클립을 호출해주는 기능이다. 생성은 다음과 같이 정의한다. AnimNotify로 블루프린트를 생성한다. AnimNotify AnimNotify에서는 위와같은 항목들을 확인할 수 있는데, 각각 GetNotify Name과 Receved_Notify이다. GetNotifyName은 에니메이션 그래프에서 설정할 Notify의 이름을 정의하는것 이고, Received Notify는 정의된 Notify를 실행하였을 때 작동할 동작사항을 이야기 한다. 우리는 AnimNotify를 실행해서 객체의 애니메이션을 실행시킬것 이다. Name에서 위와같이 ..

문제 설명 수포자는 수학을 포기한 사람의 준말입니다. 수포자 삼인방은 모의고사에 수학 문제를 전부 찍으려 합니다. 수포자는 1번 문제부터 마지막 문제까지 다음과 같이 찍습니다. 1번 수포자가 찍는 방식: 1, 2, 3, 4, 5, 1, 2, 3, 4, 5, ... 2번 수포자가 찍는 방식: 2, 1, 2, 3, 2, 4, 2, 5, 2, 1, 2, 3, 2, 4, 2, 5, ... 3번 수포자가 찍는 방식: 3, 3, 1, 1, 2, 2, 4, 4, 5, 5, 3, 3, 1, 1, 2, 2, 4, 4, 5, 5, ... 1번 문제부터 마지막 문제까지의 정답이 순서대로 들은 배열 answers가 주어졌을 때, 가장 많은 문제를 맞힌 사람이 누구인지 배열에 담아 return 하도록 solution 함수를 작..

문제 설명 0 또는 양의 정수가 주어졌을 때, 정수를 이어 붙여 만들 수 있는 가장 큰 수를 알아내 주세요. 예를 들어, 주어진 정수가 [6, 10, 2]라면 [6102, 6210, 1062, 1026, 2610, 2106]를 만들 수 있고, 이중 가장 큰 수는 6210입니다. 0 또는 양의 정수가 담긴 배열 numbers가 매개변수로 주어질 때, 순서를 재배치하여 만들 수 있는 가장 큰 수를 문자열로 바꾸어 return 하도록 solution 함수를 작성해주세요. 제한 사항 numbers의 길이는 1 이상 100,000 이하입니다. numbers의 원소는 0 이상 1,000 이하입니다. 정답이 너무 클 수 있으니 문자열로 바꾸어 return 합니다. 입출력 예 numbers return [6, 10, ..

4.4 C++디자인의 두 가지 원칙 C++에는 근간이 되는 디자인 원칙이 두 가지 있는데, 추상화와 재사용이다. 이 두가지 원칙은 너무나 중요해서 책의 테마로 삼는것 도 고려했을 정도 이다. 이 두 가지 원칙은 여러 문헌과 효율적인 C++프로그램 디자인에서 반복적으로 다루고 있다. 4.4.1 추상화 추상화(abstraction) 원칙은 비유를 통하면 이해하기 쉽다. 예를 들어 거의 모든 집에 하나씩 있는 텔레비전을 생각해보자. 어떻게 켜고 끄는지, 채널은 어떻게 바꾸고, 소리는 어떻게 조절하는지, 스피커나 DVD 플레이어 같은 오디오 장치는 어떻게 연결하는지 등등 텔레비전 사용 방법은 대부분의 사람이 알 고 있다. 하지만 텔레비전이 내부적으로 어떻게 작동하는지 설명할 수 있는 사람은 별로 없다. 공중을 ..

4.3 C++ 디자인의 특징 C++ 프로그램의 디자인은 C++의 몇몇 특징 떄문에 다른 언어보다 좀 더 어렵고 복잡하다. C++에는 너무나 많은 기능이 있다. C언어의 기능을 모두 포함하고 있으면서 객체, 연산자 오버로딩, 예외처리, 템플릿 등 여러 다른 기능이 추가되어있다. 언어크기 자체가 디자인 작업을 벅차게 만든다. C++는 객체지향 언어다. 이 때문에 클래스 계층, 클래스 인터페이스, 객체간 연동이 디자인에 포함된다. 이러한 디자인 방식은 C와 같은 절차적 언어와는 많이 다르다. C++는 공용 코드와 재사용 코드를 설계할 수 있는 많은 기능을 제공한다. 클래스와 클래스 상속 외에도 템플릿이나 연산자 오버로딩을 이용해서 효과적인 디자인을 할 수 있다. C++는 유용한 표준 라이브러리를 제공한다. s..

4.2 프로그램 디자인의 중요성 분석과 디자인 과정을 대충 수행하거나 생략하고 바로 코딩에 들어가고 싶은 경우가 많다. 그 수준이야 어떻든 코드가 컴파일되고 구동되면 뭔가 진도가 나가는 것 같고 마음이 편하다. 반면 프로그램을 어떤 식으로 개발할지 이미 어느 정도 머릿속에 들어 있는데 따로 형식에 맞춰서 문서화하는 것은 시간 낭비처럼 느껴진다. 그리고 문서화는 코딩에 비하면 재미도 ㅇ벗고 지루하다. 하루 종일 문서 작업을 하는것이 프로그래머라면 프로그래머가 되지 않았을지도 모른다. 프로그래머라면 다들 코딩부터 하고 보자는 유혹에 빠지기 쉽다. 하지만 정말 단순한 프로젝트가 아니라면 나중에 문제가 발생할 가능성이 거의 100%다. 사전 디자인 단계 없이도 구현에 성공하려면, 개발자로서의 경험, 공통으로 사..