간단히 말해서, 한 문자의 문자열은 0에서 255까지의 특정 코드를 가진 문자 이고 무게는 1바이트입니다... 그리고 너무 많은 메모리가 할당되어 256개의 값만 있고 257은 적합하지 않습니다. 거기에서 처음으로 다시 이동합니다.
예, 모든 문자열에서 각 문자는 0에서 255 사이의 숫자와 같습니다 ... 숫자 int 10000000을 얻습니다. 무게는 4바이트이고 "10000000" 문자열로 변환한 다음 각 문자에 대한 메모리를 단일 차트로 할당합니다. 0에서 255까지. .. 총 8바이트 메모리를 절약할 수 있는 곳이 없습니다.
동시에 많은 리소스 낭비도 내부 링크로 이동합니다. 문자열의 각 문자에 액세스하는 것은 char[x] 배열에 액세스하는 것과 같습니다. 이 경우 참조는 특정 배열 요소 에 대한 액세스입니다. 그리고 당신은 그것들을 엄청난 힙으로 분류할 것입니다. int를 사용한 구현은 몇 배 더 쉽고, 더 명확하고, 더 빠를 것입니다 ...
문자열 길이 제한은 일반적으로 char[x] 배열의 최대 크기 제한에 따라 다릅니다. 다른 것과 마찬가지로 자체 최대 제한이 있습니다.
동시에 많은 리소스 낭비도 내부 링크로 이동합니다. 문자열의 각 문자에 액세스하는 것은 char[x] 배열에 액세스하는 것과 같습니다. 이 경우 참조는 특정 배열 요소 에 대한 액세스입니다. 그리고 당신은 그것들을 엄청난 힙으로 분류할 것입니다. int를 사용한 구현은 몇 배 더 쉽고, 더 명확하고, 더 빠를 것입니다 ...
문자열 길이 제한은 일반적으로 char[x] 배열의 최대 크기 제한에 따라 다릅니다. 다른 것과 마찬가지로 자체 최대 제한이 있습니다.
미래의 트랜잭션 수를 미리 알지 못하기 때문에 int로 구현할 수 없습니다. 각 거래에서 배열의 크기를 추측하거나 변경하고 데이터를 앞뒤로 다시 작성해야 합니다.
미래의 트랜잭션 수를 미리 알지 못하기 때문에 int로 구현할 수 없습니다. 각 거래에서 배열의 크기를 추측하거나 변경하고 데이터를 앞뒤로 다시 작성해야 합니다.
또 어떻게 할까요?
내 솔루션의 속도는 미쳤습니다.
메모리가 소모되지만 얼마나 비효율적인지는 알 수 없습니다. 정확히 알아보셔야 합니다.
문자열에는 두 가지 옵션만 있습니다. 처음에는 최대 크기(예비 상태)이거나 메모리도 할당되고 귀하의 경우 추가 프로세스 중에 매번 할당됩니다.... 즉, 동일합니다. int 에 대한 배열의 크기를 변경하는 것과 같습니다. 1v1 글쎄, 더 많은 문자를 비교할 때 string이 1 문자에 대한 메모리를 할당하는 것보다 int가 10% 더 긴 메모리를 할당하는 것이 가능합니다 - int의 승리를 추측합니다
간단히 말해서, 한 문자의 문자열은 0에서 255까지의 특정 코드를 가진 문자 이고 무게는 1바이트입니다... 그리고 너무 많은 메모리가 할당되어 256개의 값만 있고 257은 적합하지 않습니다. 거기에서 처음으로 다시 이동합니다.
예, 모든 문자열에서 각 문자는 0에서 255 사이의 숫자와 같습니다 ... 숫자 int 10000000을 얻습니다. 무게는 4바이트이고 "10000000" 문자열로 변환한 다음 각 문자에 대한 메모리를 단일 차트로 할당합니다. 0에서 255까지. .. 총 8바이트 메모리를 절약할 수 있는 곳이 없습니다.
나는 당신을 이해했다.
이 솔루션에서 소비되는 메모리의 양을 정확하게 계산할 필요가 있습니다.
두 번째 줄 쓰기를 시작할 수 있습니다. 그런 다음 세 번째 등등... :)
추신 아, 네, 또 다른 실수가 있습니다. 세 번째 호출에서 MathRand가 예를 들어 숫자 1000을 반환하고 _3_1000_을 기록한다면 일련 번호가 1000인 트랜잭션에서 어떤 마법이 발견될까요?사실 MathRand는 마술사 수를 시뮬레이션하는 데만 필요합니다.
매직 넘버는 사용자가 설정하며 100,000(가령) 미만의 값을 우회할 수 있습니다.
단, 위의 예에는 오류가 있을 수 있습니다. 네가 옳아.
관찰해 주셔서 감사합니다. 완전한 솔루션은 이것을 고려해야 합니다.
나는 당신을 이해했다.
이 솔루션에서 소비되는 메모리의 양을 정확하게 계산할 필요가 있습니다.
동시에 많은 리소스 낭비도 내부 링크로 이동합니다. 문자열의 각 문자에 액세스하는 것은 char[x] 배열에 액세스하는 것과 같습니다. 이 경우 참조는 특정 배열 요소 에 대한 액세스입니다. 그리고 당신은 그것들을 엄청난 힙으로 분류할 것입니다. int를 사용한 구현은 몇 배 더 쉽고, 더 명확하고, 더 빠를 것입니다 ...
문자열 길이 제한은 일반적으로 char[x] 배열의 최대 크기 제한에 따라 다릅니다. 다른 것과 마찬가지로 자체 최대 제한이 있습니다.
사람은 진심으로 자신의 어리석음의 크기를 이해하지 못합니다.
더닝-크루거 효과가 작용하고 있다.
예, 모든 것이 괜찮습니다. 사람이 유형화되지 않은 언어가 필요하고 문제가 없습니다))
비록 속도의 차이는 여전히추신 아, 네, 또 다른 실수가 있습니다. 세 번째 호출에서 MathRand가 예를 들어 숫자 1000을 반환하고 _3_1000_을 기록한다면 일련 번호가 1000인 트랜잭션에서 어떤 마법이 발견될까요?
동시에 많은 리소스 낭비도 내부 링크로 이동합니다. 문자열의 각 문자에 액세스하는 것은 char[x] 배열에 액세스하는 것과 같습니다. 이 경우 참조는 특정 배열 요소 에 대한 액세스입니다. 그리고 당신은 그것들을 엄청난 힙으로 분류할 것입니다. int를 사용한 구현은 몇 배 더 쉽고, 더 명확하고, 더 빠를 것입니다 ...
문자열 길이 제한은 일반적으로 char[x] 배열의 최대 크기 제한에 따라 다릅니다. 다른 것과 마찬가지로 자체 최대 제한이 있습니다.
미래의 트랜잭션 수를 미리 알지 못하기 때문에 int로 구현할 수 없습니다. 각 거래에서 배열의 크기를 추측하거나 변경하고 데이터를 앞뒤로 다시 작성해야 합니다.
또 어떻게 할까요?
내 솔루션의 속도는 미쳤습니다.
메모리가 소모되지만 얼마나 비효율적인지는 알 수 없습니다. 정확히 알아보셔야 합니다.
그는 조금 더 "생각"하고 이 문제를 해결할 것입니다. 그는 거래 앞에 밑줄을 표시하고 마술 앞에 또 다른 기호를 표시합니다. :)
여기 있는 다른 모든 사람들과 달리 Peter는 가장 인내심이 강하고 단조로운 코드에 대한 준비가 되어 있다는 점에 주목하고 싶습니다. 그렇지 않으면 그가 어떻게 그렇게 많은 글을 쓸 수 있었는지 설명할 수 없습니다.
미래의 트랜잭션 수를 미리 알지 못하기 때문에 int로 구현할 수 없습니다. 각 거래에서 배열의 크기를 추측하거나 변경하고 데이터를 앞뒤로 다시 작성해야 합니다.
또 어떻게 할까요?
내 솔루션의 속도는 미쳤습니다.
메모리가 소모되지만 얼마나 비효율적인지는 알 수 없습니다. 정확히 알아보셔야 합니다.
문자열에는 두 가지 옵션만 있습니다. 처음에는 최대 크기(예비 상태)이거나 메모리도 할당되고 귀하의 경우 추가 프로세스 중에 매번 할당됩니다.... 즉, 동일합니다. int 에 대한 배열의 크기를 변경하는 것과 같습니다. 1v1 글쎄, 더 많은 문자를 비교할 때 string이 1 문자에 대한 메모리를 할당하는 것보다 int가 10% 더 긴 메모리를 할당하는 것이 가능합니다 - int의 승리를 추측합니다