mql5 언어의 특징, 미묘함 및 작업 방법 - 페이지 211

새 코멘트
 
fxsaber # :

네 번째 오류를 직접 보고하셨습니다. ZeroMemory가 {}보다 나쁜 이유는 무엇입니까? 저것들. 컴파일러가 어떤 이유로 감지하지 못하는 private 접근을 위한 승인되지 않은 메커니즘이 있습니다.

개발자가 수정하지 않을 것이라는 기대? 컴파일러 가 ZeroMemory에도 반응하지 않으면

 
A100 # :

네 번째 오류를 직접 보고하셨습니다. ZeroMemory가 {}보다 나쁜 이유는 무엇입니까? 저것들. 컴파일러가 어떤 이유로 감지하지 못하는 private 접근을 위한 승인되지 않은 메커니즘이 있습니다.

나는 이것을 실수로 보지 않는다. 생성자가 없는 구조, 초기화가 진행 중입니다. FileReadStruct - 그렇다면 꽤 끔찍한 일입니다 ...

 
fxsaber # :

나는 이것을 실수로 보지 않는다. 생성자가 없는 구조, 초기화가 진행 중입니다. FileReadStruct - 그렇다면 꽤 끔찍한 일입니다 ...

 uint    FileReadStruct ( 
   int           file_handle,         // handle файла 
   const void &  struct_object,       // структура, куда происходит считывание 
   int           size=- 1              // размер структуры в байтах 
   );

설명 을 보니 사기 같습니다.

 
A100 # :

설명 을 보니 사기 같습니다.

네, 완전 사기입니다.

 
A100 # :

설명 을 보니 사기 같습니다.

복사-붙여넣기 아티팩트가 없는 문서 링크 - 이상합니다.

 
fxsaber # :

복사-붙여넣기 아티팩트가 없는 문서 링크 - 이상합니다.

일반적으로 이 기능을 처음 봅니다. 설명에 오류가 있다고 보고했을 수 있습니다.

설명 외에도 구조적 오류가 있습니다.

 struct X {
    X( int i ) : i( i ) {}
     const int i;
};
void OnStart ()
{
    X x( 5 );
    FileReadStruct ( 0 , x, - 1 ); //(1) нормально ???
    ZeroMemory ( x );             //(2) Error: 'x' - not allowed for objects with protected members or inheritance
}

ZeroMemory가 FileReadStruct보다 나쁜 이유는 무엇입니까?

다시 말하지만, 계산은 개발자들이 알아차리지 못하거나/연기하거나/수정하기에는 너무 게으르다는 것입니다(필요한 경우 밑줄)?

내 주장은 간단합니다. 일단 ZeroMemory가 이 모든 것( private 포함)으로 컴파일되었지만, 그들은 알아차리거나/이해하고/고쳤습니다.

 
A100 # :

일반적으로 이 기능을 처음 봅니다. 설명에 오류가 있다고 보고했을 수 있습니다.

이 기능에 대한 설명을 본 적이 없습니다. 이름에서 모든 것이 명확합니다.

설명 외에도 구조적 오류가 있습니다.

다음 코드에는 오류가 없습니다.

 struct MqlTick2 : private MqlTick {};

void OnStart ()
{
  MqlTick2 Ticks[ 4 ] = {};

   uchar Bytes[];
  
   StructToCharArray (Ticks[ 0 ], Bytes);
   CharArrayToStruct (Ticks[ 1 ], Bytes);

   FileReadStruct ( 0 , Ticks[ 0 ]);
   FileWriteStruct ( 0 , Ticks[ 1 ]);
  
   FileWriteArray ( 0 , Ticks);
   FileReadArray ( 0 , Ticks);
}

지루함은 편리함을 이길 수 없습니다!


ZeroMemory가 FileReadStruct보다 나쁜 이유는 무엇입니까?

당신은 문서를 참조하는 것을 좋아합니다. ZeroMemory의 한계에 대한 모든 것이 거기에 기록되어 있습니다. 그리고 File* 제한 사항에 대해 - 아니요. ZeroMemory에 따르면, 나는 있는 것부터 진행합니다. 지금은 불편하지만 일부러 그렇게 한 것 같다.

이 두 함수를 비교하면 FileReadStruct는 단순한 구조에서만 작동합니다. 이것이 근본적인 차이점입니다.


이 주제는 MQL5 기능에 관한 것입니다. 하나를 가리킵니다( MQL4 에서는 작동하지 않음). 이 대화는 불행히도 시간 낭비입니다.

 
fxsaber # :

다음 코드에는 오류가 없습니다.

당신은 문서를 참조하는 것을 좋아합니다. ZeroMemory의 한계에 대한 모든 것이 거기에 기록되어 있습니다. 그리고 File* 제한 사항에 대해 - 아니요. ZeroMemory에 따르면, 나는 있는 것부터 진행합니다. 지금은 불편하지만 일부러 그렇게 한 것 같다 .

이 두 함수를 비교하면 FileReadStruct는 단순한 구조에서만 작동합니다. 이것이 근본적인 차이점입니다.

오류가 있습니다(컴파일러가 현재 보고하지 않는 것뿐입니다) . 이는 클래스 외부의 특정 함수(즉, FileReadStruct)가 이 클래스의 보호된 멤버에 직접 액세스할 수 있다는 사실에 있습니다. 개인의 매우 개념 보호.

이 기능이 ZeroMemory 및 수백 가지 다른 기능보다 나은 이유는 무엇입니까? 하지만 아무것도 아니야! - 개발자가 아직 손을 대지 못했을 뿐입니다. 이전에는 ZeroMemory도 문서에 제한이 없었습니다. 그리고 이제 여러분에게 불편을 주기 위해서가 아니라 단일 원칙이 작동하기 때문에 FileReadStruct, ZeroMemory, 다른 수백 가지 유사한 기능이 모두 동일합니다.

 
A100 # :

100개의 다른 유사한 기능은 모두 동일합니다.

FileLoad/FileSave는 여전히 불평등의 보물창고에 있습니다.

지루함은 편리함을 이길 수 없습니다!

발에 총을 쏠 이유가 없습니다.

 
fxsaber # :

FileLoad/FileSave는 여전히 불평등의 보물창고에 있습니다.

발에 총을 쏠 이유가 없습니다.

private 을 선언하여 발에 총을 쏘고 있습니다. 자신에 대한 액세스를 제한했는데 외부 기능에 공개 액세스가 필요한 코드가 갑자기 작동을 멈춘 이유가 궁금할 것입니다.

1...204205206207208209210211212213214215216217218...247
새 코멘트