내 접근 방식. 코어 - 엔진. - 페이지 86

 
Peter는 타원이 있는 gif에서 알 수 있듯이 형태가 하나의 연속적인 캔버스입니까? 드롭다운 목록은 어떻게 작동합니까? 드롭다운 목록이 양식의 크기를 초과하는 경우에 관심이 있습니다.
 
Vasiliy Sokolov :

나는 이것을 말할 것입니다 - 나 자신은 내 결정의 서투른 부분을 좋아하지 않습니다. MT 개체를 생성해야 합니다. 그러나 사실 이것은 편견일 뿐입니다. 무슨 상관이야? 완전한 전송을 위해서는 20-30 개 이상이 필요하지 않습니다.

30*64자 = 1920자. 이것은 큰 테이블 데이터를 전송하기에 충분합니다.

 
Dmitry Fedoseev :
Peter는 타원이 있는 gif에서 알 수 있듯이 형태가 하나의 연속적인 캔버스입니까? 드롭다운 목록은 어떻게 작동합니까? 드롭다운 목록이 양식의 크기를 초과하는 경우에 관심이 있습니다.

예, 양식은 하나의 캔버스입니다. 생성자 자체가 캔버스 이름을 작성하고 작업을 위한 래퍼 함수를 만듭니다.

드롭다운 목록은 창 외부 영역에서도 작동합니다. 구현되었습니다.

문제. 목록은 또 다른 캔버스일 뿐입니다. 버튼을 누르면 나타나고 사라집니다.

 
Vasiliy Sokolov :

전역 액세스를 위해 공유되는 바이트 배열에 대한 유니온을 통한 구조의 직접 매핑. 이것이 기술적으로 실현 가능한지는 모르겠지만, 그렇다면 속도는 우주적일 것입니다. 왜냐하면. 아무것도 복사할 필요가 없습니다.

예를 들어 주시면 기꺼이 이 결정을 수락하겠습니다.

 

그래프 개체를 통한 데이터 교환 에주의하십시오 :-)

그렇지 않으면 약간의 손 움직임으로 고문을 "최적화 대상이 아닌"형태로 만들 수 있습니다.

 
Реter Konow :

내 솔루션은 원래 조건에서 최상의 옵션입니다.

문자열이란 무엇입니까?

  1. 고정된 크기가 없습니다. 결과적으로 문자열 배열을 구성하고 해당 배열의 임의 문자열에 액세스할 수 없습니다.
  2. 문자열 에 데이터 입력 이 완전히 없습니다. 하위 유형은 문자열 구문 분석 내에서 동적으로 결정되어야 합니다. 필요한 어휘를 구문 분석하는 데 귀중한 시간이 소요됩니다. 그리고 토큰에 오류가 포함된 경우 라인은 이를 어떤 식으로든 제어하지 않습니다. 한 줄을 받고 올바르게 작곡되기를 기도합니다.
  3. 바이트당 정보 저장 효율성이 낮습니다. "opt=1;cancel=3"과 같은 서비스 문자열은 최대 256자(17%) 중 35-40자(바이트)를 사용합니다. 100바이트의 정보를 전송하려면 통신 채널을 로드하는 588바이트의 문자열을 구성해야 합니다. 문자를 압축하면 코드가 심각하게 복잡해집니다. 변수 이름을 줄이면 약간만 도움이 됩니다.

이 모든 명백한 사실에도 불구하고 Robin Hood 와 같은 당신은 당신이 얼마나 빠르고 정확하며 라인을 얼마나 잘 추측했는지 계속 방송합니다. 아니요, 추측하지 못했습니다. 이 모든 것이 매우 건강에 좋지 않습니다.

기본 지식이 필요한 직관에 의존하지 마십시오.

 
Vasiliy Sokolov :

문자열이란 무엇입니까?

  1. 고정된 크기가 없습니다. 결과적으로 문자열 배열을 구성하고 해당 배열의 임의 문자열에 액세스할 수 없습니다.
  2. 문자열 에 데이터 입력 이 완전히 없습니다. 하위 유형은 문자열 구문 분석 내에서 동적으로 결정되어야 합니다. 필요한 어휘를 구문 분석하는 데 귀중한 시간이 소요됩니다. 그리고 토큰에 오류가 포함된 경우 라인은 이를 어떤 식으로든 제어하지 않습니다. 한 줄을 받고 올바르게 작곡되기를 기도합니다.
  3. 바이트당 정보 저장 효율성이 낮습니다. "opt=1;cancel=3"과 같은 서비스 문자열은 최대 256자(17%) 중 35-40자(바이트)를 사용합니다. 100바이트의 정보를 전송하려면 통신 채널을 로드하는 588바이트의 문자열을 구성해야 합니다. 문자를 압축하면 코드가 심각하게 복잡해집니다. 변수 이름을 줄이면 약간만 도움이 됩니다.

이 모든 명백한 사실에도 불구하고 Robin Hood 와 같은 당신은 당신이 얼마나 빠르고 정확하며 라인을 얼마나 잘 추측했는지 계속 방송합니다. 아니요, 추측하지 못했습니다. 이 모든 것이 매우 건강에 좋지 않습니다.

기본 지식이 필요한 직관에 의존하지 마십시오.

Vasily, MT 개발자가 MT 개체의 설명을 유지하면서 문자열 문제를 고려했다고 생각하지 않습니까?

다른 사람들의 기본 지식을 타고 당신의 직관으로 시작하여 훨씬 더 많은 것을 성취하는 것이 훨씬 시원합니다.

 
Реter Konow :

Vasily, MT 개발자가 MT 개체의 설명을 유지하면서 문자열 문제를 고려했다고 생각하지 않습니까?

Peter, 각 데이터 저장 알고리즘에는 장단점이 있습니다. 물론 개발자들은 많은 것을 고려했고 확실히 훌륭하지만 기본적으로 문자열은 항상 문자열로 남아 있습니다.

 
Vasiliy Sokolov :

Peter, 각 데이터 저장 알고리즘에는 장단점이 있습니다. 물론 개발자들은 많은 것을 고려했고 확실히 훌륭하지만 기본적으로 문자열은 항상 문자열로 남아 있습니다.

Vasily, 연습이 내 결정의 결함을 보여 준다면 나는 그것을 거부할 것입니다. 그리고 니콜라이의 결정을 따르겠습니다. 이것이 나쁘다면 나는 OnChartEvent() 로 돌아가서 아무것도 할 수 없다고 말할 것입니다.

그러나 내 솔루션의 구현이 절름발이가 될 것이라고 아직 믿을 이유가 없습니다.

곧 알게 될 것입니다.

 
추신 특히 MT 개체에 문자열을 저장하는 주제에는 이상한 버그가 하나 있습니다. 데이터 압축을 시작하고 개체 이름에 인쇄할 수 없는 문자를 사용하면 경우에 따라 이 개체에 액세스할 수 없습니다. 글리치는 매우 구체적이고 이에 대해 아는 사람이 거의 없기 때문에 여전히 존재하지만 우연히 발견할 수 있습니다.