이러한 솔루션은 datetimetime 과 함께 longtime_msc 도 구조에 추가될 때 매우 유용해 보입니다. 문제는 그렇다면 왜 여기에 시간 이 필요한가 하는 것입니다. 무의미한 자원 낭비.
uint 플래그 에도 동일하게 적용되지만 uchar 는 충분하거나 적어도 ushort 입니다(이는 이미 미래에 상당한 여유가 있습니다). 그리고 거기에 대한 것은 - 마음에 이해할 수 없습니다. 개발자들이 합리적인 데이터 저장에 대한 생각을 완전히 멈춘 것이 안타깝습니다. 틱 배열은 그 자체로 거대한 볼륨입니다. 그리고 거기에 너무 부주의하게 낭비되는 기억이 있습니다 ...
글쎄, 시간에 관한 한. 밀리초를 포함하는 일반 시간 유형을 MQL에 도입할 때가 되었습니까? 그렇지 않으면 이러한 목발이 쌓일 것입니다. 게다가 현재 형태의 datetime 자체는 매우 비합리적입니다. 8바이트를 소비하지만 초만 포함합니다. 누가 그것을 필요로 할까요? 이 작업을 위해 4바이트( uint )는 향후 90년 동안 충분합니다(우리 중에는 Duncan MacLeods가 없습니다).
우리의 경험을 믿으십시오. "한 두 바이트를 치자" 게임은 앞으로 엄청난 문제를 야기합니다. 이것을 이해하는 것은 앞으로 10년 동안 소프트웨어를 작성할 때만 가능합니다.
그래서 우리는 엉덩이에서 그것을하는 방법에 대해 이야기하지 않습니다. 물론 우리는 미래를 위한 예비비를 남겨 두어야 합니다. 그러나 합리적인 범위 내에서. 여기에서 논의 중인 경우 플래그 필드는 6개의 다른 필드에 대한 정보만 저장합니다. ushort 를 입력하면 다른 10개 필드에 여백이 생깁니다. 그럼 어디가 더 많습니까? 그 외에 무엇을 채울 수 있습니까?
예를 들어 전체 유리를 저장하려는 경우 32비트로도 충분하지 않습니다. 그렇다면 바로 64비트를 수행하지 않는 이유는 무엇입니까? 분명히 유리에는 완전히 다른 구조가 필요합니다.
물론 추가 2바이트는 그다지 중요하지 않다는 것을 이해합니다. 그러나 여기 2바이트, 저기 2바이트... 그리고 결국에는 제대로 실행됩니다.
4바이트의 날짜/시간(초)은 90년 후가 아니라 2038년(22년 이상)에 끝납니다.
당신은 뭔가를 혼동하고 있습니다. 우리는 uint 에 대해 이야기하고 있습니다. 136년을 저장할 수 있습니다. 저것들. 2106년까지. MQL5를 개발할 때 처음에 실수를 한 것 같습니다.
확장할 수 없는 경제적 구조로 자신을 괴롭히고, 수십 년 동안 생각하기 시작하고, 장기적인 지원의 필요성을 생각하면 모든 것이 명확해질 것입니다.
4바이트 날짜/시간을 사용하면 많은 소프트웨어에서 2038년에만 큰 오버플로 문제가 발생하여 이전 코드를 경련적으로 다시 작성하게 됩니다. 게다가, 오버플로는 매트 연산 및 델타에서 훨씬 더 일찍 포착됩니다.
저는 25년 동안 프로그래밍을 해왔고 제가 무슨 말을 하는지 압니다. 평생 경제 프로그램을 작성했습니다. 터미널을 보십시오. 작은 크기의 단일 exe 파일에 포함된 기능의 양 측면에서 보면 정말 걸작입니다. 그냥 재미로 깨끗한 시스템에서 하나의 베어 터미널.exe를 실행하고 어떤 일이 일어나는지 보십시오.
그러나 이제 모든 것이 바뀌었습니다. 거의 모든 곳에서 여백이 있는 64비트 코드를 작성하거나 미래에서 제외됩니다. 이것은 닫힌 상자를 출시하지 않고 호환성에 대한 필수 요구 사항이 있는 개발 플랫폼을 출시하기 때문에 특히 중요합니다.
몇 년 안에 우리는 여전히 우리의 팔꿈치를 물어뜯을 것입니다. 우리가 투자하지 않았다는 것이 다시 드러날 것이기 때문입니다. 그리고 기본 구성에서 수십 기가바이트의 컴퓨터 주변.
새로운 빌드 1200의 발표와 관련하여.
이러한 솔루션은 datetime time 과 함께 long time_msc 도 구조에 추가될 때 매우 유용해 보입니다. 문제는 그렇다면 왜 여기에 시간 이 필요한가 하는 것입니다. 무의미한 자원 낭비.
uint 플래그 에도 동일하게 적용되지만 uchar 는 충분하거나 적어도 ushort 입니다(이는 이미 미래에 상당한 여유가 있습니다). 그리고 거기에 대한 것은 - 마음에 이해할 수 없습니다. 개발자들이 합리적인 데이터 저장에 대한 생각을 완전히 멈춘 것이 안타깝습니다. 틱 배열은 그 자체로 거대한 볼륨입니다. 그리고 거기에 너무 부주의하게 낭비되는 기억이 있습니다 ...
글쎄, 시간에 관한 한. 밀리초를 포함하는 일반 시간 유형을 MQL에 도입할 때가 되었습니까? 그렇지 않으면 이러한 목발이 쌓일 것입니다. 게다가 현재 형태의 datetime 자체는 매우 비합리적입니다. 8바이트를 소비하지만 초만 포함합니다. 누가 그것을 필요로 할까요? 이 작업을 위해 4바이트( uint )는 향후 90년 동안 충분합니다(우리 중에는 Duncan MacLeods가 없습니다).
이 솔루션은 초 단위 시간 또는 SymbolInfoTick() 함수 를 사용하여 이전 프로그램과의 호환성을 유지합니다.
우리의 경험을 믿으십시오. "한 두 바이트를 치자" 게임은 앞으로 엄청난 문제를 야기합니다. 이것을 이해하는 것은 앞으로 10년 동안 소프트웨어를 작성할 때만 가능합니다.
4바이트의 날짜/시간(초)은 90년 후가 아니라 2038년(22년 더)에 끝납니다.
여기서 TM=30M 은 무엇을 의미합니까?:
우리의 경험을 믿으십시오. "한 두 바이트를 치자" 게임은 앞으로 엄청난 문제를 야기합니다. 이것을 이해하는 것은 앞으로 10년 동안 소프트웨어를 작성할 때만 가능합니다.
그래서 우리는 엉덩이에서 그것을하는 방법에 대해 이야기하지 않습니다. 물론 우리는 미래를 위한 예비비를 남겨 두어야 합니다. 그러나 합리적인 범위 내에서. 여기에서 논의 중인 경우 플래그 필드는 6개의 다른 필드에 대한 정보만 저장합니다. ushort 를 입력하면 다른 10개 필드에 여백이 생깁니다. 그럼 어디가 더 많습니까? 그 외에 무엇을 채울 수 있습니까?
예를 들어 전체 유리를 저장하려는 경우 32비트로도 충분하지 않습니다. 그렇다면 바로 64비트를 수행하지 않는 이유는 무엇입니까? 분명히 유리에는 완전히 다른 구조가 필요합니다.
물론 추가 2바이트는 그다지 중요하지 않다는 것을 이해합니다. 그러나 여기 2바이트, 저기 2바이트... 그리고 결국에는 제대로 실행됩니다.
4바이트의 날짜/시간(초)은 90년 후가 아니라 2038년(22년 이상)에 끝납니다.
확장할 수 없는 경제적 구조로 자신을 괴롭히고, 수십 년 동안 생각하기 시작하고, 장기적인 지원의 필요성을 생각하면 모든 것이 명확해질 것입니다.
4바이트 날짜/시간을 사용하면 많은 소프트웨어에서 2038년에만 큰 오버플로 문제가 발생하여 이전 코드를 경련적으로 다시 작성하게 됩니다. 게다가, 오버플로는 매트 연산 및 델타에서 훨씬 더 일찍 포착됩니다.
저는 25년 동안 프로그래밍을 해왔고 제가 무슨 말을 하는지 압니다. 평생 경제 프로그램을 작성했습니다. 터미널을 보십시오. 작은 크기의 단일 exe 파일에 포함된 기능의 양 측면에서 보면 정말 걸작입니다. 그냥 재미로 깨끗한 시스템에서 하나의 베어 터미널.exe를 실행하고 어떤 일이 일어나는지 보십시오.
그러나 이제 모든 것이 바뀌었습니다. 거의 모든 곳에서 여백이 있는 64비트 코드를 작성하거나 미래에서 제외됩니다. 이것은 닫힌 상자를 출시하지 않고 호환성에 대한 필수 요구 사항이 있는 개발 플랫폼을 출시하기 때문에 특히 중요합니다.
몇 년 안에 우리는 여전히 우리의 팔꿈치를 물어뜯을 것입니다. 우리가 투자하지 않았다는 것이 다시 드러날 것이기 때문입니다. 그리고 기본 구성에서 수십 기가바이트의 컴퓨터 주변.
여기서 TM=30M 은 무엇을 의미합니까?:
4바이트 날짜/시간을 사용하면 많은 소프트웨어에서 2038년에만 큰 오버플로 문제가 발생하여 이전 코드를 경련적으로 다시 작성하게 됩니다. 게다가, 오버플로는 매트 연산 및 델타에서 훨씬 더 일찍 포착됩니다.
MQL4 코드를 의미합니까? (여기서 datetime은 원래 int 기반임). 그런 다음 호환성 문제와 관련된 또 다른 대화입니다. 하지만 처음에는 합리성 에 대한 대화를 주도했습니다. 따라서 이 경우 합리성이 훼손됩니다.
그러나 어쨌든 밀리초를 포함하는 새로운 유형의 시간이 필요하다는 데 동의할 것입니다. 그리고 카운트다운은 1970년부터 시작하는 것이 아니라 1900년부터 훨씬 더 일찍 시작해야 합니다. Forex만의 문제가 아닙니다. 증권 거래소는 아주 고대부터 존재했습니다.
...
그러나 어쨌든 밀리초를 포함하는 새로운 유형의 시간이 필요하다는 데 동의할 것입니다. 그리고 카운트다운은 1970년부터 시작하는 것이 아니라 1900년부터 훨씬 더 일찍 시작해야 합니다. 이제 Forex만의 문제가 아닙니다. 증권 거래소는 아주 고대부터 존재했습니다.
유일한 문제는 Tsar Peas 하에서 컴퓨터를 사용하는 것이 유행하지 않았고 교환의 진드기 기록이 미래 세대를 위해 저장되지 않았다는 것입니다...
예 연설은 반드시 진드기에 관한 것은 아닙니다. 예를 들어, 매일의 양초는 꽤 보존되어 있습니다.
1900 .. 년 동안 매일 양초 가격이 왜 필요한지 묻기 민망합니다. 기술적 분석을 합니까? 역사에 대한 시험 고문?
MetaTrader 5 터미널의 x64 버전에서 실행 속도가 2배에서 10배로 증가했습니다.
그만한 가치가 있습니다. 우리는 여전히 컴파일 속도를 연구하고 있습니다.
당신은 최근 MQL의 속도가 이미 C++에 가깝다고 자랑했습니다. 그리고 지금, 당신의 말에 따르면 때때로 C ++를 따라 잡을 것입니까? ))
특별히 준비된 일부 테스트에서 그러한 가속을 얻었다고 해서 다른 경우에 가속이 있을 것이라는 의미는 전혀 아닙니다. 그러나 모든 경우에 컴파일 중단이 발생합니다.