Книгата П. Naughton, Г. Shildt "Java 2. Най-пълен ръководство" казва следното за размера на типове данни:
На други места в тази книга е писано:
Може да изглежда, че с помощта на кратък или байт спестява памет, но няма гаранция, че Java няма да бъде вътрешно, така или иначе да разшири тези видове да Int. Не забравяйте, че типът определя поведението, а не на размера. (Единственото изключение - масиви, където тип байт гарантира, че само един байт на елемент от масива, а краткосрочен ще отнеме два байта, и INT - четири байта).
Във връзка с горното имам един въпрос: какво се разбира под поведението на променливите от тип цяло число, и независимо от това дали за променливи, които не са декларирани като масиви, размерът не е уточнено?
Разположен на 3 януари '13 в 16:58
Мисля, че в този случай ние влизаме вечния конфликт: искаме да се мисли за видовете поведение, като (на ниво логика), но се силно ограничени ресурси трябва да се замислим и за размера на заделената памет. В резултат на това, родени компромиси и компромиси, за да мислят за тях.
Например, по време на С, стандарт е съществувал само отношения кратко вътр <= int <= long int, все остальное являлось спецификой конкретной платформы. Это весьма шаткое положение вещей, которое было учтено в дизайне Java.
Standard Java Language Specification ясно определени крайни стойности за видове, т.е. минималната дълбочина малко на физическо ниво. Така например, дълго трябва да работи с 64-битови стойности, дори ако основната хардуерна платформа не може да направи това.
Всеки може да напише своето "изпълнение" на езика JVM или Java, но ако резултатът не отговаря на спецификацията се нарича "Java" вече не е възможно, в същността на спецификации технологии. Обърнете внимание на проблемите, свързани с такива "реализация" може да бъде, но е важно да се дистанцира от тях, тъй като вече не е проблем, платформата Java, и проблемите на някои решения на трети страни.
Мога ли да го използвам по някакъв начин да се определи реалната желязо на изпълнението? Например, на 32-битова машина дълго, относително казано, е физически представена от два intami, че работи с дълъг код ще бъде по-бавно. От друга страна, при прехода към програмата за 64-битова система се започва бавно (до 20% за SPARC, 0-15% за AMD64 и EM64T) най-малко поради увеличен от 4 до 8 байта размер показалка. С други думи, това е сложно.
В простия случай на дясно да се има предвид, че размерът на примитивен тип - това поведение (гаранционни и стойност групи, които няма да се разпадне между платформите логика на работа с тях). Но имайте предвид, че в крайна сметка тя е хваната в стандартна техника компромис, който в особено тежки случаи, ще трябва да се направи нещо.
Отговорено 02 февруари '16 в 15:38
Що се отнася до втория въпрос, трябва да знаете, че има няколко реализации на виртуалната машина (тя е съкращение JVM) от различни компании. Така че в различен JVM, когато стартирате кода:
променлива и може да бъде или 4 или 8 байта. И това зависи от изпълнението на JVM.
Моят IMHO и опит предлагам - толкова дълго, колкото да не се пишат програми, които работят с милиони записи, не се притеснява много по този въпрос. По-добре е да се учи програмиране в Java като цяло. Когато наближите линията, където програмата ще бъде голяма, но вече ще знам какво да правя и как да профилира код.
Отговорено 4 Януари '13 в 07:14
Свързани статии