그리고 이 맞춤형 지표가 iCustom을 통해 결과를 제공한다면, 사용자를 오도하기 때문에 이중으로 책임이 있습니다.
나는 여전히 프로그램이 효과적일 뿐만 아니라 편리하게 만들어지는 것을 방해하는 것을 이해하지 못합니까? 제 기억이 맞다면 5개에서 표시기 버퍼의 내장 초기화가 없다는 주장은 속도 최적화입니다. 동시에 표시기 개발자는 이전에 4개의 코어에서 실행한 것과 동일한 초기화 라인("0")을 코딩해야 합니다. 그래서 결과적으로 효율성이 더 좋아지지 않는 것 같고, 편의성이 떨어집니다. 그러나 어떤 이유에서 그렇게 하기로 결정되었으므로 선택적으로 하지 않는 이유는 무엇입니까? 저것들. 버퍼를 자동으로 초기화해야 하는지 여부를 나타내는 #property를 하나 더 입력할 수 있습니다.
요약하자면, 나는 이미 한 번 표현한 아이디어를 반복할 것입니다. MT인 플랫폼의 임무는 가능한 한 "갈퀴"로부터 사용자(프로그래머)를 보호하는 것입니다.
При написании индикатора, который использует краткую форму вызова функции OnCalculate(), можно упустить то обстоятельство, что индикатор может рассчитываться не только на ценовых данных, но и на данных другого индикатора (встроенного или пользовательского - не имеет значения). Вы хотите улучшить индикатор, чтобы он правильно считался не только на ценовых данных, но и значениях другого индикатора? В этой статье мы по шагам пройдем все необходимые этапы такой модификации и выведем дополнительные полезные правила для правильного написания индикатора.
모든 것이 정확하고 논리적입니다. 그러나 문제는 사용자가 아무것도 채우지 않은 버퍼 셀(!) iCustom() 함수가 임의로 임의의 쓰레기로 주기적으로 막힌다는 것입니다. 꼭 그래야 하는 걸까요?
Wapcheta는 일반적으로 허용되는 규칙: 사용자의 재량에 따라 배열을 초기화 합니다. 초기화되지 않은 배열에는 할당된 메모리의 임의 값이 포함됩니다. 사용자는 어레이를 불필요하게 초기화하지 않는 합당한 이유가 있을 수 있습니다(예: 시간 절약). 실제 정보가 표시되기 전에 이 쓰레기를 읽지 않고 "먹지" 않을 것이라고 확신하는 경우 때때로 이러한 방식으로 시간을 절약합니다.
MQ 측에서 악의적인 의도는 보이지 않습니다. 오히려 "예방을 위해" 내 프로그램이 느려지기 시작하면 반대할 것입니다.
나는 논쟁하지 않는다
그래서
모두 같은 쓰기 반올림이 있으므로 필요합니까?
개발자.
실수로 Expert Advisor에서 틱 처리를 반복했는데, 그 후 심각한 스택 오버플로 오류가 나타났습니다.
문제는 메시지에 정확히 발생한 내용과 위치에 대한 특정 정보가 포함되어 있지 않다는 것입니다.
컴파일 단계에서 이러한 문제(예: 호출된 메서드에서 클래스 메서드 호출)를 포착하려는 경우 이 메시지의 텍스트를 명확히 할 것을 제안합니다.
iCustom()이 실제로 아무것도 채워지지 않은 버퍼 셀에 임의의 값을 할당하는 이유는 나에게 명확하지 않으며, 이것이 어떤 식으로든 피할 수 없는 이유입니다.
나는 이것이 표시기 버퍼 의 해당 데이터 배열에 대한 메모리 할당과 어떻게든 관련이 있다고 가정합니다.
데이터의 출처와 진실을 판별하는 것이 불가능할 때 iCustom()에 의한 그러한 작업은 나에게 받아들일 수 없는 것처럼 보이며 사용자에게 추가적인 위험을 초래합니다.
iCustom()이 이미 실제 값에 해당하지 않는 버퍼 셀에 임의의 값을 할당한 경우,
그렇다면 MT4에서 구현된 대로 이러한 셀에 Empty_Value와 동일한 값을 제공하지 않는 이유는 무엇입니까?
그러면 적어도 그들의 상태는 분명할 것입니다.
개발자.
........... 유사한 문제(예: 호출 된 메서드에서 클래스 메서드 호출)를 컴파일 타임에 포착하려는 경우.
나는 반대한다. 이렇게 하면 컴파일러가 엄청나게 복잡해져서 안정성이 떨어집니다.
잘못된 재귀를 추적하는 것은 프로그래머에게 달려 있습니다.
그러나 오류 메시지에서 스택을 넘친 함수의 이름을 알려주십시오. - 예, 그렇게 하고 싶습니다.
사용하지 않은 버퍼 값을 무엇으로 채워야 하는지는 작성자 외에는 아무도 결정할 수 없습니다. 당신은 Empty_Value 라고 말하지만 나는 예를 들어 0이나 다른 것이 필요합니다. 어떤 값이 필요하므로 초기화하십시오.
모든 것이 정확하고 논리적입니다. 그러나 문제는 사용자가 아무것도 채우지 않은 버퍼 셀(!) iCustom() 함수가 임의로 임의의 쓰레기로 주기적으로 막힌다는 것입니다. 꼭 그래야 하는 걸까요?
나는 반대한다. 이렇게 하면 컴파일러가 엄청나게 복잡해져서 안정성이 떨어집니다.
잘못된 재귀를 추적하는 것은 프로그래머에게 달려 있습니다.
그러나 오류 메시지 에서 스택을 넘친 함수의 이름을 알려주십시오. - 예, 그렇게 하고 싶습니다.
예, 구체적으로 메타 정보로 작업 엔진(기본 32/64)을 복잡하게 만들지 않습니다.
재귀는 일반적으로 잡기 쉽습니다. 이는 지역 변수의 범위에 직접적으로 의존하며 프로그램에는 그러한 위치가 극히 적습니다.
모든 것이 정확하고 논리적입니다. 그러나 문제는 사용자가 아무것도 채우지 않은 버퍼 셀(!) iCustom() 함수가 임의로 임의의 쓰레기로 주기적으로 막힌다는 것입니다. 꼭 그래야 하는 걸까요?
사용자 지정 표시기가 버퍼를 올바르게 채우지 않으면 이 사용자 지정 표시기가 원인입니다.
그리고 이 맞춤형 지표가 iCustom을 통해 결과를 제공한다면, 사용자를 오도하기 때문에 이중으로 책임이 있습니다.
사용자 지정 표시기가 버퍼를 올바르게 채우지 않으면 이 사용자 지정 표시기가 원인입니다.
그리고 만약 이 커스텀 인디케이터가 iCustom을 통해 그 결과를 제공한다면, 사용자를 오도하기 때문에 두 배의 책임이 있습니다.
사용자 지정 표시기가 버퍼를 올바르게 채우지 않으면 이 사용자 지정 표시기가 원인입니다.
그리고 이 맞춤형 지표가 iCustom을 통해 결과를 제공한다면, 사용자를 오도하기 때문에 이중으로 책임이 있습니다.
나는 여전히 프로그램이 효과적일 뿐만 아니라 편리하게 만들어지는 것을 방해하는 것을 이해하지 못합니까? 제 기억이 맞다면 5개에서 표시기 버퍼의 내장 초기화가 없다는 주장은 속도 최적화입니다. 동시에 표시기 개발자는 이전에 4개의 코어에서 실행한 것과 동일한 초기화 라인("0")을 코딩해야 합니다. 그래서 결과적으로 효율성이 더 좋아지지 않는 것 같고, 편의성이 떨어집니다. 그러나 어떤 이유에서 그렇게 하기로 결정되었으므로 선택적으로 하지 않는 이유는 무엇입니까? 저것들. 버퍼를 자동으로 초기화해야 하는지 여부를 나타내는 #property를 하나 더 입력할 수 있습니다.
요약하자면, 나는 이미 한 번 표현한 아이디어를 반복할 것입니다. MT인 플랫폼의 임무는 가능한 한 "갈퀴"로부터 사용자(프로그래머)를 보호하는 것입니다.
모든 것이 정확하고 논리적입니다. 그러나 문제는 사용자가 아무것도 채우지 않은 버퍼 셀(!) iCustom() 함수가 임의로 임의의 쓰레기로 주기적으로 막힌다는 것입니다. 꼭 그래야 하는 걸까요?
Wapcheta는 일반적으로 허용되는 규칙: 사용자의 재량에 따라 배열을 초기화 합니다. 초기화되지 않은 배열에는 할당된 메모리의 임의 값이 포함됩니다. 사용자는 어레이를 불필요하게 초기화하지 않는 합당한 이유가 있을 수 있습니다(예: 시간 절약). 실제 정보가 표시되기 전에 이 쓰레기를 읽지 않고 "먹지" 않을 것이라고 확신하는 경우 때때로 이러한 방식으로 시간을 절약합니다.
MQ 측에서 악의적인 의도는 보이지 않습니다. 오히려 "예방을 위해" 내 프로그램이 느려지기 시작하면 반대할 것입니다.