- 1
- 2
- 3
- 4
- 5
- 6
byte[] buf = new byte[8192];
int len = 0;
while ((len = is.read(buf))>0)
{
requestString += new String(buf, 0, len, "UTF-8");
}-
Java / Говнокод #10381
+75
Пока никто не кормил туда настоящий UTF-8. Только ascii.
Запостил:
konsoletyper,
28 Мая 2012
Follow us!
Он бы всяко забыл про то, что следует игнорить символы, записанные не самым кратким образом. Например если 0x0A записали в виде двух-трех байт.
завёл структуру
ввёл бы несколько функций append_to() работает очень просто: складывает символы в массив, обновляя значение tail. Когда кончается место (tail + len> capacity) - реаллочит массив, увеличивая размер в полтора-два раза.
Только в интерфейсе модуля были еще buffer_free и buffer_size.
P.S. А тот вариант который я писал выше (про стек) он для языков с GC (в частности в Lua так реализована склейка строк).
(Кстати, о GObject: в GLib есть GString, который в Vala замаплен под именем - да-да, StringBuilder. И реализован он именно так.)
кстати о именно так - именно так реализовано много чего, от std::vector до, ты не поверишь, std::string, обычно лежащего в основе да-да, std::stringbuf
и не удивлюсь, если эта незатейливая идея, которую С предлагает изобрести ручками каждый раз заново, именно так реализована в библиотеках еще кучи языков
Любопытно, кстати, в Qt реализовано: поначалу выделяются степени двойки (минус константа), а при достижении размера около 4080 байт рост дальше идет линейно, размер увеличивается шагами в 4096 байт. Объясняется это тем, что при realloc-е система просто перемапливает старые страницы, а не копирует байты, поэтому наращивание массива происходит очень быстро.
Кстати, как realloc подружить с конструктором сдвига?
но Qt видней, конечно
POD'ы быстро и грязно, а классы как положено.
1) это должно быть через специализации сделано, а не отдано на откуп компиляторной оптимизации if (0) stmt1; else stmt2; --> stmt2;
2) размер в байтах на сколько надо вырасти известен аллокатору, не нужно подсовывать никаких sizeOfTypedData() и sizeof(T)
как всегда Qt блещет вылизанностью, не то, что мерзкий стандарт для лохов, ага
Т.е. вы предлагаете растащить специализации, сосредоточенные в QTypeInfo, по всем подряд контейнерам?
в голову приходит лишь объяснение, что Qt мол собралась компилироваться компилятором вообще без поддержки partial specialization
<наброс>а взрослую библиотеку информации по типам можно посмотреть вот тут http://bit.ly/Jyomed </наброс>
Согласен
Точно, некоторые фичи в Qt не используются, потому что не поддерживаются всеми компиляторами.
если что и ковырять - так это менеджер кучи, т.е. либо идти в обход того, который реализован в рантайме, либо надстраиваться поверх malloc
что должен делать такой менеджер кучи? на каждый чих сохранять адрес копирующего конструктора для каждого выделяемого пойнтера, либо признак что конструктора нет (== plain old data, достаточно побитового копирования)
что такое кастомный менеджер кучи в понятии С++ - в первом приближении - свой аллокатор, но типичное для stl stateless использование аллокатора печалит и отторгает
тем не менее, myalloc<T>::construct(ptr, T &) и myalloc<T>::destroy(ptr, count) предоставляют понимание какой конкретно тип создается по конкретному указателю, так что можно составлять таблицу типов, привязывать пойнтер к записи в таблице, там искать указатель на копирующий конструктор. как-то так
можно избавить контейнер от не очень то сложных действий in place, зато очень сильно усложнить кастомный менеджер кучи, + наверняка вся эта конструкция будет работать еще и медленнее
выхлоп не тот, всего то ради выбора memcpy/copy(dest, first, last)
вот если в менеджер еще запихать функциональность сборщика мусора и кофеварки, тогда можно и за валидным копированием элементов следить, да