Вход | Регистрация
    1  2  3

Java. Удалить в ArrayList массив строк.

Java. Удалить в ArrayList массив строк.
Я
   yavasya
 
23.03.20 - 12:18
Допустим мне в ArrayList нужно удалить 1,3,5 строку. В 1С для этого создается массив строк для удаления, и далее в метод удалить куда передается массив строк. Как сделать такую операцию в джава  чтобы индексы не сбивались ? Или остается строка с ссылкой null ?
 
 
   yavasya
 
201 - 27.03.20 - 19:07
(199) не умеешь , не берись, тем более не оценивай. cViper  было что то похожее на правду
   GANR
 
202 - 27.03.20 - 20:39
   Конструктор1С
 
203 - 28.03.20 - 05:04
(196) "надо было с _индексами_"

Очевидно, это какая-то тупая постановка задачи. Тем более, если стоит задача удалить дофига элементов из коллекции, то массив тут явно не подходит
   sevod
 
204 - 28.03.20 - 11:56
(202) а на эту ссылку всех пускает?
   sevod
 
205 - 28.03.20 - 12:21
(202)
hasNext() не поможет, если надо по индексам удалять. Индексы смещаются при удалении и перестают соответствовать тем индексам которые были в первоначальном массиве. Отсортировать массив индексов от большего к меньшему и удалять по ним. То есть снизу вверх. Самый простой алгоритм. При таком удалении, смещение нижестоящих элементов, не изменяет индексы вышестоящих. Если конечно ему именно это нужно было.
Но что бы дойти до такого супер сложного алгоритма, ему нужно свойства ArreyList прочитать, а не искать аналоги ArreyList в 1С.

(200) Я даже в 1С ООП использую :) Так что бросай Java и ползи назад в 1С. Ну или хотя бы свойства ArreyList для Java прочитай. А то так и будешь вопросы по Java на 1С форуме задавать.
   sevod
 
206 - 28.03.20 - 12:30
(203) задача очень даже не тупая. Она для того что бы разобраться с особенностями ArreyList. У Васи например даже мысль возникла "Как сделать такую операцию в джава  чтобы индексы не сбивались ? Или остается строка с ссылкой null ?". На практике скорее всего действительно не нужна.
Искать аналоги в 1С не стоит. В 1С разработчики платформы сделали намного проще, но цена за это "скорость" 1С. Кому очень хочется, может разобраться с массивами в Си и адресной арифметикой в Си. Но для 1С это все лишнее.
   Сияющий в темноте
 
207 - 28.03.20 - 14:59
нет
ну если отойти от программирования вообще и рассмотреть,скажем стопку из семи ящиков.
если мы удаляем пятый ящик,то можно как-то сохранить нумерацию?
очевидный ответ-нет,или мы вместо пятого ящика пихаем что-то его заменяющее или шестой ящик становится пятым.
а представьте,что кто-то захочет вставить ящик между вторым и третьим?

это,кстати,нашлядная модель поведенря индексов при изменении данных.
   sevod
 
208 - 28.03.20 - 15:40
(207) ты сейчас расписал часть работы ArreyList :) Наверное Вася и ждал такого поста :)
Если взять для сравнения Arrey, то это комод с выдвигающимися ящиками. Нельзя добавить или уменьшить количество ящиков комода. Только заменить на новый комод. А вот в ArreyList очень даже можно. Его для этого и создавали. Правда ArreyList это тоже комод, поскольку "по капотом" там Arrey, но вот реально, кому нужно, найдут нормальную статью.
   GANR
 
209 - 28.03.20 - 18:59
(205) Дак там по ссылке удалять можно же - никакие смещения не страшны

public static void main(String[] args) {

   ArrayList<Cat> cats = new ArrayList<>();
   Cat thomas = new Cat("Томас");
   Cat behemoth = new Cat("Бегемот");
   Cat philipp = new Cat("Филипп Маркович");
   Cat pushok = new Cat("Пушок");

   cats.add(thomas);
   cats.add(behemoth);
   cats.add(philipp);
   cats.add(pushok);
   System.out.println(cats.toString());

   cats.remove(philipp);

   System.out.println(cats.toString());
}

Вывод:

[Cat{name='Томас'}, Cat{name='Бегемот'}, Cat{name='Филипп Маркович'}, Cat{name='Пушок'}]
[Cat{name='Томас'}, Cat{name='Бегемот'}, Cat{name='Пушок'}]
   sevod
 
210 - 28.03.20 - 19:08
(209) А нам по "Ссылке" (наверное правильнее "по значению") или по индексу? :) Вася какие то намеки делает, но интригу продолжает сохранять :)
   Конструктор1С
 
211 - 28.03.20 - 19:15
(206) а чё в 1с не так? 1сные коллекции во многом похожы на джавовые. При этом 1сное соответствие хитро оптимизировано, т.к. на нём завязаны многие платформенные механизмы. И пожалуй соответствие даже будет попроизводительнее джавового аналога в виде интерфейса Map
   Сияющий в темноте
 
212 - 28.03.20 - 19:35
(208)
на самом деле,ArrayList работает так:
при создании выделяется место,то есть создается комод на 4 ящика,все ящики заклеены,то есть не используются.
добааляется первый элемент-распечатывается первый ящик,
добавляется второй элемент-распечатывается второй ящик,
также третий-в третий ящик
теперь,если мы удаляем второй элемент,то мы должны выкинуть содержимое второго ящика
потом содержимое третьего ящика переложить во второй и заклеить третий ящик.

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

вот так.
на самом деле,насколько я помню,первоначально выделяется 16 элементов,а потом не в два раза,а на одну треть больше,но суть от этого не меняется.
   Сияющий в темноте
 
213 - 28.03.20 - 19:52
и,на самом деле,если быть точным,то
в ящиках комода находятся дощечки,на которыз написан адрес(номер)обьекта,который саи размещается рядом с комодом,и мы не перемещаем дощечки,так как они в ящики встроены,а просто переписываем значение с одной дощечки на другую.
когда нам меняют комод,то старый остается стоять на том же месте,где и был,новый появляется рядом и где-то на дощечке номер старого комода меняется на новый.

опять же,место,где живут комоды и другие обьекты называется эдем-представим его ангаром.
ангаров таких в системе два,когда один заполняется,и новый обьект не всунуть,то сборщик мусора начинает просматривать таблички в ппмяти программы и переносит уапомчнутые там обьекты в новый ангар,к каждого переносимого обьекта он просматривает все таблички,чтобы перенести упомянутые там обьекты и так до тех пор,пока переносить будет нечего.
потом,все,что осталось в старом ангаре уничтожается,и старый ангар ждет следующей сборки мусора,где он будет принимающим.
   sevod
 
214 - 28.03.20 - 20:17
Вот так Вася, вот так ссын. Добился таки своего. ArreyList уже разжевали :) Расписывайте Arrey, без него ArreyList будет не точным.
По моим данным, на старте пустой ArreyList это 10 ячеек, далее увеличение идет на коэффициент 1,5. Но по сути это не принципиально.

(211) проблема 1С в том, что нельзя по 1С учить java. Для изучения java, надо как ни странно читать документацию по java. Собственно и 1С по java учить тоже как то не очень умно. Но знание одного, может помочь с пониманием с другого. Но не всегда :)
   Конструктор1С
 
215 - 29.03.20 - 08:09
Накатал тест https://pastebin.com/WE71dQPw

Создаётся коллекция определенного размера. В этой коллекции ищется 10% значений. Затем из коллекции удаляются 10% значений

Вывод: за поиск и удаление из ArrayList нужно бить по рукам. Эта коллекция не заточена под такие операции, и время вырастает пропорционально размеру массива. Но добавление значений в массив происходит очень быстро. Так что ArrayList нужно использовать как буфер

Количество = 100000
TestArray: заполнение коллекции - 0.001 сек.
TestArray: поиск в коллекции - 0.794 сек.
TestArray: удаление из коллекции - 1.184 сек.
TestMap: заполнение коллекции - 0.018 сек.
TestMap: поиск в коллекции - 0.005 сек.
TestMap: удаление из коллекции - 0.006 сек.

Количество = 500000
TestArray: заполнение коллекции - 0.002 сек.
TestArray: поиск в коллекции - 16.541 сек.
TestArray: удаление из коллекции - 21.863 сек.
TestMap: заполнение коллекции - 0.042 сек.
TestMap: поиск в коллекции - 0.021 сек.
TestMap: удаление из коллекции - 0.013 сек.

Количество = 1000000
TestArray: заполнение коллекции - 0.002 сек.
TestArray: поиск в коллекции - 65.444 сек.
TestArray: удаление из коллекции - 108.472 сек.
TestMap: заполнение коллекции - 0.073 сек.
TestMap: поиск в коллекции - 0.026 сек.
TestMap: удаление из коллекции - 0.025 сек.
   Конструктор1С
 
216 - 29.03.20 - 08:13
+ сам я не джавист, поэтому мог нарукожопить. Но в целом результат должен быть близок к правде

TestArray - выполняет заполнение, поиск и удаление в ArrayList (аналог 1сного массива)
TestMap - выполняет заполнение, поиск и удаление в HashMap (аналог 1сного соответствия)
   Конструктор1С
 
217 - 29.03.20 - 08:25
(214) учить-то джаву по 1с однозначно не стоит. Но вот насчет "тормознутости" 1сных коллекций я не уверен. Разработчики платформы 1с тоже не в носу ковыряются, и некоторые моменты заточили как надо
   sevod
 
218 - 29.03.20 - 10:49
(217) я не писал про тормознутость 1С коллекций. В яве есть Arrey и ArreyList. Второй значительно удобнее перового и медленнее. 1С-ый массив по функционалу аналогичен ArreyList и он разумеется медленнее Arrey.
   cViper
 
219 - 29.03.20 - 13:59
(215) Глянул код. СОздавать коллекции лучше с помощью конструктора и с предполагаемым размером количества элементов, чтобы избежать постоянного расширения. Это очень сильно влияет на производительность.
Выводы которые вы написали, они очевидны и без вашего теста.
(199) А я даже не вникал особо в код в (128) комментарии. Там говнокод написан. И мой комментарий из (193) относится исключительно к комментарию из (190).
   yavasya
 
220 - 29.03.20 - 20:06
(218) потому что в ArrayList можно добавить строки в отличие от Array
   v77
 
221 - 29.03.20 - 20:33
(218) Да напиши ты хоть раз Array вместо Arrey. Ёлки моталки.
   sevod
 
222 - 29.03.20 - 23:23
(221) Да как я это тебе напишу?! Тут IDE нет! Эта IDEA сама за меня все пишет. Знаю что лучше что нибудь по проще, но лень.
(220) Молодца, прогрессируешь.
   v77
 
223 - 30.03.20 - 09:23
(222) Ладно заливать. Не писал ты ничего и не читал. Потому и пишешь с ошибками.
   fisher
 
224 - 30.03.20 - 09:55
(219) > А я даже не вникал особо в код в (128) комментарии
Да-да. Я заметил. На критику без "особого вникания" у вас времени полно. А на демонстрацию "как надо" примерами живого кода (что называется, вместо тысячи слов) времени не находится. Не царское это дело. Это ж, не дай бог, программировать придется. А там ведь и закритиковать могут.
   cViper
 
225 - 31.03.20 - 01:27
(224)
1) Есть такие принципы, как SOLID. Один из этих принципов рекомендует писать код отталкиваясь от интерфейса. То есть, в примере 128 надо принимать аргумент типа List<String> и возвращать также List<String>, вместо ArrayList<String>. Это урочень джуна.
2) Именование переменных как z и ii недопустимо. Оно ничего не говорит тому, кто будет этот код читать. Это тоже урочень джуна.
3) Зачем использовать разные структуры данных для значений и индексов? Либо человек не понимает как они работают, либо просто не знает как отсортировать List стандартными средствами jdk.

Сам код, думаю, корректен. Но ковыряться в нем мне не интересно. Как можно решить задачу с индексами и с сохранением позиций я писал в одном из комментариев. Там настолько все просто, что не вижу смысло писать имлементацию.
   Sserj
 
226 - 31.03.20 - 03:42
(215) На самом деле не очень правильный тест применительно к топику.
В тесте удаление происходит через removeAll с коллекцией объектов. А это очень нехороший метод, посмотрев исходники ArrayList можно увидеть:
        final Object[] es = elementData;
        int r;
        // Optimize for initial run of survivors
        for (r = from;; r++) {
            if (r == end)
                return false;
            if (c.contains(es[r]) != complement)
                break;
        }

Т.е. поиск ведется перебором массива ArrayList и поиском каждого элемента в переданной коллекции.
В топике задача была на удаление по индексу, опять же посмотрев исходники ArrayList видим метод удаления по индексу:
        modCount++;
        final int newSize;
        if ((newSize = size - 1) > i)
            System.arraycopy(es, i + 1, es, i, newSize - i);
        es[size = newSize] = null;

Тобишь фактически выполняется только System.arraycopy, которая в свою очередь является лишь оберткой над системной memcopy.
Удаление по индексу в итоге будет не сильно отличаться по скорости от времени заполнения коллекции в тесте.
   fisher
 
227 - 31.03.20 - 09:10
(225) > настолько все просто, что не вижу смысло писать имлементацию
Ну вот опять. Чужой код настолько очевидно бездарен, что даже нет смысла в нем разбираться. А свой код настолько прост и самоочевидно идеален, что даже нет смысла его писать :)
А вы возьмите и напишите. И другим наука будет на конкретном примере и вы без критики не останетесь. Авось тоже польза будет.
   v77
 
228 - 31.03.20 - 09:50
(225) "Там настолько все просто, что не вижу смысло писать имлементацию."
Это типа "моя фамилия слишком известна, чтобы я её называл" :))
   Sserj
 
229 - 31.03.20 - 10:37
(225) "..Именование переменных как z и ii недопустимо. Оно ничего не говорит тому, кто будет этот код читать. Это тоже урочень джуна.."
хихи. В (226) выдержка из исходников jdk:
        int r;
        // Optimize for initial run of survivors
        for (r = from;; r++) ...
Можешь смело утверждать что стандартную библиотеку явы писали джуны-лузеры :)
   Конструктор1С
 
230 - 31.03.20 - 15:23
(229) тем не менее, имена классов и объектов стандартных библиотек выбраны лаконично, интерфейсы хорошо задокументированы. Стандартную библиотеку дорабатывает только оракл, внуть библиотеки нырять не принято, разве что из интереса "что там под капотом". А вот твой код будут читать и дорабатывать другие программисты, которым односимвольные переменные будут не понятны. Поэтому всегда нужно выбирать хорошие описательные имена переменных/методов/классов
 
 Рекламное место пустует
   Конструктор1С
 
231 - 31.03.20 - 15:27
+кстати, имена переменных-счетчиков допускается делать короткими, вплоть до одного символа: i, j, k. Но это "так исторически сложилось". А вообще, чем больше область видимости у переменной, тем тщательнен должно быть выбрано её имя
   fisher
 
232 - 01.04.20 - 09:28
(230) Строго говоря, описательные имена переменных больше касаются прикладного программирования. А в системном программировании и системных алгоритмах имена переменных часто не несут большого смысла достойного имен СКД во-первых (речь часто просто о тасовании безликих ячеек памяти), во-вторых - их количество обычно невелико в области видимости, в-третьих - они часто используются. Поэтому сплошь и рядом используют односимвольные/двухсимвольные имена переменных. Как раз для повышения читабельности, как бы на первый взгляд это парадоксально не звучало.
   Конструктор1С
 
233 - 02.04.20 - 05:20
(232) тут скорее тоже "так исторически сложилось". Многие низкоуровневые ЯП имели ограничение на длину имен переменных
  1  2  3

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.