생성자가 필요합니다. 클래스를 사용하거나 샤프에 오신 것을 환영합니다. 왜 그러한 함축의 구조를 박탈합니까? 프로그램은 이것에서 더 표현력이 될 것입니다. 여기서 나는 누군가의 코드를 가져갈 것입니다. 클래스 대신 구조체를 참조하십시오. 단 한 단어에서 많은 정보를 얻을 수 있습니다. 당신은 아무 것도 얻지 못할 것입니다. 당신은 내가 한 순간에 얻은 것과 같은 결과를 얻기 위해 부지런히 소스 코드를 연구할 것입니다. 내 경험에 따르면, 구조에 대한 이러한 동의는 존중됩니다. 글쎄, 어쩌면 약간의 허무주의적 주변주의일 수도 있습니다.
음, C++에서 구조와 클래스는 하나이며 동일합니다. 따라서 "코드의 표현성"에 대한 모든 추론은 사물의 본질에 영향을 미치지 않습니다. 정의를 통해 구조체 또는 클래스 외에 다른 표현적인 단어를 정의할 수 있으며 이는 아무 것도 변경하지 않습니다(C ++에 대해 말하는 것입니다).
따라서 C#의 관점에서 구조에 대해서만 생각해야 합니다. 여기서 개념이 나옵니다. 구조체는 값 유형이므로 클래스보다 훨씬 더 간결하고 다형성이 아니며 참조할 수 없습니다. 마지막 것이 특히 중요합니다.
거기에는 악이 없다고 생각합니다. 그들은 심지어 그것을 표준으로 확장했습니다. 초기화되지 않은 unsigned char 및 std:: byte를 읽는 것은 정의되지 않은 동작이 아닙니다. POD에 대한 집계 초기화가 가능합니다. 그리고 잊지 마세요. 이 모든 초기화는 무료가 아니며 리소스(CPU, 메모리, 실행 파일 크기)의 실제 비용입니다. 이것을 넘버 크러셔로 장착하면 일부 마이크로 컨트롤러의 경우 이것이 중요할 수 있습니다. 결국 C/C++는 단순히 나사처럼 날카롭게 때리는 것이 아니다.
변수 하나를 초기화하는 것만으로도 명령어 크기가 30% 증가했습니다.
초기화 자체가 자유롭다고 말하는 사람은 없습니다. 그러나 그녀는 어쨌든 그것을 필요로 할 것입니다. 따라서 초기화가 있거나 없는 측정의 의미를 잘 이해하지 못합니다.
또 다른 점은 컴파일러가 변수를 다시 초기화하지 않는다는 것입니다.
int a= 0 ; // Эту инициализацию компилятор вырежет
//...
a= 10 ;
연속으로 최소 100번 초기화할 수 있습니다. 따라서 변수의 사전 초기화에 대한 두려움에 대한 이 모든 편집증은 단순히 우스꽝스럽습니다. 2020년이 다가오고 있습니다. 특히 POD 구조에 대해 이야기하는 경우. 컴파일러는 하나 또는 둘의 초기화를 정확하게 최적화합니다.
사전 초기화 부족은 초기화되지 않은 변수 읽기를 금지하는 컴파일러 제어가 100% 있는 경우에만 허용됩니다.
음, C++에서 구조와 클래스는 하나이며 동일합니다. 따라서 "코드의 표현성"에 대한 모든 추론은 사물의 본질에 영향을 미치지 않습니다. 정의를 통해 구조체 또는 클래스 외에 다른 표현적인 단어를 정의할 수 있으며 이는 아무 것도 변경하지 않습니다(C ++에 대해 말하는 것입니다).
여기 완고한 사람이 있습니다)), 이것은 당신에게도 동일합니다. 정의를 통해 아무 것도 정의할 필요가 없습니다. 이미 struct라는 단어가 있습니다. 당신은 이것을 무시할 수 있지만, 괜찮은 코더가 당신의 기능으로 가득 찬 구조를 볼 때 당신을 똥코더처럼 볼 것이라는 사실에 놀라지 마십시오. 아마도 십자가의 새벽에 실수였을 것입니다. 구조와 계급의 권리를 동등하게 하려면 C에서와 같이 구조를 그대로 둘 필요가 있었습니다.
따라서 C#의 관점에서 구조에 대해서만 생각해야 합니다. 여기서부터 개념이 나옵니다. 구조체는 값 유형이므로 클래스보다 훨씬 더 간결하고 다형성이 아니며 참조할 수 없습니다. 마지막 것이 특히 중요합니다.
당신의 날카로운 것이 들판에서 나타났다고 생각합니까? C에 뿌리를 둔 struct는 추가 설탕이 없는 멍청한 컨테이너입니다.
또 다른 점은 컴파일러가 변수를 다시 초기화하지 않는다는 것입니다.
int a= 0 ; // Эту инициализацию компилятор вырежет
//...
a= 10 ;
연속으로 최소 100번 초기화할 수 있습니다. 따라서 변수의 사전 초기화에 대한 두려움에 대한 이 모든 편집증은 단순히 우스꽝스럽습니다. 2020년이 다가오고 있습니다. 특히 POD 구조에 대해 이야기하는 경우. 컴파일러는 하나 또는 둘의 초기화를 정확하게 최적화합니다.
그런 자신감은 어디서 오는 걸까요? 다른 번역 단위/다른 모듈/루프/일종의 컴파일러/...에서 함수 호출. 옵티마이저의 기능을 과대평가하지 마십시오. 이것은 컴파일러가 수행해야 하는 복사 제거 최적화가 아닙니다. 옵티마이저가 너무 똑똑해지고 비용이 들지 않는다면 다음 C 표준에서 "기본 초기화는 개체를 불확실한 상태로 두지 않습니다."라고 씁니다.
아니요. 다른 사람이 수정된 파일을 읽을 수 있도록 하려면 FileFlush가 필수입니다.
문제는 MQL5 프로그램이 파일을 열 때 자체 버퍼로 파일을 읽는다는 것입니다. 그리고 파일을 다시 읽을 때까지 파일에서 무언가가 변경되었다는 사실에 대해 아무것도 알지 못합니다. 이 파일을 닫았다가 열 때만 파일을 다시 읽을 수 있습니다.
고마워, 그게 문제야. 내가 위에 게시한 링크를 보면 그것을 재현하는 코드를 찾을 수 있습니다.
하나의 EA에서 동일한 파일이 열리고 1개의 쓰기용 핸들, 2개의 읽기용 핸들, 쓰기 후 fileflush가 사용되며 읽기를 시도하지만 제대로 작동하지 않습니다.
물론 닫거나 열면 작동하지만 FileFlush를 사용할 필요가 없습니다.
고마워, 그게 문제야. 내가 위에 게시한 링크를 보면 그것을 재현하는 코드를 찾을 수 있습니다.
하나의 EA에서 동일한 파일이 열리고 1개의 쓰기용 핸들, 2개의 읽기용 핸들, 쓰기 후 fileflush가 사용되며 읽기를 시도하지만 제대로 작동하지 않습니다.
물론 닫거나 열면 작동하지만 FileFlush를 사용할 필요가 없습니다.
나는 당신이 설명하는 문제를 이해합니다.
1차 고문이 파일을 작성합니다. 이 파일을 닫지 않을 수 있지만 이 경우 FileFlush를 호출해야 합니다.
2차 고문이 파일을 읽습니다. 매번 파일을 연 다음 닫아야 합니다.
세컨드 어드바이저만의 파일 열기와 닫기!
그게 바로 내가 말하는 것입니다. 닫았다가 다시 엽니다
아니면 파일을 닫기 전에 FileFlush를 의미합니까?
예, 닫기 전에 세척해야 합니까? 또는 닫으면 녹음된 파일이 최신 상태로 유지됩니다.
예, 닫기 전에 세척해야 합니까? 또는 닫으면 녹음된 파일이 최신 상태로 유지됩니다.
나는 당신이 설명하는 문제를 이해합니다.
1차 고문이 파일을 작성합니다. 이 파일을 닫지 않을 수 있지만 이 경우 FileFlush를 호출해야 합니다.
2차 고문이 파일을 읽습니다. 매번 파일을 연 다음 닫아야 합니다.
세컨드 어드바이저만의 파일 열기와 닫기!
이것이 해결 방법이라는 것을 이해합니다.
하지만 버그를 수정하는 것이 더 나을 것입니다. 쉽게 불가능하지 않습니까?
예, 닫기 전에 세척해야 합니까? 또는 닫으면 녹음된 파일이 최신 상태로 유지됩니다.
필요하지 않습니다. 닫기 전에 FileFlush 가 호출되지 않으면 버퍼가 자동으로 플러시됩니다.
버그 МТ5(빌드 2390) 클래스 구조 설명에서 중괄호 계산이 잘못되었습니다.
파일을 읽는 Expert Advisor는 이 파일을 닫힌 상태로 유지해야 합니다.
MQL5에서 파일 구현의 특징은 자체 버퍼에 있는 파일의 데이터를 최대로 유지한다는 것입니다. 정보의 양이 너무 커서 버퍼에 맞지 않으면 포인터를 파일의 시작 부분으로 이동한 다음 끝 부분으로 이동하는 트릭이 작동할 수 있습니다.
그래서 지금 은 파일을 열고 내용을 확인한 다음 다시 닫습니다.
위에서 보고한 바와 같이(귀하가 답변한 텍스트에서) 특히 내 테스트 사례에서는 그 반대가 사실입니다. 지표는 읽고 전문가는 씁니다. 그러나 내가 아는 한 프로그램의 유형은 중요하지 않습니다. 문제는 건축이다.
MQL5에서 지정된 파일 구현은 버그입니다. 파일을 닫고 여는 것이 효과적인 해결 방법이지만 공유 파일을 읽는 경우에는 그렇지 않습니다.
성능 최적화에 대한 우려는 좋지만 기능에 부정적인 영향을 미쳐서는 안 됩니다.
추신. 빠른 수정으로 다음 제안: 읽기 위해 열린 파일에 대한 FileFlush 호출에 대한 응답으로 해당 버퍼를 업데이트합니다.
아마도 C++이 유사하고 C의 구조가 거기에 왔기 때문일 것입니다.
생성자가 필요합니다. 클래스를 사용하거나 샤프에 오신 것을 환영합니다. 왜 그러한 함축의 구조를 박탈합니까? 프로그램은 이것에서 더 표현력이 될 것입니다. 여기서 나는 누군가의 코드를 가져갈 것입니다. 클래스 대신 구조체를 참조하십시오. 단 한 단어에서 많은 정보를 얻을 수 있습니다. 당신은 아무 것도 얻지 못할 것입니다. 당신은 내가 한 순간에 얻은 것과 같은 결과를 얻기 위해 부지런히 소스 코드를 연구할 것입니다. 내 경험에 따르면, 구조에 대한 이러한 동의는 존중됩니다. 글쎄, 어쩌면 약간의 허무주의적 주변주의일 수도 있습니다.
음, C++에서 구조와 클래스는 하나이며 동일합니다. 따라서 "코드의 표현성"에 대한 모든 추론은 사물의 본질에 영향을 미치지 않습니다. 정의를 통해 구조체 또는 클래스 외에 다른 표현적인 단어를 정의할 수 있으며 이는 아무 것도 변경하지 않습니다(C ++에 대해 말하는 것입니다).
따라서 C#의 관점에서 구조에 대해서만 생각해야 합니다. 여기서 개념이 나옵니다. 구조체는 값 유형이므로 클래스보다 훨씬 더 간결하고 다형성이 아니며 참조할 수 없습니다. 마지막 것이 특히 중요합니다.
거기에는 악이 없다고 생각합니다. 그들은 심지어 그것을 표준으로 확장했습니다. 초기화되지 않은 unsigned char 및 std:: byte를 읽는 것은 정의되지 않은 동작이 아닙니다. POD에 대한 집계 초기화가 가능합니다. 그리고 잊지 마세요. 이 모든 초기화는 무료가 아니며 리소스(CPU, 메모리, 실행 파일 크기)의 실제 비용입니다. 이것을 넘버 크러셔로 장착하면 일부 마이크로 컨트롤러의 경우 이것이 중요할 수 있습니다. 결국 C/C++는 단순히 나사처럼 날카롭게 때리는 것이 아니다.
변수 하나를 초기화하는 것만으로도 명령어 크기가 30% 증가했습니다.
초기화 자체가 자유롭다고 말하는 사람은 없습니다. 그러나 그녀는 어쨌든 그것을 필요로 할 것입니다. 따라서 초기화가 있거나 없는 측정의 의미를 잘 이해하지 못합니다.
또 다른 점은 컴파일러가 변수를 다시 초기화하지 않는다는 것입니다.
연속으로 최소 100번 초기화할 수 있습니다. 따라서 변수의 사전 초기화에 대한 두려움에 대한 이 모든 편집증은 단순히 우스꽝스럽습니다. 2020년이 다가오고 있습니다. 특히 POD 구조에 대해 이야기하는 경우. 컴파일러는 하나 또는 둘의 초기화를 정확하게 최적화합니다.
사전 초기화 부족은 초기화되지 않은 변수 읽기를 금지하는 컴파일러 제어가 100% 있는 경우에만 허용됩니다.
음, C++에서 구조와 클래스는 하나이며 동일합니다. 따라서 "코드의 표현성"에 대한 모든 추론은 사물의 본질에 영향을 미치지 않습니다. 정의를 통해 구조체 또는 클래스 외에 다른 표현적인 단어를 정의할 수 있으며 이는 아무 것도 변경하지 않습니다(C ++에 대해 말하는 것입니다).
여기 완고한 사람이 있습니다)), 이것은 당신에게도 동일합니다. 정의를 통해 아무 것도 정의할 필요가 없습니다. 이미 struct라는 단어가 있습니다. 당신은 이것을 무시할 수 있지만, 괜찮은 코더가 당신의 기능으로 가득 찬 구조를 볼 때 당신을 똥코더처럼 볼 것이라는 사실에 놀라지 마십시오. 아마도 십자가의 새벽에 실수였을 것입니다. 구조와 계급의 권리를 동등하게 하려면 C에서와 같이 구조를 그대로 둘 필요가 있었습니다.
따라서 C#의 관점에서 구조에 대해서만 생각해야 합니다. 여기서부터 개념이 나옵니다. 구조체는 값 유형이므로 클래스보다 훨씬 더 간결하고 다형성이 아니며 참조할 수 없습니다. 마지막 것이 특히 중요합니다.
당신의 날카로운 것이 들판에서 나타났다고 생각합니까? C에 뿌리를 둔 struct는 추가 설탕이 없는 멍청한 컨테이너입니다.
또 다른 점은 컴파일러가 변수를 다시 초기화하지 않는다는 것입니다.
연속으로 최소 100번 초기화할 수 있습니다. 따라서 변수의 사전 초기화에 대한 두려움에 대한 이 모든 편집증은 단순히 우스꽝스럽습니다. 2020년이 다가오고 있습니다. 특히 POD 구조에 대해 이야기하는 경우. 컴파일러는 하나 또는 둘의 초기화를 정확하게 최적화합니다.