Этот релиз -- инкрементальный апгрейд.
Основное добавление -- не-интрузивные контейнеры списков и мапов, включая "компактные" версии, значительно более быстрые, чем традиционные.
Здравствуйте, Шахтер, Вы писали: Ш>Основное добавление -- не-интрузивные контейнеры списков и мапов, включая "компактные" версии, значительно более быстрые, чем традиционные.
Традиционные возможно и помедленнее но вникать в чужие велосипеды и ловить баги в итоге дороже выйдет.
Здравствуйте, UA, Вы писали:
UA>Здравствуйте, Шахтер, Вы писали: Ш>>Основное добавление -- не-интрузивные контейнеры списков и мапов, включая "компактные" версии, значительно более быстрые, чем традиционные.
UA>Традиционные возможно и помедленнее но вникать в чужие велосипеды и ловить баги в итоге дороже выйдет.
Здравствуйте, trophim, Вы писали:
T>Не сравнивали потому то не знали об их существовании или свой вариант разработали в "добустовскую" эпоху? Или еще какие причины?
Здравствуйте, trophim, Вы писали:
T>Не сравнивали потому то не знали об их существовании или свой вариант разработали в "добустовскую" эпоху? Или еще какие причины?
Не надо, пожалуйста, разводить здесь холивар. Про "эпоху буста" и прочее (тем более, что началась эпоха CCore ).
Если у вас есть разумные вопросы, касающиеся библиотеки, вы их можете задать.
Если вам интересно разобраться, что и как в этой библиотеке реализовано и почему, то есть документация и исходный код. Ну и неплохо знать теорию.
Вопросы типа: а чем это лучше/хуже буста (или другой библиотеки), я не принимаю -- мне не интересно этим заниматься. Но если вам интересно, можете пожертвовать своё драгоценное время и разобраться.
Только не забывайте, что подобное надо сравнивать с подобным.
В CCore, например, одних массивов 5 штук, а не-интрузивных списков 9 штук, хороших и разных.
Что вы тут собираетесь сравнивать с чем-то из буста -- я не представляю.
Здравствуйте, Шахтер, Вы писали:
Ш>В CCore, например, одних массивов 5 штук, а не-интрузивных списков 9 штук, хороших и разных. Ш>Что вы тут собираетесь сравнивать с чем-то из буста -- я не представляю.
Collector is not an array! The purpose of this container is to be an efficient collector of elements. This container stores a sequence of elements in a list of arrays. So appending and extending operations are the most efficient. At desired moment you can copy or move this sequence into true array. Or you can "flat" the Collector itself.
boost::container::deque?
5. TempArray — согласен, замены в boost пока нет, ездим на лисапедах.
6. ??? — boost::container::stable_vector
7. ??? — boost::ptr_vector
А вообще вопрос то был про производительность, которая по заявлению:
значительно более быстрые, чем традиционные.
Если же ты говоришь что
Ш>Что вы тут собираетесь сравнивать с чем-то из буста -- я не представляю.
Здравствуйте, Piko, Вы писали:
P>5. TempArray — согласен, замены в boost пока нет, ездим на лисапедах.
std::string во многих реализациях именно так и сделан, так что можно просто использовать его, параметризуя не char, а твоим типом.
Здравствуйте, jazzer, Вы писали:
P>>5. TempArray — согласен, замены в boost пока нет, ездим на лисапедах. J>std::string во многих реализациях именно так и сделан, так что можно просто использовать его, параметризуя не char, а твоим типом.
Не серьёзно. Допустим мы знаем что в среднем количество элементов — 16 (также много вариантов когда 13,14,15), размер элементов — 16 байт.
И куда тут string'и лепить?
Здравствуйте, Piko, Вы писали:
P>Здравствуйте, jazzer, Вы писали:
P>>>5. TempArray — согласен, замены в boost пока нет, ездим на лисапедах. J>>std::string во многих реализациях именно так и сделан, так что можно просто использовать его, параметризуя не char, а твоим типом.
P>Не серьёзно. Допустим мы знаем что в среднем количество элементов — 16 (также много вариантов когда 13,14,15), размер элементов — 16 байт. P>И куда тут string'и лепить?
В смысле? Вот в STLport std::string представляет собой статический массив на 16 элементов плюс динамический на сколько угодно.
Т.е. делаешь std::string< My16ByteType > — и получаешь то, что надо, не? Если я правильно понял, что такое TempArray, конечно.
Здравствуйте, jazzer, Вы писали:
P>>Не серьёзно. Допустим мы знаем что в среднем количество элементов — 16 (также много вариантов когда 13,14,15), размер элементов — 16 байт. P>>И куда тут string'и лепить? J>В смысле? Вот в STLport std::string представляет собой статический массив на 16 элементов плюс динамический на сколько угодно.
ну пусть будет в среднем не 16, а 8 или 32.
J>Т.е. делаешь std::string< My16ByteType > — и получаешь то, что надо, не? Если я правильно понял, что такое TempArray, конечно.
На сколько я понял, в TempArray задаётся размер "встроенного" массива как шаблонный параметр. Если размер получается больше, то используется динамический, причём используется что-то типа union/aligned_storage/variant для экономии места.
В std::string же, размер sso никак не регулируется и вообще sso не гарантируется стандартом.
Здравствуйте, Piko, Вы писали:
P>На сколько я понял, в TempArray задаётся размер "встроенного" массива как шаблонный параметр. Если размер получается больше, то используется динамический, причём используется что-то типа union/aligned_storage/variant для экономии места.
ХЗ, из доки это непонятно. В STLport размер SSO прибит гвоздями. Это и хорошо, и плохо. Если это параметр — мы получаем гибкость, если прибит гвоздями — совместимость типов.
P>В std::string же, размер sso никак не регулируется и вообще sso не гарантируется стандартом.
Ну так я ж сразу сказал, что в некоторых реализациях, а не во всех.
PS Мы тоже для этой цели свой лисапед используем.
PPS Он предлагался в буст под именем AutoBuffer
Здравствуйте, jazzer, Вы писали:
P>>На сколько я понял, в TempArray задаётся размер "встроенного" массива как шаблонный параметр. Если размер получается больше, то используется динамический, причём используется что-то типа union/aligned_storage/variant для экономии места. J>ХЗ, из доки это непонятно. В STLport размер SSO прибит гвоздями.
template <class T,ulen StackLen>
class TempArray : NoCopy
...
J>Это и хорошо, и плохо. Если это параметр — мы получаем гибкость, если прибит гвоздями — совместимость типов.
для строк важна совместимость, для TempArray-like — производительность.
P>>В std::string же, размер sso никак не регулируется и вообще sso не гарантируется стандартом. J>Ну так я ж сразу сказал, что в некоторых реализациях, а не во всех.
ну да — поэтому лучше свой лисапед на несколько сот строк и тесты.
J>PS Мы тоже для этой цели свой лисапед используем.
аналогично
J>PPS Он предлагался в буст под именем AutoBuffer
Супер. кстати, в открытой библиотеке фейсбука есть своя вариация на эту тему
Здравствуйте, Piko, Вы писали:
J>>Это и хорошо, и плохо. Если это параметр — мы получаем гибкость, если прибит гвоздями — совместимость типов.
P>для строк важна совместимость, для TempArray-like — производительность.
производительность одинаковая, разница только в гибкости
J>>PPS Он предлагался в буст под именем AutoBuffer
P>Супер. кстати, в открытой библиотеке фейсбука есть своя вариация на эту тему
Здравствуйте, jazzer, Вы писали:
J>>>Это и хорошо, и плохо. Если это параметр — мы получаем гибкость, если прибит гвоздями — совместимость типов. P>>для строк важна совместимость, для TempArray-like — производительность. J>производительность одинаковая, разница только в гибкости
Это как, одинаковая? если мы размер "local"-size задаём параметром — то в каждом отдельном случае мы можем задавать такое значение, при котором в большинстве случаев это будет local, и при этом не будет большого непроизводственного перерасхода.
Иногда это 8, иногда 24, а иногда и все 64 элемента. Если такого параметра нет, и всё прибито гвоздями, то будет больше косвенности — будет медленней.
J>>>PPS Он предлагался в буст под именем AutoBuffer P>>Супер. кстати, в открытой библиотеке фейсбука есть своя вариация на эту тему J>вот прямо сейчас обсуждается, уже под именем varray и hybrid_vector: J>http://thread.gmane.org/gmane.comp.lib.boost.devel/238631
Здравствуйте, Piko, Вы писали:
P>А вообще вопрос то был про производительность, которая по заявлению: P>
P>значительно более быстрые, чем традиционные.
P>Если же ты говоришь что
Ш>>Что вы тут собираетесь сравнивать с чем-то из буста -- я не представляю.
P>Зачем говорить что более быстрые?
Затем, что более быстрые.
При чем здесь буст? Написано одно, а ты читаешь другое. Абберация восприятия.
Есть традиционные списки. Например, в CCore таким будет LinearDList2. В традиционных списках при добавлении нового элемента аллокируется память из кучи, а при удалении
память возвращается обратно. Это довольно накладно. Для борьбы с этим есть несколько подходов. В "компактных" вариантах (CompactList2), память под ноды аллокируется блоками.
Это позволяет аммортизировать затраты на аллокацию памяти. Чтобы избежать резервирования черезмерного количества памяти, в "компактном" списке при удалении узла,
на его место перемещается другой узел. Это позволяет поддерживать количество дополнительной памяти в фиксированных пределах. Недостаток такого подхода -- перемещение узлов
при удалении. В STL требованиях на список это запрещено, поэтому в STL списках подобная техника использована быть не может.
Что касается традиционных списков -- то их быстродействие во всех разумных реализациях из любых библиотек будет одинаково. Просто потому что эти реализации
отличаются не столько внутренней механикой, сколько оформлением.