자, 변수 자체는 있지만 문자열 이름이 있습니다. 저장할 수 있는 유일한 이중 유형은 말할 것도 없고 이 변수에 액세스하기 위해 매번 문자열 검색을 수행하고 저장해야 합니다. Union을 사용할 수 있다는 것은 분명하지만 그 사용도 무료는 아닙니다.
전역 변수를 사용하려는 아이디어와 열망이 있었지만 구식 방식으로 디스크에 무언가를 저장하기로 결정했습니다. 특히 지금은 가능한 한 정확하게 코드를 작성하기 시작했습니다. 데이터를 구조에 저장하고 구조를 다음 위치에 덤프할 수 있습니다. 한 번의 클릭으로 디스크 - FileWriteStruct()
따라서 전역 변수는 "정확히 반대"로 사용해야 합니다. 데이터는 전역 변수의 이름으로 저장되어야 합니다. Base64를 사용하여 이중 체크섬 - 모든 것이 CryptEncode()에서 준비되었으며 이상적으로는 일반적으로 Base85( Ascii85 ) 또는 Base128 github 어딘가에서 소스를 보았습니다.
내가 틀리지 않았다면 터미널 의 전역 변수 이름 은 256자입니까? Base64 효율성은 60%(크기)보다 약간 높으며 다른 인코딩 방법은 더 높습니다. 하나의 전역 변수에 총 160-180바이트를 저장할 수 있습니다.
사실, 접두사로 데이터를 정의해야 하지만 일반적으로 이 모든 것이 작동합니다. 특히 전역 변수가 거의 사용되지 않기 때문에 모든 이름은 기본적으로 무료입니다.
전역 변수를 사용하려는 아이디어와 열망이 있었지만 구식 방식으로 디스크에 무언가를 저장하기로 결정했습니다. 특히 지금은 가능한 한 정확하게 코드를 작성하기 시작했습니다. 데이터를 구조에 저장하고 구조를 다음 위치에 덤프할 수 있습니다. 한 번의 클릭으로 디스크 - FileWriteStruct()
따라서 전역 변수는 "정확히 반대"로 사용해야 합니다. 데이터는 전역 변수의 이름으로 저장되어야 합니다. Base64를 사용하여 이중 체크섬 - 모든 것이 CryptEncode()에서 준비되었으며 이상적으로는 일반적으로 Base85( Ascii85 ) 또는 Base128 github 어딘가에서 소스를 보았습니다.
내가 틀리지 않았다면 터미널 의 전역 변수 이름 은 256자입니까? Base64 효율성은 60%(크기)보다 약간 높으며 다른 인코딩 방법은 더 높습니다. 하나의 전역 변수에 총 160-180바이트를 저장할 수 있습니다.
사실, 접두사로 데이터를 정의해야 하지만 일반적으로 이 모든 것이 작동합니다. 특히 전역 변수가 거의 사용되지 않기 때문에 모든 이름은 기본적으로 무료입니다.
어쨌든 변수에 도달하려면 원하는 체크섬을 만날 때까지 체크섬을 반복해야 합니다. 그리고 변수가 어마어마하다면?
또는 변수의 순서를 추적하고 인덱스를 할당하십시오. 그러나 이것은 확실히 쓸모가 없기 때문입니다. 데이터 지속성 클래스를 작성하는 것이 더 쉽습니다.
아마 여기 노트에
오, 네, 그렇다면 디스크 과부하에 대해 걱정할 필요가 없습니다.
나를 놀라게 하는 유일한 것은 큰 데이터 배열을 저장하기 위해 전역 터미널 변수를 사용한다는 것입니다.
끔찍한 목발입니다.
자, 변수 자체는 있지만 문자열 이름이 있습니다. 저장할 수 있는 유일한 이중 유형은 말할 것도 없고 이 변수에 액세스하기 위해 매번 문자열 검색을 수행하고 저장해야 합니다. Union을 사용할 수 있다는 것은 분명하지만 그 사용도 무료는 아닙니다.
디스크에 주기적으로 자동 저장하거나 deinit 이벤트가 발생할 때 데이터 어레이의 리소스를 통해 스스로 저장을 구현하는 것이 훨씬 더 정확합니다.
자, 변수 자체는 있지만 문자열 이름이 있습니다. 저장할 수 있는 유일한 이중 유형은 말할 것도 없고 이 변수에 액세스하기 위해 매번 문자열 검색을 수행하고 저장해야 합니다. Union을 사용할 수 있다는 것은 분명하지만 그 사용도 무료는 아닙니다.
전역 변수를 사용하려는 아이디어와 열망이 있었지만 구식 방식으로 디스크에 무언가를 저장하기로 결정했습니다. 특히 지금은 가능한 한 정확하게 코드를 작성하기 시작했습니다. 데이터를 구조에 저장하고 구조를 다음 위치에 덤프할 수 있습니다. 한 번의 클릭으로 디스크 - FileWriteStruct()
따라서 전역 변수는 "정확히 반대"로 사용해야 합니다. 데이터는 전역 변수의 이름으로 저장되어야 합니다. Base64를 사용하여 이중 체크섬 - 모든 것이 CryptEncode()에서 준비되었으며 이상적으로는 일반적으로 Base85( Ascii85 ) 또는 Base128 github 어딘가에서 소스를 보았습니다.
내가 틀리지 않았다면 터미널 의 전역 변수 이름 은 256자입니까? Base64 효율성은 60%(크기)보다 약간 높으며 다른 인코딩 방법은 더 높습니다. 하나의 전역 변수에 총 160-180바이트를 저장할 수 있습니다.
사실, 접두사로 데이터를 정의해야 하지만 일반적으로 이 모든 것이 작동합니다. 특히 전역 변수가 거의 사용되지 않기 때문에 모든 이름은 기본적으로 무료입니다.
전역 변수를 사용하려는 아이디어와 열망이 있었지만 구식 방식으로 디스크에 무언가를 저장하기로 결정했습니다. 특히 지금은 가능한 한 정확하게 코드를 작성하기 시작했습니다. 데이터를 구조에 저장하고 구조를 다음 위치에 덤프할 수 있습니다. 한 번의 클릭으로 디스크 - FileWriteStruct()
따라서 전역 변수는 "정확히 반대"로 사용해야 합니다. 데이터는 전역 변수의 이름으로 저장되어야 합니다. Base64를 사용하여 이중 체크섬 - 모든 것이 CryptEncode()에서 준비되었으며 이상적으로는 일반적으로 Base85( Ascii85 ) 또는 Base128 github 어딘가에서 소스를 보았습니다.
내가 틀리지 않았다면 터미널 의 전역 변수 이름 은 256자입니까? Base64 효율성은 60%(크기)보다 약간 높으며 다른 인코딩 방법은 더 높습니다. 하나의 전역 변수에 총 160-180바이트를 저장할 수 있습니다.
사실, 접두사로 데이터를 정의해야 하지만 일반적으로 이 모든 것이 작동합니다. 특히 전역 변수가 거의 사용되지 않기 때문에 모든 이름은 기본적으로 무료입니다.
예제를 포함하여 클래스가 구성됩니다. 개발자는 리소스 주위에 래퍼를 작성하지 않고 데이터를 전송할 수 있는 새로운 기능을 도입할 것입니다.
플래그에 전역 변수 를 사용합니다. 항상 자신의 가치를 볼 수있는 기능도 편리합니다 - F3.
예제를 포함하여 클래스가 구성됩니다. 개발자는 리소스 주위에 래퍼를 작성하지 않고 데이터를 전송할 수 있는 새로운 기능을 도입할 것입니다.
플래그에 전역 변수 를 사용합니다. 항상 값을 확인하는 것도 편리합니다. - F3.
내 시각적 테스트 모드 에서 SymbolInfoTick() 함수 는 하나의 값을 반환하고 Close[0] 시계열에는 다른 값이 있음을 발견했습니다.
이게 내 실수야? 내가 뭔가 잘못하고 있습니까?
값이 같아야 하는 것 같습니다.
일반적으로 그 차이는 1-2 점이지만 날카로운 움직임에서는 그 이상이 될 수 있습니다.
나 뿐인가요?
지금까지 시계열을 "더 정확한" 것으로 간주했습니다. SymbolInfoTick()이 Close[0]과 다른 값을 제공하는 것으로 판명되면 Close[0]이 올바른 값이라고 생각하고 스프레드를 그대로 둡니다. SymbolInfoTick()에 의해 반환된 것과 같습니다.
그러나 그럼에도 불구하고 SymbolInfoTick() 또는 Close[0]에서 어떤 가격이 정확한지, DC가 "보는" 가격을 이해하는 것은 흥미롭습니다.
빌드 번호는 무엇입니까?
빌드 2155는 이미 수정되어야 합니다. 이 버그는 지난 주에 수정되었습니다.
빌드 번호는 무엇입니까?
빌드 2155는 이미 수정되어야 합니다. 이 버그는 지난 주에 수정되었습니다.
오. 그리고 2085가 있습니다.
알겠습니다. 업데이트 중입니다.
PS 예, 이제 값이 동일합니다.빌드 번호는 무엇입니까?
빌드 2155는 이미 수정되어야 합니다. 이 버그는 지난 주에 수정되었습니다.
이것에 대해 알려진 것이 있습니까?
재현할 세부정보를 제공하지 않았습니다.
재현할 세부정보를 제공하지 않았습니다.