내 경험에서 알 수 있듯이 프로그래머가 인덱스 20에 10개의 요소가 포함된 배열에 무언가를 쓴다면 이는 그가 실수를 했다는 의미일 가능성이 높으며 프로그램은 오류를 제공해야 하며 배열의 크기를 늘리면 안 됩니다. 의심스러운 행동.
이러한 모든 "크기 조정 배열"은 편리함보다 잠재적인 버그를 숨기는 데 훨씬 더 골칫거리입니다. 게다가 배열의 크기를 추적하지 않아도 되는 것 또한 잠재적으로 위험한 관행이며 수정하기 어려운 버그로 이어집니다.
그것은 나에게 보이거나 문제의 언어로 작업하지 않았습니까? 추가된 요소의 인덱스는 전혀 지정할 필요가 없으며 자동으로 할당되며 배열 차원도 증가합니다. 프로그래머는 이 작업 중에 인덱스에서 실수를 할 기회가 없습니다.
클래스로 유사한 동작을 구현하고, pop, shift, unshift 등과 관련된 기능을 추가할 수 있습니다. 그리고 %10..20 함수가 각 코드에서 사용된다는 사실에도 불구하고 코드에서 코드로 클래스 카트를 드래그합니다. 이것이 올바른 해결책처럼 들립니까? 내 생각에 올바른 솔루션의 예는 ObjectsDeleteAll 함수 에 접두사로 삭제하는 기능을 추가하는 것입니다. 이것은 더 높은 수준의 프로그래밍을 향한 또 다른 미크론입니다. 대부분의 코더에게 해당 자체 제작 함수는 휴지통으로 날아갔습니다. 아아, 배열을 사용하면 그런 것을 볼 수 없을 것입니다.
그것은 나에게 보이거나 문제의 언어로 작업하지 않았습니까? 추가된 요소의 인덱스는 전혀 지정할 필요가 없으며 자동으로 할당되며 배열 차원도 증가합니다. 프로그래머는 이 작업 중에 인덱스에서 실수를 할 기회가 없습니다.
Uuuuu ... 프로그래머가 실수를 할 기회가 얼마나 많습니까? 복잡한 프로그램이 작동하는 방식에 대한 모든 옵션을 고려할 수 있다고 생각해서는 안 됩니다.
이러한 모든 "기본 작업"은 복잡한 개체의 속성이어야 합니다. 수업만. 변수, 배열 및 간단한 구조와 같은 간단한 개체는 가능한 한 적은 수의 "기본" 속성을 가져야 합니다.
예를 들어 생성할 때 정의되지 않은 값을 저장해야 하며 전혀 0이 아닌 값을 저장해야 합니다.
클래스로 유사한 동작을 구현하고, pop, shift, unshift 등과 관련된 기능을 추가할 수 있습니다. 그리고 %10..20 함수가 각 코드에서 사용된다는 사실에도 불구하고 코드에서 코드로 클래스 카트를 드래그합니다. 이것이 올바른 해결책처럼 들립니까?
이것은 논리 측면에서 올바른 솔루션입니다. 이러한 클래스로 작업할 때 동작은 투명합니다.
그리고 "수업 카트 나르기"에 대해서는 코딩할 때 가지고 다니지 않고 라이브러리만 포함하면 됩니다. 그리고 컴파일할 때 일반 링커는 라이브러리의 모든 메서드를 한 행에 실행 모듈로 밀어넣지 않고 사용되는 메서드만 밀어넣어야 합니다.
내 생각에 올바른 솔루션의 예는 ObjectsDeleteAll 함수 에 접두사로 삭제하는 기능을 추가하는 것입니다. 이것은 고급 프로그래밍 방향으로 또 다른 미크론입니다. 대부분의 코더에게 해당 자체 제작 기능은 쓰레기통으로 날아갔습니다. . 아아, 배열을 사용하면 그런 것을 볼 수 없을 것입니다.
그리고 제 생각에는 같은 이유로 잘못된 접근 방식이기도 합니다. 함수는 응용 프로그램의 논리를 따르지 않는 비정상적인 작업으로 로드됩니다.
내가 보기에 올바른 솔루션은 차트에 있는 개체의 클래스 관리자로서 개체 목록을 유지 관리하고 함수가 호출될 때 필요한 개체를 제거하는 것 같습니다. 이름 접두사는 사람이 개체에 대한 일부 정보를 이해하도록 하기 위해서만 사용되어야 하는 것 같습니다. 그리고 삭제 - 어떤 식으로든 개체 이름을 기반으로 해서는 안 되며 이 이름을 배열에 저장하는 데 기반해야 합니다.
내 경험에서 알 수 있듯이 프로그래머가 인덱스 20에 10개의 요소가 포함된 배열에 무언가를 쓴다면 이는 그가 실수를 했다는 의미일 가능성이 높으며 프로그램은 오류를 제공해야 하며 배열의 크기를 늘리면 안 됩니다. 의심스러운 행동.
이러한 모든 "크기 조정 배열"은 편리함보다 잠재적인 버그를 숨기는 데 훨씬 더 골칫거리입니다. 게다가 배열의 크기를 추적하지 않아도 되는 것 또한 잠재적으로 위험한 관행이며 수정하기 어려운 버그로 이어집니다.
그것은 나에게 보이거나 문제의 언어로 작업하지 않았습니까? 추가된 요소의 인덱스는 전혀 지정할 필요가 없으며 자동으로 할당되며 배열 차원도 증가합니다. 프로그래머는 이 작업 중에 인덱스에서 실수를 할 기회가 없습니다.
클래스로 유사한 동작을 구현하고, pop, shift, unshift 등과 관련된 기능을 추가할 수 있습니다. 그리고 %10..20 함수가 각 코드에서 사용된다는 사실에도 불구하고 코드에서 코드로 클래스 카트를 드래그합니다. 이것이 올바른 해결책처럼 들립니까? 내 생각에 올바른 솔루션의 예는 ObjectsDeleteAll 함수 에 접두사로 삭제하는 기능을 추가하는 것입니다. 이것은 더 높은 수준의 프로그래밍을 향한 또 다른 미크론입니다. 대부분의 코더에게 해당 자체 제작 함수는 휴지통으로 날아갔습니다. 아아, 배열을 사용하면 그런 것을 볼 수 없을 것입니다.
И таскать телегу классов из кода в код, при том что в каждом коде из неё используются %10..20 функций.
"스마트 어레이" 클래스를 작성할 필요가 없습니다. 이미 MetaQuotes Standard Library 에 있습니다. Arry 클래스 제품군을 참조하세요.
그것은 나에게 보이거나 문제의 언어로 작업하지 않았습니까? 추가된 요소의 인덱스는 전혀 지정할 필요가 없으며 자동으로 할당되며 배열 차원도 증가합니다. 프로그래머는 이 작업 중에 인덱스에서 실수를 할 기회가 없습니다.
Uuuuu ... 프로그래머가 실수를 할 기회가 얼마나 많습니까? 복잡한 프로그램이 작동하는 방식에 대한 모든 옵션을 고려할 수 있다고 생각해서는 안 됩니다.
이러한 모든 "기본 작업"은 복잡한 개체의 속성이어야 합니다. 수업만. 변수, 배열 및 간단한 구조와 같은 간단한 개체는 가능한 한 적은 수의 "기본" 속성을 가져야 합니다.
예를 들어 생성할 때 정의되지 않은 값을 저장해야 하며 전혀 0이 아닌 값을 저장해야 합니다.
클래스로 유사한 동작을 구현하고, pop, shift, unshift 등과 관련된 기능을 추가할 수 있습니다. 그리고 %10..20 함수가 각 코드에서 사용된다는 사실에도 불구하고 코드에서 코드로 클래스 카트를 드래그합니다. 이것이 올바른 해결책처럼 들립니까?
이것은 논리 측면에서 올바른 솔루션입니다. 이러한 클래스로 작업할 때 동작은 투명합니다.
그리고 "수업 카트 나르기"에 대해서는 코딩할 때 가지고 다니지 않고 라이브러리만 포함하면 됩니다. 그리고 컴파일할 때 일반 링커는 라이브러리의 모든 메서드를 한 행에 실행 모듈로 밀어넣지 않고 사용되는 메서드만 밀어넣어야 합니다.
내 생각에 올바른 솔루션의 예는 ObjectsDeleteAll 함수 에 접두사로 삭제하는 기능을 추가하는 것입니다. 이것은 고급 프로그래밍 방향으로 또 다른 미크론입니다. 대부분의 코더에게 해당 자체 제작 기능은 쓰레기통으로 날아갔습니다. . 아아, 배열을 사용하면 그런 것을 볼 수 없을 것입니다.
그리고 제 생각에는 같은 이유로 잘못된 접근 방식이기도 합니다. 함수는 응용 프로그램의 논리를 따르지 않는 비정상적인 작업으로 로드됩니다.
내가 보기에 올바른 솔루션은 차트에 있는 개체의 클래스 관리자로서 개체 목록을 유지 관리하고 함수가 호출될 때 필요한 개체를 제거하는 것 같습니다. 이름 접두사는 사람이 개체에 대한 일부 정보를 이해하도록 하기 위해서만 사용되어야 하는 것 같습니다. 그리고 삭제 - 어떤 식으로든 개체 이름을 기반으로 해서는 안 되며 이 이름을 배열에 저장하는 데 기반해야 합니다.
버전 5.0 빌드 1150, 데모
터미널을 업데이트하십시오(MetaQuotes-Demo 데모 서버에 연결해야 함). 현재 빌드:
다음은 스크립트입니다.
이 결과를 제공합니다:
터미널을 업데이트하십시오(MetaQuotes-Demo 데모 서버에 연결해야 함). 현재 빌드:
다음은 스크립트입니다.
이 결과를 제공합니다:
감사합니다. 하지만 아무 것도 변경되지 않은 것처럼 플래그 값이 0 인 이유를 모르겠습니다.