Alexey, 이 예제는 패자에게도 명확하도록 만들어졌습니다. 그래서 나는 그것이 원시적이라고 썼습니다. 죄송합니다. 우수한 학생을 위해 설계되지 않았습니다.
오늘 아침 그는 지나가는 트럭에 개가 짖는 것을 봅니다. 그녀는 당신에게 인사했습니다.
그녀와 함께 탔나요?
객체를 생성하기 전에 객체의 존재 여부를 확인하지 않는 예에서 무엇을 이해할 수 있습니까? 심각한 오류와 함께 무작위로 작성하는 것이 가능하지 않았다는 개발자의 주장 ? 그런 식으로 무작위로 작성하고 개발자가 이에 대한 모든 조건을 만들어야합니다. 개발자는 내가 미래에 저지를 수 있는 모든 가능한 실수를 예견해야 합니다. 그래서 뭐??? 문제가 존재하지 않는 곳에서 문제를 빨아들일 필요가 없습니다.
객체를 생성하기 전에 객체의 존재 여부를 확인하지 않는 예에서 무엇을 이해할 수 있습니까? 심각한 오류와 함께 무작위로 작성하는 것이 가능하지 않았다는 개발자의 주장 ?
그 과정에서 Alex, 당신은 주제에서 완전히 벗어났습니다. 원본 소스 를 읽으십시오. 나는 인용한다: " 객체가 이전에 생성되었다면, 그 좌표를 변경하려는 시도가 이루어진다. "
나는 다양한 종류의 수표를 두는 것이 큰 일에 좋은 습관이라는 것을 이해합니다. 그러나 이 경우 이 검사는 의미가 없습니다. 왜냐하면 객체가 존재하지 않으면 ObjectCreate가 객체를 생성하고 객체가 존재하면 단순히 좌표를 변경합니다. 이 매우 원시적인 예에서 목표는 Deunit이 이전 TF에서 개체를 제거했다는 사실을 보여주는 것이었습니다. 당신의 "도착"은 아무것도 아닙니다. 관심을 끌기 위한 시도일 가능성이 큽니다. 그리고 손가락을 훈련시키기 위해 의미가 없는 추가 코드 줄을 원하신다면 훌륭한 리소스 "Keyboard Solo" 를 추천합니다.
객체를 생성하기 전에 객체의 존재 여부를 확인하지 않는 예에서 무엇을 이해할 수 있습니까? 심각한 오류와 함께 무작위로 작성하는 것이 가능하지 않았다는 개발자의 주장 ? 그런 식으로 무작위로 작성하고 개발자가 이에 대한 모든 조건을 만들어야합니다. 개발자는 내가 미래에 저지를 수 있는 모든 가능한 실수를 예견해야 합니다. 그래서 뭐??? 문제가 존재하지 않는 곳에서 문제를 빨아낼 필요가 없습니다.
Dmitry, 나는 당신이 교육받은 프로그래머라고 생각합니다. 프로그래밍에서 매너를 배우지 않았습니까?
그렇지 않으면 예를 들어 어레이 및 기타 가정을 넘어서는 기능을 사용하여 이전 mql4에서와 같이 작성할 수 있습니다. 이에 대한 응답으로 우리는 오류를 수신했습니다 ... 글쎄, 플래그가 그녀에게 돌아 왔습니다 ... 계속 진행합시다. 시간이 없습니다 ... 그리고 나서 우리는 더 엄격한 언어를 사용하고 개발자에게 소유권을 주장하기 시작합니다 ...
Alexey Viktorov : 비삭제 사실은 응답 예시에 나와 있습니다. 문제가 존재하지 않는 곳에서 문제를 빨아들일 필요가 없습니다. 초기화 해제 이유를 체크했는데 객체가 삭제되지 않고 좌표만 변경됩니다.
//Часть твоего кода:
voidOnDeinit ( constint reason)
{
if ( UninitializeReason () != REASON_CHARTCHANGE ) // Что ты здесь сделал? - ЕСЛИ ПРОИСХОДИТ СМЕНА ТФ, ТО НИЧЕГО НЕ ДЕЛАЕМ. Бред!
// И зачем здесь использовать функцию UninitializeReason (), когда можно уже существует переменная reason? {
ObjectDelete ( 0 , "InitDeinit" );
ChartRedraw ( 0 ); // Не нужная функция в данном случае, т.к. она обычно применяется после изменении свойств объктов. Объект удалится и так.
Print ( __FUNCTION__ , " InitDeinit удалён" ); // А где ж твоя любимая проверка, вдруг не удален.
}
}
제 예제는 새로운 TF의 Unit과 기존 TF의 DeUnit의 실행 순서가 모호한 문제를 보여주기 위해 만든 것이지 해결 방법이 아닙니다.
당신은 문제를 우회했을 뿐이지 해결하지 못했습니다. 내 예에서는 이전 TF의 Deunit에서 TF를 변경할 때를 포함하여 어떤 경우에도 개체가 삭제되고 새 개체의 Unit에서 다시 생성되는 것이 중요합니다.
시퀀스가 먼저 이전 TF의 Deunit이면 논리적으로 있어야 하므로 새 TF의 단위입니다. 그런 다음 개체가 삭제된 다음 다시 생성됩니다.
시퀀스가 먼저 새 TF의 단위이고 그 다음이 이전 TF의 단위인 경우 개체는 단위에서 생성하려고 할 때 단순히 수정되기 때문입니다. 아직 제거되지 않았습니다. 그런 다음 이전 TF의 Deunit에 의해 제거됩니다. 여기에 버그가 있습니다.
이것이 이 예제의 요점입니다 - 이 분기를 읽지 않고 이 "기능"을 모르는 프로그래머가 만날 수 있는 것을 보여줍니다. 이 예는 해결책으로 간주되지 않았습니다. 솔루션이 여기 와 여기에서 제시됩니다. 조금 후에 솔루션을 추가할 생각이지만 터미널과 파일의 전역 변수를 사용하지 않고 이 솔루션이 작동하려면 한 창에 여러 개의 동일한 표시기가 설치되어 있어도 마찬가지입니다. 그런 문제를 해결해 보시겠습니까? 또는 다른 사람의 코드에서 특히 오류가 없는 경우에만 오류를 찾을 수 있습니다.
재작업한 예제는 논의 중인 문제와 완벽하게 맞지 않았습니다. UninitializeReason 솔루션이 없는 다른 예를 보여주는 것이 가능합니다.
그게 다야, 나는이 대화를 중단합니다. 귀 긁는 것을 논하는 요점이 무엇입니까? 글쎄, 당신의 코드를 사용하기 위한 다른 해결책은 없을 것이지만, 일반성이 항상 문제에 대한 이상적인 해결책은 아닙니다.
예를 들어, 나무 딸기 덤불 1개를 자르기 위해 벌목 여단을 부를 사람은 아무도 없을 것입니다. 따라서 귀하의 코드는 나무 딸기 덤불 하나를 자르는 벌목꾼 팀과 비슷합니다.
진심으로, 알렉스.
이전 DeInit과 새로운 OnInit이 다른 스레드에서 실행되는지 이해가 안 가는데, OnInit의 문제가 무엇인지, DeInit가 시작되고 완료될 때까지 기다리면 됩니다. 전역 변수 를 세마포어로 사용하십시오.
패자의 원시적인 예를 사용하는 요점이 무엇입니까?
ALMOST 올바른 코드의 더 나은 예 사용
Alexey, 이 예제는 패자에게도 분명하도록 만들어졌습니다. 그래서 나는 그것이 원시적이라고 썼습니다. 죄송합니다. 우수한 학생을 위해 설계되지 않았습니다.
오늘 아침 그는 지나가는 트럭에 개가 짖는 것을 봅니다. 그녀는 당신에게 인사했습니다.
Alexey, 이 예제는 패자에게도 명확하도록 만들어졌습니다. 그래서 나는 그것이 원시적이라고 썼습니다. 죄송합니다. 우수한 학생을 위해 설계되지 않았습니다.
오늘 아침 그는 지나가는 트럭에 개가 짖는 것을 봅니다. 그녀는 당신에게 인사했습니다.
그녀와 함께 탔나요?
객체를 생성하기 전에 객체의 존재 여부를 확인하지 않는 예에서 무엇을 이해할 수 있습니까? 심각한 오류와 함께 무작위로 작성하는 것이 가능하지 않았다는 개발자의 주장 ? 그런 식으로 무작위로 작성하고 개발자가 이에 대한 모든 조건을 만들어야합니다. 개발자는 내가 미래에 저지를 수 있는 모든 가능한 실수를 예견해야 합니다. 그래서 뭐??? 문제가 존재하지 않는 곳에서 문제를 빨아들일 필요가 없습니다.
객체를 생성하기 전에 객체의 존재 여부를 확인하지 않는 예에서 무엇을 이해할 수 있습니까? 심각한 오류와 함께 무작위로 작성하는 것이 가능하지 않았다는 개발자의 주장 ?
그 과정에서 Alex, 당신은 주제에서 완전히 벗어났습니다. 원본 소스 를 읽으십시오.
나는 인용한다: " 객체가 이전에 생성되었다면, 그 좌표를 변경하려는 시도가 이루어진다. "
나는 다양한 종류의 수표를 두는 것이 큰 일에 좋은 습관이라는 것을 이해합니다. 그러나 이 경우 이 검사는 의미가 없습니다. 왜냐하면 객체가 존재하지 않으면 ObjectCreate가 객체를 생성하고 객체가 존재하면 단순히 좌표를 변경합니다. 이 매우 원시적인 예에서 목표는 Deunit이 이전 TF에서 개체를 제거했다는 사실을 보여주는 것이었습니다.
당신의 "도착"은 아무것도 아닙니다. 관심을 끌기 위한 시도일 가능성이 큽니다.
그리고 손가락을 훈련시키기 위해 의미가 없는 추가 코드 줄을 원하신다면 훌륭한 리소스 "Keyboard Solo" 를 추천합니다.
그녀와 함께 탔나요?
객체를 생성하기 전에 객체의 존재 여부를 확인하지 않는 예에서 무엇을 이해할 수 있습니까? 심각한 오류와 함께 무작위로 작성하는 것이 가능하지 않았다는 개발자의 주장 ? 그런 식으로 무작위로 작성하고 개발자가 이에 대한 모든 조건을 만들어야합니다. 개발자는 내가 미래에 저지를 수 있는 모든 가능한 실수를 예견해야 합니다. 그래서 뭐??? 문제가 존재하지 않는 곳에서 문제를 빨아낼 필요가 없습니다.
기존 개체를 만들려고 하는 것이 뭐가 그렇게 끔찍합니까? 그는 사라질 것인가?
기존 개체를 만들려고 하는 것이 뭐가 그렇게 끔찍합니까? 그는 사라질 것인가?
Dmitry, 나는 당신이 교육받은 프로그래머라고 생각합니다. 프로그래밍에서 매너를 배우지 않았습니까?
그렇지 않으면 예를 들어 어레이 및 기타 가정을 넘어서는 기능을 사용하여 이전 mql4에서와 같이 작성할 수 있습니다. 이에 대한 응답으로 우리는 오류를 수신했습니다 ... 글쎄, 플래그가 그녀에게 돌아 왔습니다 ... 계속 진행합시다. 시간이 없습니다 ... 그리고 나서 우리는 더 엄격한 언어를 사용하고 개발자에게 소유권을 주장하기 시작합니다 ...
예수님이 부활 하셨다.
... 이 매우 원시적인 예에서 목표는 Deunit이 이전 TF에서 개체를 제거했다는 사실을 보여주는 것이었습니다. ...
비삭제 사실은 응답 예시에 나와 있습니다. 문제가 존재하지 않는 곳에서 문제를 빨아들일 필요가 없습니다. 초기화 해제 이유를 체크했는데 객체가 삭제되지 않고 좌표만 변경됩니다.
제 예제는 새로운 TF의 Unit과 기존 TF의 DeUnit의 실행 순서가 모호한 문제를 보여주기 위해 만든 것이지 해결 방법이 아닙니다.
당신은 문제를 우회했을 뿐이지 해결하지 못했습니다.
내 예에서는 이전 TF의 Deunit에서 TF를 변경할 때를 포함하여 어떤 경우에도 개체가 삭제되고 새 개체의 Unit에서 다시 생성되는 것이 중요합니다.
시퀀스가 먼저 이전 TF의 Deunit이면 논리적으로 있어야 하므로 새 TF의 단위입니다. 그런 다음 개체가 삭제된 다음 다시 생성됩니다.
시퀀스가 먼저 새 TF의 단위이고 그 다음이 이전 TF의 단위인 경우 개체는 단위에서 생성하려고 할 때 단순히 수정되기 때문입니다. 아직 제거되지 않았습니다. 그런 다음 이전 TF의 Deunit에 의해 제거됩니다. 여기에 버그가 있습니다.
이것이 이 예제의 요점입니다 - 이 분기를 읽지 않고 이 "기능"을 모르는 프로그래머가 만날 수 있는 것을 보여줍니다.
이 예는 해결책으로 간주되지 않았습니다. 솔루션이 여기 와 여기에서 제시됩니다. 조금 후에 솔루션을 추가할 생각이지만 터미널과 파일의 전역 변수를 사용하지 않고 이 솔루션이 작동하려면 한 창에 여러 개의 동일한 표시기가 설치되어 있어도 마찬가지입니다. 그런 문제를 해결해 보시겠습니까? 또는 다른 사람의 코드에서 특히 오류가 없는 경우에만 오류를 찾을 수 있습니다.