즉, 바이트 단위로 크기가 같은 정수 타입의 변수는 바이트 단위의 정보 손실 없이 서로에게 전달할 수 있습니다.
즉, 전문가 어드바이저는 울롱 타입의 마법 숫자를 허용하지만 프로그램에서 항상 긴 형식, 즉 서명된 형식으로 설정하고 읽을 수 있습니다.
2. 이제 <some_type>과 uchar를 살펴보십시오. 예를 들어 int. sizeof(int) 에서 알 수 있듯이 크기는 4바이트입니다. 즉, 메모리에 있는 이 4바이트는 uchar[4] 배열로 쉽게 표현할 수 있습니다 이중 ( 8바이트 )이 있으면 uchar[8] 배열로 표현할 수 있습니다 이것은 문자열의 바이트에도 적용됩니다 - MQL에서는 ushort 배열입니다. 따라서 모든 유형의 구조가 있으면 모든 데이터를 uchar 배열로 쉽게 제공할 수 있습니다.
MQL5 버전에서 사용되는 바이트에 대한 기본 개념은 메모리 CFastFile의 가상 파일입니다. 모든 데이터를 uchar 배열 메모리에 저장합니다.
즉, 외부 프로그램과 데이터를 교환할 필요가 없는 경우입니다. 또는 인터넷 페이지 읽기와 같은 데이터 스트림의 형태로 다른 프로그램에서 데이터를 수신하고이 데이터를 모두 디스크에 저장할 필요가없는 경우 Windows 매핑 대신 CFastFile을 사용하는 것이 좋습니다.
'GetLastError' - ambiguous call to overloaded function with the same parameters SymbolInfo.mqh 718 10
'GetLastError' - ambiguous call to overloaded function with the same parameters SymbolInfo.mqh 725 57
저는 대단한 프로그래머가 아닙니다. 하지만 보편성이 어디에 있는지 이해가 안 되네요. uchar는 사용자를 제한하기 때문에 보편적일 수 없습니다: uchar는 양수 값만 사용할 수 있습니다. 최소값은 0이고 최대값은 255입니다.
uchar 값을 초과하는 모든 데이터는 uchar의 최대값 또는 최소값과 같게 됩니다.
제가 말씀드린 내용을 바탕으로 처음부터 "int 또는 double을 전달하는 방법"을 물었습니다. 이해가 안 돼요, 과장님.
좋아, 그럼 잠깐 둘러보겠습니다.
1. char와 uchar의 예를 들어보겠습니다. 두 변수의 크기는 모두 1바이트입니다.
즉, 서로에게 할당해도 바이트가 손실되지 않으므로 원래 데이터의 값이 손실되지 않습니다.
다음 표현식을 보세요.
롱/울롱, 인트/유인트도 마찬가지입니다.
즉, 바이트 단위로 크기가 같은 정수 타입의 변수는 바이트 단위의 정보 손실 없이 서로에게 전달할 수 있습니다.
즉, 전문가 어드바이저는 울롱 타입의 마법 숫자를 허용하지만 프로그램에서 항상 긴 형식, 즉 서명된 형식으로 설정하고 읽을 수 있습니다.
2. 이제 <some_type>과 uchar를 살펴보십시오.
예를 들어 int. sizeof(int) 에서 알 수 있듯이 크기는 4바이트입니다. 즉, 메모리에 있는 이 4바이트는 uchar[4] 배열로 쉽게 표현할 수 있습니다
이중 ( 8바이트 )이 있으면 uchar[8] 배열로 표현할 수 있습니다
이것은 문자열의 바이트에도 적용됩니다 - MQL에서는 ushort 배열입니다.
따라서 모든 유형의 구조가 있으면 모든 데이터를 uchar 배열로 쉽게 제공할 수 있습니다.
MQL5 버전에서 사용되는 바이트에 대한 기본 개념은 메모리 CFastFile의 가상 파일입니다. 모든 데이터를 uchar 배열 메모리에 저장합니다.
즉, 외부 프로그램과 데이터를 교환할 필요가 없는 경우입니다. 또는 인터넷 페이지 읽기와 같은 데이터 스트림의 형태로 다른 프로그램에서 데이터를 수신하고이 데이터를 모두 디스크에 저장할 필요가없는 경우 Windows 매핑 대신 CFastFile을 사용하는 것이 좋습니다.
마지막으로 https://www.mql5.com/ko/articles/364.
MT5 642 Win7 64는 내가 이해하는 한 작동하지 않습니다.
hmem=CreateFileMapping(INVALID_HANDLE_VALUE,NULL,PAGE_READWRITE,0,size+HEAD_MEM,path); // 메모리 객체 생성
1400 오류가 발생합니다,
하지만 비스타 32는 작동합니다.
32와 64 시스템에서 포인터 크기가 다르기 때문입니다.
이 라이브러리 파일은 32비트 터미널용으로 만들어졌습니다.
하지만 64비트 터미널을 사용하는 경우 포인터가 암시되는 모든 위치(예: PBYTE, LPVOID 등 및 모든 memcpy 유형)에 8바이트 길이의 타입을 넣어야 합니다.
하지만 어떻게 연결하나요?
그것은 제공합니다
이 두 가지 인클루드는 서로 없이도 작동합니다.
하지만 어떻게 연결하나요?
제공
이 두 개의 포함은 서로 없이 작동합니다.
컨텍스트 해결을 사용해보세요:
고마워요
방금 표준 라이브러리를 수정해야했습니다.
좋은 일이 아닌 것 같아요....감사합니다.
표준 라이브러리를 수정해야 했습니다.
그건 좋은 일이 아닌 것 같아요.이해가 안되네요.
kernel32::GetLastError에 대해 말씀드렸는데 제 코드에서 어떻게 구현되어 있는지 보세요.
이 옵션이 만족스럽지 않다면예를 들어 int 매개 변수를 사용하여 kernel32 GetLastError에서 가져 오기를 선언하십시오. 호출 할 때 차이는 없지만 충돌을 피할 수 있습니다.
이해하지 못하실 겁니다.
kernel32::GetLastError에 대해 말씀드렸습니다 . 제 코드에서 어떻게 구현되어 있는지 보세요.
이 옵션이 적합하지 않은 경우예를 들어 int 매개 변수를 사용하여 kernel32에서 가져 오기를 선언하십시오. 호출 할 때 차이는 없지만 충돌을 피할 수 있습니다.
제가 제대로 설명하지 않았을 수도 있습니다.
하지만 우리는
표준 라이브러리가 첨부된 코드의 예가 여기 있으니까요.
컴파일할 때 동일한 오류가 발생합니다.
올레야키시, 제가 쓴 글을 다시 한 번 자세히 읽어보세요.
문맥이 만족스럽지 않으시다면 제가 정확히 무슨 뜻인지 말씀드리겠습니다.
이해하지 못하실 겁니다.
kernel32::GetLastError에 대해 말씀드렸습니다 . 제 코드에서 어떻게 구현되어 있는지 보세요.
이 옵션이 적합하지 않은 경우예를 들어 int 매개 변수를 사용하여 kernel32 GetLastError에서 가져 오기를 선언하십시오. 호출 할 때 차이는 없지만 충돌을 피할 수 있습니다.
코드에서 컨텍스트와 함께 kernel32::GetLastError를 호출할 때 컴파일러는 컨텍스트 없이GetLastError를 호출 합니다.
프로그래머는 컨텍스트와 함께 표준 WinAPI 함수의 MQL 아날로그를 호출하는 것을 규칙으로 만들기만 하면 됩니다. 그러면 이후 수정에 문제가 없을 것입니다.
표준 바이블을 수정하면 업데이트되므로 다시 수정해야 합니다.
그래서 표준 성경을 수정하면 업데이트되고 다시 편집해야 합니다.