내가 어디에서 무언가를 교체하도록 제안 했습니까? 발명할 필요가 없습니다. 나는 그러한 가능성으로 언어를 보완 할 것을 제안했고 더 이상은 아닙니다. 변화에 대한 이야기는 없었다. 개발자들은 내 말을 들었고 나는 그것에 대해 기쁘게 생각합니다. 그리고 여기에서 다시 한 번, 당신이 달성하려는 것이 무엇인지 확신할 수 없습니다. 누군가가 이제 확립된 사물의 순서를 바꿀 것이라고 정말로 생각합니까? 예, 여기 사용자는 이를 위해 당신을 지울 것입니다.
포인터가 같은지 비교하기 위해 특수 함수를 사용할 수 있다는 사실에도 불구하고
원하는 경우 - 건강에 대한 기능을 사용하십시오. GetPointer 로 이 작업을 수행하는 것으로 충분합니다. 그리고 곧 개발자들이 &를 추가하고 일반적으로 편리하기를 바랍니다.
내 관심은 현재 가능한 유일한 방법으로 생성된 코드가 작동하고 미래에는 다음과 같은 이해하기 어려운 표현이 작동한다는 것입니다.
*a = (*b + *c) - *d**e + *f;
분명히 GetPointer 를 & -로 교체해도 아무 영향을 미치지 않으며 여기에서 편의 문제로 안내할 수 있습니다. 그러나 다른 혁신이 코드에 영향을 미칠 수 있습니다. 즉, 최소한 이점을 제공하고 기존 모순을 해결해야 하며 동시에 새로운 모순을 만들지 않아야 합니다. 지금까지는 *를 도입하는 장점이 눈에 띄지 않고 한정된 경우에 좀 더 편리한 표기가 장점이 아니라 편의성일 뿐입니다.
GetPointer를 &로 대체하는 것에 관해서는 원래 &의 해석을 주소를 취하는 연산으로 배제하기 위해 그러한 대체가 특별히 이루어졌다고 생각합니다. 그리고 의도적이라면 그럴만한 이유가 있었다.
우선, * 또는 &의 도입이 기존 코드에 어떤 영향을 미칠 수 있는지에 대한 적어도 하나의 예를 제공하십시오. 그러면 대화에 대한 예가 이미 있을 것입니다. 현재로서는 모두 횡설수설입니다. 또한 아무도 필요하지 않은 곳에 * 를 사용하도록 강요하지 않습니다(귀하가 인용한 공식에서와 같이).
* 도입의 장점은 눈에 보이지 않지만
글쎄, 당신이 볼 수 없다고해서 그것이 존재하지 않는다는 것을 의미하지는 않습니다. 이것은 이미 논의되었습니다. 나는 두 번째 원(더 정확하게는 세 번째 원)으로 가지 않을 것입니다.
GetPointer를 &로 대체하는 것에 관해서 는 원래 &의 해석을 주소를 취하는 연산으로 배제하기 위해 그러한 대체가 특별히 이루어졌다고 생각합니다 . 그리고 의도적이라면 그럴만한 이유가 있었다.
브라보, 셜록! 당신의 공제액은 비교할 수 없습니다. "범죄가 해결되었습니다."라고 덧붙이는 것만 남아 있습니다.
시장 중재자의 편에서 어떤 종류의 변태입니까?
내 제품은 통화 3 및 5자에서만 작동합니다(설명에 표시됨)
그리고 그들은 제품의 버그로 인해 새 버전을 출시하지 않습니다.
2015.08.26 15:43:03.415 2015.03.03 04:02 Hedging_Recovery__1 XAUUSD,H1: OrderSend error 130
나는 금속이 아닌 통화만을 위한 것이라고 분명히 말했습니다.
그리고 누가 옳습니까? 아니면 그들은 나에게 무엇을 원하는가?
금속을 금지하는 것이 더 쉽습니다.
맞습니다. 완전무결합니다. 사용자가 어떻게 쇠구슬도 부러뜨릴 수 있다는 변태를 알 수 있습니다...
초기화 검사에서 통과하지 못하면 화면과 인쇄 및 강제 완료에 메시지가 표시됩니다.
고마워 . 그래서 저는 생각합니다.
그러나 기호에 관해서는 예를 들어 XAUUSD라고 쓰고 거기에 센트에 넣을 것입니다 (쌍의 이름이 다르며 내가 아는 한 직접 작동하지 않았습니다)
통화인지 금속(선물 등)인지 즉시 알려주는 market_info 변수가 있습니까?
확인하다 .
아아. 변경 없이. 일치하지 않습니다.
사실, 당신은 간단하고 이해하기 쉬운 표기법을 제공합니다
~로 교체되다내가 어디에서 무언가를 교체하도록 제안 했습니까? 발명할 필요가 없습니다. 나는 그러한 가능성으로 언어를 보완 할 것을 제안했고 더 이상은 아닙니다. 변화에 대한 이야기는 없었다. 개발자들은 내 말을 들었고 나는 그것에 대해 기쁘게 생각합니다. 그리고 여기에서 다시 한 번, 당신이 달성하려는 것이 무엇인지 확신할 수 없습니다. 누군가가 이제 확립된 사물의 순서를 바꿀 것이라고 정말로 생각합니까? 예, 여기 사용자는 이를 위해 당신을 지울 것입니다.
포인터가 같은지 비교하기 위해 특수 함수를 사용할 수 있다는 사실에도 불구하고
원하는 경우 - 건강에 대한 기능을 사용하십시오. GetPointer 로 이 작업을 수행하는 것으로 충분합니다. 그리고 곧 개발자들이 &를 추가하고 일반적으로 편리하기를 바랍니다.
그리고 여기에서 다시 한 번, 당신이 달성하려는 것이 무엇인지 확신할 수 없습니다.
분명히 GetPointer 를 & -로 교체해도 아무 영향을 미치지 않으며 여기에서 편의 문제로 안내할 수 있습니다. 그러나 다른 혁신이 코드에 영향을 미칠 수 있습니다. 즉, 최소한 이점을 제공하고 기존 모순을 해결해야 하며 동시에 새로운 모순을 만들지 않아야 합니다. 지금까지는 *를 도입하는 장점이 눈에 띄지 않고 한정된 경우에 좀 더 편리한 표기가 장점이 아니라 편의성일 뿐입니다.
GetPointer를 &로 대체하는 것에 관해서는 원래 &의 해석을 주소를 취하는 연산으로 배제하기 위해 그러한 대체가 특별히 이루어졌다고 생각합니다. 그리고 의도적이라면 그럴만한 이유가 있었다.
누가 mt4와 mysql의 작업을 구현하려고 했는지 말해줘
지금까지 기사가 있습니다 https://www.mql5.com/ru/articles/932
우리는 코드의 간단한 구현이 필요합니다 ... 아마도 누군가가 알고 있거나 코드를 도와주거나 유사한 상황에서 어떻게 빠져나왔는지 알려줄 수 있습니다....
그러나 다른 혁신은 코드에 영향을 줄 수 있습니다.
우선, * 또는 &의 도입이 기존 코드에 어떤 영향을 미칠 수 있는지에 대한 적어도 하나의 예를 제공하십시오. 그러면 대화에 대한 예가 이미 있을 것입니다. 현재로서는 모두 횡설수설입니다. 또한 아무도 필요하지 않은 곳에 * 를 사용하도록 강요하지 않습니다(귀하가 인용한 공식에서와 같이).
* 도입의 장점은 눈에 보이지 않지만
글쎄, 당신이 볼 수 없다고해서 그것이 존재하지 않는다는 것을 의미하지는 않습니다. 이것은 이미 논의되었습니다. 나는 두 번째 원(더 정확하게는 세 번째 원)으로 가지 않을 것입니다.
GetPointer를 &로 대체하는 것에 관해서 는 원래 &의 해석을 주소를 취하는 연산으로 배제하기 위해 그러한 대체가 특별히 이루어졌다고 생각합니다 . 그리고 의도적이라면 그럴만한 이유가 있었다.
남. 포럼 관리자!
FAVORITES 섹션에서 그래픽을 제거하고 좋아하는 주제를 일반 라인으로 표시합니다. 그리고 거기에 새 메시지가 나타나면 포럼 주제의 이름으로 줄의 강조 표시를 입력하십시오.
벌써 눈이 휘둥그레지고, 선정된 토픽이 많으면 다 둘러보기도 불편하다. 또한 십자가를 클릭하여 주제를 실수로 즐겨찾기에서 삭제할 수 있습니다. 확인은 없습니다.