"Новый взгляд" на контейнеры , по версии явиста

Цитата Qraizer @ 19.03.18, 14:50

У Майерса один из советов был "не знаете, какой контейнер использовать, берите вектор".

Aга и получайте out of memory, лучше бы он или другой кто , показал
пример как использовать аllocator, Я не хочу на два умножать и тратить память
в пустую.

Добавлено 30.05.18, 21:13

Цитата applegame @ 19.03.18, 13:35

Он предлагает никогда не использовать связные списки? Совсем что-ли тронулся умом старый?
https://www.youtube.com/watch?v=YQs6IC-vgmo

Где ты услышал слово никогда? Он говорит почему не стоит юзать,
хотя и не говорит почему таки иногда его пользовать таки стоит,

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Эта тема была разделена из темы "Новый взгляд на контейнеры"

settler, не хочешь, не трать. Кто тебя заставляет-то?

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата Qraizer @ 30.05.18, 23:08

settler, не хочешь, не трать. Кто тебя заставляет-то?

out of memory и заставляет

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата settler @ 30.05.18, 21:00

Aга и получайте out of memory

list и прочие контейнеры больше памяти жут, чем вектор, очевидно.

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата OpenGL @ 31.05.18, 07:05

Цитата settler @ 30.05.18, 21:00

Aга и получайте out of memory

list и прочие контейнеры больше памяти жут, чем вектор, очевидно.

list больше на 8 байт это очевидно,
если имеем x байт у вектора , то list - х+8 ,
при размере n , sizeofVextor - *x*n , list - n(x+8)
при добавке елемента sizeofVextor - 2*x*n , list - (n+1)(x+8)
при больших n list меньше , если х большой то на 8 можно забить,

Если програмист этого не знает, то он ламер.

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

По-моему то, что ты написал, написать может только ламер Мало того, что написанные тобой якобы формулы - пустой набор символов, не несущих смысловой нагрузки, так ещё и вывод, который ты делаешь из них, очевидно неверный банально из-за того, что list-у на каждый элемент, помимо этого самого элемента, нужно хранить указатель на следующий. Вероятно, bad_alloc может у вектора случиться раньше, чем у list-а, но это будет из-за невозможности найти непрерывный кусок памяти нужного размера, а вовсе не из-за того, что он больше занимает памяти.

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата settler @ 31.05.18, 07:28

list больше на 8 байт это очевидно,
если имеем x байт у вектора , то list - х+8 ,
при размере n , sizeofVextor - *x*n , list - n(x+8)
при добавке елемента sizeofVextor - 2*x*n , list - (n+1)(x+8)
при больших n list меньше , если х большой то на 8 можно забить,

Если програмист этого не знает, то он ламер.

Боже, какой бред!

На, проверяй:

#include <stdio.h>
#include <memory>
#include <vector>
#include <list>
 
namespace mmap_allocator_namespace {
  template <typename T>
    class mmap_allocator: public std::allocator <T> {
      public: typedef size_t size_type;
      typedef T * pointer;
      typedef
      const T * const_pointer;
 
      template <typename _Tp1>
      struct rebind {
        typedef mmap_allocator <_Tp1> other;
      };
 
      pointer allocate(size_type n,
        const void * hint = 0) {
        fprintf(stdout, "Alloc %d bytes.\n", n * sizeof(T));
        return std::allocator <T> ::allocate(n, hint);
      }
 
      void deallocate(pointer p, size_type n) {
        fprintf(stdout, "Dealloc %d bytes (%p).\n", n * sizeof(T), p);
        return std::allocator <T> ::deallocate(p, n);
      }
 
      mmap_allocator() throw (): std::allocator <T> () {
        fprintf(stdout, "Hello allocator!\n");
      }
      mmap_allocator(const mmap_allocator & a) throw (): std::allocator <T> (a) {}
      template <class U>
      mmap_allocator(const mmap_allocator <U> & a) throw (): std::allocator <T> (a) {}~mmap_allocator() throw () {}
    };
}
 
using namespace std;
using namespace mmap_allocator_namespace;
 
int main() {
  // раскомментируем нужное:
  // vector<int, mmap_allocator<int>> int_vec(32, 0, mmap_allocator<int>());
  // list<int, mmap_allocator<int>> int_lst(32, 0, mmap_allocator<int>());
  return 0;
}

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата settler @ 31.05.18, 07:28

при добавке елемента sizeofVextor - 2*x*n , list - (n+1)(x+8)

Дай ссылку, где бы чётко показывалось, что не (n+1)*x

Добавлено 31.05.18, 12:00

Цитата settler @ 31.05.18, 06:30

out of memory и заставляет

А. Понятно. Не читатель.

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата Qraizer @ 31.05.18, 11:55

Дай ссылку, где бы чётко показывалось, что не (n+1)*x

man 3 realloc, или сорцы вектора, или ,
там есть умножение на два, чтобы выделить блок памяти
когда size=upperLimit, нормальные люди перегружают исходя их конкретной
задачи,
Да ты все это знаешь, только дурку косишь

Добавлено 01.06.18, 13:10

Цитата JoeUser @ 31.05.18, 10:13

На, проверяй:

Ну проверил, алокаторы работают по разному, у вектора есть внутренние attributes,
под которые память тоже выделаеться,

проверь сам

  vector<int> v;
cout<< sizeof(v) ;
vector<int> l;
cout<< sizeof(l) ;

Если увидишь разницу то расскажешь

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Знаю. Только я ещё кое-что знаю, потому что документацию читал.

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата OpenGL @ 31.05.18, 07:50

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

Не Вероятно, bad_alloc может у вектора случиться раньше , а случиться на 100%,

Вероятность bad_alloc листа равна 0.00000001 ;

Причину ты указал, расчеты мои ты не понял потому что я сравнивал
с массивом, а sizeof(vector) eq sizeof(list), и применяемы они для разных целей,
The second one is not instead of the first, it's in additional.
Как это на-русский перевезти?

Добавлено 01.06.18, 13:33

Цитата Qraizer @ 01.06.18, 13:26

Знаю. Только я ещё кое-что знаю, потому что документацию читал.

Скорее книгу по Data Structures, или OS, лет так 15-20назад
Это общие базовые/фундаментальные вещи не зависимые от ЯП,

А алокатор как я уже понял совсем для других целей придуман.

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Сообщение отредактировано: settler - 10.06.18, 14:29

Цитата settler @ 01.06.18, 13:02

у вектора есть внутренние attributes,

А у списка нет?

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата JoeUser @ 01.06.18, 14:00

Цитата settler @ 01.06.18, 13:02

у вектора есть внутренние attributes,

А у списка нет?

А зачем они ему?
Хотя проверь а тo мало ли

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата settler @ 01.06.18, 13:02

проверь сам

M

settler, давай доказательства своих расчетов в студию!

Пиши код, показывай суммарные аллокации памяти (включая твои пресловутые attributes), у вектора и листа. Если этого не будет, я посчитаю твой пост от начала и до конца - демагогией и троллингом. Выводы и действия себя ждать не заставят - просто возьми и поверь мне.

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата settler @ 01.06.18, 13:27

Скорее книгу по Data Structures, или OS, лет так 15-20назад

Не-а. Стандарт языка.

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата settler @ 01.06.18, 13:27

Не Вероятно, bad_alloc может у вектора случиться раньше , а случиться на 100%,

То есть вот тут произошло событие с нулевой вероятностью?

Code

#include <vector>
#include <vector>
#include <algorithm>
#include <iostream>
#include <map>
#include <optional>
#include <memory>
#include <type_traits>
#include <list>
#include <sys/time.h>
#include <sys/resource.h>
 
template<class C> void gen()
{
    C v;        
    for(int i = 0; i < 5000; ++i) v.push_back(i);
}
 
int main()
{
    rlimit lim;
    lim.rlim_cur = 0;
    lim.rlim_max = 1000000;
    setrlimit(RLIMIT_AS, &lim);
    gen<std::vector<int>>();
    std::cout << "Vector was generated\n";
    
    //gen<std::vector<int>>();
    //std::cout << "Vector2 was generated\n";
    
    gen<std::list<int>>();
    std::cout << "List was generated\n";
}
}

Вывод:

terminate called after throwing an instance of 'St9bad_alloc'
Vector was generated
  what():  std::bad_alloc
Aborted

Если ты заменишь std::list в последнем примере на std::vector - внезапно всё отработает. Как это поведение объяснимо в твоей картине мира?

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Сообщение отредактировано: OpenGL - 10.06.18, 14:29

Цитата OpenGL @ 07.06.18, 06:48

Если ты заменишь std::list в последнем примере на std::vector - внезапно всё отработает. Как это поведение объяснимо в твоей картине мира?

В реальных задачах память всегда дефрагментирована и bsd_alloc, когда ты пытаешься выделить один большой кусок памяти, случится гораздо вероятнее, чем когда вделяешь много маленьких.

Вообще, сравнивать vector и list - это примерно как сравнивать пароход с паровозом - который из них лучше?
Это совершенно разные структуры для реализации разных задач. Проблемы возникают ене потому что, один хуже или лучше другого, а потому, что для решения конкретной задачи используется не тот контейнер.

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата Олег М @ 07.06.18, 07:29

В реальных задачах память всегда дефрагментирована и bsd_alloc, когда ты пытаешься выделить один большой кусок памяти, случится гораздо вероятнее, чем когда вделяешь много маленьких.

Это понятно. Тут спорят с бредом "вектор потребляет больше памяти", которые его срасчёты вроде как по его мнению показывают.

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата OpenGL @ 07.06.18, 08:38

Это понятно. Тут спорят с бредом "вектор потребляет больше памяти", которые его срасчёты вроде как по его мнению показывают.

Ты понимаешь как вектор добавляет новый елемент ?
Сколько он выделает памяти ? Сколько выделяет список ?

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата settler @ 07.06.18, 21:06

Ты понимаешь как вектор добавляет новый елемент ?

А почему ты спрашиваешь? Ты не догадываешься, что я на этот вопрос отвечу?
Ответь лучше на вопрос выше - почему мой код падает с bad_alloc в случае списка и не падает в случае вектора если вектор занимает памяти больше

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Олег М, как ты понимаешь значение слова "дефрагментирована"?
Потому как у меня при прочтении твоих постов возникают некоторые сомнения, что ты полностью понимаешь, что в них пишешь.

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

Цитата OpenGL @ 08.06.18, 07:09

Цитата settler @ 07.06.18, 21:06

Ты понимаешь как вектор добавляет новый елемент ?

А почему ты спрашиваешь? Ты не догадываешься, что я на этот вопрос отвечу?
Ответь лучше на вопрос выше - почему мой код падает с bad_alloc в случае списка и не падает в случае вектора если вектор занимает памяти больше

Ну так твой код, Я так писать еще не научился,
Вектор увеличивает памать в два раза, то есть выделил памать под 1000
элементов - а надо 1001, так вот на 1001 он выделает *2 то есть 2000, (999байт коту под хвост)
на 2001 - 4000, и т.д. Tак пишут в книгах по OS,
в какой то момент будет out of memory, памяти всего может быть, но может не быть
linear memory block, до сих что не так ?

Лист не занимает больше памяти он больше выделает,(sizeof() = 24 дважды) и потом стирает,(см сорцы)
фактически у него не два поинтера а три (третий temp каждый раз выделает и делилит память),
возможно при больших обьемах он не увеличивает размер на два, возможно оптимизатор
собирает статистику и выделает память более умно, но это мои догадки,

так вот в твоем случае память не дефрагментирована, по сути пустая, нету с чего, и с тем что я написал не столкнулся, то есть нет проблем выделить linear memory block,


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

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

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

Сообщения были разделены в тему "Новый взгляд на контейнеры"

Это сообщение было перенесено сюда или объединено из темы "Что несет Бьёрн Страуструп?"

!

JoeUser, заряжай.

Эта тема была разделена из темы "Что несет Бьёрн Страуструп?"

Сообщение отредактировано: JoeUser - 09.06.18, 04:29

Цитата amk @ 08.06.18, 15:40

Олег М, как ты понимаешь значение слова "дефрагментирована"?
Потому как у меня при прочтении твоих постов возникают некоторые сомнения, что ты полностью понимаешь, что в них пишешь.

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

Цитата settler @ 09.06.18, 00:45

Вектор увеличивает памать в два раза, то есть выделил памать под 1000
элементов - а надо 1001, так вот на 1001 он выделает *2 то есть 2000, (999байт коту под хвост)
на 2001 - 4000, и т.д. Tак пишут в книгах по OS,

Во-первых, если мне надо 1001 элемент, я выделю 1001 элемент, а не 1000, как это ни странно Во-вторых, это будет только при реаллокации, так что не страшно. В-третьих, на практике коэфициент 2 используют редко - обычно он меньше. И в-чётвёртых даже если предположить, что у меня действительно capacity вдвое больше, чем size, занимаемая память всё равно будет меньше из-за того, что sizeof(void*) в данном случае вдвое больше самого int-а, а это значит в твоём сценарии памяти съест вектор всё равно в полтора раза меньше, чем такой список

Добавлено 09.06.18, 06:38

Цитата Олег М @ 09.06.18, 06:21

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

Вероятно, он о том, что реально ты хотел сказать "в реальных задачах паметь фрагментирована"

Цитата OpenGL @ 09.06.18, 06:36

Вероятно, он о том, что реально ты хотел сказать "в реальных задачах паметь фрагментирована"

Да, точно, ошибся.

settler, вектор старается уменьшитьчисло перераспределений памяти, но не настолько. Ёмкость удваивается только пока вектор относительно небольшой. при средних размерах ёмкость увеличивается наполовину, Большие вектора увеличиваются при перераспределении где-то на четверть. При этом вектор всё так же имеет линейные затраты, просто константа увеличивается. При этом мы ещё и избавляемся от одного неприятного явления, проявляющегося при удвоении ёмкости, когда освобождённой ранее вектором памяти, даже после склейки освобождённых кусков всё время не хватает для нового буфера (память становится одноразовой).
Кроме того, если примерное количество мест в векторе известно, всегда можно запросить нужный размер вручную сразу, тогда вектор вообще перераспределять память не будет.

Добавлено 09.06.18, 18:34
Олег М, просто ты такую ошибку допустил в каждом из мест, где писал о фрагментации.

Цитата amk @ 09.06.18, 18:33

settler, вектор старается уменьшитьчисло перераспределений памяти, но не настолько. Ёмкость удваивается только пока вектор относительно небольшой. при средних размерах ёмкость увеличивается наполовину, Большие вектора увеличиваются при перераспределении где-то на четверть. При этом вектор всё так же имеет линейные затраты, просто константа увеличивается. При этом мы ещё и избавляемся от одного неприятного явления, проявляющегося при удвоении ёмкости, когда освобождённой ранее вектором памяти, даже после склейки освобождённых кусков всё время не хватает для нового буфера (память становится одноразовой).

Это вполне логично,(свои вектора примерно так и делают),как ты понимаешь это тема есть в любом языке, в Ява сорцах явно видно как умножается на два (если надо могу выложить),
ArrayList на 3/2, где сказано про c++ vector что в нем так как ты говоришь, и как это
грамотно изменить для конкретной задачи ? В яве наследуют тут надо писать свой алокатор ?
или что ?

Добавлено 09.06.18, 19:46

Цитата amk @ 09.06.18, 18:33

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

Это понятно, я говорю о том когда неизвестно , лист для того и придумал,
да там оверхад в 16байт(два поинтера) и memory overflow будет как в примере OpenGL но когда сам обьект большой оно мало влияет, ну кто мешает юзать sigleList он есть в C++11 ЕМНИП.

Добавлено 09.06.18, 19:52

Цитата OpenGL @ 09.06.18, 06:36

Во-первых, если мне надо 1001 элемент, я выделю 1001 элемент, а не 1000, как это ни странно

Как ни странно ты об этом не всегда заранее знаешь
И представь себе что данные постоянно то стираються то добавляются снова,
В этом случае нужен лист и лучше single,

Добавлено 09.06.18, 19:55

Цитата OpenGL @ 09.06.18, 06:36

Во-вторых, это будет только при реаллокации, так что не страшно.

Если реаллокации много то может и страшно, от задачи зависит.

Добавлено 09.06.18, 20:07

Цитата OpenGL @ 09.06.18, 06:36

В-третьих, на практике коэфициент 2 используют редко - обычно он меньше.

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

Добавлено 09.06.18, 20:31

Цитата OpenGL @ 09.06.18, 06:36

И в-чётвёртых даже если предположить, что у меня действительно capacity вдвое больше, чем size, занимаемая память всё равно будет меньше из-за того, что sizeof(void*) в данном случае вдвое больше самого int-а, а это значит в твоём сценарии памяти съест вектор всё равно в полтора раза меньше, чем такой список

Не понял , кто у тебя void*

смотри еще раз мои расчеты, what is wrong here ?

class Node<T>{
 node* prev;
 node* next;
 T value;
 
}

sizeof(node) = sizeof(T) + sizeof(next) +sizeof(prev) для 64бит
будет sizeof(T) + 16,

для листа будет n(sizeof(T) + 16) ,

для вектора n*sizeof(T) , при увиличении на 2 или на х , то есть при первой перелокации
имеем
для листа будет (n+1)(sizeof(T) + 16) ,
для вектора х*n*sizeof(T)

если х небольшой то проблем нет если он 2 или 1.5 и Т большой то лист выигрывает и очень не слабо,
Понимаешь что все не однозначто еще есть cashing line problem , о которой програмисты C++, c 15-20 опытом молчат как партизаны и вектор можно гонять потоками, как в яве 8,
а с листом (у него нет индекса) это сложнее.

В общем разные контейнеры для разных задач, и говорить что один лучше, есть показатель
собсвенных lack of knowledge ( не путать с luck слышиться одинаково )

Все .

Цитата Qraizer @ 09.06.18, 02:35

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

Почему из других не делаю? вот код openGL
и навел, точнее дополнил, трех строк хватило,
а что в моих выводах не устраивает(они не мои а Вирта или
Таненбаума, и лет им по 20-25 если не больше ) . А ты типо про работу OS
никогда не слышал , ага счас поверил,

А месть за КрымНеНашь (джо зажигай) это глупо, ты же не ватник типа Кили,
или програма , Или Я ошибаюсь ?

Так. Давай-ка заглянем в историю. Итак.

Цитата settler @ 30.05.18, 21:00

Цитата Qraizer @ 19.03.18, 14:50

У Майерса один из советов был "не знаете, какой контейнер использовать, берите вектор".

Aга и получайте out of memory, лучше бы он или другой кто , показал
пример как использовать аllocator, Я не хочу на два умножать и тратить память
в пустую.

Цитата Qraizer @ 30.05.18, 23:08

settler, не хочешь, не трать. Кто тебя заставляет-то?

Как по-моему, amk этот мой ответ прокомментировал исчерпывающе. А вот предупреждение в синей рамке ты получил за то, что это сделал именно amk, а не ты. Материала тебе было предоставлено выше крыши. Это во-первых. Вместо того, чтобы искать у себя ошибки в рассуждениях и следовательно учиться, ты продолжил демонстрировать совершенное нежелание вести предметный разговор. Это твоё решение, на которое ты, конечно, имел полное право. Пусть тебе и плевать на свою репутацию, само по себе это ничего не нарушает. Но вот то, что ты т.о. проигнорил предупреждение в синей рамке от модератора, как раз и явилось настоящей причиной банки на 14 дней. Это во-вторых. Ровно эта же причина отражена и в логах. И не надо тут искать политических заговоров.

Добавлено 09.06.18, 22:01
Собственно, если ты проигнорил в "не знаете, какой контейнер использовать, берите вектор" выделенное синим, этого уже было достаточно, чтобы выкинуть дискуссию в корзину.

Цитата Qraizer @ 09.06.18, 21:59

А вот предупреждение в синей рамке ты получил за то, что это сделал именно amk, а не ты.

Ага только пост amk был после,

Добавлено 09.06.18, 22:46

Цитата Qraizer @ 09.06.18, 21:59

Так. Давай-ка заглянем в историю. Итак.

Цитата settler @ 30.05.18, 21:00

Цитата Qraizer @ 19.03.18, 14:50

У Майерса один из советов был "не знаете, какой контейнер использовать, берите вектор".

Aга и получайте out of memory, лучше бы он или другой кто , показал
пример как использовать аllocator, Я не хочу на два умножать и тратить память
в пустую.

Цитата Qraizer @ 30.05.18, 23:08

settler, не хочешь, не трать. Кто тебя заставляет-то?

Ну и что тут не так, помоему ясно было что речь идет что речь об обьектах,
у меня они от 500К до 3Мега, и приходят они по сокету , когда и и сколько
мне не известно, поэтому перeгрузка ensureCapacity (push back in C++) о которой
тут говорят мало что даст,

Добавлено 09.06.18, 22:56

Цитата Qraizer @ 09.06.18, 21:59

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

А вот это уже wrong IMHO, не знаешь что юзать бери redblackTree,
на любом языке, почему тебе обьяснять не надо, а вот некоторые
этого не знают, или мне кажется, а ворнинги пошли после политики
и с приходом джо, или так случайно получилось

Добавлено 09.06.18, 23:22

Цитата Qraizer @ 09.06.18, 21:59

Но вот то, что ты т.о. проигнорил предупреждение в синей рамке от модератора,

Ну да устроили клоунаду, я как раз и привел расчеты, после примера
openGL , У меня vector<int> держит 58мил записей, таких коллекций
в природе не бывает( а если и бывают то решается это совсем по-другому и не програмным путем) а вот 500,000 тяжелых обьектов , например в системах ERP, где в DB бывает
по 30-40 полей, а бывает и 200, это уже другая опера, пока я вижу детсский сад,
типо сам дурак, а где и что сказал не так привести не можем, ну джо эт лист не может,
поэтому и привел скаченный из тугля алокатор не понимая зачем.

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

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

Цитата settler @ 09.06.18, 19:37

где сказано про c++ vector что в нем так как ты говоришь, и как это
грамотно изменить для конкретной задачи ?

Для меня всегда главным документом по вопросам, определённым в стандарте как зависящее от реализации были файлы заголовков и исходные тексты библиотек.
Грамотно (и законным образом) изменить поведение библиотечного класса можно лишь написав свою версию этого класса (возможно унаследовавшись от этого библиотечного).

Цитата settler @ 09.06.18, 22:38

Ага только пост amk был после,

Возможно, имеется в виду, что ты сам даже после рамки не попытался разобраться в вопросе. И объяснение дождалось меня
Я обычно в будни только раз в сутки где-то на часок на форум заглядываю. С работы возможности нет, а дома и других дел полно.

Т.е. ты так ничего и не понял, settler.

Добавлено 10.06.18, 14:08
Мои девочки в отделе, что на испытательном были, уже через минуту после вопроса об оберхеде вектора нашли ответ, тебе для этого потребовался amk. Ты уверен, что ты программист? Девочки-то тестеры. Они не отказываются учиться и не страдают синдромом диванного аналитизма.
Во-первых, советовать ассоциативные контейнеры на безусловную замену последовательным может только полный профан. Во-вторых, нет, объяснять надо. Тот же Майерс свой тезис аргументировал весьма объёмным текстом. Ты же, как я погляжу, считаешь свои тезисы аксиомами. Не многовато-ли из себя изображаешь, а?
Ты привёл расчёты. Угу. Аха. Ну да. Клоунада заключалась, видимо, в том, что реальный код их опроверг. И это даже не насторожило, не говоря уже о том, что должно было бы заставить броситься немедленно читать мануалы. Браво. Это надо же, какая вера в собственную святость. Нет, братан, спасибо за профессиональную импотенцию тебе никто говорить не будет.

Добавлено 10.06.18, 14:24

!

Что происходит в Политическом гадюшнике, мне совершенно коллинеарно. С волками жить – по волчьи выть. Если ты там себя проявляешь аналогично, то предупреждаю: появишься такой красивый в МШ, увидишь разницу от Политики.
В сухом остатке.

• прямое оскорбление участника, дважды (неделя*2);
• флуд в тематическом разделе (3 дня);
• вред участникам и гостям форума посредством дезинформирования (3 дня + премод на 20 дней).

Цитата settler @ 10.06.18, 10:57

Ты читал что эта мразь мне писала...

Отчего столь сильно бомбануло то, Серж?..
Неужто пропиндосам от мегаоблома по захвату Крыма:

Цитата settler @ 09.06.18, 20:59

месть за КрымНеНашь

крайне тяжко стало жить?..

Цитата settler @ 09.06.18, 19:37

И представь себе что данные постоянно то стираються то добавляются снова,
В этом случае нужен лист и лучше single,

Да ладно Неужели ты хочешь сказать, что нужно брать тот контейнер, который удобнее сейчас, а не всегда один и тот же?

Цитата settler @ 09.06.18, 19:37

Если реаллокации много то может и страшно, от задачи зависит.

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

Цитата settler @ 09.06.18, 19:37

смотри еще раз мои расчеты, what is wrong here ?

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

Добавлено 13.06.18, 06:30

Цитата amk @ 10.06.18, 06:19

Грамотно (и законным образом) изменить поведение библиотечного класса можно лишь написав свою версию этого класса (возможно унаследовавшись от этого библиотечного).

Если только приватно. Наследоваться публично от вектора или прочих стандартных контейнеров - неплохой способ выстрелить себе в ногу.

Мне кажется, что название не отражает сути, ибо дело тут не в Яве...