주문을 부분적으로 마감 하지 않은 경우 주석을 사용하여 원래 쌍/기간 정보를 저장할 수 있습니다..?
동일한 기호와 기간에 두 개의 EA가 있는 경우 각각의 ID를 선택해야 하는 과거 주문을 어떻게 알 수 있습니까?
이 모든 것은 부분적으로 다시 시작할 때 사용할 수 있다고 가정하는 정보에 따라 다릅니다. 예를 들어, 이 포럼에는 차트 창의 숨겨진 개체 에 이러한 선을 따라 데이터를 저장하는 사람들이 있습니다. 나쁘지는 않지만 저는 개인적으로 사용자가 어떻게 또는 왜 깨뜨릴 수 있는지 알지 못하는 메커니즘에 대해 두려워합니다.
MT4나 사용자가 각 EA에 ID를 할당하지 않고는 이것이 어떻게 가능한지 알 수 없습니다. 또는 더 정확하게는 고유 ID를 생성한 다음 EA의 extern 매개변수의 일부로 ID를 저장하도록 EA의 .chr 파일을 수정하는 것과 같이 매우 불쾌한 일을 포함하지 않는 것을 볼 수 없습니다.
그리고 일반적인 오락을 위해 다음은 어떤 식으로든 토론을 실제로 진행시키지는 않지만 djb2 해시에 대한 입력을 고유하게 보장되는 값으로 대체합니다(DLL 호출을 요구하는 비용으로). 나는 djb2가 GUID와 같은 것에 대해 얼마나 좋은 의미인지 모르지만 충돌 없이 1,000,000개의 ID를 생성하려고 시도했습니다. 그러나 여전히 다시 시작 문제를 해결하지 못합니다.
MT4나 사용자가 각 EA에 ID를 할당하지 않고는 이것이 어떻게 가능한지 알 수 없습니다. 또는 더 정확하게는 고유 ID를 생성한 다음 EA의 extern 매개변수의 일부로 ID를 저장하도록 EA의 .chr 파일을 수정하는 것과 같이 매우 불쾌한 일을 포함하지 않는 것을 볼 수 없습니다.
>>EA p/u의 n번째 인스턴스는 어떻게 chartyy.chr 파일인가요?
.
인스턴스가 실제로 자체 .chr 파일을 매핑할 수 있다고 가정합니다.
EA 소스에 다음이 있는 경우 extern int myID = <someCompileTimeVal>;
그러면 <someCompileTimeVal>을 보는 모든 인스턴스는 '처음' -> gen it's id -> mod myID line -> myID의 고유성을 사용하여 복구 파일을 생성한다고 가정할 수 있습니다.
그런 다음 다시 시작 감지 액세스 시 .chr 파일이 p/u myID에 있으며 이는 파일 재맵핑을 허용하는 마스터 키가 됩니다...
그리고 일반적인 오락을 위해 다음은 어떤 식으로든 토론을 실제로 진행시키지는 않지만 djb2 해시에 대한 입력을 고유하게 보장되는 값으로 대체합니다(DLL 호출을 요구하는 비용으로). 나는 djb2가 GUID와 같은 것에 대해 얼마나 좋은 의미인지 모르지만 충돌 없이 1,000,000개의 ID를 생성하려고 시도했습니다.
나는 1mil을 빨아들이기 위해 PsPad ed를 사용했고, 제거 dups가 체크된 상태에서 정렬을 했습니다.
" 그리고 일반적인 오락을 위해 다음은 토론을 어떤 식으로든 실제로 진행시키지는 않지만 djb2 해시에 대한 입력을 고유하게 보장되는 값으로 대체합니다(DLL 호출을 요구하는 비용으로). djb2가 GUID와 같은 것에 대해 얼마나 좋은 의미인지 모르지만 충돌 없이 1,000,000개의 ID를 생성하려고 시도했습니다."
EA 소스에 다음이 있는 경우 extern int myID = <someCompileTimeVal>;
그러면 <someCompileTimeVal>을 보는 모든 인스턴스는 '처음' -> gen it's id -> mod myID line -> myID의 고유성을 사용하여 복구 파일을 생성한다고 가정할 수 있습니다.
그런 다음 다시 시작 감지 액세스 시 .chr 파일이 p/u myID에 있으며 이는 파일 재맵핑을 허용하는 마스터 키가 됩니다...
네가 옳아. 동일한 기호 및 기간에 대해 여러 개의 EA가 있는 경우 EA가 .chr 파일을 식별할 수 있는 확실한 방법이 없다는 것을 잊었습니다. GUID와 같은 것을 포함하는 숨겨진 레이블 개체 를 만든 다음 올바른 값이 포함된 .chr 파일을 찾을 수 있다고 생각했습니다. 그러나 새 개체가 차트에 추가될 때 .chr 파일이 업데이트되지 않는다고 확신합니다.
그리고 또 다른 문제가 있습니다. 나는 MT4가 메모리에 차트에 대한 정보를 보유하고 MT4가 닫힐 때(또는 EA의 속성이 변경될 때) .chr 파일에 기록한다고 확신합니다. 따라서 EA 자체가 만든 모든 변경 사항을 덮어씁니다. 실행되는 동안 .chr 파일로 이동합니다. 당신이 엄청나게 용감했다면 대신 속성 창을 불러오고, 필수 설정으로 이동하고, 변경하고, Enter 키를 누르는 등 키 누르기를 시뮬레이션하여 extern 속성을 설정해 볼 수 있습니다.
네가 옳아. 동일한 기호 및 기간에 대해 여러 개의 EA가 있는 경우 EA가 .chr 파일을 식별할 수 있는 확실한 방법이 없다는 것을 잊었습니다. GUID와 같은 것을 포함하는 숨겨진 레이블 개체를 만든 다음 올바른 값이 포함된 .chr 파일을 찾을 수 있다고 생각했습니다. 그러나 새 개체가 차트에 추가될 때 .chr 파일이 업데이트되지 않는다고 확신합니다.
그리고 또 다른 문제가 있습니다. 나는 MT4가 메모리에 차트에 대한 정보를 보유하고 MT4가 닫힐 때(또는 EA의 속성이 변경될 때) .chr 파일에 기록한다고 확신합니다. 따라서 EA 자체가 만든 모든 변경 사항을 덮어씁니다. 실행되는 동안 .chr 파일로 이동합니다. 당신이 엄청나게 용감했다면 대신 속성 창을 불러오고, 필수 설정으로 이동하고, 변경하고, Enter 키를 누르는 등 키 누르기를 시뮬레이션하여 extern 속성을 설정해 볼 수 있습니다.
나는 위에서 읽었다 -> 운동을 하러 갔다 -> 그리고 샤워하는 동안 회색 세포가 OBJECT를 외쳤다. .chr 경로를 종료했지만 "label object"라는 두 단어가 그 두뇌 폭발을 일으켰습니다. :)
그럼 어때요? 100% 보장된 ID를 얻는 것을 잠시 잊었습니다. 다른 부분은 EA ID를 포함하는 이 복구 가능한 상태 메모리 입니다.
잘...
1. void vArchiveID(int iID), int iRestoreID() [및 int iGetNewID()가 괜찮으면 다른 게시물로 이동합니다.]
2. vArchiveID()는 [hidden?] 레이블을 생성합니까? 개체 를 EA상태 메모리 차트 에 표시합니다.
obj 이름은 호출하는 모든 EA에 대해 동일해야 합니다. 따라서 (1)의 경우 .ex4 lib 또는 .mqh lib
3. CT가 무너지거나 EA가 배꼽이 빠지는 등
4. 다시 시작할 때 EA 첫 번째 작업은 차트에 개체가 없거나 이전 실행에서 보관된 ID가 없으면 -1을 반환하는 iRestoreID()를 호출하는 것입니다.
5. ID가 없으면 iGetNewID()를 호출한 다음 vArchiveID()를 호출하고 아마도 [처음으로] 덤프 파일 항목을 설정합니다.
6. ID가 '복원'되면 덤프 파일을 통해 마지막 상태를 복구하는 작업을 즐겁게 진행합니다...
당신이 제안하는 것은 - 제 생각에는 - 타임스탬프가 찍힌 14:43 게시물에서 정확히 제가 언급한 것입니다. 이 경로의 유일한 위험이자 extern 속성 을 설정하기 위해 .chr 파일을 직접 사용하는 유일한 이유는 사용자가 차트에서 실수로 개체를 삭제할 가능성을 제거하기 위한 것입니다. 그러나 필요하다면 deinit()에서 객체가 다시 생성되도록 함으로써 그마저도 크게 극복할 수 있습니다.
그러나 BB/CB는 .chr 파일에 대한 의존을 허용할 수 없는 것으로 간주할 수 있습니다. 그들은 오프사이트에 보관된 데이터(예: 브로커가 보유한 거래 목록)에서 순수하게 복구할 수 있는 것을 원할 수 있습니다.
자동화된 매직 넘버로 복구 가능성을 허용하기 위해 어느 정도 복잡성을 추가하는 것 같습니다. 예? 즉. 그래서 다시 태어난 코드의 멍청한 조각은 그가 무엇인지, 그가 어디에 있는지만 알 때 그가 전생에 누구였는지 알아낼 수 있습니다. 반드시 나쁜 것은 아닙니다. 하지만..
(매우 간결하게) 문서화하는 것이 유용할 것이라고 생각했습니다.
- 매직넘버 구현 결정 기준
- 자동 매직넘버 생성 사용 여부 판단 기준
- 퍼시스턴스 레이어 구현 결정 기준
- 지속성을 위한 전역 대 파일 액세스를 결정하는 기준
내가 이것을 제안하는 이유는 모든 사람들이 EA에 부엌 싱크대를 구현해야 한다고 생각하는 것을 피하기 위함입니다.
네, 결국, 부엌 싱크대는 이 사이트 에 있을 가능성이 가장 높습니다. 모두 학문적입니다. 저에게 최우선 관심사는 전문가 ID를 자동으로 확보하는 것입니다. 다양한 용도로 사용할 수 있는 값입니다.
다시 시작할 때 덤프 파일에 액세스하는 고유한 방법을 갖는 것은 기껏해야 우연이며 어떤 경우에도 사용자가 EA 사용 규칙을 준수해야 합니다. 많은 ccy+period+EA 인스턴스는 옵션이 아닙니다.
나는 다시 시작하기 전에 내가 누구 인지 확인할 수 있는 모든 인스턴스에 의도했으며 이는 작동 불가능한 것으로 표시됩니다. 내 입장에서는 어떤 사용자도 가장 기본적인 규칙 집합을 따르는 것을 믿지 않을 것입니다. 자동 방법을 완전히 확신할 수 없다면 사용자 개입이 필요한 중간 집을 채택하지 않을 것입니다.
.
jjc의 CoCreateGuid() i/f를 사용하여 충분히 반복되지 않는 숫자를 생성할 것입니다. 충분하다는 것은 주관적이지만 저는 많은 것을 하려고 합니다... 파일 보유 번호에 대한 리소스 액세스 서버 기능 으로 하나의 라이브러리 코드 덩어리와 결합됩니다. 숫자의 양은 숫자를 다시 사용하지 않고 최소 2년이 지나갈 수 있을 정도입니다. EOF에 도달하면 BOF로 랩핑되고 계속해서 숫자를 제공합니다. My finger in the sky 계산은 매주 5일 및 연간 50주를 실행하는 10명의 요청자를 기반으로 하며, 매일 한 명의 요청자가 20개의 새 ID를 요구할 수 있습니다. 이 결과는 두 배가 됩니다. 터무니없는 숫자 - 기본적으로 200,000. 예, 석기 시대 기능이지만 내 코드를 실행할 수 있는 능력 이상으로 터미널에 의존할 필요 없이 방수가 됩니다. 물론 1개, 10개 또는 100개 파일의 파급효과와 물리적 위치 및 액세스 메커니즘에 대해 오랫동안 계속할 수 있습니다. 결국 내 불쌍한 메이크 엑스퍼트 id 기능보다 훨씬 낫고 2 년 이상 [실제로] 번호 고유성에 대해 철저하게 생각합니다.
주문을 부분적으로 마감 하지 않은 경우 주석을 사용하여 원래 쌍/기간 정보를 저장할 수 있습니다..?
동일한 기호와 기간에 두 개의 EA가 있는 경우 각각의 ID를 선택해야 하는 과거 주문을 어떻게 알 수 있습니까?
이 모든 것은 부분적으로 다시 시작할 때 사용할 수 있다고 가정하는 정보에 따라 다릅니다. 예를 들어, 이 포럼에는 차트 창의 숨겨진 개체 에 이러한 선을 따라 데이터를 저장하는 사람들이 있습니다. 나쁘지는 않지만 저는 개인적으로 사용자가 어떻게 또는 왜 깨뜨릴 수 있는지 알지 못하는 메커니즘에 대해 두려워합니다.
동일한 기호와 기간에 두 개의 EA가 있는 경우 각각의 ID를 선택해야 하는 주문을 어떻게 알 수 있습니까?
젠장 - 그것이 프로젝트의 범위에 있었습니까? :D
EA(유형 또는 버전이 다른 경우)에도 주석에 식별자가 있다고 가정했습니다. :)
-BB-
MT4나 사용자가 각 EA에 ID를 할당하지 않고는 이것이 어떻게 가능한지 알 수 없습니다. 또는 더 정확하게는 고유 ID를 생성한 다음 EA의 extern 매개변수의 일부로 ID를 저장하도록 EA의 .chr 파일을 수정하는 것과 같이 매우 불쾌한 일을 포함하지 않는 것을 볼 수 없습니다.
그리고 일반적인 오락을 위해 다음은 어떤 식으로든 토론을 실제로 진행시키지는 않지만 djb2 해시에 대한 입력을 고유하게 보장되는 값으로 대체합니다(DLL 호출을 요구하는 비용으로). 나는 djb2가 GUID와 같은 것에 대해 얼마나 좋은 의미인지 모르지만 충돌 없이 1,000,000개의 ID를 생성하려고 시도했습니다. 그러나 여전히 다시 시작 문제를 해결하지 못합니다.
MT4나 사용자가 각 EA에 ID를 할당하지 않고는 이것이 어떻게 가능한지 알 수 없습니다. 또는 더 정확하게는 고유 ID를 생성한 다음 EA의 extern 매개변수의 일부로 ID를 저장하도록 EA의 .chr 파일을 수정하는 것과 같이 매우 불쾌한 일을 포함하지 않는 것을 볼 수 없습니다.
>>EA p/u의 n번째 인스턴스는 어떻게 chartyy.chr 파일인가요?
.
인스턴스가 실제로 자체 .chr 파일을 매핑할 수 있다고 가정합니다.
EA 소스에 다음이 있는 경우 extern int myID = <someCompileTimeVal>;
그러면 <someCompileTimeVal>을 보는 모든 인스턴스는 '처음' -> gen it's id -> mod myID line -> myID의 고유성을 사용하여 복구 파일을 생성한다고 가정할 수 있습니다.
그런 다음 다시 시작 감지 액세스 시 .chr 파일이 p/u myID에 있으며 이는 파일 재맵핑을 허용하는 마스터 키가 됩니다...
.
예:
차트02.chr
<차트>
기호=EURUSD
기간=15
..
..
<전문가>
이름=LMT 1.8
플래그=343
window_num=0
<입력>
myID=<someCompileTimeVal>
...
</입력>
</전문가>
EOF
돕다 !!
.
그리고 일반적인 오락을 위해 다음은 어떤 식으로든 토론을 실제로 진행시키지는 않지만 djb2 해시에 대한 입력을 고유하게 보장되는 값으로 대체합니다(DLL 호출을 요구하는 비용으로). 나는 djb2가 GUID와 같은 것에 대해 얼마나 좋은 의미인지 모르지만 충돌 없이 1,000,000개의 ID를 생성하려고 시도했습니다.
나는 1mil을 빨아들이기 위해 PsPad ed를 사용했고, 제거 dups가 체크된 상태에서 정렬을 했습니다.
>>하지만... 어떻게 ".. 충돌 없이." 발각?
" 그리고 일반적인 오락을 위해 다음은 토론을 어떤 식으로든 실제로 진행시키지는 않지만 djb2 해시에 대한 입력을 고유하게 보장되는 값으로 대체합니다(DLL 호출을 요구하는 비용으로). djb2가 GUID와 같은 것에 대해 얼마나 좋은 의미인지 모르지만 충돌 없이 1,000,000개의 ID를 생성하려고 시도했습니다."
.
참고로, 1mil의 코드 호출에서 충돌을 발견했습니다.
정렬된 EOF
.
정렬된 + 중복 제거 EOF
>>EA p/u의 n번째 인스턴스는 어떻게 chartyy.chr 파일인가요?
.
인스턴스가 실제로 자체 .chr 파일을 매핑할 수 있다고 가정합니다.
EA 소스에 다음이 있는 경우 extern int myID = <someCompileTimeVal>;
그러면 <someCompileTimeVal>을 보는 모든 인스턴스는 '처음' -> gen it's id -> mod myID line -> myID의 고유성을 사용하여 복구 파일을 생성한다고 가정할 수 있습니다.
그런 다음 다시 시작 감지 액세스 시 .chr 파일이 p/u myID에 있으며 이는 파일 재맵핑을 허용하는 마스터 키가 됩니다...
네가 옳아. 동일한 기호 및 기간에 대해 여러 개의 EA가 있는 경우 EA가 .chr 파일을 식별할 수 있는 확실한 방법이 없다는 것을 잊었습니다. GUID와 같은 것을 포함하는 숨겨진 레이블 개체 를 만든 다음 올바른 값이 포함된 .chr 파일을 찾을 수 있다고 생각했습니다. 그러나 새 개체가 차트에 추가될 때 .chr 파일이 업데이트되지 않는다고 확신합니다.
그리고 또 다른 문제가 있습니다. 나는 MT4가 메모리에 차트에 대한 정보를 보유하고 MT4가 닫힐 때(또는 EA의 속성이 변경될 때) .chr 파일에 기록한다고 확신합니다. 따라서 EA 자체가 만든 모든 변경 사항을 덮어씁니다. 실행되는 동안 .chr 파일로 이동합니다. 당신이 엄청나게 용감했다면 대신 속성 창을 불러오고, 필수 설정으로 이동하고, 변경하고, Enter 키를 누르는 등 키 누르기를 시뮬레이션하여 extern 속성을 설정해 볼 수 있습니다.
참고로, 1mil의 코드 호출에서 충돌을 발견했습니다.
정렬된 EOF
다시 실행했을 때 저도 마찬가지였습니다. 1,000,000번의 시도에서 172번의 충돌이 발생했습니다.
네가 옳아. 동일한 기호 및 기간에 대해 여러 개의 EA가 있는 경우 EA가 .chr 파일을 식별할 수 있는 확실한 방법이 없다는 것을 잊었습니다. GUID와 같은 것을 포함하는 숨겨진 레이블 개체를 만든 다음 올바른 값이 포함된 .chr 파일을 찾을 수 있다고 생각했습니다. 그러나 새 개체가 차트에 추가될 때 .chr 파일이 업데이트되지 않는다고 확신합니다.
그리고 또 다른 문제가 있습니다. 나는 MT4가 메모리에 차트에 대한 정보를 보유하고 MT4가 닫힐 때(또는 EA의 속성이 변경될 때) .chr 파일에 기록한다고 확신합니다. 따라서 EA 자체가 만든 모든 변경 사항을 덮어씁니다. 실행되는 동안 .chr 파일로 이동합니다. 당신이 엄청나게 용감했다면 대신 속성 창을 불러오고, 필수 설정으로 이동하고, 변경하고, Enter 키를 누르는 등 키 누르기를 시뮬레이션하여 extern 속성을 설정해 볼 수 있습니다.
나는 위에서 읽었다 -> 운동을 하러 갔다 -> 그리고 샤워하는 동안 회색 세포가 OBJECT를 외쳤다. .chr 경로를 종료했지만 "label object"라는 두 단어가 그 두뇌 폭발을 일으켰습니다. :)
그럼 어때요? 100% 보장된 ID를 얻는 것을 잠시 잊었습니다. 다른 부분은 EA ID를 포함하는 이 복구 가능한 상태 메모리 입니다.
잘...
1. void vArchiveID(int iID), int iRestoreID() [및 int iGetNewID()가 괜찮으면 다른 게시물로 이동합니다.]
2. vArchiveID()는 [hidden?] 레이블을 생성합니까? 개체 를 EA 상태 메모리 차트 에 표시합니다.
obj 이름은 호출하는 모든 EA에 대해 동일해야 합니다. 따라서 (1)의 경우 .ex4 lib 또는 .mqh lib
3. CT가 무너지거나 EA가 배꼽이 빠지는 등
4. 다시 시작할 때 EA 첫 번째 작업은 차트에 개체가 없거나 이전 실행에서 보관된 ID가 없으면 -1을 반환하는 iRestoreID()를 호출하는 것입니다.
5. ID가 없으면 iGetNewID()를 호출한 다음 vArchiveID()를 호출하고 아마도 [처음으로] 덤프 파일 항목을 설정합니다.
6. ID가 '복원'되면 덤프 파일을 통해 마지막 상태를 복구하는 작업을 즐겁게 진행합니다...
..
어떻게 생각해?
[...]
어떻게 생각해?
당신이 제안하는 것은 - 제 생각에는 - 타임스탬프가 찍힌 14:43 게시물에서 정확히 제가 언급한 것입니다. 이 경로의 유일한 위험이자 extern 속성 을 설정하기 위해 .chr 파일을 직접 사용하는 유일한 이유는 사용자가 차트에서 실수로 개체를 삭제할 가능성을 제거하기 위한 것입니다. 그러나 필요하다면 deinit()에서 객체가 다시 생성되도록 함으로써 그마저도 크게 극복할 수 있습니다.
그러나 BB/CB는 .chr 파일에 대한 의존을 허용할 수 없는 것으로 간주할 수 있습니다. 그들은 오프사이트에 보관된 데이터(예: 브로커가 보유한 거래 목록)에서 순수하게 복구할 수 있는 것을 원할 수 있습니다.
나는 잠시 동안 이 스레드에서 떨어져 있었습니다.
자동화된 매직 넘버로 복구 가능성을 허용하기 위해 어느 정도 복잡성을 추가하는 것 같습니다. 예? 즉. 그래서 다시 태어난 코드의 멍청한 조각은 그가 무엇인지, 그가 어디에 있는지만 알 때 그가 전생에 누구였는지 알아낼 수 있습니다. 반드시 나쁜 것은 아닙니다. 하지만..
(매우 간결하게) 문서화하는 것이 유용할 것이라고 생각했습니다.
- 매직넘버 구현 결정 기준
- 자동 매직넘버 생성 사용 여부 판단 기준
- 퍼시스턴스 레이어 구현 결정 기준
- 지속성을 위한 전역 대 파일 액세스를 결정하는 기준
내가 이것을 제안하는 이유는 모든 사람들이 EA에 부엌 싱크대를 구현해야 한다고 생각하는 것을 피하기 위함입니다.
견해 ?
CB
-잠시 휴식을 취하기 전에 8 개의 게시물 만 남았습니다.
네, 결국, 부엌 싱크대는 이 사이트 에 있을 가능성이 가장 높습니다. 모두 학문적입니다. 저에게 최우선 관심사는 전문가 ID를 자동으로 확보하는 것입니다. 다양한 용도로 사용할 수 있는 값입니다.
다시 시작할 때 덤프 파일에 액세스하는 고유한 방법을 갖는 것은 기껏해야 우연이며 어떤 경우에도 사용자가 EA 사용 규칙을 준수해야 합니다. 많은 ccy+period+EA 인스턴스는 옵션이 아닙니다.
나는 다시 시작하기 전에 내가 누구 인지 확인할 수 있는 모든 인스턴스에 의도했으며 이는 작동 불가능한 것으로 표시됩니다. 내 입장에서는 어떤 사용자도 가장 기본적인 규칙 집합을 따르는 것을 믿지 않을 것입니다. 자동 방법을 완전히 확신할 수 없다면 사용자 개입이 필요한 중간 집을 채택하지 않을 것입니다.
.
jjc의 CoCreateGuid() i/f를 사용하여 충분히 반복되지 않는 숫자를 생성할 것입니다. 충분하다는 것은 주관적이지만 저는 많은 것을 하려고 합니다... 파일 보유 번호에 대한 리소스 액세스 서버 기능 으로 하나의 라이브러리 코드 덩어리와 결합됩니다. 숫자의 양은 숫자를 다시 사용하지 않고 최소 2년이 지나갈 수 있을 정도입니다. EOF에 도달하면 BOF로 랩핑되고 계속해서 숫자를 제공합니다. My finger in the sky 계산은 매주 5일 및 연간 50주를 실행하는 10명의 요청자를 기반으로 하며, 매일 한 명의 요청자가 20개의 새 ID를 요구할 수 있습니다. 이 결과는 두 배가 됩니다. 터무니없는 숫자 - 기본적으로 200,000. 예, 석기 시대 기능이지만 내 코드를 실행할 수 있는 능력 이상으로 터미널에 의존할 필요 없이 방수가 됩니다. 물론 1개, 10개 또는 100개 파일의 파급효과와 물리적 위치 및 액세스 메커니즘에 대해 오랫동안 계속할 수 있습니다. 결국 내 불쌍한 메이크 엑스퍼트 id 기능보다 훨씬 낫고 2 년 이상 [실제로] 번호 고유성에 대해 철저하게 생각합니다.
.
CB, 666은 헬기 조종사의 행운의 숫자여야 합니까? :\