도구 모음 아이콘을 통해 프로필을 변경합니다. 즉시 가격 척도에서 숫자가 손실됩니다(왼쪽 그림). 또한 다른 탭을 선택하여 차트를 변경하면 숫자가 복원됩니다(오른쪽 그림). 윈도우 8.1/32. 해상도는 1024x768이고 1280x1024도 시도했습니다. 125%를 확장합니다. 4개의 표지판에서 1개의 표지판이 분실되었고 5-2개의 표지판이 사라졌습니다.
빌드가 업데이트될 때마다 코드 컴파일이 중지되는 것이 얼마나 오래 지속됩니까? 그리고 컴파일하면 이전과 다르게 작동하기 시작합니다(더 나빠짐). 누가 그런 프로그래밍 언어를 필요로 합니까?
A100의 인내심에 감탄하며 이러한 버그를 꼼꼼히 파헤칩니다. 나는 이미 혐오감으로 가득 차 있다.
여기 위에서 누군가 A100이 컴파일러 검증 테스트를 수집할 것을 제안했습니다. 그러나 재미있는 것은 컴파일러 개발자 자신이 아닌 사용자가 이 문제를 처리해야 한다는 것입니다.
그리고 가장 중요한 것은 이 모든 것이 본질적으로 원숭이의 일이라는 것입니다. 프로그래머 팀의 수년간의 고된 작업(따라서 엄청난 돈)과 코드를 여러 번 다시 작성해야 하는 사용자의 수년간의 고된 작업을 낭비하는 이유는 무엇입니까? "C++ 컴파일러"라는 자전거를 발명합니다(약간의 수정 포함). 기성품 오픈 소스 컴파일러를 사용(또는 구매)하는 대신 필요에 맞게 몇 달 안에 완료하십시오.
그러나 아니요, 간단한 방법은 우리에게 적합하지 않습니다 ... 결국 가슴에 발 뒤꿈치로 자랑스럽게 자신을 이기는 것이 훨씬 더 중요합니다. 자전거.
세부 사항에 관해서는 최적화 비활성화 가능성에 대한 A100의 아이디어를 전적으로 지지합니다. 예를 들어 많은 실제 컴파일러에서와 같이 디버그 및 릴리스 모드를 만드십시오.
개인적으로, 당신의 자랑스러운 최적화 때문에 나는 여전히 빌드 1159에 머물고 있습니다. 왜냐하면 내 프로젝트 는 2초 만에 컴파일되고 후속 빌드에서는 20초 만에 컴파일되기 때문입니다. 약간의 성능 향상으로는 문제가 해결되지 않습니다. 대부분의 시간은 프로그램을 개발하고 편집하는 데 사용됩니다.
개인적으로, 당신의 자랑스러운 최적화 때문에 나는 여전히 빌드 1159에 머물고 있습니다. 왜냐하면 내 프로젝트는 2초 만에 컴파일되고 후속 빌드에서는 20초 만에 컴파일되기 때문입니다. 약간의 성능 향상으로는 문제가 해결되지 않습니다. 대부분의 시간은 프로그램을 개발하고 편집하는 데 사용됩니다.
100Kb의 소스 코드가 있는 프로젝트는 1325 빌드에서 1초 미만으로 컴파일됩니다. 견고한 OOP, 많은 가상 함수 및 오버로드, 템플릿, 포인터, const 수정자(가능한 모든 곳). DLL 및 OpenCL 없이.
브레이크의 원인을 알고 싶습니다. 컴파일러가 빠르게 최적화하는 데 도움이 되는 것은 아마도 const일 것입니다. 나는 브레이크를 다룬 적이 없다. 속도가 느려지는 코드 기반의 소스 코드를 제공하십시오.
컴파일러의 형태로 자전거에 대해. 수정을 위해 다른 사람의 프로젝트를 맡는 것은 장단점이 있습니다. 장단점을 모두 고려한 후 처음에는 자전거 쪽으로 몸을 기울일 것입니다. 물론 그러한 결정이 내려졌을 때 언어/컴파일러의 타이밍과 기능 측면에서 그러한 매복이 발생할 것이라고는 아무도 생각하지 못했습니다. 자신의 강점을 과대평가하거나 작업의 복잡성을 과소평가합니다. 물론 그들은 자전거 개발을 위해 돈 구름을 부풀렸습니다.
Занимается профессиональной разработкой ПО для биржевой и брокерской деятельности более 12 лет. Координатор группы проектов в компании Devexperts, участвует в разработке торговой платформы thinkorswim. Эксперт по...
MT4/950/32. 프로필 변경 시 숫자 손실
도구 모음 아이콘을 통해 프로필을 변경합니다. 즉시 가격 척도에서 숫자가 손실됩니다(왼쪽 그림). 또한 다른 탭을 선택하여 차트를 변경하면 숫자가 복원됩니다(오른쪽 그림). 윈도우 8.1/32. 해상도는 1024x768이고 1280x1024도 시도했습니다. 125%를 확장합니다. 4개의 표지판에서 1개의 표지판이 분실되었고 5-2개의 표지판이 사라졌습니다.
아마도 MT4에서 MT5로 글꼴 크기 를 늘리고 바로 시작했을 것입니다.
역학에서 작동하지 않는 CHART_SHIFT_SIZE
test391.ex5에서와 같이 예상되는 역학MT4 편집기를 통해 Vault에서 내 파일을 다운로드 할 수 없습니다. 오류가 발생합니다.
MT4 편집기를 통해 Vault에서 내 파일을 다운로드 할 수 없습니다. 오류가 발생합니다.
빌드가 업데이트될 때마다 코드 컴파일이 중지되는 것이 얼마나 오래 지속됩니까? 그리고 컴파일하면 이전과 다르게 작동하기 시작합니다(더 나빠짐). 누가 그런 프로그래밍 언어를 필요로 합니까?
A100의 인내심에 감탄하며 이러한 버그를 꼼꼼히 파헤칩니다. 나는 이미 혐오감으로 가득 차 있다.
여기 위에서 누군가 A100이 컴파일러 검증 테스트를 수집할 것을 제안했습니다. 그러나 재미있는 것은 컴파일러 개발자 자신이 아닌 사용자가 이 문제를 처리해야 한다는 것입니다.
그리고 가장 중요한 것은 이 모든 것이 본질적으로 원숭이의 일이라는 것입니다. 프로그래머 팀의 수년간의 고된 작업(따라서 엄청난 돈)과 코드를 여러 번 다시 작성해야 하는 사용자의 수년간의 고된 작업을 낭비하는 이유는 무엇입니까? "C++ 컴파일러"라는 자전거를 발명합니다(약간의 수정 포함). 기성품 오픈 소스 컴파일러를 사용(또는 구매)하는 대신 필요에 맞게 몇 달 안에 완료하십시오.
그러나 아니요, 간단한 방법은 우리에게 적합하지 않습니다 ... 결국 가슴에 발 뒤꿈치로 자랑스럽게 자신을 이기는 것이 훨씬 더 중요합니다. 자전거.
세부 사항에 관해서는 최적화 비활성화 가능성에 대한 A100의 아이디어를 전적으로 지지합니다. 예를 들어 많은 실제 컴파일러에서와 같이 디버그 및 릴리스 모드를 만드십시오.
개인적으로, 당신의 자랑스러운 최적화 때문에 나는 여전히 빌드 1159에 머물고 있습니다. 왜냐하면 내 프로젝트 는 2초 만에 컴파일되고 후속 빌드에서는 20초 만에 컴파일되기 때문입니다. 약간의 성능 향상으로는 문제가 해결되지 않습니다. 대부분의 시간은 프로그램을 개발하고 편집하는 데 사용됩니다.
개인적으로, 당신의 자랑스러운 최적화 때문에 나는 여전히 빌드 1159에 머물고 있습니다. 왜냐하면 내 프로젝트는 2초 만에 컴파일되고 후속 빌드에서는 20초 만에 컴파일되기 때문입니다. 약간의 성능 향상으로는 문제가 해결되지 않습니다. 대부분의 시간은 프로그램을 개발하고 편집하는 데 사용됩니다.
100Kb의 소스 코드가 있는 프로젝트는 1325 빌드에서 1초 미만으로 컴파일됩니다. 견고한 OOP, 많은 가상 함수 및 오버로드, 템플릿, 포인터, const 수정자(가능한 모든 곳). DLL 및 OpenCL 없이.
브레이크의 원인을 알고 싶습니다. 컴파일러가 빠르게 최적화하는 데 도움이 되는 것은 아마도 const일 것입니다. 나는 브레이크를 다룬 적이 없다. 속도가 느려지는 코드 기반의 소스 코드를 제공하십시오.
컴파일러의 형태로 자전거에 대해. 수정을 위해 다른 사람의 프로젝트를 맡는 것은 장단점이 있습니다. 장단점을 모두 고려한 후 처음에는 자전거 쪽으로 몸을 기울일 것입니다. 물론 그러한 결정이 내려졌을 때 언어/컴파일러의 타이밍과 기능 측면에서 그러한 매복이 발생할 것이라고는 아무도 생각하지 못했습니다. 자신의 강점을 과대평가하거나 작업의 복잡성을 과소평가합니다. 물론 그들은 자전거 개발을 위해 돈 구름을 부풀렸습니다.
브레이크의 원인을 알고 싶습니다. 컴파일러가 빠르게 최적화하는 데 도움이 되는 것은 아마도 const일 것입니다. 나는 브레이크를 다룬 적이 없다. 속도가 느려지는 코드 기반의 소스 코드를 제공하십시오.
아마도 그것은 텍스트의 발보 형태의 거대한 기능을 가지고 있습니다.
이러한 발판에서 최적화 프로그램은 많은 패스를 수행하여 코드를 계속해서 개선해야 합니다. 옵티마이저의 속도가 급격히 증가하도록 함수의 크기를 줄이는 것으로 충분합니다.
글쎄, 우리는 품질과 속도를 지속적으로 개선하고 있으므로 최신 빌드로 전환하십시오.
아마도 그것은 텍스트의 발보 형태의 거대한 기능을 가지고 있습니다.
이러한 발판에서 최적화 프로그램은 많은 패스를 수행하여 코드를 계속해서 개선해야 합니다. 옵티마이저의 속도가 급격히 증가하도록 함수의 크기를 줄이는 것으로 충분합니다.
글쎄, 우리는 품질과 속도를 지속적으로 개선하고 있으므로 최신 빌드로 전환하십시오.
아마도 신발장에있을 것입니다. 적어도 나는 그것들을 가지고 있지 않다.
국제 프로그래밍 대회 우승자로부터 함수가 최대 20줄(조건부)이어야 한다는 말을 들은 적이 있습니다. 더 많은 경우 아키텍처/알고리즘적으로 최적의 접근 방식이 아닙니다.
Roman Elizarov 의 소스 코드를 보면 와일드 네스팅이 포함된 측정되지 않은 수의 단순 함수가 있습니다. 그리고 거의 모든 것이 최대 5줄입니다. 이 지적인 덩어리에 비하면 나 자신이 애벌레야.... 그래서 내 시간에 아무리 애를 써도 잘 안 된다.
서로 겹치는 개체 위로 마우스를 가져가면 상단 개체 대신 배경 개체에 대한 설명이 표시됩니다. OBJ_EVENT 개체에서 발음됩니다. 나는 빨간색을보고 설명은 파란색입니다.