당신의 날카로운 것이 들판에서 나타났다고 생각합니까? C에 뿌리를 둔 struct는 추가 설탕이 없는 멍청한 컨테이너입니다.
글쎄요, 인간은 유인원에서 진화했습니다. 그러나 이것이 사람이 "추가 설탕이 없는" 어리석은 원숭이라는 것을 의미하지는 않습니다. 그렇지 않습니까? ) 실제로 MQL 구조 = C# 구조, 약간의 차이점이 있음을 이미 설명했습니다. C#에서는 여전히 인터페이스를 구현할 수 있습니다. 인터페이스, 칼! )
그런 자신감은 어디에서 오는가? 다른 번역 단위/다른 모듈/루프/일종의 컴파일러/...에서 함수 호출. 옵티마이저의 기능을 과대평가하지 마십시오. 이것은 컴파일러가 수행해야 하는 복사 제거 최적화가 아닙니다. 옵티마이저가 너무 똑똑해지고 비용이 들지 않는다면 다음 C 표준에서 "기본 초기화는 개체를 불확실한 상태로 두지 않습니다."라고 씁니다.
이것은 최적화라고 부르기조차 힘든 가장 진부하고 원시적인 것이기 때문입니다. 디버그 모드에서도 모든 컴파일러가 기본적으로 이 작업을 수행한다고 생각합니다. 그러면 무엇이 더 쉬울 수 있습니까? 코드를 구문 분석하는 동안변수에 대한 액세스를 모니터링합니다. 반복된 쓰기 작업이 있고 읽기 작업이 없으면 이전 레코드를 잘라냅니다.
당신은 이것을 무시할 수 있지만, 괜찮은 코더가 당신의 함수로 채워진 구조를 볼 때 당신을 똥코더처럼 볼 것이라는 사실에 놀라지 마십시오.
차라리 초기화 코딩 없이 작업으로 접근 방식을 호출하고 싶습니다. 컴퓨터 프로그램의 주요 품질은 무엇입니까? 안정. 동일한 입력 데이터로 동일한 결과를 제공해야 합니다. 그리고 당신은 그것을 입겠다고 제안합니다. 어딘가에서 변수를 초기화하는 것을 잊었고, 어딘가에서 구조에 새 필드를 추가했는데, 이 필드는 프로그램 전체에서 초기화되지 않은 상태였습니다. 프로그램은 다음과 같이 작동합니다 ...
C 언어는 하드웨어의 능력이 극도로 약한 고대에 만들어졌기 때문에 최적화 작업의 상당 부분이 프로그래머에게 이양되었습니다. 그리고 이제 이 마조히즘은 더 이상 관련이 없습니다. 너무 가렵다면 예를 들어 어셈블러가 아닌 C를 참조하는 이유는 무엇입니까? 어셈블러에서 직접 거래 시스템을 인코딩합니다. 나는 그들이 가장 빨리 될 것이라고 확신합니다. 아마도 시장보다 앞서있을 것입니다)
이것은 최적화라고 부르기조차 힘든 가장 진부하고 원시적인 것이기 때문입니다. 디버그 모드에서도 모든 컴파일러가 기본적으로 이 작업을 수행한다고 생각합니다. 그러면 무엇이 더 쉬울 수 있습니까? 코드를 구문 분석하는 동안 변수에 대한 액세스를 모니터링합니다. 반복된 쓰기 작업이 있고 읽기 작업이 없으면 이전 레코드를 잘라냅니다.
프로그램이 컴파일 타임에 완전히 예측 가능했다면 런타임에 실행될 필요가 전혀 없었을 것입니다. 정의상 외부 세계에서 무언가를 가져와 이를 기반으로 결과를 생성해야 하며 이것이 옵티마이저를 방해하는 불확실성입니다. 또한 비밀을 밝힐 것입니다. 공유 라이브러리는 런타임에 실행 파일과 연결되며 최적화 프로그램은 거기에서 아무 것도 추적할 수 없습니다. 당신은 여전히 백만 가지의 모든 종류의 케이스를 던질 수 있습니다. 밀리언 칼!
어딘가에서 변수를 초기화하는 것을 잊었고, 어딘가에서 구조에 새 필드를 추가했는데, 이 필드는 프로그램 전체에서 초기화되지 않은 상태였습니다. 프로그램은 다음과 같이 작동합니다 ...
fn_() 대신 fn()이라고 하는 3 대신 2를 곱한 것, ... . 손이 비뚤어지면 문제가됩니다.
C 언어는 하드웨어의 능력이 극도로 약한 고대에 만들어졌기 때문에 최적화 작업의 상당 부분이 프로그래머에게 이양되었습니다. 그리고 이제 이 마조히즘은 더 이상 관련이 없습니다. 너무 가렵다면 예를 들어 어셈블러가 아닌 C를 참조하는 이유는 무엇입니까? 어셈블러에서 직접 거래 시스템을 인코딩합니다. 나는 그들이 가장 빨리 될 것이라고 확신합니다. 아마도 시장보다 앞서있을 것입니다)
참고: C 표준(최신, C++ 표준이 아님): C11, C18, C2x가 준비 중입니다. 오히려 당신은 무능의 결과로 그것을 썼습니다.
프로그램이 컴파일 타임에 완전히 예측 가능했다면 런타임에 실행될 필요가 전혀 없었을 것입니다. 정의상 외부 세계에서 무언가를 가져와 이를 기반으로 결과를 생성해야 하며 이것이 옵티마이저를 방해하는 불확실성입니다. 또한 비밀을 밝힐 것입니다. 공유 라이브러리는 런타임에 실행 파일과 연결되며 최적화 프로그램은 거기에서 아무 것도 추적할 수 없습니다. 당신은 여전히 백만 가지의 모든 종류의 케이스를 던질 수 있습니다. 밀리언 칼!
외부 세계와의 데이터 교환 은 이미 특별한 경우입니다. 그리고 그들은 특별한 솔루션이 필요합니다. 그리고 우리는 그 자체로 프로그래밍에 대해 이야기하고 있으며 컴파일러가 변수가 외부에서 제어되지 않는다는 것을 알도록 보장되는 경우에 대해 이야기하고 있습니다. 그리고 그것은 대부분의 경우일 것입니다. 그렇지 않으면 순전히 시스템 프로그래밍으로 끝납니다. 이는 C에서 실제로 더 잘 수행되고 어셈블러에서 훨씬 더 좋습니다.
어딘가에 3 대신 2를 곱하고 fn_() 대신 fn()이라고 하며 ... . 손이 비뚤어지면 문제가됩니다.
3 대신 2를 곱하면 프로그램에서 안정적인 오류가 발생하므로 진단 및 찾기가 쉽습니다. 그리고 초기화되지 않은 변수를 사용하면 작동 여부에 관계없이 때때로 예측할 수 없는 결과를 초래하는 악마를 얻게 됩니다. 일반적으로 경험이 풍부한 프로그래머로 자신을 배치하면서 그러한 기본 사항을 설명하는 것이 다소 이상합니다.
외부 세계와의 데이터 교환은 이미 특별한 경우입니다. 그리고 그들은 특별한 솔루션이 필요합니다. 그리고 우리는 그 자체로 프로그래밍에 대해 이야기하고 있으며 컴파일러가 변수가 외부에서 제어되지 않는다는 것을 알도록 보장되는 경우에 대해 이야기하고 있습니다. 그리고 그것은 대부분의 경우일 것입니다. 그렇지 않으면 순전히 시스템 프로그래밍으로 끝납니다. 이는 C에서 실제로 더 잘 수행되고 어셈블러에서 훨씬 더 좋습니다.
외부 세계와의 교류는 모든 프로그램의 필수적인 부분입니다. 반복합니다. 그렇지 않으면 컴파일 시간에 계산할 수 있습니다. 예를 들어, 컴파일러가 여기서 초기화를 잘라낼까요?
int i = 54 ;
if (read_socket() == SIGNAL) {
fn(i);
}
i = 100 ;
...
// естественно, что никто не пишет такой бред:
int q = 3;
q = 7;
q = 9;
fq(q);
분명히 그는 read_socket()이 거기에서 무엇을 반환할지 전혀 모릅니다. 전체 프로그램은 외부 세계와의 상호 작용으로 "침투"됩니다. + 여기에 외부 모듈에 대한 호출 추가, ... .
3 대신 2를 곱하면 프로그램에서 안정적인 오류가 발생하므로 진단 및 찾기가 쉽습니다. 그리고 초기화되지 않은 변수를 사용하면 작동 여부에 관계없이 때때로 예측할 수 없는 결과를 초래하는 악마를 얻게 됩니다. 일반적으로 경험이 풍부한 프로그래머로 자신을 배치하면서 그러한 기본 사항을 설명하는 것이 다소 이상합니다.
안정적인 오류를 얻으려면 스택을 초기화하는 것이 매우 간단합니다.
int main() {
if ( true )
int init_stack[ 10000 ] { 0 };
}
엉덩이에서 메모리를 초기화하는 것도 사소한 문제입니다. 일종의 표현 함정에 빠지면 일반적으로 코어 덤프가 발생합니다.
다시 한 번 반복합니다. 옵티마이저가 매우 똑똑한 경우 기본 초기화는 일부 C11에서 필요한 경우 초기화 지침을 삽입하는 컴파일러와 함께 초기화 값과 동일합니다. 하지만 안타깝습니다. 아무도 강요하지 않습니다. 원하지 않으면 어디서나 하세요 T val{}; 기본적인 것들을 설명하는 것에 지쳤습니다.
다시 한 번 반복합니다. 옵티마이저가 매우 똑똑한 경우 기본 초기화는 일부 C11에서 필요한 경우 초기화 지침을 삽입하는 컴파일러와 함께 초기화 값과 동일합니다. 하지만 안타깝습니다. 아무도 강요하지 않습니다. 원하지 않으면 어디서나 하세요 T val{}; 기본적인 것들을 설명하는 것에 지쳤습니다.
내가 이해하는 것처럼 C++ 표준은 컨텍스트 없이 매우 형식적인 방식으로 규칙을 설명하기 때문입니다. 저것들. 초기화는 항상 수행되거나 수행되지 않습니다. 비교를 위해 C#에서는 초기화 없이 변수를 선언할 수 있지만 더 나아가 코드를 따라 초기화해야 합니다. 저것들. 컴파일러는 현재 명령뿐만 아니라 후속 코드를 분석하며 이는 언어 규칙에 포함됩니다. 그러나 C++에서는 표준에서 분석을 제공하지 않습니다. 유연성이 없습니다. 따라서 강제 초기화가 처방되면 분개하기 시작할 것입니다. 어떻습니까? 나는 모든 것을 제어하고 초기화하고 싶습니다! )
내가 이해하는 것처럼 C++ 표준은 컨텍스트 없이 매우 형식적인 방식으로 규칙을 설명하기 때문입니다. 저것들. 초기화는 항상 수행되거나 수행되지 않습니다. 비교를 위해 C#에서는 초기화 없이 변수를 선언할 수 있지만 더 나아가 코드를 따라 초기화해야 합니다. 저것들. 컴파일러는 현재 명령뿐만 아니라 후속 코드를 분석하며 이는 언어 규칙에 포함됩니다. 그러나 C++에서는 표준에서 분석을 제공하지 않습니다. 유연성이 없습니다. 따라서 강제 초기화가 처방되면 분개하기 시작할 것입니다. 어떻습니까? 나는 모든 것을 제어하고 초기화하고 싶습니다! )
런인 솔루션이 거기에 도달하고 그루터기 데크를 통해 작동하여 종종 추가 오버헤드가 발생하면 아무도 켤 수 없습니다. 예를 들어, 컴파일러가 C++17에서 복사 생략을 수행하도록 OBLIGATION 표준에 작성했습니다.
엉덩이에서 메모리를 초기화하는 것도 사소한 문제입니다. 일종의 표현 함정에 빠지면 일반적으로 코어 덤프가 발생합니다.
마지막 코멘트, 중재자는 화를 내지 않습니다)).
여기에서 명확히 할 필요가 있습니다. 호출에서 호출까지 스택에 다른 값이 있는 이유는 무엇입니까? https://ru.wikipedia.org/wiki/ASLR을 보호하는 것이 전부이며 앞서 말했듯이 초기화할 필요도 없습니다. 제 경우에는 시작할 때마다 동일한 주소에 배치하는 gdb(디버거)에서 소프트웨어를 실행합니다. 스택은 "임의의" 반환 주소로 오염되지 않습니다.
당신의 날카로운 것이 들판에서 나타났다고 생각합니까? C에 뿌리를 둔 struct는 추가 설탕이 없는 멍청한 컨테이너입니다.
글쎄요, 인간은 유인원에서 진화했습니다. 그러나 이것이 사람이 "추가 설탕이 없는" 어리석은 원숭이라는 것을 의미하지는 않습니다. 그렇지 않습니까? ) 실제로 MQL 구조 = C# 구조, 약간의 차이점이 있음을 이미 설명했습니다. C#에서는 여전히 인터페이스를 구현할 수 있습니다. 인터페이스, 칼! )
이것은 최적화라고 부르기조차 힘든 가장 진부하고 원시적인 것이기 때문입니다. 디버그 모드에서도 모든 컴파일러가 기본적으로 이 작업을 수행한다고 생각합니다. 그러면 무엇이 더 쉬울 수 있습니까? 코드를 구문 분석하는 동안변수에 대한 액세스를 모니터링합니다. 반복된 쓰기 작업이 있고 읽기 작업이 없으면 이전 레코드를 잘라냅니다.
당신은 이것을 무시할 수 있지만, 괜찮은 코더가 당신의 함수로 채워진 구조를 볼 때 당신을 똥코더처럼 볼 것이라는 사실에 놀라지 마십시오.
차라리 초기화 코딩 없이 작업으로 접근 방식을 호출하고 싶습니다. 컴퓨터 프로그램의 주요 품질은 무엇입니까? 안정. 동일한 입력 데이터로 동일한 결과를 제공해야 합니다. 그리고 당신은 그것을 입겠다고 제안합니다. 어딘가에서 변수를 초기화하는 것을 잊었고, 어딘가에서 구조에 새 필드를 추가했는데, 이 필드는 프로그램 전체에서 초기화되지 않은 상태였습니다. 프로그램은 다음과 같이 작동합니다 ...
C 언어는 하드웨어의 능력이 극도로 약한 고대에 만들어졌기 때문에 최적화 작업의 상당 부분이 프로그래머에게 이양되었습니다. 그리고 이제 이 마조히즘은 더 이상 관련이 없습니다. 너무 가렵다면 예를 들어 어셈블러가 아닌 C를 참조하는 이유는 무엇입니까? 어셈블러에서 직접 거래 시스템을 인코딩합니다. 나는 그들이 가장 빨리 될 것이라고 확신합니다. 아마도 시장보다 앞서있을 것입니다)
이것은 최적화라고 부르기조차 힘든 가장 진부하고 원시적인 것이기 때문입니다. 디버그 모드에서도 모든 컴파일러가 기본적으로 이 작업을 수행한다고 생각합니다. 그러면 무엇이 더 쉬울 수 있습니까? 코드를 구문 분석하는 동안 변수에 대한 액세스를 모니터링합니다. 반복된 쓰기 작업이 있고 읽기 작업이 없으면 이전 레코드를 잘라냅니다.
프로그램이 컴파일 타임에 완전히 예측 가능했다면 런타임에 실행될 필요가 전혀 없었을 것입니다. 정의상 외부 세계에서 무언가를 가져와 이를 기반으로 결과를 생성해야 하며 이것이 옵티마이저를 방해하는 불확실성입니다. 또한 비밀을 밝힐 것입니다. 공유 라이브러리는 런타임에 실행 파일과 연결되며 최적화 프로그램은 거기에서 아무 것도 추적할 수 없습니다. 당신은 여전히 백만 가지의 모든 종류의 케이스를 던질 수 있습니다. 밀리언 칼!
어딘가에서 변수를 초기화하는 것을 잊었고, 어딘가에서 구조에 새 필드를 추가했는데, 이 필드는 프로그램 전체에서 초기화되지 않은 상태였습니다. 프로그램은 다음과 같이 작동합니다 ...
fn_() 대신 fn()이라고 하는 3 대신 2를 곱한 것, ... . 손이 비뚤어지면 문제가됩니다.
C 언어는 하드웨어의 능력이 극도로 약한 고대에 만들어졌기 때문에 최적화 작업의 상당 부분이 프로그래머에게 이양되었습니다. 그리고 이제 이 마조히즘은 더 이상 관련이 없습니다. 너무 가렵다면 예를 들어 어셈블러가 아닌 C를 참조하는 이유는 무엇입니까? 어셈블러에서 직접 거래 시스템을 인코딩합니다. 나는 그들이 가장 빨리 될 것이라고 확신합니다. 아마도 시장보다 앞서있을 것입니다)
프로그램이 컴파일 타임에 완전히 예측 가능했다면 런타임에 실행될 필요가 전혀 없었을 것입니다. 정의상 외부 세계에서 무언가를 가져와 이를 기반으로 결과를 생성해야 하며 이것이 옵티마이저를 방해하는 불확실성입니다. 또한 비밀을 밝힐 것입니다. 공유 라이브러리는 런타임에 실행 파일과 연결되며 최적화 프로그램은 거기에서 아무 것도 추적할 수 없습니다. 당신은 여전히 백만 가지의 모든 종류의 케이스를 던질 수 있습니다. 밀리언 칼!
외부 세계와의 데이터 교환 은 이미 특별한 경우입니다. 그리고 그들은 특별한 솔루션이 필요합니다. 그리고 우리는 그 자체로 프로그래밍에 대해 이야기하고 있으며 컴파일러가 변수가 외부에서 제어되지 않는다는 것을 알도록 보장되는 경우에 대해 이야기하고 있습니다. 그리고 그것은 대부분의 경우일 것입니다. 그렇지 않으면 순전히 시스템 프로그래밍으로 끝납니다. 이는 C에서 실제로 더 잘 수행되고 어셈블러에서 훨씬 더 좋습니다.
어딘가에 3 대신 2를 곱하고 fn_() 대신 fn()이라고 하며 ... . 손이 비뚤어지면 문제가됩니다.
3 대신 2를 곱하면 프로그램에서 안정적인 오류가 발생하므로 진단 및 찾기가 쉽습니다. 그리고 초기화되지 않은 변수를 사용하면 작동 여부에 관계없이 때때로 예측할 수 없는 결과를 초래하는 악마를 얻게 됩니다. 일반적으로 경험이 풍부한 프로그래머로 자신을 배치하면서 그러한 기본 사항을 설명하는 것이 다소 이상합니다.
외부 세계와의 데이터 교환은 이미 특별한 경우입니다. 그리고 그들은 특별한 솔루션이 필요합니다. 그리고 우리는 그 자체로 프로그래밍에 대해 이야기하고 있으며 컴파일러가 변수가 외부에서 제어되지 않는다는 것을 알도록 보장되는 경우에 대해 이야기하고 있습니다. 그리고 그것은 대부분의 경우일 것입니다. 그렇지 않으면 순전히 시스템 프로그래밍으로 끝납니다. 이는 C에서 실제로 더 잘 수행되고 어셈블러에서 훨씬 더 좋습니다.
외부 세계와의 교류는 모든 프로그램의 필수적인 부분입니다. 반복합니다. 그렇지 않으면 컴파일 시간에 계산할 수 있습니다. 예를 들어, 컴파일러가 여기서 초기화를 잘라낼까요?
분명히 그는 read_socket()이 거기에서 무엇을 반환할지 전혀 모릅니다. 전체 프로그램은 외부 세계와의 상호 작용으로 "침투"됩니다. + 여기에 외부 모듈에 대한 호출 추가, ... .
3 대신 2를 곱하면 프로그램에서 안정적인 오류가 발생하므로 진단 및 찾기가 쉽습니다. 그리고 초기화되지 않은 변수를 사용하면 작동 여부에 관계없이 때때로 예측할 수 없는 결과를 초래하는 악마를 얻게 됩니다. 일반적으로 경험이 풍부한 프로그래머로 자신을 배치하면서 그러한 기본 사항을 설명하는 것이 다소 이상합니다.
안정적인 오류를 얻으려면 스택을 초기화하는 것이 매우 간단합니다.
엉덩이에서 메모리를 초기화하는 것도 사소한 문제입니다. 일종의 표현 함정에 빠지면 일반적으로 코어 덤프가 발생합니다.
다시 한 번 반복합니다. 옵티마이저가 매우 똑똑한 경우 기본 초기화는 일부 C11에서 필요한 경우 초기화 지침을 삽입하는 컴파일러와 함께 초기화 값과 동일합니다. 하지만 안타깝습니다. 아무도 강요하지 않습니다. 원하지 않으면 어디서나 하세요 T val{}; 기본적인 것들을 설명하는 것에 지쳤습니다.
다시 한 번 반복합니다. 옵티마이저가 매우 똑똑한 경우 기본 초기화는 일부 C11에서 필요한 경우 초기화 지침을 삽입하는 컴파일러와 함께 초기화 값과 동일합니다. 하지만 안타깝습니다. 아무도 강요하지 않습니다. 원하지 않으면 어디서나 하세요 T val{}; 기본적인 것들을 설명하는 것에 지쳤습니다.
내가 이해하는 것처럼 C++ 표준은 컨텍스트 없이 매우 형식적인 방식으로 규칙을 설명하기 때문입니다. 저것들. 초기화는 항상 수행되거나 수행되지 않습니다. 비교를 위해 C#에서는 초기화 없이 변수를 선언할 수 있지만 더 나아가 코드를 따라 초기화해야 합니다. 저것들. 컴파일러는 현재 명령뿐만 아니라 후속 코드를 분석하며 이는 언어 규칙에 포함됩니다. 그러나 C++에서는 표준에서 분석을 제공하지 않습니다. 유연성이 없습니다. 따라서 강제 초기화가 처방되면 분개하기 시작할 것입니다. 어떻습니까? 나는 모든 것을 제어하고 초기화하고 싶습니다! )
내가 이해하는 것처럼 C++ 표준은 컨텍스트 없이 매우 형식적인 방식으로 규칙을 설명하기 때문입니다. 저것들. 초기화는 항상 수행되거나 수행되지 않습니다. 비교를 위해 C#에서는 초기화 없이 변수를 선언할 수 있지만 더 나아가 코드를 따라 초기화해야 합니다. 저것들. 컴파일러는 현재 명령뿐만 아니라 후속 코드를 분석하며 이는 언어 규칙에 포함됩니다. 그러나 C++에서는 표준에서 분석을 제공하지 않습니다. 유연성이 없습니다. 따라서 강제 초기화가 처방되면 분개하기 시작할 것입니다. 어떻습니까? 나는 모든 것을 제어하고 초기화하고 싶습니다! )
런인 솔루션이 거기에 도달하고 그루터기 데크를 통해 작동하여 종종 추가 오버헤드가 발생하면 아무도 켤 수 없습니다. 예를 들어, 컴파일러가 C++17에서 복사 생략을 수행하도록 OBLIGATION 표준에 작성했습니다.
주제는 "오류, 버그, 질문"이라고 합니다.
MQL 대 C#, C++ 및 구문, 컴파일러 및 정신 운동과 관련된 기타 사항에 대해 논의할 주제를 직접 만드십시오.
주제를 막고 사용자의 다른 질문과 메시지가 토론에 빠져들고 있습니다.
그들은 나에게 질문을 할 곳을 묻습니다. 나는 여기에 그것을 보내고 그들은 나에게 대답합니다. 거기에서 사람들은 백 페이지에 대해 논쟁합니다. 나는 방해하지 않을 것입니다. 나머지는 의미가 없습니다 ...
'DEFAULT_INT_VALUE' - 상수 예상 NoConstForInput.mq5 13 33
오류 1개, 경고 0개 2 1
빌드 2361 및 2390
'DEFAULT_INT_VALUE' - 상수 예상 NoConstForInput.mq5 13 33
오류 1개, 경고 0개 2 1
빌드 2361 및 2390
안정적인 오류를 얻으려면 스택을 초기화하는 것이 매우 간단합니다.
엉덩이에서 메모리를 초기화하는 것도 사소한 문제입니다. 일종의 표현 함정에 빠지면 일반적으로 코어 덤프가 발생합니다.
마지막 코멘트, 중재자는 화를 내지 않습니다)).
여기에서 명확히 할 필요가 있습니다. 호출에서 호출까지 스택에 다른 값이 있는 이유는 무엇입니까? https://ru.wikipedia.org/wiki/ASLR을 보호하는 것이 전부이며 앞서 말했듯이 초기화할 필요도 없습니다. 제 경우에는 시작할 때마다 동일한 주소에 배치하는 gdb(디버거)에서 소프트웨어를 실행합니다. 스택은 "임의의" 반환 주소로 오염되지 않습니다.