네 번째에서 #property strict를 사용하면 키워드로 정의된 숫자와 문자열 Content 배열의 kibcode(생성자 코드)로 작성된 숫자가 "불법적으로" 문자열 유형으로 변환된다는 사실에 대해 불필요한 경고가 많이 있었습니다. 이 때문에이 #property strict를 비활성화했습니다. 즉, 프로그래밍 규칙의 관점에서 내 생성자는 존재하지 않아야 합니다.))
네 번째에서 #property strict를 사용하면 키워드로 정의된 숫자와 문자열 Content 배열의 kibcode(생성자 코드)로 작성된 숫자가 "불법적으로" 문자열 유형으로 변환된다는 사실에 대해 불필요한 경고가 많이 있었습니다. 이 때문에이 #property strict를 비활성화했습니다. 즉, 프로그래밍 규칙의 관점에서 내 생성자는 존재하지 않아야 합니다.))
설명하겠습니다: 생성자로 작업하는 것은 문자열 배열의 초기화입니다. 이 배열은 숫자 값과 문자열의 항목을 대체합니다. 숫자는 좌표와 키워드(및 요소 유형의 이름)가 될 수 있고 문자열은 이름 또는 텍스트가 될 수 있습니다.#property strict 를 사용 하려면 이 배열의 모든 항목 을 string형으로 캐스팅해야 합니다 . 그러나 이 경우 cybcode는 정상적인 가독성을 잃습니다. 탈출구는 #property strict없이 작업하는 것입니다 .
코드 예:
//----------------------------------------------------------------------------------
GROUP, A,
__, V_LINE, "vL" ,H, 61 ,_,N_COLOR,( int ) C'255,223,199' ,
END_GROUP,
//------------------------------------
i, AT, _X2X, "R1" , 1 , _Y2Y, "R1" , 1 ,
창의성의 레일에 있는 화살표를 MQL5로 번역하기로 결정한 것을 기쁘게 생각합니다.
나는 항상 이것을 하려고 했다. MT4의 배포에 대해 이야기한 적이 없습니다. )
지금까지 전환 과정에서 다음 두 가지를 제외하고는 어려움을 본 적이 없습니다.
1. 선언된 모든 변수 와 배열은 의도적으로 0으로 설정해야 합니다. 내 프로그램의 규모에서 이 작업을 수행하는 데 몇 시간이 걸렸습니다.
2. 어레이 오버플로의 영구 오류. 4에서는 눈치채지 못했다. 흔한 실수임이 밝혀졌습니다.
그 외에는 아직 문제점을 발견하지 못했습니다. 프로젝트를 컴파일하는 데 정말 오랜 시간이 걸립니다. 나도 몰라... 이것 때문에 생성자로 작업하는 것이 크게 느려질 것입니다. :(
나는 항상 이것을 하려고 했다. MT4의 배포에 대해 이야기한 적이 없습니다. )
지금까지 전환 과정에서 다음 두 가지를 제외하고는 어려움을 본 적이 없습니다.
1. 선언된 모든 변수 와 배열은 의도적으로 0으로 설정해야 합니다. 내 프로그램의 규모에서 이 작업을 수행하는 데 몇 시간이 걸렸습니다.
2. 배열을 넘어서는 끊임없는 오류. 4에서는 눈치채지 못했다. 흔한 실수임이 밝혀졌습니다.
그 외에는 아직 문제점을 발견하지 못했습니다. 프로젝트를 컴파일하는 데 정말 오랜 시간이 걸립니다. 나도 몰라... 이것 때문에 생성자로 작업하는 것이 크게 느려질 것입니다. :(
4개에서 #property strict를 사용하지 않았습니까?
아니요.
아니요.
Popadalovo 특정.
혼자 고층 빌딩을 지을 때 석고는 생각하지 않습니다. 모든 바닥이 끝나면 장식을 할 수 있습니다.
이 "석고"는 이미 작성된 것을 수정할 필요를 즉시 제거합니다.
이 "석고"는 이미 작성된 것을 수정할 필요를 즉시 제거합니다.
네 번째에서 #property strict를 사용하면 키워드로 정의된 숫자와 문자열 Content 배열의 kibcode(생성자 코드)로 작성된 숫자가 "불법적으로" 문자열 유형으로 변환된다는 사실에 대해 불필요한 경고가 많이 있었습니다. 이 때문에 이 #property strict를 비활성화했습니다. 즉, 프로그래밍 규칙의 관점에서 내 생성자는 존재하지 않아야 합니다.))
네 번째에서 #property strict를 사용하면 키워드로 정의된 숫자와 문자열 Content 배열의 kibcode(생성자 코드)로 작성된 숫자가 "불법적으로" 문자열 유형으로 변환된다는 사실에 대해 불필요한 경고가 많이 있었습니다. 이 때문에 이 #property strict를 비활성화했습니다. 즉, 프로그래밍 규칙의 관점에서 내 생성자는 존재하지 않아야 합니다.))
문자열 유형 으로 "합법적으로" 캐스트되는 것을 방해한 이유는 무엇입니까?
문자열 유형 으로 "합법적으로" 캐스트되는 것을 방해한 이유는 무엇입니까?
설명하겠습니다: 생성자로 작업하는 것은 문자열 배열의 초기화입니다. 이 배열은 숫자 값과 문자열의 항목을 대체합니다. 숫자는 좌표와 키워드(및 요소 유형의 이름)가 될 수 있고 문자열은 이름 또는 텍스트가 될 수 있습니다. #property strict 를 사용 하려면 이 배열의 모든 항목 을 string형으로 캐스팅해야 합니다 . 그러나 이 경우 cybcode는 정상적인 가독성을 잃습니다. 탈출구는 #property strict 없이 작업하는 것입니다 .
#property strict가 요구하는 것의 예.