Отказ от кастинга

@mselez · Регистрация: 22.07.2009

Студворк — интернет-сервис помощи студентам

Меня всегда раздражала необходимость кастинга при извлечении обьекта из библиотечной коллекции. Обычно в коллекции хранят обьекты одного известного типа, но при извлечении приходится всякий раз этот кастинг делать. Модные нынче дженерики не в счет. Там внутри тот же кастинг делается. Придумано исключительно для удобства программирования, но не для повышения эффективности программы.
Кастинг - отнюдь не самая тяжелая операция, но все же операция (по моим примитивным тестам время извлечения обьектов из коллекции возрастает примерно на 5% ). Возникает ли желание взять, скажем, ArrayList и на его основе сделать к примеру StringArrayList, заточенный под хранение стрингов? Чтобы исключить кастинг. Или это паранойя и маразм?

@boombastik · 22.11.2006, 20:05

во-первых, про 5% на приведение типов при работе с коллекцией - это ты загнул, по-моему

во-вторых, generics применительно к collections должны работать как типизированные коллекции, нечто похожее на С++ templates, по крайней мере на уровене классов входящих в JDK, правда я не смотрел как это реализовано, но если правильно, то приведение типов в этом случае не требуется

а так, в общем, если для задачи достаточно набора возможностей предоставляемых массивом, то всегда стоит отдавать предпочтение массиву по сравнению с любого рода коллекцией, потому как: меньше памяти, быстрее создание самого массива, быстрее установка значений в массиве, быстрее извлечение значений из массива, нежели из любой коллекции

С уважением,

Владимир

@mselez · 22.11.2006, 20:25 **[ТС]**

во-первых, про 5% на приведение типов при работе с коллекцией - это ты загнул, по-моему

Я побаловался простеньким тестом и на истину особо не претендую. А что, на самом деле должно быть больше или меньше? В какую сторону загнул?

во-вторых, generics применительно к collections должны работать как типизированные коллекции, нечто похожее на С++ templates, по крайней мере на уровене классов входящих в JDK, правда я не смотрел как это реализовано, но если правильно, то приведение типов в этом случае не требуется

Я тоже сам не смотрел, но читал на другом форуме мнение тех, кто смотрел (по их словам).

а так, в общем, если для задачи достаточно набора возможностей предоставляемых массивом, то всегда стоит отдавать предпочтение массиву по сравнению с любого рода коллекцией, потому как: меньше памяти, быстрее создание самого массива, быстрее установка значений в массиве, быстрее извлечение значений из массива, нежели из любой коллекции

Я всеми четырьмя конечностями за массив, но часто нужна автоматическая расширяемость. Собственно, ArrayList и есть массив, в который добавлено несколько полезных методов. И без Hash.. коллекций тоже не обойтись.</SPAN>

@boombastik · 23.11.2006, 01:21

по-моему должно быть меньше 5%

ты как тест проводил? извлекал String объекты из коллекции с приведением к String и сравнивал результаты с извлечением String объектов из коллекции в той же последовательности, но оставляя их как Object? какую коллекцию использовал?

С уважением,

Владимир

@mselez · 23.11.2006, 02:44 **[ТС]**

да, именно так. Коллекция - ArrayList.

24.11.2006, 22:02

ну в принципе можно попробовать Class.forName(String name,boolean initialize,ClassLoader loader)

Но скорей всего это вряд ли поможет отцу русской демократии

)

@mselez · 25.11.2006, 00:03 **[ТС]**

признаться, я ничего не понял

25.11.2006, 00:24

Чё то я фигню спорол

похоже

25.11.2006, 00:30

по моему то что вы пытаетесь сделать практически невозможно. Можно написать свой ArrayList - да но тогда для каждого объекта писать свой ArrayList? Овчинка выделки не стоит по моему. Не такие уж большие затраты на кастинг чтоб заниматься этим

@mselez · 25.11.2006, 00:54 **[ТС]**

Можно написать свой ArrayList - да но тогда для каждого объекта писать свой ArrayList?

Почему бы и нет, если в узком месте, под конкретный обьект. Очень часто этим обьектом может быть String.

Овчинка выделки не стоит по моему. Не такие уж большие затраты на кастинг чтоб заниматься этим

Наверное.

25.11.2006, 02:07

mselez (24.11.2006)

Можно написать свой ArrayList - да но тогда для каждого объекта писать свой ArrayList?

Почему бы и нет, если в узком месте, под конкретный обьект. Очень часто этим обьектом может быть String.

Овчинка выделки не стоит по моему. Не такие уж большие затраты на кастинг чтоб заниматься этим

Наверное.

Ну наверное у вас как то по другому всё. У нас в основном в коллекции помещаются бины у которых пропнетями может быть что угодно и писать под каждый такой бин - а их сотни свою коллекция - на фиг нада

)))

@boombastik · 25.11.2006, 05:25

mishgun (24.11.2006)
по моему то что вы пытаетесь сделать практически невозможно. Можно написать свой ArrayList - да но тогда для каждого объекта писать свой ArrayList?

это как раз то, для чего предназначены Templates в C++ - пишешь один раз (оптимально), применяешь к любому типу (классу), какой захочешь

мне казалось, что Java реализовала в 5-ой версии нечто подобное при помощи Generics, но вот говорят, что это не совсем так, а жаль

27.11.2006, 18:51

boombastik (25.11.2006)

это как раз то, для чего предназначены Templates в C++ - пишешь один раз (оптимально), применяешь к любому типу (классу), какой захочешь

мне казалось, что Java реализовала в 5-ой версии нечто подобное при помощи Generics, но вот говорят, что это не совсем так, а жаль

Жаль что в Java не как шаблоны в С++? Я не видел ни одного человека, кто на шаблоны не плевался бы.

Если не трудно, спроси там, где говорят - чем они всеже отличаются? А то как в детском саду - мама сказала в носу ковырять нехорошо.

@boombastik · 27.11.2006, 18:54

здесь же выше и сказали

кстати, никогда не плевался на C++ шаблоны

С уважением,

Владимир

27.11.2006, 18:57

mselez (22.11.2006)Или это паранойя и маразм?

Если кастинг стал узким местом приложения - можно и его оптимизировать.

@boombastik · 27.11.2006, 19:05

http://www.artima.com/intv/generics2.html

For example, with Java generics, you don't actually get any of the execution efficiency that I talked about, because when you compile a generic class in Java, the compiler takes away the type parameter and substitutes Object everywhere. So the compiled image for List<T> is like a List where you use the type Object everywhere. Of course, if you now try to make a List<int>, you get boxing of all the ints. So there's a bunch of overhead there. Furthermore, to keep the VM happy, the compiler actually has to insert all of the type casts you didn't write. If it's a List of Object and you're trying to treat those Objects as Customers, at some point the Objects must be cast to Customers to keep the verifier happy.

27.11.2006, 20:22

В Java для обратной совместимости выбран метод "стирания типов" для инстанцирования шаблонов. В С++ шаблон инстанцируется через генерацию класса на основе шаблона.

Выбирая из двух зол, бери оба - потом и этого не будет. (с)

По поводу приведения типов можно сказать следущее: протестируйте instanceof и вызов интерфейсного метода.

Но не надо расстраиваться - жизнь вообще вредная штука.

@boombastik · 27.11.2006, 21:43

paradise (27.11.2006)
В Java для обратной совместимости выбран метод "стирания типов" для инстанцирования шаблонов. В С++ шаблон инстанцируется через генерацию класса на основе шаблона.

А внешняя типизированность реализована внутренним скрытым от программиста привидениями типов Object -> UserClass, о чем, собственно, и говорил mselez, на что я и посетовал: "мне казалось, что Java реализовала в 5-ой версии нечто подобное при помощи Generics, но вот говорят, что это не совсем так, а жаль"

С уважением,

Владимир

28.11.2006, 18:29

Ок. Я понял. Жаль, потому что каст остался.

@Danissimo · 29.11.2006, 15:50

Разрешите поделиться мыслями об узких местах. Не помню, кто сказал, что преобразование типов может выполняться в узком месте, и в этом случае было бы не лишним написать свой контейнер. Хочу возразить: писать свою коллекцию только для того, чтобы избавиться от приведения типов -- это все равно, что узкое место переписать на ассемблере. Нужно? Мой ответ -- нет. Знаю все возражения. Но также знаю, что как не переписывай квадратичный алгоритм, так он квадратичным и останется. Коэффициент может сделать его более крутым или пологим. Не более. Так что, я считаю, что преобразование типов проблемой стать не может. Следовательно, потребности переписывать возникать не должно.

Новые блоги и статьи Все статьи Все блоги /
Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.	Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .	Настройки VS Code Loafer 13.04.2026 { "cmake. configureOnOpen": false, "diffEditor. ignoreTrimWhitespace": true, "editor. guides. bracketPairs": "active", "extensions. ignoreRecommendations": true, . . .	Оптимизация кода на разграничение прав доступа к элементам формы Maks 13.04.2026 Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2. Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива. Было так:. . .
Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .	Архитектура слоя интернета для сервера-слоя. Hrethgir 11.04.2026 В продолжение https:/ / www. cyberforum. ru/ blogs/ 223907/ 10860. html Знаешь что я подумал? Раз мы все источники пишем в голове ветки, то ничего не мешает добавить в голову такой источник, который сам. . .	Подстановка значения реквизита справочника в табличную часть документа Maks 10.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: при выборе сотрудника (справочник Сотрудники) в ТЧ документа. . .	Очистка реквизитов документа при копировании Maks 09.04.2026 Алгоритм из решения ниже применим как для типовых, так и для нетиповых документов на самых различных конфигурациях. Задача: при копировании документа очищать определенные реквизиты и табличную. . .

@mselez 0 / 0 / 0 Регистрация: 22.07.2009 Сообщений: 457

	Отказ от кастинга 22.11.2006, 19:52. Показов 8861. Ответов 38 Метки нет (Все метки) Меня всегда раздражала необходимость кастинга при извлечении обьекта из библиотечной коллекции. Обычно в коллекции хранят обьекты одного известного типа, но при извлечении приходится всякий раз этот кастинг делать. Модные нынче дженерики не в счет. Там внутри тот же кастинг делается. Придумано исключительно для удобства программирования, но не для повышения эффективности программы. Кастинг - отнюдь не самая тяжелая операция, но все же операция (по моим примитивным тестам время извлечения обьектов из коллекции возрастает примерно на 5% ). Возникает ли желание взять, скажем, ArrayList и на его основе сделать к примеру StringArrayList, заточенный под хранение стрингов? Чтобы исключить кастинг. Или это паранойя и маразм? 0

@boombastik 7 / 7 / 12 Регистрация: 13.02.2007 Сообщений: 1,255
	22.11.2006, 20:05
	во-первых, про 5% на приведение типов при работе с коллекцией - это ты загнул, по-моему во-вторых, generics применительно к collections должны работать как типизированные коллекции, нечто похожее на С++ templates, по крайней мере на уровене классов входящих в JDK, правда я не смотрел как это реализовано, но если правильно, то приведение типов в этом случае не требуется а так, в общем, если для задачи достаточно набора возможностей предоставляемых массивом, то всегда стоит отдавать предпочтение массиву по сравнению с любого рода коллекцией, потому как: меньше памяти, быстрее создание самого массива, быстрее установка значений в массиве, быстрее извлечение значений из массива, нежели из любой коллекции С уважением, Владимир 0

@boombastik 7 / 7 / 12 Регистрация: 13.02.2007 Сообщений: 1,255
	23.11.2006, 01:21
	по-моему должно быть меньше 5% ты как тест проводил? извлекал String объекты из коллекции с приведением к String и сравнивал результаты с извлечением String объектов из коллекции в той же последовательности, но оставляя их как Object? какую коллекцию использовал? С уважением, Владимир 0

@mselez 0 / 0 / 0 Регистрация: 22.07.2009 Сообщений: 457
	23.11.2006, 02:44 [ТС]
	да, именно так. Коллекция - ArrayList. 0

mishgun
	24.11.2006, 22:02
	ну в принципе можно попробовать Class.forName(String name,boolean initialize,ClassLoader loader) Но скорей всего это вряд ли поможет отцу русской демократии)

@mselez 0 / 0 / 0 Регистрация: 22.07.2009 Сообщений: 457
	25.11.2006, 00:03 [ТС]
	признаться, я ничего не понял 0

mishgun
	25.11.2006, 00:24
	Чё то я фигню спорол похоже

mishgun
	25.11.2006, 00:30
	по моему то что вы пытаетесь сделать практически невозможно. Можно написать свой ArrayList - да но тогда для каждого объекта писать свой ArrayList? Овчинка выделки не стоит по моему. Не такие уж большие затраты на кастинг чтоб заниматься этим

@boombastik 7 / 7 / 12 Регистрация: 13.02.2007 Сообщений: 1,255
	27.11.2006, 18:54
	здесь же выше и сказали кстати, никогда не плевался на C++ шаблоны С уважением, Владимир 0

paradise
	27.11.2006, 20:22
	В Java для обратной совместимости выбран метод "стирания типов" для инстанцирования шаблонов. В С++ шаблон инстанцируется через генерацию класса на основе шаблона. Выбирая из двух зол, бери оба - потом и этого не будет. (с) По поводу приведения типов можно сказать следущее: протестируйте instanceof и вызов интерфейсного метода. Но не надо расстраиваться - жизнь вообще вредная штука.

paradise
	28.11.2006, 18:29
	Ок. Я понял. Жаль, потому что каст остался.

@Danissimo 4 / 4 / 4 Регистрация: 28.08.2008 Сообщений: 611
	29.11.2006, 15:50
	Разрешите поделиться мыслями об узких местах. Не помню, кто сказал, что преобразование типов может выполняться в узком месте, и в этом случае было бы не лишним написать свой контейнер. Хочу возразить: писать свою коллекцию только для того, чтобы избавиться от приведения типов -- это все равно, что узкое место переписать на ассемблере. Нужно? Мой ответ -- нет. Знаю все возражения. Но также знаю, что как не переписывай квадратичный алгоритм, так он квадратичным и останется. Коэффициент может сделать его более крутым или пологим. Не более. Так что, я считаю, что преобразование типов проблемой стать не может. Следовательно, потребности переписывать возникать не должно. 0