나에게 지금 평범한 작업은 .dll의 VS를 우아한 방식으로 MT5로 고정하고 싶습니다.)) - 클래스의 버튼 클릭 핸들러를 래핑하고 포인터 배열을 우회하여 호출하고 싶습니다. 핸들러 함수, 그리고 VS에서와 같이 기본 EA 코드에서 이름 f를 일대일로 쓰는 기능을 얻고 싶습니다. button2_Click() ....button2_Click()
흥미롭게도 "중괄호가없는"이 지지자들은 누구입니까? 실제로 if 또는 for 아래에 한 줄의 코드가 있는 코드는 없습니다. 처음에 하나라도 시간이 지나면 더 많이 나타나서 중괄호를 작성해야 할 가능성이 매우 큽니다. 처음에는 두 개의 중괄호를 넣는 것이 비용이 많이 드는 작업이 아니지만 나중에 넣으면 코드를 눈으로 확인하고 줄의 끝을 찾아야 합니다.
나는 그들이 교사라고 가정합니다. 언어에 대한 아주 좋은 지식이 있기 때문에, 특히 실제로 거의 사용되지 않는 순간에 대해 무한한 시간 동안 미루는 경향이 있습니다. 강의에서 나는 몇 줄의 코드를 작성했고 한 시간 반 동안 토론했습니다. 여기서 중괄호에 대한 질문은 발생하지 않습니다.
중괄호 누락의 가장 큰 문제는 재작업 및 디버깅에서 발생합니다. 무언가를 인쇄해야 한다고 가정합니다. 행이 추가 되고 현재로서는 인접 행이 if 또는 under에 의해 위치한다고 생각하는 사람은 거의 없습니다. 그래서 개선 사항으로 - 나는 장소를 찾았고, 한 줄을 추가했고 모든 것이 망가졌습니다. 나는 그러한 문제를 여러 번 만났습니다. 내 자리뿐만 아니라 (내 자리에서 한 번만 그리고 그 순간부터 즉시 두 개의 대괄호를 씁니다). 따라서 모든 사람에게 if 및 for를 작성한 직후 중괄호 두 개를 작성하는 것이 좋습니다. 또한 분실된 중괄호를 잘 보호하므로 가장 찾기 어려운 실수입니다.
int sum( int a, int b){ return a+b; }
//+------------------------------------------------------------------+voidOnStart ()
{
Print (sum( 3 , 7 ));
}
//+------------------------------------------------------------------+
그럼, 통제 질문: 당신은 왜 여기 에 있습니까?
전체를 대괄호로 묶지 않습니까?
여기에 괄호가 포함되어 있기 때문에 받아들이지 않습니다.
그러나 당신은 그러한 암시적인 의미가 없습니다. 모든 것이 엄격하게 "과학에 따라"여야합니다.
그럼, 통제 질문: 당신은 왜 여기 에 있습니까?
괄호 안 쳐?
여기에 괄호가 포함되어 있기 때문에 받아들이지 않습니다.
그러나 당신은 그러한 암시적인 의미가 없습니다. 모든 것이 "과학"에 따라 엄격하게 이루어져야 합니다.
My t는 유형이고 n은 2의 거듭제곱의 특정 수이며 이에 대한 마스크는 (1<<(n+1))-1입니다. 마지막 버전의 나는 다음과 같이 작성되었습니다.
두 번째 경우에 첫 번째에 비해 녹음을 복잡하게 만든 이유는 스스로 짐작할 수 있습니다.
여기서 나는 각각의 경우에 대괄호를 \ "상황에 따라" 넣지 않는다는 결론을 내렸습니다. 그러나 컴파일러는 그렇게 할 수 없습니다. 경고를 발행하기 위한 엄격한 규칙이 필요합니다.
나는 그들이 논리를 이해하는 데 필요하지 않습니다. 내가 더 재능이 있다는 뜻인가요? )
나는 군대와 캐치 프레이즈를 기억하고 있습니다. 감독은 "모든 사람에게는 자신의 진실이 있습니다"라는 다소 영리한 문구를 말한 것 같습니다. IMHO, 맞습니다.
;)
추신: 불행히도 우리 시대에 재능은 돈으로 측정됩니다. 나는 그것에 대해 반대할 것이 없고 더 재능이 있지만 다른 사람들에게 해를 끼치지는 않습니다.)
나에게 지금 평범한 작업은 .dll의 VS를 우아한 방식으로 MT5로 고정하고 싶습니다.)) - 클래스의 버튼 클릭 핸들러를 래핑하고 포인터 배열을 우회하여 호출하고 싶습니다. 핸들러 함수, 그리고 VS에서와 같이 기본 EA 코드에서 이름 f를 일대일로 쓰는 기능을 얻고 싶습니다. button2_Click() ....button2_Click()
추신: EOP 영역의 작업)))
계속하지 마십시오. 그렇지 않으면 이 작업을 수행하고 게시하면 그래픽 패널/인터페이스를 만들기 위한 기사/라이브러리의 수가 기록에 남을 것입니다.
계속하지 마십시오. 그렇지 않으면 이 작업을 수행하고 게시하면 그래픽 패널/인터페이스를 만들기 위한 기사/라이브러리의 수가 기록에 남을 것입니다.
아아, "서두르기에는 너무 늦었습니다", 내가 여기 주제에 글을 쓰고 있는 동안 그들은 이미 내 생각을 도왔습니다. 나는 이미 모든 것을 매우 간결하게 수행했으며 모든 것이 VS 스타일입니다
오랫동안 아무 것도 게시하지 않을 것입니다. 죄송합니다. 그러나 다시 한 번 나는 좋은 사람들에게서 뒤에서 침을 수집합니다 ... 나는 오프라인으로 충분합니다. 연습에서 알 수 있듯이 더 쉽습니다. 그들이 말하는 대로 하기: 질문을 받지 않은 사람을 절대 돕지 마십시오
))
흥미롭게도 "중괄호가없는"이 지지자들은 누구입니까? 실제로 if 또는 for 아래에 한 줄의 코드가 있는 코드는 없습니다. 처음에 하나라도 시간이 지나면 더 많이 나타나서 중괄호를 작성해야 할 가능성이 매우 큽니다. 처음에는 두 개의 중괄호를 넣는 것이 비용이 많이 드는 작업이 아니지만 나중에 넣으면 코드를 눈으로 확인하고 줄의 끝을 찾아야 합니다.
나는 그들이 교사라고 가정합니다. 언어에 대한 아주 좋은 지식이 있기 때문에, 특히 실제로 거의 사용되지 않는 순간에 대해 무한한 시간 동안 미루는 경향이 있습니다. 강의에서 나는 몇 줄의 코드를 작성했고 한 시간 반 동안 토론했습니다. 여기서 중괄호에 대한 질문은 발생하지 않습니다.
중괄호 누락의 가장 큰 문제는 재작업 및 디버깅에서 발생합니다. 무언가를 인쇄해야 한다고 가정합니다. 행이 추가 되고 현재로서는 인접 행이 if 또는 under에 의해 위치한다고 생각하는 사람은 거의 없습니다. 그래서 개선 사항으로 - 나는 장소를 찾았고, 한 줄을 추가했고 모든 것이 망가졌습니다. 나는 그러한 문제를 여러 번 만났습니다. 내 자리뿐만 아니라 (내 자리에서 한 번만 그리고 그 순간부터 즉시 두 개의 대괄호를 씁니다). 따라서 모든 사람에게 if 및 for를 작성한 직후 중괄호 두 개를 작성하는 것이 좋습니다. 또한 분실된 중괄호를 잘 보호하므로 가장 찾기 어려운 실수입니다.
두 개의 다른 캠프가 있습니다.
1. 버티컬 코드의 지지자.
2. 수평 코드의 지지자.
또한 흥미로운 주제입니다.
두 개의 다른 캠프가 있습니다.
1. 버티컬 코드의 지지자.
2. 수평 코드의 지지자.
또한 흥미로운 주제입니다.
쓸모 없음()에 대한 주제의 주요 주제를 새 주제와 하나의 코드로 병합했습니다.
...팝콘 먹으러 갔어...