• 최대한 잘라먹기(Maximal Munch) 는 컴파일러가 코드를 파싱할 때 가장 긴 토큰을 우선적으로 인식하는 방식입니다.
• 이는 형태소 분석(lexical analysis) 과정에서 애매모호한 구문을 어떻게 처리할지를 결정하는 중요한 원칙입니다.

• 컴파일러는 소스 코드를 읽고 토큰(Token) 으로 나누어 의미를 분석합니다.
• 이 과정에서 컴파일러는 가능한 가장 긴 문자열을 하나의 토큰으로 인식하려고 합니다.

• 소스 출처 : C++ gotchas! 및 Internet

• cpp

•  +++++p->*mp
  

• 위의 코드에서 ->* 는 두 가지로 해석될 수 있습니다.

  • 1. -> 와 * 두 개의 연산자로 분리
  • 2. ->* 하나의 연산자로 처리

• 이처럼 해석이 달라질 수 있는 부분이 Maximal Munch에서 발생하는 대표적인 문제입니다.

• cpp

•  list<vector<string>> loves;
  

• 이 코드도 해석이 애매할 수 있습니다.

• 컴파일러는 >> 를 이동 연산자(Shift Operator) 로 잘못 해석할 가능성이 있습니다.

• cpp

•  list< vector<string> > loves;
  

• 위와 같이 공백을 추가하면 명확하게 해석됩니다.

• 같은 코드라도 컴파일러와 버전에 따라 다르게 처리됩니다.

  • Visual C++ 2005 → 컴파일 성공
  • GCC 3.4.2 → 컴파일 오류 발생
  • MINGW/GCC → >> 대신 > > 필요함 (컴파일 오류)
  • C99 컴파일러 → >> 로 인한 오류 발생
  • g++ 4.8, g++ 7.3 → 컴파일 성공

• 이처럼 최신 컴파일러에서는 과거의 오류를 자동으로 해결하는 경우도 있습니다.

• 언어마다 구문 처리 방식이 다르므로, 같은 코드를 작성하더라도 해석이 달라질 수 있습니다.

• Python

  • 공백과 들여쓰기(Tab, Space)가 문법적으로 중요함.

• Java

  • 공백이 비교적 자유로우며, 들여쓰기와 관계없이 코드가 동작함.

• C++에서는 공백이 큰 영향을 미치지는 않지만, 위와 같은 >> 문제처럼 특정 문맥에서는 주의가 필요합니다.

• Maximal Munch는 컴파일러의 토큰 인식 원칙 중 하나로, 애매한 구문을 어떻게 해석할지를 결정하는 역할을 합니다.
• 컴파일러마다 해석이 다를 수 있으며, 최신 버전에서는 해결될 수도 있습니다.
• 구형 컴파일러가 오류를 발생시키는 것이 꼭 잘못된 것은 아닙니다. 애매모호한 코드는 문제를 일으킬 가능성이 있기 때문입니다.
• 표준을 준용하되, 현실적으로 다양한 컴파일러의 동작을 고려해야 합니다.

• Visual C++ 6.0 에서는 double atof(const char *str) 함수만 지원하며, double _wtof(const wchar_t *str) 함수는 제공되지 않습니다.
• 참고로, 정수형(generic-text 타입)은 지원되지만, 뭔가 5% 부족한 느낌이 있습니다.

그래서 직접 함수를 만들어 보았습니다.

• atof() 대신 사용할 수 있도록 VC++ 6.0에서 TCHAR을 지원하는 형식으로 개선 한 함수입니다.
• 만약 VC++ 6.0을 어쩔 수 없이 사용해야 한다면 한 번 활용해 보세요!

• cpp

  
  ////////////////////////////////////////////////////////////////////////// 
  //
  // TTOF2.h
  //
  //  made by j2doll (https://j2doll.tistory.com/102) 
  //  v0.2 : check valiation of input parameter
  //  v0.1 : Initial version ( 9, May, 2007 )
  //  use for visual c++ 6.0 or under version  
  // 
  //////////////////////////////////////////////////////////////////////////
  
  #ifndef _TTOF2_DEFINE
  #define _TTOF2_DEFINE
  
  #if _MFC_VER >= 0x0700
  
  #ifdef _UNICODE
  static double TTOF2(WCHAR *szIn) { return ( _wtof(szIn) ); }; 
  #else
  static double TTOF2(CHAR *szIn) { return ( atof(szIn) ); } 
  #endif 
  
  #else // 6 or under version 
  
  #ifdef _UNICODE
  static double TTOF2(WCHAR *szIn)
  {
  
    if ( szIn == NULL ) 
  
      return 0;
  
    double retVal;
    size_t len = _tcslen( szIn );
  
    if ( len == 0 )
  
      return 0; 
  
    CHAR  * szMBCSBuf = new CHAR [ len + 1 ];
    ASSERT(NULL!=szMBCSBuf); // DEBUG 
  
    WideCharToMultiByte( CP_ACP, 0, szIn, (-1), szMBCSBuf, sizeof(szMBCSBuf), NULL, NULL ); // convert character-set
    retVal = atof( szMBCSBuf ); 
  
    delete [] szMBCSBuf; 
  
    return retVal;
  }
  #else
   static double TTOF2(CHAR *szIn) { return ( atof(szIn) ); } 
  #endif //  _UNICODE
  
  #endif // _MFC_VER >= 0x0700 
  
  #endif // _TTOF2_DEFINE 
  
  //----------------------------------------------------------
  
  

MFC SDI/MDI 프로그램에서 특정 확장자(예: .myc)를 연결하려면,

리소스 편집기에서 IDR_MAINFRAME 항목을 다음과 같이 수정합니다:

MyCalc Windows Application\nSheet\nWorksheet\nWorksheets (*.myc)\n.myc\nMyCalcSheet\nMyCalc Worksheet

이 설정을 통해 .myc 확장자를 프로그램과 연동할 수 있습니다.

해당 리소스는 CMainFrame 클래스가 사용합니다.

• MSXML(Microsoft XML Core Services)은 JScript, VBScript 및 Microsoft 개발 도구로 작성된 응용 프로그램이 Windows 네이티브 XML 기반 응용 프로그램을 구축할 수 있도록 지원하는 서비스 모음입니다.
• 이 서비스는 XML 1.0, DOM, SAX, XSLT 1.0 프로세서, XSD 및 XDR을 포함한 XML 스키마 지원 등 다양한 XML 관련 기술을 지원합니다.

개요

• 모든 MSXML 제품은 OLE Automation(즉, COM의 하위 집합) 구성 요소로 프로그래밍 방식으로 노출됩니다.
• 개발자는 C, C++ 또는 JScript 및 VBScript와 같은 Active Scripting 언어를 통해 MSXML 구성 요소를 프로그래밍할 수 있습니다.
• 그러나 .NET 관리 코드에서 MSXML COM 구성 요소와의 상호 운용은 지원되지 않으며 권장되지 않습니다.

• 모든 COM 구성 요소와 마찬가지로, MSXML 객체는 CLSID 또는 ProgID를 통해 프로그래밍 방식으로 인스턴스화됩니다.
• 각 MSXML 버전은 자체 CLSID 및 ProgID 세트를 제공합니다.
• 예를 들어, IXmlDomDocument, IXmlDomDocument2 및 IXmlDomDocument3 COM 인터페이스를 노출하는 MSXML 6.0 DOMDocument 객체를 생성하려면 ProgID "MSXML2.DOMDocument.6.0"을 사용해야 합니다.

• MSXML은 버전에 독립적인 ProgID도 지원합니다.
• 이러한 ProgID는 버전 번호와 연관되어 있지 않습니다.
• 예를 들어, "Microsoft.XMLHTTP"가 있습니다.
• 이러한 ProgID는 MSXML 1.0에서 처음 도입되었지만, 현재는 MSXML 3.0 객체 및 msxml3.dll에 매핑되어 있습니다.

• MSXML의 다양한 버전은 약간씩 다른 기능 세트를 지원합니다.
• 예를 들어, MSXML 3.0은 XDR 스키마만 지원하며 XSD 스키마는 지원하지 않습니다.
• 반면에 MSXML 4.0, 5.0 및 6.0은 XSD 스키마를 지원하지만, MSXML 6.0은 XDR 스키마를 지원하지 않습니다.
• XML 디지털 서명 지원은 MSXML 5.0에서만 제공됩니다.
• 새로운 XML 관련 소프트웨어 개발을 위해 Microsoft는 MSXML 6.0 또는 네이티브 코드 전용 프로젝트의 경우 경량화된 XmlLite의 사용을 권장합니다.

버전

• MSXML은 Microsoft에서 릴리스하고 지원하는 개별 제품 모음입니다. 주요 버전은 다음과 같습니다:

• 현재 지원 버전:
  • MSXML 6.0: MSXML6은 Microsoft의 최신 MSXML 제품으로, MSXML3과 함께 Microsoft SQL Server 2005, Visual Studio 2005, .NET Framework 3.0, Windows XP 서비스 팩 3, Windows Vista 및 이후 모든 Windows 버전에 포함되어 있습니다. 또한 네이티브 64비트 환경을 지원합니다.
  • 이는 MSXML 3 및 4의 업그레이드 버전이지만, 이전 버전에서 제공하는 레거시 기능을 지원하지 않으므로 완전한 대체는 아닙니다.
  • 버전 6, 4 및 3은 동시에 설치 및 실행될 수 있습니다. MSXML 6은 Windows 9x에서는 지원되지 않습니다.

• MSXML 3.0: MSXML3은 현재 사용 가능한 MSXML 제품으로, msxml3.dll로 표현됩니다.
  • MSXML 3.0 SP2는 Windows XP, Internet Explorer 6.0 및 MDAC 2.7과 함께 처음 출시되었습니다.
  • Windows XP SP2에는 MDAC 2.81의 일부로 MSXML 3.0 SP5가 포함되어 있습니다.
  • Windows 2000 SP4에도 MSXML 3.0이 포함되어 있습니다.
  • 기본적으로 Internet Explorer 6.0, 7.0 및 8.0은 창에 로드된 XML 문서를 구문 분석할 때 MSXML 3을 사용합니다.
  • MSXML 3.0 SP7은 Windows 95에서 지원되는 마지막 버전입니다.
  • Windows XP SP3에는 MSXML 3.0 SP9이 포함되어 있습니다.
  • Windows Vista에도 MSXML 3.0(SP10)이 포함되어 있습니다.

• 이전 버전:

  • MSXML 5.0: MSXML5는 Microsoft Office를 위해 특별히 개발된 바이너리로, 원래 Office 2003에 포함되었으며 Office 2007에도 포함되어 있습니다.
  • Microsoft는 MSXML 5를 Office 2003의 내부 통합 구성 요소로 간주하므로 이 버전에 대한 문서를 공개하지 않았습니다.
  • MSXML 5는 Office 2010에는 포함되지 않았습니다.

• MSXML 4.0: MSXML4는 독립 실행형 SDK로 제공되었으며, 독립 소프트웨어 벤더 및 타사 개발자를 대상으로 했습니다.
• 이는 MSXML3의 업그레이드 버전이지만, MSXML3이 제공하는 레거시 기능을 지원하므로 완전한 대체는 아닙니다.
• 64비트 버전은 제공되지 않았지만, 32비트 프로세스에서는 64비트 운영 체제에서 지원되었습니다.
• 버전 4와 3은 동시에 실행될 수 있습니다.
• MSXML 4.0 SP3은 2009년 3월에 출시된 최신 버전이며, SP2 지원은 2010년 4월에 종료되었고, MSXML 4.0 SP3 지원은 2014년 4월에 종료되었습니다.

• MSXML 2.6: 초기 버전의 MSXML로, msxml2.dll로 표현

• GetProcAddress 함수는 동적 라이브러리(DLL)에서 함수를 동적으로 가져올 때 사용됩니다.
• 이 함수의 두 번째 매개변수인 lpProcName은 LPCSTR 타입으로 정의되어 있으며, 이는 C 스타일의 문자열(char 포인터)을 의미합니다.
• 즉, 함수 이름은 항상 멀티바이트 문자열로 처리되며, 유니코드 문자열을 직접 사용할 수 없습니다.

• 따라서 유니코드 설정에서 함수 이름을 지정할 때도 멀티바이트 문자열을 사용해야 합니다. 예를 들어, 유니코드 설정에서 다음과 같이 작성하면:

cpp

... = (...) GetProcAddress(hMod, _T("Hello"));

• 이 코드는 컴파일되지 않습니다.
• _T("Hello")는 유니코드 문자열이므로, GetProcAddress는 이를 인식하지 못합니다.
• 올바르게 사용하려면 다음과 같이 수정해야 합니다:

cpp

... = (...) GetProcAddress(hMod, "Hello");

• 이처럼 함수 이름은 영문자, 숫자, 일부 특수문자로만 구성되어야 하며, 유니코드 문자를 포함할 수 없습니다.
• 이는 Windows API의 설계 원칙에 따른 것으로, 함수 이름은 국제화되지 않고 영어(English) 를 기반으로 합니다.

• 요약하면, GetProcAddress를 사용할 때는 항상 멀티바이트 문자열로 함수 이름을 지정해야 하며, 유니코드 문자열을 사용할 수 없습니다.

[발췌] 이재규, 2000

• 세 점의 방향판단은 세 점 A, B, C 를 차례로 선분으로 연결할때 그 방향이 시계방향인지, 반시계방향인지를 판단하는 것이다.

• 이때 벡터의 외적을 이용한다.

• 오른손 법칙에 의하여, 세 점의 방향이 시계방향 🔃 일 경우 벡터의 외적은 ➖가 되고, 반시계방향 🔄 일 경우 ➕가 되게 된다.

• 즉, 벡터 외적의 음양 부호에 따라서 판단하게 된다.

• 클래스

Random rnd = new Random();

• 예제

int rndR = rnd.Next(0x00, 0xff); // 0 부터 255 사이의 값을 만드는 경우....

• 원문 : http://www.codeproject.com/dotnet/DetectDotNet.asp

이 글은 C++로 작성된 CDetectDotNet 클래스를 소개하며, 이를 통해 시스템에 설치된 .NET 프레임워크의 존재 여부와 버전을 확인하는 방법을 설명합니다.

주요 기능:

• .NET 프레임워크 존재 확인: IsDotNetPresent() 메서드를 사용하여 시스템에 .NET 프레임워크가 설치되어 있는지 확인합니다.

• 설치 경로 확인: GetInstallRootPath() 메서드를 통해 .NET 프레임워크의 설치 루트 경로를 얻을 수 있습니다.

• CLR 버전 열거: EnumerateCLRVersions() 메서드를 사용하여 시스템에 설치된 CLR(Common Language Runtime) 버전들을 열거할 수 있습니다.

사용 예시:

cpp

#include "DetectDotNet.h"

CDetectDotNet detect;
vector<string> CLRVersions;

cout << "Is .NET present: " << (detect.IsDotNetPresent() ? "Yes" : "No") << endl;

TCHAR szPath[300];
cout << "Root Path: " << (detect.GetInstallRootPath(szPath, 299) ? szPath : "") << endl;

cout << "Number of CLRs detected: " << (int)detect.EnumerateCLRVersions(CLRVersions) << endl;
cout << "CLR versions available:" << endl;
for (const auto& version : CLRVersions) {
    cout << version << endl;
}

구현 원리:

• .NET 프레임워크 존재 확인: mscoree.dll을 LoadLibrary로 로드하고, GetProcAddress를 통해 GetCORVersion 함수의 존재 여부를 확인하여 .NET 프레임워크의 설치 여부를 판단합니다.

• CLR 버전 열거: 레지스트리에서 .NET 프레임워크의 설치 루트 경로를 얻은 후, 해당 경로 내의 하위 디렉토리를 탐색하여 설치된 CLR 버전들을 확인합니다.

이 클래스는 설치 프로그램 등에서 시스템의 .NET 프레임워크 설치 상태를 확인하는 데 유용하게 활용될 수 있습니다.

• SAFEARRAY는 COM 프로그래밍에서 사용되는 배열 구조체로, 다양한 데이터 타입을 담을 수 있습니다.
• 아래는 SAFEARRAY를 생성하고 삭제하는 방법을 설명한 예제입니다.

• 1. SAFEARRAY 생성:
  • 1부터 n까지의 정수를 담는 배열을 생성하려면, SAFEARRAY 포인터와 SAFEARRAYBOUND 구조체를 사용합니다.

  c

  SAFEARRAY *psa = NULL;
  SAFEARRAYBOUND bound[1];
  
  bound[0].lLbound = 1;      // 배열의 시작 인덱스 설정
  bound[0].cElements = 8;    // 배열의 요소 개수 설정
  
  psa = SafeArrayCreate(VT_I2, 1, bound);
  if (psa == NULL) {
      // 메모리 부족 등의 이유로 배열 생성 실패
      throw ERROR_NOT_ENOUGH_MEMORY;
  }
  

  • 위 코드에서 VT_I2는 배열의 요소 타입이 2바이트 정수(short)임을 나타냅니다.
  • SafeArrayCreate 함수는 지정된 타입과 경계를 가진 SAFEARRAY를 생성합니다.

• 2. SAFEARRAY 사용:
  • 생성한 SAFEARRAY를 사용하여 필요한 작업을 수행합니다.

  c

  // 배열 요소에 접근하거나 값을 설정하는 코드 작성
  

• 3. SAFEARRAY 삭제:
  • 사용이 끝난 SAFEARRAY는 메모리 누수를 방지하기 위해 반드시 삭제해야 합니다.

  c

  HRESULT hr = SafeArrayDestroy(psa);
  if (FAILED(hr)) {
      // 배열 삭제 실패
      throw hr;
  }
  

  • SafeArrayDestroy 함수는 SAFEARRAY를 삭제하고, 관련된 메모리를 해제합니다.

• 이러한 방식으로 SAFEARRAY를 생성하고 사용한 후 적절하게 삭제하여 메모리 관리를 수행할 수 있습니다.

@REM ========================================
@REM  ... Delete Debug Intermediate Files
@REM ========================================
@del /S /F /Q "./Debug"
@rmdir /S /Q "./Debug"
@rmdir /Q "Debug"
@exit