멋진 속담이 있습니다. "바보에게 유리잔을 주면, 그는 ***를 깨고 손을 베게 될 것입니다."
TF를 자주 전환해야 하는 이유는 무엇입니까? - 이러한 신체 움직임(프로그램 동작)의 실질적인 의미는 무엇입니까? 나는 대답을 기다리지 않았다.
디자인 원리를 이해할 때 갈퀴가 없는 것은 좋은 것이고, 있는 것은 나쁜 것이고, 속담과의 유추는 부적절하다는 것을 분명히 해야 한다.
질문에 대해. 첫째, "자주 전환"에 대한 문구에 집착하는 이유는 무엇입니까? 현재 구현에서는 주파수가 문제에 영향을 미치지 않으며 단일 스위치로도 나타날 수 있습니다. 둘째, 본질적으로 대답하면 예를 들어 동일한 Slava가 ChartSetSymbolPeriod를 호출 하여 오프라인 차트를 새로 고치는 "현대적인" 방법으로 권장했습니다. 이 노하우가 차트의 여러 지표에 구축되지 않고 단기간에 작동하지 않을 것이라는 보장은 없습니다.
상황이 바뀌지 않을 것이라는 점을 이해하지만 최소한 MQ에 이 모든 멋진 현재 논리를 도움말에 작성하도록 요청하고 전문가와 터키 간의 차이점, 시간 프레임의 위아래 전환, 초기화 해제에 대한 모든 세부 정보와 함께 이유 코드(특히, 지금까지 참조는 표시기에 대한 코드 3을 거부함).
디자인 원리를 이해할 때 갈퀴가 없는 것은 좋은 것이고, 있는 것은 나쁜 것이고, 속담과의 유추는 부적절하다는 것을 분명히 해야 한다.
질문에 대해. 첫째, "자주 전환"에 대한 문구에 집착하는 이유는 무엇입니까? 현재 구현에서는 주파수가 문제에 영향을 미치지 않으며 단일 스위치로도 나타날 수 있습니다. 둘째, 본질적으로 대답하면 예를 들어 동일한 Slava가 ChartSetSymbolPeriod를 호출 하여 오프라인 차트를 새로 고치는 "현대적인" 방법으로 권장했습니다. 이 노하우가 차트의 여러 지표에 구축되지 않고 단기간에 작동하지 않을 것이라는 보장은 없습니다.
상황이 바뀌지 않을 것이라는 점을 이해하지만 최소한 MQ에 이 모든 멋진 현재 논리를 도움말에 작성하도록 요청하고 전문가와 터키 간의 차이점, 시간 프레임의 위아래 전환, 초기화 해제에 대한 모든 세부 정보와 함께 이유 코드(특히, 지금까지 참조는 표시기에 대한 코드 3을 거부함).
빈번한 TF 전환은 Dmitry가 바보도 할 수 있다는 점에서 주장으로 호소한 유일한 것입니다. 그러므로 이 속담은 매우 적절합니다. 내가 동의할 수 있는 유일한 것은 그것이 인증서에 문서화되어야 한다는 것입니다. 그리고 특히 다른 유형의 프로그램에 대해 동일한 상황에서 다르게 작동할 수 있는 사항에 대해 자세히 설명합니다.
빈번한 TF 전환은 Dmitry가 바보도 할 수 있다는 점에서 주장으로 호소한 유일한 것입니다. 그러므로 이 속담은 매우 적절합니다. 내가 동의할 수 있는 유일한 것은 그것이 인증서에 문서화되어야 한다는 것입니다. 그리고 특히 다른 유형의 프로그램에 대해 동일한 상황에서 다르게 작동할 수 있는 사항에 대해 자세히 설명합니다.
사실, 나는 init와 deinit가 어떻게 돌아가는지 방금 말했습니다.
그러나 일반적으로 엔지니어링 접근 방식은 매우 뛰어납니다. 작동 여부에 관계없이, 때로는 작동하고 때로는 작동하지 않습니다). 전혀 무섭지 않고 치명적이지 않습니다.
확인. 소켓의 경우 실패한 예입니다.
그런 다음 발코니에서 뛰어내립니다. 영국은 발코니에서 점프를 금지? - 아니요? - 그럼 아드레날린을 올릴 목적으로 연습을 해보는 건 어떨까요?
모든 목표는 올바른 수단으로 달성해야 합니다. 그렇지 않으면 목표가 미친 것입니다.
발코니도 나쁜 예입니다. 발코니에는 난간이 있으며 높이도 깍두기로 조절됩니다. 그러나 집에서는 모든 것을 이해하고 발코니에서 뛰어 내리지 않기 때문에 발코니에서 난간을 제거 할 수 있습니다.
발코니도 나쁜 예입니다. 발코니에는 난간이 있으며 높이도 깍두기로 조절됩니다. 그러나 집에서는 모든 것을 이해하고 발코니에서 뛰어 내리지 않기 때문에 발코니에서 난간을 제거 할 수 있습니다.
형법이 금지하지 않는 행위에 대해 말씀하셨습니다. 형법 발코니에서 점프하는 것은 금지되지 않습니다. 형법은 컴퓨터의 전원 버튼을 빠르게 누르는 것을 금지하지 않습니다. 형법은 많은 일을 금지하지 않지만 올바른 정신을 가진 사람은 아무도하지 않을 것입니다.
하지만 자주 TF를 바꾸고 싶으시다면.... 관심이 있는데요 - 왜?! 형법이 금지하지 않기 때문에? - 하지만 이것은 비판이지 MQ에 대한 바램이 아니다.
형법에서 금지하지 않는 행위에 대해 말씀하셨습니다. 형법 발코니에서 점프하는 것은 금지되지 않습니다. 형법은 컴퓨터의 전원 버튼을 빠르게 누르는 것을 금지하지 않습니다. 형법은 많은 일을 금지하지 않지만 올바른 정신을 가진 사람은 아무도하지 않을 것입니다.
하지만 자주 TF를 바꾸고 싶다.... 관심이 있다 - 왜?! 형법이 금지하지 않기 때문에? - 그러나 이것은 MQ에 대한 바램이 아니라 비판입니다.
나는 내가 원하는 것을 쓰지 않았다. 일어날 수 있다는 사실입니다. 문이 열리면 전구가 켜지거나 켜지지 않는 집의 냉장고를 상상해보십시오. 올바르게 작동하려면 특정 속도로 어떻게 든 문을 열어야합니다. 크레티니즘 아님?
나는 당신이 디자인 엔지니어이기 때문에 놀랍습니다. 아니면 문화의 집에서 아마추어 미술계의 수장입니까? 기본 설계 원칙에 대한 이해가 부족합니다.
나는 내가 원하는 것을 쓰지 않았다. 일어날 수 있다는 사실입니다. 문이 열리면 전구가 켜지거나 켜지지 않는 집의 냉장고를 상상해보십시오. 올바르게 작동하려면 특정 속도로 어떻게 든 문을 열어야합니다. 크레티니즘 아님?
나는 당신이 디자인 엔지니어이기 때문에 놀랍습니다. 아니면 문화의 집에서 아마추어 미술계의 수장입니까? 기본 디자인 원칙에 대한 이해가 부족합니다.
이것은 디자인 원칙에 대한 이해 부족입니다.
멋진 속담이 있습니다. "바보에게 유리잔을 주면, 그는 ***를 깨고 손을 베게 될 것입니다."
TF를 자주 전환해야 하는 이유는 무엇입니까? - 이러한 신체 움직임(프로그램 동작)의 실질적인 의미는 무엇입니까? 나는 대답을 기다리지 않았다.
이를 위해 나는 이별을 합니다. 의도적으로 무언가를 깨뜨릴 수 있는 방법에 대한 바보 같은 토론에 참여할 생각이 없습니다. 저는 엔지니어이지 터미네이터가 아닙니다.
디자인 원칙에 대한 이해가 부족하기 때문입니다.
멋진 속담이 있습니다. "바보에게 유리잔을 주면, 그는 ***를 깨고 손을 베게 될 것입니다."
TF를 자주 전환해야 하는 이유는 무엇입니까? - 이러한 신체 움직임(프로그램 동작)의 실질적인 의미는 무엇입니까? 나는 대답을 기다리지 않았다.
이를 위해 나는 이별을 합니다. 의도적으로 무언가를 깨뜨릴 수 있는 방법에 대한 바보 같은 토론에 참여할 생각이 없습니다. 저는 엔지니어이지 터미네이터가 아닙니다.
고등 교육 배지를 착용하기 시작했습니까?
TF를 변경할 때 deinit 및 init 실행 순서 문제에 대한 건설적인 논의와 관련이 없기 때문에 메시지 125부터 시작하는 모든 것을 삭제할 것을 제안합니다.
여기 당신은 헛된 것입니다. 매우 건설적인 토론은 유익했습니다.
디자인 원칙에 대한 이해가 부족하기 때문입니다.
멋진 속담이 있습니다. "바보에게 유리잔을 주면, 그는 ***를 깨고 손을 베게 될 것입니다."
TF를 자주 전환해야 하는 이유는 무엇입니까? - 이러한 신체 움직임(프로그램 동작)의 실질적인 의미는 무엇입니까? 나는 대답을 기다리지 않았다.
디자인 원리를 이해할 때 갈퀴가 없는 것은 좋은 것이고, 있는 것은 나쁜 것이고, 속담과의 유추는 부적절하다는 것을 분명히 해야 한다.
질문에 대해. 첫째, "자주 전환"에 대한 문구에 집착하는 이유는 무엇입니까? 현재 구현에서는 주파수가 문제에 영향을 미치지 않으며 단일 스위치로도 나타날 수 있습니다. 둘째, 본질적으로 대답하면 예를 들어 동일한 Slava가 ChartSetSymbolPeriod를 호출 하여 오프라인 차트를 새로 고치는 "현대적인" 방법으로 권장했습니다. 이 노하우가 차트의 여러 지표에 구축되지 않고 단기간에 작동하지 않을 것이라는 보장은 없습니다.
상황이 바뀌지 않을 것이라는 점을 이해하지만 최소한 MQ에 이 모든 멋진 현재 논리를 도움말에 작성하도록 요청하고 전문가와 터키 간의 차이점, 시간 프레임의 위아래 전환, 초기화 해제에 대한 모든 세부 정보와 함께 이유 코드(특히, 지금까지 참조는 표시기에 대한 코드 3을 거부함).
디자인 원리를 이해할 때 갈퀴가 없는 것은 좋은 것이고, 있는 것은 나쁜 것이고, 속담과의 유추는 부적절하다는 것을 분명히 해야 한다.
질문에 대해. 첫째, "자주 전환"에 대한 문구에 집착하는 이유는 무엇입니까? 현재 구현에서는 주파수가 문제에 영향을 미치지 않으며 단일 스위치로도 나타날 수 있습니다. 둘째, 본질적으로 대답하면 예를 들어 동일한 Slava가 ChartSetSymbolPeriod를 호출 하여 오프라인 차트를 새로 고치는 "현대적인" 방법으로 권장했습니다. 이 노하우가 차트의 여러 지표에 구축되지 않고 단기간에 작동하지 않을 것이라는 보장은 없습니다.
상황이 바뀌지 않을 것이라는 점을 이해하지만 최소한 MQ에 이 모든 멋진 현재 논리를 도움말에 작성하도록 요청하고 전문가와 터키 간의 차이점, 시간 프레임의 위아래 전환, 초기화 해제에 대한 모든 세부 정보와 함께 이유 코드(특히, 지금까지 참조는 표시기에 대한 코드 3을 거부함).
빈번한 TF 전환은 Dmitry가 바보도 할 수 있다는 점에서 주장으로 호소한 유일한 것입니다. 그러므로 이 속담은 매우 적절합니다.
내가 동의할 수 있는 유일한 것은 그것이 인증서에 문서화되어야 한다는 것입니다. 그리고 특히 다른 유형의 프로그램에 대해 동일한 상황에서 다르게 작동할 수 있는 사항에 대해 자세히 설명합니다.
빈번한 TF 전환은 Dmitry가 바보도 할 수 있다는 점에서 주장으로 호소한 유일한 것입니다. 그러므로 이 속담은 매우 적절합니다.
내가 동의할 수 있는 유일한 것은 그것이 인증서에 문서화되어야 한다는 것입니다. 그리고 특히 다른 유형의 프로그램에 대해 동일한 상황에서 다르게 작동할 수 있는 사항에 대해 자세히 설명합니다.
사실, 나는 init와 deinit가 어떻게 돌아가는지 방금 말했습니다.
그러나 일반적으로 엔지니어링 접근 방식은 매우 뛰어납니다. 작동 여부에 관계없이, 때로는 작동하고 때로는 작동하지 않습니다). 전혀 무섭지 않고 치명적이지 않습니다.