Увеличение размера массива

ты уверен, что ты слышал, что битовыми операциями можно расширить массив?

Может ты про прямую работу с памятью речь ведешь? Вроде за это отвечает класс Unsafe.

Спасибо, я знаю что такое битовые операции. :-)

Я тоже в первую очередь подумал о работе с памятью, но хочется увидеть пример. Англо-русский гугл пестрит

Нет, я спрошу не о том, как создать новый массив и скопировать в него элементы старого, и речь пойдет не о коллекциях

Дальше остается совместить это знание с тем, что ты хочешь получить.

ещё возможно ты имел ввиду sun.misc.Unsafe.reallocMemory и операции с массивами оттуда же, но вот далеко не факт, что в итоге все данные не будут просто скопированы по новому адресу, как и в случае сишного realloc.

а я тут слышал на днях, будто в С++ есть секретные директивы для компилятора, которые позволяют избежать любых утечек памяти.

а я тут слышал на днях, будто в С++ есть секретные директивы для компилятора, которые позволяют избежать любых утечек памяти.

ты перепутал - это была библиотека:

http://packages.ubuntu.com/raring/libgc1c2

нет-нет, никаких сборщиков мусора, только волшебство и завеса тайны!

Норкомания какая-то. Я даже никогда не слышал о таком.

Разве такое возможно, в принципе? ЕМПИП, какой-нибудь realloc не увеличиввает выделенную память, а выделяет новую, и копирует старые данные в новый сегмент.

Разве такое возможно, в принципе?

при очень удачном стечении обстоятельств, когда блок можно «расширить», в общем же случае можно считать, что нельзя.

#pragma magic_gc on?

не работает. может g++ 4.7 это уже не поддерживает?

какой-нибудь realloc не увеличиввает выделенную память, а выделяет новую, и копирует старые данные в новый сегмент

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

Если

Емнип, да.

то за счет чего будет память увеличиваться? За счет файла подкачки из астрала?

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

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

ну можно порезать всех жителей пополам, упаковать компактней, наверное это он имеет ввиду

За счет свободных ячеек памяти, любезно предоставленных блоком адресации?

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

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

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

Ну а если сама jvm выделит память?

Хм, индекс не может быть больше чем пол-int. Может имелось ввиду что можно сделать массив массивов, а потом битовыми операциями по long ломать long на две части?

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

Может массив boolean в 256?

Точно не работает? Что ты делал, что бы убедиться, что не работает?

Любых типов, как примитивных, так и врапперов. И даже массив пользовательских классов.

я включил эту директиву и начал протекать память. он не остановил меня.

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

Может, все так офигели, что поправить не могли?
Не, ну можно увеличить массив boolean (почти) в 8 раз: в HotSpot boolean занимает один байт, следовательно, если использовать массив чисел и производить битовые операции, получится в 8 раз больше (не считая оверхед).

Может имелась в виду модификация байткода без перекомпиляции, но до парсинга?

Еще есть мысль поклпаться в исходниках openJDK чтобы доказать или опровергнуть данную возможность.

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

По стандарту C++ по крайней мере, вектор должен располагаться на непрерывном участке памяти. То, о чём ты говоришь, называется deque, емнип.

По стандарту C++ по крайней мере, вектор должен располагаться на непрерывном участке памяти.

А если память «рядом» занята, куда он будет расширяться?

Никуда. Будет копироваться в другое место.

Мне кажется это оверхед, почему нельзя разместить вектор непоследовательно?

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

Чтобы с вектором можно было сделать так

vector<mytype> vec;
//filling vector...
somecoolfunc_accepting_rawbytes((char*)&vec[0],vec.size()*sizeof(mytype));

Окай О_о

Может ты про прямую работу с памятью речь ведешь? Вроде за это отвечает класс Unsafe.

неужели враги даже это в жабу затащили???

Какие враги? Вы о чем? Этот класс вроде как давной уже в Java. К сожалению, я не знаю, где можно посмотреть историю изменений и правок в Sun JDK, дабы уточнить, с каких он пор в ней и когда последний раз правился. Копирайт там стоит «2000-2006 Sun Microsystems, Inc.»

P.S.: Прямая работа с памятью вроде как со времен JNI должна быть. А это вроде как начиная с 1.1 версии. Это если уж придираться. Не пугало сие раньше?