Сообщение Re: VC14 std::containers allocs node in ctor от 11.02.2016 18:03
Изменено 11.02.2016 18:11 VTT
Эта реализация в таком виде вроде еще с 2012 живет.
2. Кажется в блоге разработчиков кто-то высказывался по этому поводу. Но вообще хорошо бы в Connect тикет завести.
3. А вы уверены, что проблемы с эффективностью у вас именно из-за такой реализации контейнеров?
Целесообразность выделение памяти на куче весьма сомнительна, однако эти контейнеры выдают неплохую дебаг диагностику при работе с итераторами.
Из альтернатив — только boost и boost.intrusive. Для их визуализации кстати есть соотв расширение.
2. Кажется в блоге разработчиков кто-то высказывался по этому поводу. Но вообще хорошо бы в Connect тикет завести.
3. А вы уверены, что проблемы с эффективностью у вас именно из-за такой реализации контейнеров?
Целесообразность выделение памяти на куче весьма сомнительна, однако эти контейнеры выдают неплохую дебаг диагностику при работе с итераторами.
Из альтернатив — только boost и boost.intrusive. Для их визуализации кстати есть соотв расширение.
Re: VC14 std::containers allocs node in ctor
Эта реализация в таком виде вроде еще с 2012 живет.
2. Кажется в блоге разработчиков кто-то высказывался по этому поводу. Но вообще хорошо бы в Connect тикет завести.
3. А вы уверены, что проблемы с эффективностью у вас именно из-за такой реализации контейнеров?
Целесообразность выделение памяти на куче весьма сомнительна, однако эти контейнеры выдают неплохую дебаг диагностику (за исключением самоприсваивания).
Из альтернатив — только boost.container и boost.intrusive. Для их визуализации кстати есть соотв расширение.
В плане производительности меня больше напрягает древняя проблема со множественным наследованием пустых классов и недостаточно хорошая оптимизация move семантики (типа make_unique).
2. Кажется в блоге разработчиков кто-то высказывался по этому поводу. Но вообще хорошо бы в Connect тикет завести.
3. А вы уверены, что проблемы с эффективностью у вас именно из-за такой реализации контейнеров?
Целесообразность выделение памяти на куче весьма сомнительна, однако эти контейнеры выдают неплохую дебаг диагностику (за исключением самоприсваивания).
Из альтернатив — только boost.container и boost.intrusive. Для их визуализации кстати есть соотв расширение.
В плане производительности меня больше напрягает древняя проблема со множественным наследованием пустых классов и недостаточно хорошая оптимизация move семантики (типа make_unique).