나는 새로운 지표를 취한다. 약간 까다로운 가격 샤넬. 종소리와 휘파람이없는 표시기는 30 분 또는 1 시간 안에 완료됩니다.
OOP 종소리와 휘파람을 사용하는 경우 이 표시기가 먼저 내 라이브러리에서 허용되는 범용 가상 인터페이스와 데이터 공급자에서 허용되는 범용 가상 인터페이스를 제공할 수 있도록 두 배의 시간이 필요합니다. 이 표시기는 "허용된 프로토콜 형식에 따라 생성됩니다 ". 게다가 그 이전에도 데이터 공급자와 전문가, 개별 지표와 시계열 간의 상호 작용을 위한 가상 인터페이스의 전체 구조를 데이터 공급자 자체 내부에서 생성하는 데 상당한 시간이 소요되었습니다.
하지만.
그 후 데이터 공급자는 "익숙한" 다른 모든 지표와 마찬가지로 이 지표의 가상 인터페이스를 내보냅니다. 결과적으로 코드에서 한 채널을 다른 채널로 변경하는 것이 매우 쉬워집니다. 데이터 공급자에게 채널 표시기를 요청할 때 요청 구조에서 이 최신 표시기의 식별자를 표시합니다. 그 후, 고문은 문제 없이 이 새로운 채널로 작업을 시작합니다.
또한 액세스 공식화로 인해 오류 및 수정이 있는 경우 이 작업이 크게 간소화됩니다. 그리고 가장 중요한 것은 - 캡슐화로 인해 - 나는 매 순간 제한된 수의 엔티티로 작업하므로 내 메모리의 부하를 크게 줄입니다. - 이미 두 번 이상 이야기했습니다.
즉, OOP의 메인 브레이크는 이제 막 개발 중입니다. 그리고 컴퓨터의 컴퓨팅 리소스 에는 전혀 없습니다.
요약: OOP는 개발 및 생성 시 추가 리소스가 필요하지만 사용 및 지원 리소스를 절약합니다. 글쎄요, 항상 새로운 것을 쓰는 것보다 유지하는 것이 더 어렵기 때문에 OOP를 선택하고 지금까지 한 번도 후회한 적이 없습니다. (동시에 OOP 인터페이스 없이 "무릎을 꿇고" 주기적으로 무언가를 합니다.)
자, 여기 내 감정을 표현했습니다. OOP 래퍼의 경우에도 배열의 데이터와 변수로 직접 작업하는 경우에도 작업 속도의 차이를 볼 수 없습니다.
하지만 개발하는 데 더 많은 시간이 필요합니다. 내가 가진 보상 - 단지 지원의 편의 때문입니다. 따라서 내가 "한 번에하지 않는"모든 작업은 항상 OOP 형식으로 작성합니다. 내가 아는 것은 두 번 필요하지 않습니다. 가상 기능 , 다형성 및 기타 OOP 종소리와 휘파람 없이 작성합니다.
가끔은 절대 필요하지 않을 거라 생각했던 상황을 마주하게 되는데, 결국 다시 필요하게 되었고, 바로 OOP 형식으로 작성하지 않은 것이 속상합니다. 그리고 그 반대의 경우도 마찬가지입니다. OOP 래퍼에 꽤 많은 시간을 할애하고 일정 시간이 지나면 여기서 한 일이 나에게 결코 유용하지 않을 것임을 알 수 있습니다. 그리고 질문이 생깁니다. "그리고 무엇을 위해, 내가 모든 것을 했습니까?"
Можно есть всё, НО в меру!!!!! Мера должна присутствовать и в сексе, и в спорте, и в работе, короче ГАРМОНИЯ во всём))))) Що занадто, то не здраво. (Доктор)
나는 무엇을 추측할 수 있다.
나는 새로운 지표를 취한다. 약간 까다로운 가격 샤넬. 종소리와 휘파람이없는 표시기는 30 분 또는 1 시간 안에 완료됩니다.
OOP 종소리와 휘파람을 사용하는 경우 이 표시기가 먼저 내 라이브러리에서 허용되는 범용 가상 인터페이스와 데이터 공급자에서 허용되는 범용 가상 인터페이스를 제공할 수 있도록 두 배의 시간이 필요합니다. 이 표시기는 "허용된 프로토콜 형식에 따라 생성됩니다 ". 게다가 그 이전에도 데이터 공급자와 전문가, 개별 지표와 시계열 간의 상호 작용을 위한 가상 인터페이스의 전체 구조를 데이터 공급자 자체 내부에서 생성하는 데 상당한 시간이 소요되었습니다.
하지만.
그 후 데이터 공급자는 "익숙한" 다른 모든 지표와 마찬가지로 이 지표의 가상 인터페이스를 내보냅니다. 결과적으로 코드에서 한 채널을 다른 채널로 변경하는 것이 매우 쉬워집니다. 데이터 공급자에게 채널 표시기를 요청할 때 요청 구조에서 이 최신 표시기의 식별자를 표시합니다. 그 후, 고문은 문제 없이 이 새로운 채널로 작업을 시작합니다.
또한 액세스 공식화로 인해 오류 및 수정이 있는 경우 이 작업이 크게 간소화됩니다. 그리고 가장 중요한 것은 - 캡슐화로 인해 - 나는 매 순간 제한된 수의 엔티티로 작업하므로 내 메모리의 부하를 크게 줄입니다. - 이미 두 번 이상 이야기했습니다.
즉, OOP의 메인 브레이크는 이제 막 개발 중입니다. 그리고 컴퓨터의 컴퓨팅 리소스 에는 전혀 없습니다.
요약: OOP는 개발 및 생성 시 추가 리소스가 필요하지만 사용 및 지원 리소스를 절약합니다. 글쎄요, 항상 새로운 것을 쓰는 것보다 유지하는 것이 더 어렵기 때문에 OOP를 선택하고 지금까지 한 번도 후회한 적이 없습니다. (동시에 OOP 인터페이스 없이 "무릎을 꿇고" 주기적으로 무언가를 합니다.)
개발 시간은 무엇입니까? 오버헤드 실행에 관한 것이었습니다.
1. 회계사가 필요하면 성별은 상관없어요. 내가 여자를 필요로 한다면 - 나는 그녀가 회계사이든 아니든 상관하지 않습니다.
2. 차이를 느끼지 못한다면 그것은 존재하지 않는 것입니다.
슬프게도. 그것은 색맹과 같습니다. 적어도 빨간색이 무엇인지 설명하십시오. 그가 그것을 보지 못한다면 그에게는 항상 녹색입니다. 아무데나 길을 건너십시오.
감사합니다.
1. 회계사가 필요하면 성별은 상관없어요. 내가 여자를 필요로 한다면 - 나는 그녀가 회계사이든 아니든 상관하지 않습니다.
2. 차이를 느끼지 못한다면 그것은 존재하지 않는 것입니다.
맞습니다. 가상화를 느끼면 실제로 존재하는 차이점을 볼 수 없으며 실제로 차이가 있지만 차이가 없음을 확신하게 될 것입니다. 이는 치명적인 결과를 초래할 수 있으며, 가상화의 피해자인 피해자가 될 수 있습니다.
우리는 당신을 가상 마스터라고 부를 것입니다))
예, "피해자"도 가능합니다. 어떻습니까, 위에서 제안한 것입니다 ... 그들은 부분적으로 옳습니다 ...
개발 시간은 무엇입니까? 오버헤드 실행에 관한 것이었습니다.
자, 여기 내 감정을 표현했습니다. OOP 래퍼의 경우에도 배열의 데이터와 변수로 직접 작업하는 경우에도 작업 속도의 차이를 볼 수 없습니다.
하지만 개발하는 데 더 많은 시간이 필요합니다. 내가 가진 보상 - 단지 지원의 편의 때문입니다. 따라서 내가 "한 번에하지 않는"모든 작업은 항상 OOP 형식으로 작성합니다. 내가 아는 것은 두 번 필요하지 않습니다. 가상 기능 , 다형성 및 기타 OOP 종소리와 휘파람 없이 작성합니다.
가끔은 절대 필요하지 않을 거라 생각했던 상황을 마주하게 되는데, 결국 다시 필요하게 되었고, 바로 OOP 형식으로 작성하지 않은 것이 속상합니다. 그리고 그 반대의 경우도 마찬가지입니다. OOP 래퍼에 꽤 많은 시간을 할애하고 일정 시간이 지나면 여기서 한 일이 나에게 결코 유용하지 않을 것임을 알 수 있습니다. 그리고 질문이 생깁니다. "그리고 무엇을 위해, 내가 모든 것을 했습니까?"
성배 ))) 성배는 어디에 있습니까?
예, "피해자"도 가능합니다. 어떻습니까, 위에서 제안한 것입니다 ... 그들은 부분적으로 옳습니다 ...
감사합니다.
Можно есть всё, НО в меру!!!!! Мера должна присутствовать и в сексе, и в спорте, и в работе, короче ГАРМОНИЯ во всём))))) Що занадто, то не здраво. (Доктор)
성배로 돌아가자))) 성배는 어디에 있습니까?
스레드 제목에서 이미 답변:
성배 - 테스터에서!
스레드 제목에서 이미 답변:
성배 - 테스터에서!
))))))))))))))
항상 시장의 그래프 테스터 차트가 다음과 같이 촬영된다는 의혹이 있었습니다.