회사에서 Borland C++ 6.0 Enterprise 버젼으로 기존에 존재하던 프로그램을 수정해야 할 일이 생겼는데 어떻게 하다보니 기존에 없던 새로운 디자인의 컨트롤을 제작하여 사용해야 하는 것이었습니다. 그렇게 대단한 일도 아니고 고급 기능을 원하는 컨트롤도 아니라서 일단 제작을 하다보니 대충대충 해도 쉽게 되더군요. 그래서 정리해 보기로 했습니다.
1. Codegear Package 생성
일단 VCL 컴포넌트를 만들기 위해서 Package를 생성해야 합니다. 그렇지 않고 따로 하는 것은 딱히 잘 모르겠네요. 일단 이 방법으로 하여 컴포넌트 설치까지는 무난하게 진행 되니 따라 하시면 될것 같습니다.
2. Package 프로젝트를 이름 지정하여 저장
패키지를 선택하여 생성버튼을 누르면 해당 프로젝트에 대해서 VS.net 처럼 프로젝트의 이름을 바로 묻는 것이 아니기에 추가할 때는 임시로 이름을 붙이고, 저장할 때 해당 파일을 저장하게 되며, 그 파일 내부의 동일 클래스명은 자동으로 바꿔집니다. 일단 Codegear 에서는 추가하면 저장하는 기능을 먼저 생각하는 것이 좋더군요.
3. 컴포넌트 생성
이제 컴포넌트를 생성해야 합니다. New -> Other 메뉴로 들어가시면 해당 창이 표시되며 해당 창에서 보나마나 설명할 것도 없이 Component 를 선택 후 OK 버튼을 살포시 눌러줍니다.
4. 기본 베이스 컴포넌트 선택하기
컴포넌트를 제작하기 위해 기본 Base Class 로 사용할 컴포넌트를 선택하는 화면 입니다. 여기서 선택하는 클래스가 기본 클래스로 등록되며 이 클래스의 동작에 많은 영향을 받게 됩니다. 그래서 하나를 신중히 생각하고 비슷한 쪽으로 선택을 하면 되겠습니다. 전 일단 TGroupBox 를 선택해봤습니다.
5. 컴포넌트 이름 지정하기
해당 컴포넌트를 생성했으므로 이 컴포넌트가 폼에 컨트롤을 배치할 때 어떤 팔레트 위치에 어떤 이름으로 존재하게 될 것인지를 지정하게 됩니다. 이 부분에서 이상하게 지어버린다면 평생 이 컴포넌트가 존재하고 사용되는한 이상한 이름으로 되겠죠^^ 신중히 선택해 줍시다.
6. 컴포넌트 저장하기
프로젝트와 마찬 가지로 컴포넌트를 추가한 다음에도 따로 저장버튼을 눌러 파일을 저장해주어야 합니다. 저도 이게 맞는 건지 아님 다른 방법이 있는 것인지는 모르겠지만 약간 불편한 것 같긴 하군요.
7. 코드 추가하기
일단 GroupBox 자체에서 Paint 메소드가 virtual 함수로 지정되어 있었고, 수정이 가능하기에 간단하게 이를 override 하여 기존에 존재하던 그룹박스의 이미지를 제거하고 문자열을 간단히 추가하도록 해봤습니다. 그런 다음 컴파일을 하여 인스톨 하면 됩니다.
8. 컴파일 후 인스톨 하기
Build 메뉴 혹은 Make 메뉴를 선택하시고 Install 메뉴를 선택하시면 해당 패키지가 설치 됩니다. 만약 에러가 있다면 문법적 에러가 있을 것이고 해당 에러를 제거하신 뒤, 다시 설치하시면 됩니다.
9. 컴포넌트 사용하기
이제 컴포넌트를 사용해 보는 일이 남았군요. 일단 New -> Form 을 클릭하신 다음 폼이 새로 추가 되면 오른쪽 아래 Tool Palette에서 TTestGroupBox 를 찾아 선택 후 창에 배치를 해봅시다. 짜잔~ 해당 창에 우리가 만든 TTestGroupBox가 배치 되었습니다. 해당 작동 그대로 "테스트"라는 문자열도 출력이 되는군요.
이러한 방법을 통한 컴포넌트를 쉽게 생성해서 추후 원하는 GUI작업을 편하게 할 수 있을것이라 생각이됩니다^^. 편리한 방법이 계속해서 늘어나는 군요. 그럼 오늘도 즐거운 하루 되세요^^.
http://www.filewiki.net/tc/entry/PSP-개발-AppWizard 여기서 해당 설정방법은 참고를 해주시고, 동일한 방법으로 설치하시면 됩니다. 변경사항은 저번에 올렸던 AppWizard가 *.cpp, *.c 파일에 대하여 적용이 가능하게 한게 아니라 main.c 혹은 main.cpp 파일에만 컴파일 등록이 되어 있어 수동적으로 바꾸어 주어야하는 면이 존재했던 것을 수정하였습니다. 그리고 기존 main.cpp가 program.cpp 로 바뀌었고, main.cpp / main.h 파일은 싱글톤 인터페이스를 이용한 클래스 Wrapping을 해놓았습니다. Run 함수의 //ToDo : My Work 부분에서 원하는 작업을 추가하시면 될거구요. 그리고 중요한 것인데 해당 라이브러리에 있어서 종속성 문제가 발생할 수 있습니다. 개발을 하다보면 다음과 같은 라이브러리들이 필요할 수도 있는데요. 알아보자면.
해당 라이브러리의 문제점을 해결하기 위하여 Library 파일에 LIBS를 추가하도록 해놓았습니다. 기본 라이브러리 추가 방법은 만약 libpspnet.a 라이브러리를 참고하고자 할 때에는 -lpspnet 으로 LIBS 에 덧붙여주시면 됩니다. 그리고 한 가지 유의하셔야 할 점이 기본적으로 -lstdc++ 를 통하여 C++ 지원이 되도록 해놓았는데, 컴파일 옵션을 보면 -fno-exceptions, -fno-rtti를 지정해놓았으므로 Exception인 throw와, typeid를 사용하면 에러가 발생합니다. 이점 유의하시고 개발하시면 될 것 같네요. 그럼 전 이만 설정은 그만하고 개발 하러 가봐야겠습니다^^.
대단하긴요.. 설마 그렇겠습니까^^;;
아직 많이 멀었는데요..
어젠 sceGumDrawArray 를 이용한 폰트 출력 샘플이 있길래 보고 있는 중인데, 출력 형식이 어떻게 되는지 이해가 잘 되지 않더라구요.
font.raw 파일이 자동으로 읽혀 출력이 되는건가 하기도 합니다.
일단 이게 먼저 해결이 되어야 프로그램을 만들 수 있을것 같네요..
어제 올렸던 Psp AppWizard 부분에서 cpp 파일임에도 불구하고 C++ 문법이 제대로 컴파일 되지 않는 문제가 발생하였습니다. 그 문제는 아래와 같은 구문입니다.
new, delete 가 C++의 기본 문법임에도 불구하고 컴파일이 되지 않더군요. 그 이유는 operator new, operator delete, operator new[], operator delete[]에 해당하는 연산자 정의와 라이브러리의 정보를 찾을 수 없었던 것 때문이었습니다. 그래서 저 같은 경우 C 보다는 C++이 복잡한 프로그램을 짤 때 더 깔끔하고 괜찮다고 생각하기 때문에 C++ 프로그래밍을 위하여 저 문제를 해결해보려고 했습니다. 그리고 결국 문제점을 찾을 수 있었구요. 일단 해당 문제는 Makefile 에서 종속 라이브러리를 추가할 때 생기는 문제점으로 판명되었습니다. 이거 AppWizard에서 체크 박스로 종속 라이브러리를 선택할 수 있도록 수정을 해야 될지도 모르겠습니다. 간단하게 시작한 일이 결국 복잡하게 되는군요. 일단 이렇게 저렇게 해서 C++ 구문 컴파일이 되는 것 까지는 확인을 했습니다. 하지만 Class 파일을 생성하여 컴파일하는 쪽에서는 여전히 문제가 발생하는 군요.
일단 해당 문제를 해결한 다음 Psp AppWizard 1.1 버젼을 만들어서 올려봐야겠습니다.
컴퓨터로 프로그램을 만들어보신 분이라면 컴파일러 혹은 인터프리터라는 단어를 한 번쯤은 들어보셨으리라 생각합니다. 그만큼 필수적인 단어이자 프로그램 이죠. 이 프로그램들이 없으면 실행이라는 것 자체가 불가능하니까요. 그럼 이 부분은 어떻게 인식을 하게 될까요? 아시는대로 컴퓨터는 자동적으로 알아서 프로그램을 생성하는 것이 아니라 코딩을 통한 작동명령을 제시해주어야 합니다. 그렇지 않으면 제대로 동작하지도 않을뿐더러 어떠한 역할을 수행하지도 못하겠지요. 그럼 어떻게 문법적 구문을 인식할까요? 그건 바로 오토마타를 통한 LALR(N), LR(N) 등의 문자열 파싱 방법등으로 처리하곤 합니다. 물론 학교에서만 배운 지식이기에 현재 자주 사용하는 gcc, C++ Builder, VS.net C++ 등의 컴파일러는 더 최신의 기술을 사용할지도 모릅니다. 하지만 기본은 아마도 비슷하겠죠? 그 문법적 문자열을 인식하는것은 일일히 코딩을 통하여 인식을 할 수도 있겠지만 그 것은 시간적으로도 키보드의 플라스틱으로도 낭비가 아닐 수 없습니다. 왜냐하면 yacc, lex 등의 좋은 툴이 많이 나와있기 때문이죠. 그 것과 더불어 boost에는 spirit 이라는 라이브러리가 존재합니다. 아마도 규모면에서는 약간 적은 프로그램에서 사용될 것 같습니다. 그럼 대충 어떻게 사용하는지 알아볼까요??
사용은 boost가 흔히 그렇듯이 boost에 속하는 hpp 파일을 include 시켜주어야 합니다. 목적 헤더파일은 core.hpp 파일입니다. 이 boost::spirit이 지원하는 부분은 문법을 분석하고 문법이 실행되는 것 까지 지원되나, 제가 거기까지는 사용을 못해봤으므로 일단 입력 문자열이 맞는지 검사하는 부분으로 진행하겠습니다. 일단 문자열이 파싱이 되느냐 되지 않느냐를 판단하기 위해서는 Rule 이라는 것이 필요합니다. 이 것이 무엇이냐 하면 오토마타때 배우는 EBNF( Extended Backus Naur Form )와 동일하게 생각하시면 됩니다. 즉 하나의 룰이 하나의 Non-Terminal을 표현한다고 보시면 됩니다. 위 코드는 제가 IPangYa 라이브러리에서 계산수식을 인식하여 정확한 것인지 파악하기 위하여 작성하였던 코드입니다. 나름 고생도 했죠. 룰을 만들기 위해서는 Rule 형태의 변수를 선언을 하게 되고 = 연산자 우측엔 >> 로 이루어진 룰의 조합이 존재하면 됩니다. 예를 들면 ch_p< wchar_t >( L'+') >> L'(' 이렇게 된다면 +( 이라는 문자열을 인식하는 룰이됩니다. C++ 에 존재하는 라이브러리 답게 *, | 연산자들을 오버로딩 하여 룰을 C++ 문법으로 간단히 표현할 수 있도록 제작이 되어있습니다. 그러므로 Expr에서 (abcc)*, (abcc)+ 와 같은 문자열 형식을 인식할 수 있습니다. 물론 ParseTree가 제작되기 위하여 *, /, +, - 등의 연산자 오버로딩을 정해주기 위하여 룰의 위치, 순서들을 먼저 조절 해주어야 합니다. 그게 약간의 사용법에 있어서 어려움이 될 수도 있습니다. 종이의 룰은 그냥 적으면 되지만 OOP라고는 하지만 내부 함수는 절차지향이니 그 순서를 생각한다면 반대로 생각해야할 부분도 있기 때문이죠. 만약 이러한 작업들을 통하여 Rule이 생성되었다면 boost의 parse 함수를 이용하여 최상위 룰과, 입력 문자열을 같이 넣어준다면 작업을 수행하고, parse_info의 변수에 에러 위치, 혹은 성공 여부를 채워주게 됩니다. 무척 간편하죠?^^ 필요한데 간단간단하게 제작을하여 사용하려면 이러한 것들을 사용하는 것은 어떻까요?
저도 STL에 있어서 많은 것을 알고 있는 사람이 아니고, 아직 미숙하지만 개중에 입출력과 관련해서 유용한 iterator가 있다는 것을 알아 유용하게 사용하고 있습니다. 제가 사용하는 부분은 std::copy 알고리즘에서 std::ostream_iterator를 이용한 개체 내용의 출력부분입니다. 이를 이용한 코드는 저번에도 포스팅이 되었던 내용입니다. 그런데 이 ostream_iterator, istream_iterator에 대하여 Effective STL에서 한 가지 주제가 존재하여서 그에 대한 내용을 보려고 합니다.
주로 사용은 이렇게 하더군요. 이게 가능한 까닭은 바로 다음과 같은 코드에 있다는 것이 중요합니다.
Copy 알고리즘에서는 iterator이기 때문에 *연산자를 통하여 값을 읽어오게 되고, ostreambuf_iterator에 = 대입 연산자로 값을 입력하기 때문에 그렇습니다. 실제로 대충 돌아가는 루틴이 눈에 보이시죠?^^. 이 istreambuf_iterator, ostreambuf_iterator와 istream_iterator, ostream_iterator가 다른 점은 기타 점도 있겠지만 출력에 있어서 값을 읽어오고 값을 출력하는 부분이 _Strbuf 를 이용한 직접 액세스 라는 점입니다.
buf_iterator와 다른 점은 <<, >> 연산자를 통하냐 통하지 않고 직접 액세스 하느냐에 따라 달렸습니다. 이 점 때문에 buf_iterator와 아닌 것의 속도 차이가 분명 존재하게 됩니다. 그래서 별 다른 문제가 존재하지 않고 buf_iterator로써 가능하다면 이 것을 사용하는 것이 속도상으로 좋다는 말이 여기서 나오는 말 일테구요. 하지만 장점이 있다면 단점도 존재하겠죠??
이 코드를 실행해 보면 에러가 발생합니다. 그 이유는 바로 rdbuf 개체를 통한 직접 액세스를 std::cout 에서 하기 때문에 그렇습니다. 대충 이러한 오류가 발생하는 까닭은 std::cout이 다음과 같이 정의 되어있기 때문인것 같습니다.
위와 같이 정의가 되어있는데 basic_ostream이 int 형으로 됨으로 인하여 생성되는 Class 는 typedef basic_ostream<_Elem, _Traits> ostream_type; 와 같은 형태인데. 이 형태를 int 형 buf_iterator 내부에 존재하는 클래스와 호환이 안되기 때문에 그런 것 같군요. 정확한 이유는 한 번 제대로 따라가봐야 할 것 같은데, 일단 결론만 얘기하자면 ostream_iterator는 int 형태로 잡아주어도 출력이 가능합니다. 위에 언급한 바와 같이 <<, >> 연산자로써 std::cout << 1; 을 실행하는 것과 동일하게 처리가 된다고 보시면 되니까요.
buf_iterator 와 아닌 것의 차이를 대충 보았는데, 간단한 몇 자의 타자의 차이임에도 불구하고 속도의 차이가 벌어질 수 있다는 점. 놓칠 수 없다고 생각되지 않나요?^^. 하나하나 살펴보다 보면 모든 부분을 정복할 수 있을 것이라 생각이 드는군요^^;
댓글을 달아 주세요