블로그는 귀차니즘

  컴퓨터로 프로그램을 만들어보신 분이라면 컴파일러 혹은 인터프리터라는 단어를 한 번쯤은 들어보셨으리라 생각합니다. 그만큼 필수적인 단어이자 프로그램 이죠. 이 프로그램들이 없으면 실행이라는 것 자체가 불가능하니까요. 그럼 이 부분은 어떻게 인식을 하게 될까요?
  아시는대로 컴퓨터는 자동적으로 알아서 프로그램을 생성하는 것이 아니라 코딩을 통한 작동명령을 제시해주어야 합니다. 그렇지 않으면 제대로 동작하지도 않을뿐더러 어떠한 역할을 수행하지도 못하겠지요. 그럼 어떻게 문법적 구문을 인식할까요? 그건 바로 오토마타를 통한 LALR(N), LR(N) 등의 문자열 파싱 방법등으로 처리하곤 합니다. 물론 학교에서만 배운 지식이기에 현재 자주 사용하는 gcc, C++ Builder, VS.net C++ 등의 컴파일러는 더 최신의 기술을 사용할지도 모릅니다. 하지만 기본은 아마도 비슷하겠죠?
  그 문법적 문자열을 인식하는것은 일일히 코딩을 통하여 인식을 할 수도 있겠지만 그 것은 시간적으로도 키보드의 플라스틱으로도 낭비가 아닐 수 없습니다. 왜냐하면 yacc, lex 등의 좋은 툴이 많이 나와있기 때문이죠. 그 것과 더불어 boost에는 spirit 이라는 라이브러리가 존재합니다. 아마도 규모면에서는 약간 적은 프로그램에서 사용될 것 같습니다. 그럼 대충 어떻게 사용하는지 알아볼까요??

CalcExpr.h (Language : cpp)

1. #pragma once
2.  
3. #include <boost/spirit/core.hpp>
4. #include <string>
5.  
6. using namespace boost::spirit;
7.  
8. typedef rule< scanner< wchar_t const * > > Rule;
9.  
10. class CCalcExpr
11. {
12. public:
13.     CCalcExpr(void);
14.     ~CCalcExpr(void);
15.  
16.     static bool TryParse( std::wstring &Str, size_t &ErrIndex );
17. };

CalcExpr.cpp (Language : cpp)

1.  
2. #include "stdafx.h"
3. #include "CalcExpr.h"
4.  
5. CCalcExpr::CCalcExpr(void)
6. {
7. }
8.  
9. CCalcExpr::~CCalcExpr(void)
10. {
11. }
12.  
13. bool CCalcExpr::TryParse( std::wstring &Str, size_t &ErrIndex )
14. {
15.     Rule Expr;
16.     Rule PowOp      = *space_p >> L'^' >> *space_p;
17.     Rule MulOp      = *space_p >> ( ch_p< wchar_t >( L'*' ) | ch_p< wchar_t >( L'/' ) ) >> *space_p;
18.     Rule AddOp      = *space_p >> ( ch_p< wchar_t >( L'+' ) | ch_p< wchar_t >( L'-' ) ) >> *space_p;
19.    
20.     Rule Symbol   = +( range_p( L'A', L'Z' ) | range_p( L'a', L'z' ) );
21.     Rule Function      = ( Symbol >> L'{' >> ( Symbol | real_p ) >> L'}' );
22.     Rule Value      = real_p | ( L'[' >> Function >> L']' );
23.     Rule Element        = ( L'(' >> Expr >> L')' ) | Value;
24.     Rule MinusElement   = ( L'-' >> Element ) | Element;
25.     Rule Factor   = ( MinusElement >> PowOp >> Factor ) | MinusElement;
26.     Rule Term         = ( Factor >> MulOp >> Term ) | Factor;
27.     Expr                = ( Term >> AddOp >> Expr ) | Term | end_p;
28.  
29.     parse_info< wchar_t const * > Parse_Info = parse< wchar_t >( Str.c_str(), Expr );
30.  
31.     if( !Parse_Info.full )  {
32.        
33.         ErrIndex = Parse_Info.length;
34.         return false;
35.     }
36.  
37.     return true;
38. }

  사용은 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의 변수에 에러 위치, 혹은 성공 여부를 채워주게 됩니다. 무척 간편하죠?^^
  필요한데 간단간단하게 제작을하여 사용하려면 이러한 것들을 사용하는 것은 어떻까요?

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  저도 STL에 있어서 많은 것을 알고 있는 사람이 아니고, 아직 미숙하지만 개중에 입출력과 관련해서 유용한 iterator가 있다는 것을 알아 유용하게 사용하고 있습니다. 제가 사용하는 부분은 std::copy 알고리즘에서 std::ostream_iterator를 이용한 개체 내용의 출력부분입니다. 이를 이용한 코드는 저번에도 포스팅이 되었던 내용입니다. 그런데 이 ostream_iterator, istream_iterator에 대하여 Effective STL에서 한 가지 주제가 존재하여서 그에 대한 내용을 보려고 합니다.

iteratorbuf_iterator.cpp (Language : cpp)

1. #include <iostream>
2. #include <algorithm>
3.  
4. int main( int argc, char **argv )
5. {
6.     std::copy( ( std::istreambuf_iterator< char >( std::cin ) ), std::istreambuf_iterator< char >(), std::ostreambuf_iterator< char >( std::cout ) );
7.     return 0;
8. }

  주로 사용은 이렇게 하더군요. 이게 가능한 까닭은 바로 다음과 같은 코드에 있다는 것이 중요합니다.

copy.cpp (Language : cpp)

1. template<class _InIt, class _OutIt>
2. inline
3. _SCL_INSECURE_DEPRECATE
4. _IF_NOT_CHK(_OutIt) __CLRCALL_OR_CDECL copy(_InIt _First, _InIt _Last, _OutIt _Dest)
5. {   // copy [_First, _Last) to [_Dest, ...)
6.     return (_Copy_opt(_CHECKED_BASE(_First), _CHECKED_BASE(_Last), _Dest,
7.         _Iter_random(_First, _Dest), _Ptr_cat(_First, _Dest), _Range_checked_iterator_tag()));
8. }

istreambuf_iterator.cpp (Language : cpp)

1. template<class _Elem,
2.     class _Traits>
3.     class istreambuf_iterator
4.         : public iterator<input_iterator_tag,
5.             _Elem, typename _Traits::off_type, _Elem *, _Elem&>
6. .
7. .
8. .
9. _Elem operator*() const
10. {   // return designated value
11.     if (!_Got)
12.         ((_Myt *)this)->_Peek();
13.  
14.  #if _HAS_ITERATOR_DEBUGGING
15.     if (_Strbuf == 0)
16.         _DEBUG_ERROR("istreambuf_iterator is not dereferencable");
17.  #endif /* _HAS_ITERATOR_DEBUGGING */
18.  
19.     return (_Val);
20. }

ostreambuf_iterator.cpp (Language : cpp)

1. template<class _Elem,
2.     class _Traits>
3.     class ostreambuf_iterator
4.         : public _Outit
5. .
6. .
7. .
8. _Myt& operator=(_Elem _Right)
9. {   // store element and increment
10.     if (_Strbuf == 0
11.         || traits_type::eq_int_type(_Traits::eof(),
12.         _Strbuf->sputc(_Right)))
13.     _Failed = true;
14.     return (*this);
15. }

  Copy 알고리즘에서는 iterator이기 때문에 *연산자를 통하여 값을 읽어오게 되고, ostreambuf_iterator에 = 대입 연산자로 값을 입력하기 때문에 그렇습니다. 실제로 대충 돌아가는 루틴이 눈에 보이시죠?^^. 이 istreambuf_iterator, ostreambuf_iterator와 istream_iterator, ostream_iterator가 다른 점은 기타 점도 있겠지만 출력에 있어서 값을 읽어오고 값을 출력하는 부분이 _Strbuf 를 이용한 직접 액세스 라는 점입니다.

istream_iterator.cpp (Language : cpp)

1. template<class _Ty,
2.     class _Elem = char,
3.     class _Traits = char_traits<_Elem>,
4.     class _Diff = ptrdiff_t>
5.     class istream_iterator
6.         : public iterator<input_iterator_tag, _Ty, _Diff,
7.             const _Ty *, const _Ty&>
8. .
9. .
10. .
11. const _Ty& operator*() const
12. {   // return designated value
13.  
14.  #if _HAS_ITERATOR_DEBUGGING
15.     if (_Myistr == 0)
16.     {
17.         _DEBUG_ERROR("istream_iterator is not dereferencable");
18.         _SCL_SECURE_OUT_OF_RANGE;
19.     }
20.  #else
21.     _SCL_SECURE_VALIDATE_RANGE(_Myistr != 0);
22.  #endif /* _HAS_ITERATOR_DEBUGGING */
23.  
24.     return (_Myval);
25. }

ostream_iterator.cpp (Language : cpp)

1. template<class _Ty,
2.     class _Elem = char,
3.     class _Traits = char_traits<_Elem> >
4.     class ostream_iterator
5.         : public _Outit
6. .
7. .
8. .
9. ostream_iterator<_Ty, _Elem, _Traits>& operator=(const _Ty& _Val)
10. {   // insert value into output stream, followed by delimiter
11.     *_Myostr << _Val;
12.     if (_Mydelim != 0)
13.         *_Myostr << _Mydelim;
14.  
15.  #if _HAS_ITERATOR_DEBUGGING
16.     if (!*_Myostr)
17.     {
18.         _DEBUG_ERROR("ostream_iterator is not dereferencable");
19.         _SCL_SECURE_OUT_OF_RANGE;
20.     }
21.  #else
22.     _SCL_SECURE_VALIDATE_RANGE(*_Myostr != NULL);
23.  #endif /* _HAS_ITERATOR_DEBUGGING */
24.  
25.     return (*this);
26. }

  buf_iterator와 다른 점은 <<, >> 연산자를 통하냐 통하지 않고 직접 액세스 하느냐에 따라 달렸습니다. 이 점 때문에 buf_iterator와 아닌 것의 속도 차이가 분명 존재하게 됩니다. 그래서 별 다른 문제가 존재하지 않고 buf_iterator로써 가능하다면 이 것을 사용하는 것이 속도상으로 좋다는 말이 여기서 나오는 말 일테구요.
  하지만 장점이 있다면 단점도 존재하겠죠??

Error.cpp (Language : cpp)

1. #include <iostream>
2. #include <algorithm>
3.  
4. int main( int argc, char **argv )
5. {
6.     std::copy( ( std::istreambuf_iterator< char >( std::cin ) ), std::istreambuf_iterator< char >(), std::ostreambuf_iterator< int >( std::cout ) );
7.     return 0;
8. }

  이 코드를 실행해 보면 에러가 발생합니다. 그 이유는 바로 rdbuf 개체를 통한 직접 액세스를 std::cout 에서 하기 때문에 그렇습니다. 대충 이러한 오류가 발생하는 까닭은 std::cout이 다음과 같이 정의 되어있기 때문인것 같습니다.

cout.cpp (Language : cpp)

1. __PURE_APPDOMAIN_GLOBAL extern _CRTDATA2 ostream cout;

ostream.cpp (Language : cpp)

1. typedef basic_ostream<char, char_traits<char> > ostream;

  위와 같이 정의가 되어있는데 basic_ostream이 int 형으로 됨으로 인하여 생성되는 Class 는  typedef basic_ostream<_Elem, _Traits> ostream_type; 와 같은 형태인데. 이 형태를 int 형 buf_iterator 내부에 존재하는 클래스와 호환이 안되기 때문에 그런 것 같군요.
  정확한 이유는 한 번 제대로 따라가봐야 할 것 같은데, 일단 결론만 얘기하자면 ostream_iterator는 int 형태로 잡아주어도 출력이 가능합니다. 위에 언급한 바와 같이 <<, >> 연산자로써 std::cout << 1; 을 실행하는 것과 동일하게 처리가 된다고 보시면 되니까요.

  buf_iterator 와 아닌 것의 차이를 대충 보았는데, 간단한 몇 자의 타자의 차이임에도 불구하고 속도의 차이가 벌어질 수 있다는 점. 놓칠 수 없다고 생각되지 않나요?^^. 하나하나 살펴보다 보면 모든 부분을 정복할 수 있을 것이라 생각이 드는군요^^;

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  boost::shared_ptr 에 대해서는 이미 아시고 계실테고, 관심이 더욱 있으신 분, 혹은 이미 아시는 분들은 boost::scoped_ptr 에 대해서도 알고 계실겁니다. 그런데 C++ 에도 표준으로 원래 존재하는 Smart Pointer가 존재합니다. 그 이름은 auto_ptr<> 입니다. 어떤 것이냐구요??

autoptr.cpp (Language : cpp)

1. #include <memory>
2. #include <iostream>
3.  
4. int main(int argc, char **argv)
5. {
6.     std::auto_ptr< int > aa( new int );
7.  
8.     *aa = 100;
9.  
10.     std::cout << *aa << std::endl;
11.  
12.     return 0;
13. }

  대충 이렇게 사용합니다. 그럼 scope를 벗어 날때 auto_ptr의 ~소멸자가 호출됨으로 인하여 해당 보관 메모리를 해제하게 됩니다. 그런데 사용은 아주 간단하게 보이지만 신경 써주어야하는 점이 몇가지 있습니다. 무엇인가 하면 new와 new [], delete, delete []의 차이점 때문이죠.

~auto_ptr.cpp (Language : cpp)

1. ~auto_ptr()
2. {   // destroy the object
3.     if (_Myptr != 0)
4.         delete _Myptr;
5. }

  소멸자에서 사용하는 부분이 delete [] 가 아닌 delete이기 때문에 실질적으로 생성자에서 new int 가 아닌 new int[ 100 ] 과 같은 구문을 사용하였을때, 하나의 개체를 제외하고는 소멸자가 호출되지 않습니다. 그리고 할당된 개체가 int, double 등의 기본 타입이 아닌 메모리를 또 개별적으로 관리하는 개체일 경우는 더 큰 문제가 발생하게 되겠죠.
  또 하나 생길 수 있는 문제점이란 무엇일까요?? 바로 = operator overloading으로 인한 소유권 이전에 대한 문제점입니다.

auto_ptr.cpp (Language : cpp)

1. auto_ptr<_Ty>& operator=(auto_ptr<_Ty>& _Right) _THROW0()
2. {   // assign compatible _Right (assume pointer)
3.     reset(_Right.release());
4.     return (*this);
5. }
6.  
7. void reset(_Ty* _Ptr = 0)
8. {   // destroy designated object and store new pointer
9.     if (_Ptr != _Myptr && _Myptr != 0)
10.         delete _Myptr;
11.     _Myptr = _Ptr;
12. }

  이렇게 구현이 되어있기 때문에 _Right에 해당하는 개체는 _Myptr이 삭제 되고, 해당 개체가 소유권을 이전 받기 때문에 문제점이 존재할 여지가 있습니다.
  어떤 부분에서냐고 물어보신다면 물론 이 것이 STL Container 과 같은 부분에서 사용이 되거나, 코드 도중 사용이 된다면 소유권이 넘어감으로 인하여 예상치 못한 점이 발생할 수 있다는 점이죠. 물론 코딩을 하는 사람치고 이런 것을 알아보지 않고 바로 사용하는 경우는 거의 없겠지만, 보통의 경우를 생각하고 코딩할 경우는 무척 문제가 될 수 있습니다. 실제로 STL Container의 경우 내부에서 대입문이 존재하는 알고리즘을 사용했을 때, 개체에 대한 메모리가 존재하지 않는 경우가 생깁니다. 이는 프로그램이 예상대로 동작하지 않는다는 소리가 됩니다. 그로인해 프로그램은 오작동 혹은 버그가 생길테구요.
  이러한 점을 보았을 때엔, 편리하지만 문제점이 존재하는 소스 양날의 검이 되지 않기 위해선 사용하기 이 전에 파악을 먼저하고 사용해야 하지 않을까 하는 생각이듭니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  오늘 정말 희한한 현상을 겪게 되었습니다. 그게 뭐냐하면 바로 C#의 Main단에서 Try-Catch 구문을 걸었는데 제대로 Catch가 걸리지 않았던 것이죠. 그 때는 참 황당했습니다. 왜냐구요? Visual Studio.Net을 C++개발자 타입으로 설정하였을 때, 디버그 모드로 프로세스를 실행하면 Catch까지 잘 걸리는데, 단독 프로세스로 실행했을 경우엔 Catch에 제대로 걸리지 않더군요. Application.Run 내부적으로 처리하는 것 같았습니다.

Program.cs (Language : csharp)

1. using System;
2. using System.Collections.Generic;
3. using System.Linq;
4. using System.Windows.Forms;
5.  
6. namespace WindowsFormsApplication3
7. {
8.     static class Program
9.     {
10.         /// <summary>
11.         /// The main entry point for the application.
12.         /// </summary>
13.         [STAThread]
14.         static void Main()
15.         {
16.             try
17.             {
18.                 Application.EnableVisualStyles();
19.                 Application.SetCompatibleTextRenderingDefault(false);
20.                 Application.Run(new Form1());
21.             }
22.             catch
23.             {
24.                 MessageBox.Show("테스트 Catch");
25.             }
26.         }
27.     }
28. }
29.  

Form1.cs (Language : csharp)

1. using System;
2. using System.Collections.Generic;
3. using System.ComponentModel;
4. using System.Data;
5. using System.Drawing;
6. using System.Linq;
7. using System.Text;
8. using System.Windows.Forms;
9.  
10. namespace WindowsFormsApplication3
11. {
12.     public partial class Form1 : Form
13.     {
14.         public Form1()
15.         {
16.             InitializeComponent();
17.         }
18.  
19.         private void button1_Click(object sender, EventArgs e)
20.         {
21.             string aa = null;
22.             aa.Substring(0);
23.         }
24.     }
25. }
26.  

  코드는 대충 위와 같았습니다. Program.cs 에서 Application.Run으로 폼을 표시하고 내부적으로 메시지 펌핑(?)을 하게 될거라 생각을 한 후, Form1에서는 고의적으로 익셉션을 발생시키게 하였습니다. 여기서 바로 문제가 발생합니다. 어떤 거냐구요? Debug 모드로 실행을 한 번 해보시고, 단독 모드로 실행을 한 번 해보십시오. 단독으로 실행을 하면 C#의 기본 Exception MessageBox(?)가 뜰거에요. 절대 메시지 박스가 뜨지 않습니다.
  그래서 결국 구글링을 하다가 찾게 된 페이지에서 하나의 해결책을 발견하고 적용시켜보니 제대로 작동이 되었습니다.


  찾은 코드를 한 번 적용 시켜 보겠습니다. 그럼 Program.cs에 존재하는 코드에 한 줄이 추가됩니다.

Program.cs (Language : csharp)

1. using System;
2. using System.Collections.Generic;
3. using System.Linq;
4. using System.Windows.Forms;
5.  
6. namespace WindowsFormsApplication3
7. {
8.     static class Program
9.     {
10.         /// <summary>
11.         /// The main entry point for the application.
12.         /// </summary>
13.         [STAThread]
14.         static void Main()
15.         {
16.             try
17.             {
18.                 Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
19.                 Application.EnableVisualStyles();
20.                 Application.SetCompatibleTextRenderingDefault(false);
21.                 Application.Run(new Form1());
22.             }
23.             catch
24.             {
25.                 MessageBox.Show("테스트 Catch");
26.             }
27.         }
28.     }
29. }
30.  

  Application.SetUnhandledExceptionMode를 ThrowException으로 설정하도록 하니 단독 모드에서도 테스트 Catch 메시지 박스 코드가 존재하는 Catch가 걸립니다. 아마도 추측하기론 Run 내부에서 Try-Catch를 설정하는 듯도 보이는 군요. 30분 정도 이 것때문에 삽질을 하긴 했지만 다음에 이런 일이 발생했을 때는 아주 유용할 것이라 생각합니다.^^

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  정신이 약간 오락가락 하네요. 너무 놀아서 그런가 봅니다. 오늘 12시쯤 회사로 출근을 하여 웹 서핑중 boost 의 1.35 버젼 릴리즈 소식이 보이더군요. 개인적으로 엄청 좋아하는 라이브러리이다 보니 반갑기 그지 없었습니다. 자자 어떤게 업데이트 되었냐구요??

  대충 살펴보니 좋은게 많이 추가된 것 같습니다. 에구 있는 것도 다 파악 못했는데, 아주 주르르륵 쏟아져 나오는군요. 조금씩 살펴보면서 적재적소에 사용을 해봐야겠습니다. 회사에서 건네받은 다른회사가 진행하고 제가 유지보수 해야 될 프로젝트 부분을 보니 std::lexical_???? 쪽 함수를 사용하더군요.
  마음이 설레어 옵니다^^;

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.