디자인 측면에서: 모든 것이 훨씬 간단합니다. @Fedor Arkhipov (주제 작성자 및 개시자)는 "이것이 정확히 이와 같기를 원하며 특히 Hibou가 지금 필요합니다"라고 선언합니다. 그리고 사소한 / 우리의 조정에 동의했습니다. :-) 왜냐하면 전체 아이디어를 알고있는 사람이기 때문입니다.
예를 들어, 많은 수업의 목적이 명확하지 않지만 이것들은 내 바퀴벌레입니다 ...
젠장, 당신은 그것을 필요로합니다. 그래서 당신은 가장 간결한 형태로 물건을 얻습니다. 당신은 신청하고, 명확한 답변과 스트림을 얻었고, 오류를 분류했습니다. 클래스와 메소드는 수백 개의 계층 구조로 채워질 수 있습니다 :-)
제가 이해한대로 답변드리도록 하겠습니다....
예, 하나의 Huobi 클래스(브로커 이름으로)를 만들고 모든 것을 거기에 넣고 웹 소켓에 액세스하고 구문 분석 요청 응답을 처리하면 결과적으로 빌어 먹을 파일을 얻을 수 있습니다. 원칙적으로 , 보드카 1리터로 이해하거나 다룰 수 없습니다. 따라서 기능을 클래스로 나누는 것은 매우 논리적으로 보입니다. 각 클래스에는 고유한 기능이 있습니다. C#은 절대 OOP이며, 그 안에 절차적 프로그래밍이 없습니다. 단어부터 전혀 모든 것이 클래스로 작성됩니다. 그러나 정적 클래스를 사용하여 절차적 프로그래밍의 환상을 만들 수 있습니다. 따라서 우리는 하나의 파일에서 서로 다른 기능을 사용할 뿐이라고 생각하십시오.
주제의 저자는 결국 자신이 원하는 것이 무엇인지 알고 있지만 이를 달성하는 방법을 모릅니다. 어떤 경우에는 소켓 작업을 정확하게 상상조차하지 못합니다.
물론 다른 동지들처럼 할 수 있습니다. "여기에 habr 및 wikis에 대한 링크가 있으며 악마는 다른 곳이 어디인지 알고 있습니다. 모든 것이 오래 전에 결정되었습니다. 재료를 피우러 가십시오 ....."
Maxim, 이러한 "도움"은 포럼 참가자의 90%가 제공합니다. 이런 일을 접할 때마다 나는 겁이 난다. 도움은 어디에 있습니까? 이 포럼은 무엇을 위한 것입니까? 글쎄요, 이것들은 모두 심리적인 측면입니다. 그것에 대해 이야기하지 맙시다.
기사 형태로 지식을 게시하는 사람들만이 본질적으로 모든 포럼 참가자에게 도움을 제공하고 나머지는 raspaltsovka에만 종사합니다. Fedor는 해당 주제의 다른 참가자들이 그에게 준 도움을 어디까지 발전시켰습니까?
자, 가사를 마치겠습니다.
젠장, Maxim은 "비난"으로 전체 퓨즈를 껐습니다. 기본적으로 모든 것이 끝나는 방식입니다. 진정한 도움을 주고자 하는 사람은 진흙탕에 젖어 소위 "도움"을 받는 그들 자신이 약간의 소리를 지르며 옆으로 치워둡니다. 결과적으로 질문자는 답변이 없는 상태로 남아 있고 일부 사용자는 과시하고 버려지고 누군가는 쓰레기였습니다.
예, 하나의 Huobi 클래스(브로커 이름으로)를 만들고 모든 것을 거기에 넣고 웹 소켓에 액세스하고 구문 분석 요청 응답을 처리하면 결과적으로 빌어 먹을 파일을 얻을 수 있습니다. 원칙적으로 , 보드카 1리터로 이해하거나 다룰 수 없습니다. 따라서 기능을 클래스로 나누는 것은 매우 논리적으로 보입니다. 각 클래스에는 고유한 기능이 있습니다. C#은 절대 OOP이며, 그 안에 절차적 프로그래밍이 없습니다. 단어부터 전혀 모든 것이 클래스로 작성됩니다. 그러나 정적 클래스를 사용하여 절차적 프로그래밍의 환상을 만들 수 있습니다. 따라서 우리는 하나의 파일에서 서로 다른 기능을 사용할 뿐이라고 생각하십시오.
주제의 저자는 결국 자신이 원하는 것이 무엇인지 알고 있지만 이를 달성하는 방법을 모릅니다. 어떤 경우에는 소켓 작업을 정확하게 상상조차하지 못합니다.
물론 다른 동지들처럼 할 수 있습니다. "여기에 habr 및 wikis에 대한 링크가 있으며 악마는 다른 곳이 어디인지 알고 있습니다. 모든 것이 오래 전에 결정되었습니다. 재료를 피우러 가십시오 ....."
Maxim, 이러한 "도움"은 포럼 참가자의 90%가 제공합니다. 이런 일을 접할 때마다 나는 겁이 난다. 도움은 어디에 있습니까? 이 포럼은 무엇을 위한 것입니까? 글쎄요, 이것들은 모두 심리적인 측면입니다. 그것에 대해 이야기하지 맙시다.
기사 형태로 지식을 게시하는 사람들만이 본질적으로 모든 포럼 참가자에게 도움을 제공하고 나머지는 raspaltsovka에만 종사합니다. Fedor는 해당 주제의 다른 참가자들이 그에게 준 도움을 어디까지 발전시켰습니까?
아, 가사를 마치겠습니다.
젠장, Maxim은 "비난"으로 전체 퓨즈를 껐습니다. 기본적으로 모든 것이 끝나는 방식입니다. 진정한 도움을 주고자 하는 사람은 진흙탕에 젖어 소위 "도움"을 받는 그들 자신이 약간의 소리를 지르며 옆으로 치워둡니다. 결과적으로 질문자는 답변이 없는 상태로 남아 있고 일부 사용자는 과시하고 버려지고 누군가는 쓰레기였습니다.
yapping에 대해 - 이 스레드에서 나에 관한 것이었습니까? 알렉스 피곤해..
그리고 미래에 대해 - 서버 메시지의 압축을 푸는 방법을 모르는 동안 어떤 nafik 클래스가 있습니까? 당신은 뭐 해요...
고객은 특정한 것을 원하고 멋진 C#에 대한 동화를 가지고 있습니다. 주제 발행 후 며칠이 지났습니까? 그리고 코드의 양과 결과는??
and -L and -l for linker to link against shared libraries. . Then compile like this: And export LD_LIBRARY_PATH and run like this: You can refer to the following Makefile to get a better picture...
프로토콜 자체는 모든 사람에게 동일하고 API 요청의 구현은 모든 사람에게 다릅니다. 다른 사람의 서재를 공부하다 보면 카밀포 자신도 모릅니다. 자신의 것을 작성하고 무엇이 어디에 있는지 이해하는 것이 더 쉽습니다. 또한 API 문서는 새로운 방법으로 지속적으로 업데이트되며 조정이 필요합니다. 나는 또한 다양한 기성품 솔루션을 삽질하고 침을 뱉고 C)로 내 라이브러리를 작성했습니다.)
프로토콜 자체는 모든 사람에게 동일하고 API 요청의 구현은 모든 사람에게 다릅니다. 다른 사람의 서재를 공부하다 보면 카밀포 자신도 모릅니다. 자신의 것을 작성하고 무엇이 어디에 있는지 이해하는 것이 더 쉽습니다. 또한 API 문서는 새로운 방법으로 지속적으로 업데이트되며 조정이 필요합니다. 나는 또한 다양한 기성품 솔루션을 삽질하고 침을 뱉고 C)로 내 라이브러리를 작성했습니다.)
나는 네트워크 프로토콜 (websockets)에 대해 말하는 것이 아니라 그것들을 기반으로 하는 요청/응답의 형태에 대한 다음 수준의 규칙에 대해 이야기하고 있습니다.
huobi libu를 보고 약 5분 만에 데이터 획득의 기본 원리를 이해했습니다. 나는 그것이 어렵다고 생각하지 않는다.
디자인 측면에서: 모든 것이 훨씬 간단합니다. @Fedor Arkhipov (주제 작성자 및 개시자)는 "이것이 정확히 이와 같기를 원하며 특히 Hibou가 지금 필요합니다"라고 선언합니다. 그리고 사소한 / 우리의 조정에 동의했습니다. :-) 왜냐하면 전체 아이디어를 알고있는 사람이기 때문입니다.
예를 들어, 많은 수업의 목적이 명확하지 않지만 이것들은 내 바퀴벌레입니다 ...
젠장, 당신은 그것을 필요로합니다. 그래서 당신은 가장 간결한 형태로 물건을 얻습니다. 당신은 신청하고, 명확한 답변과 스트림을 얻었고, 오류를 분류했습니다. 클래스와 메소드는 수백 개의 계층 구조로 채워질 수 있습니다 :-)
제가 이해한대로 답변드리도록 하겠습니다....
예, 하나의 Huobi 클래스(브로커 이름으로)를 만들고 모든 것을 거기에 넣고 웹 소켓에 액세스하고 구문 분석 요청 응답을 처리하면 결과적으로 빌어 먹을 파일을 얻을 수 있습니다. 원칙적으로 , 보드카 1리터로 이해하거나 다룰 수 없습니다. 따라서 기능을 클래스로 나누는 것은 매우 논리적으로 보입니다. 각 클래스에는 고유한 기능이 있습니다. C#은 절대 OOP이며, 그 안에 절차적 프로그래밍이 없습니다. 단어부터 전혀 모든 것이 클래스로 작성됩니다. 그러나 정적 클래스를 사용하여 절차적 프로그래밍의 환상을 만들 수 있습니다. 따라서 우리는 하나의 파일에서 서로 다른 기능을 사용할 뿐이라고 생각하십시오.
주제의 저자는 결국 자신이 원하는 것이 무엇인지 알고 있지만 이를 달성하는 방법을 모릅니다. 어떤 경우에는 소켓 작업을 정확하게 상상조차하지 못합니다.
물론 다른 동지들처럼 할 수 있습니다. "여기에 habr 및 wikis에 대한 링크가 있으며 악마는 다른 곳이 어디인지 알고 있습니다. 모든 것이 오래 전에 결정되었습니다. 재료를 피우러 가십시오 ....."
Maxim, 이러한 "도움"은 포럼 참가자의 90%가 제공합니다. 이런 일을 접할 때마다 나는 겁이 난다. 도움은 어디에 있습니까? 이 포럼은 무엇을 위한 것입니까? 글쎄요, 이것들은 모두 심리적인 측면입니다. 그것에 대해 이야기하지 맙시다.
기사 형태로 지식을 게시하는 사람들만이 본질적으로 모든 포럼 참가자에게 도움을 제공하고 나머지는 raspaltsovka에만 종사합니다. Fedor는 해당 주제의 다른 참가자들이 그에게 준 도움을 어디까지 발전시켰습니까?
자, 가사를 마치겠습니다.
젠장, Maxim은 "비난"으로 전체 퓨즈를 껐습니다. 기본적으로 모든 것이 끝나는 방식입니다. 진정한 도움을 주고자 하는 사람은 진흙탕에 젖어 소위 "도움"을 받는 그들 자신이 약간의 소리를 지르며 옆으로 치워둡니다. 결과적으로 질문자는 답변이 없는 상태로 남아 있고 일부 사용자는 과시하고 버려지고 누군가는 쓰레기였습니다.
모든 것을 했어, 욕은 하지 않았어
제가 이해한대로 답변드리도록 하겠습니다....
예, 하나의 Huobi 클래스(브로커 이름으로)를 만들고 모든 것을 거기에 넣고 웹 소켓에 액세스하고 구문 분석 요청 응답을 처리하면 결과적으로 빌어 먹을 파일을 얻을 수 있습니다. 원칙적으로 , 보드카 1리터로 이해하거나 다룰 수 없습니다. 따라서 기능을 클래스로 나누는 것은 매우 논리적으로 보입니다. 각 클래스에는 고유한 기능이 있습니다. C#은 절대 OOP이며, 그 안에 절차적 프로그래밍이 없습니다. 단어부터 전혀 모든 것이 클래스로 작성됩니다. 그러나 정적 클래스를 사용하여 절차적 프로그래밍의 환상을 만들 수 있습니다. 따라서 우리는 하나의 파일에서 서로 다른 기능을 사용할 뿐이라고 생각하십시오.
주제의 저자는 결국 자신이 원하는 것이 무엇인지 알고 있지만 이를 달성하는 방법을 모릅니다. 어떤 경우에는 소켓 작업을 정확하게 상상조차하지 못합니다.
물론 다른 동지들처럼 할 수 있습니다. "여기에 habr 및 wikis에 대한 링크가 있으며 악마는 다른 곳이 어디인지 알고 있습니다. 모든 것이 오래 전에 결정되었습니다. 재료를 피우러 가십시오 ....."
Maxim, 이러한 "도움"은 포럼 참가자의 90%가 제공합니다. 이런 일을 접할 때마다 나는 겁이 난다. 도움은 어디에 있습니까? 이 포럼은 무엇을 위한 것입니까? 글쎄요, 이것들은 모두 심리적인 측면입니다. 그것에 대해 이야기하지 맙시다.
기사 형태로 지식을 게시하는 사람들만이 본질적으로 모든 포럼 참가자에게 도움을 제공하고 나머지는 raspaltsovka에만 종사합니다. Fedor는 해당 주제의 다른 참가자들이 그에게 준 도움을 어디까지 발전시켰습니까?
아, 가사를 마치겠습니다.
젠장, Maxim은 "비난"으로 전체 퓨즈를 껐습니다. 기본적으로 모든 것이 끝나는 방식입니다. 진정한 도움을 주고자 하는 사람은 진흙탕에 젖어 소위 "도움"을 받는 그들 자신이 약간의 소리를 지르며 옆으로 치워둡니다. 결과적으로 질문자는 답변이 없는 상태로 남아 있고 일부 사용자는 과시하고 버려지고 누군가는 쓰레기였습니다.
yapping에 대해 - 이 스레드에서 나에 관한 것이었습니까? 알렉스 피곤해..
그리고 미래에 대해 - 서버 메시지의 압축을 푸는 방법을 모르는 동안 어떤 nafik 클래스가 있습니까? 당신은 뭐 해요...
고객은 특정한 것을 원하고 멋진 C#에 대한 동화를 가지고 있습니다. 주제 발행 후 며칠이 지났습니까? 그리고 코드의 양과 결과는??
yapping에 대해 - 이 스레드에서 나에 관한 것이었습니까? 알렉스 피곤해..
그리고 미래에 대해 - 서버 메시지의 압축을 푸는 방법을 모르는 동안 어떤 nafik 클래스가 있습니까? 당신은 뭐 해요...
고객은 특정 것을 원하고 멋진 C #에 대한 동화를 가지고 있습니다. 주제 발행 후 며칠이 지났습니까? 그리고 코드의 양과 결과는??
글쎄요 ... 나는 그것을 제쳐두고 있지만 숙련 된 전문가로서 사용 방법을 알고있는 방법을 사용하여 고객을 논리적 솔루션으로 안내합니다.
글쎄요 ... 나는 그것을 제쳐두고 있지만 숙련 된 전문가로서 사용 방법을 알고있는 방법을 사용하여 고객을 논리적 솔루션으로 안내합니다.
아니요, Alexei, 당신은 이미 그것을 가지고 당신에게 가져옵니다. 구체적인 내용을 다루기 위해 올바른 방향으로 안내하고 있습니다. 제가 정확히 지적한 것 같습니다.
그렇지 않으면 기술적 인 문제가 많을 때 "클래스를 구축"하는 방향으로 이동하십시오.
나는 고백합니다 - 왜냐하면 나는 엄격하고 억제되지 않기 때문입니다 ...
PS / 생성 + 정적 Hibou 메서드 제거, 논쟁의 여지가 더 많습니다. 파생 클래스를 사용할 수 있지만 "조금 숨을 쉬기" 시작하는 것은 모두 나중입니다.
PPS / 내 결정으로 인해 금지되었습니다 :-)
...
바이낸스 거래소에 동일한 시세 브로드캐스트에 대한 또 다른 요청이 있습니다.
그리고 모든 교환에서 서버와 클라이언트 간의 동일한 프로토콜은 무엇입니까? 보편적인 해결책은 없을 것이라고 확신합니다. 다시 github으로 이동하고 몇 분 안에 https://github.com/binance-exchange/binacpp 를 찾습니다.
사람들이 여가시간이 너무 많은 것 같아서 부럽습니다.
그리고 모든 교환에서 서버와 클라이언트 간의 동일한 프로토콜은 무엇입니까? 보편적인 해결책은 없을 것이라고 확신합니다. 다시 github으로 이동하고 몇 분 안에 https://github.com/binance-exchange/binacpp 를 찾습니다.
사람들이 여가시간이 너무 많은 것 같아서 부럽습니다.
프로토콜 자체는 모든 사람에게 동일하고 API 요청의 구현은 모든 사람에게 다릅니다.
다른 사람의 서재를 공부하다 보면 카밀포 자신도 모릅니다.
자신의 것을 작성하고 무엇이 어디에 있는지 이해하는 것이 더 쉽습니다.
또한 API 문서는 새로운 방법으로 지속적으로 업데이트되며 조정이 필요합니다.
나는 또한 다양한 기성품 솔루션을 삽질하고 침을 뱉고 C)로 내 라이브러리를 작성했습니다.)
프로토콜 자체는 모든 사람에게 동일하고 API 요청의 구현은 모든 사람에게 다릅니다.
다른 사람의 서재를 공부하다 보면 카밀포 자신도 모릅니다.
자신의 것을 작성하고 무엇이 어디에 있는지 이해하는 것이 더 쉽습니다.
또한 API 문서는 새로운 방법으로 지속적으로 업데이트되며 조정이 필요합니다.
나는 또한 다양한 기성품 솔루션을 삽질하고 침을 뱉고 C)로 내 라이브러리를 작성했습니다.)
나는 네트워크 프로토콜 (websockets)에 대해 말하는 것이 아니라 그것들을 기반으로 하는 요청/응답의 형태에 대한 다음 수준의 규칙에 대해 이야기하고 있습니다.
huobi libu를 보고 약 5분 만에 데이터 획득의 기본 원리를 이해했습니다. 나는 그것이 어렵다고 생각하지 않는다.