- 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");
}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+75
byte[] buf = new byte[8192];
int len = 0;
while ((len = is.read(buf))>0)
{
requestString += new String(buf, 0, len, "UTF-8");
}
Пока никто не кормил туда настоящий UTF-8. Только ascii.
someone 28.05.2012 14:13 # 0
konsoletyper 28.05.2012 14:30 # 0
Steve_Brown 28.05.2012 14:24 # +2
konsoletyper 28.05.2012 14:27 # 0
Steve_Brown 28.05.2012 14:36 # +3
bormand 28.05.2012 16:03 # +1
bormand 28.05.2012 16:10 # 0
Он бы всяко забыл про то, что следует игнорить символы, записанные не самым кратким образом. Например если 0x0A записали в виде двух-трех байт.
konsoletyper 28.05.2012 14:31 # 0
vistefan 28.05.2012 16:10 # −1
roman-kashitsyn 28.05.2012 16:13 # +3
vistefan 28.05.2012 16:15 # 0
bormand 28.05.2012 16:22 # +1
konsoletyper 28.05.2012 16:58 # +3
roman-kashitsyn 28.05.2012 17:12 # +4
завёл структуру
ввёл бы несколько функций append_to() работает очень просто: складывает символы в массив, обновляя значение tail. Когда кончается место (tail + len> capacity) - реаллочит массив, увеличивая размер в полтора-два раза.
bormand 28.05.2012 17:42 # +1
Только в интерфейсе модуля были еще buffer_free и buffer_size.
P.S. А тот вариант который я писал выше (про стек) он для языков с GC (в частности в Lua так реализована склейка строк).
defecate-plusplus 28.05.2012 17:56 # −2
roman-kashitsyn 28.05.2012 18:01 # 0
someone 28.05.2012 18:53 # +3
(Кстати, о GObject: в GLib есть GString, который в Vala замаплен под именем - да-да, StringBuilder. И реализован он именно так.)
defecate-plusplus 28.05.2012 19:30 # +4
кстати о именно так - именно так реализовано много чего, от std::vector до, ты не поверишь, std::string, обычно лежащего в основе да-да, std::stringbuf
и не удивлюсь, если эта незатейливая идея, которую С предлагает изобрести ручками каждый раз заново, именно так реализована в библиотеках еще кучи языков
Steve_Brown 29.05.2012 09:58 # +1
Любопытно, кстати, в Qt реализовано: поначалу выделяются степени двойки (минус константа), а при достижении размера около 4080 байт рост дальше идет линейно, размер увеличивается шагами в 4096 байт. Объясняется это тем, что при realloc-е система просто перемапливает старые страницы, а не копирует байты, поэтому наращивание массива происходит очень быстро.
TarasB 29.05.2012 10:00 # 0
Кстати, как realloc подружить с конструктором сдвига?
defecate-plusplus 29.05.2012 10:16 # 0
но Qt видней, конечно
guest 29.05.2012 12:20 # 0
POD'ы быстро и грязно, а классы как положено.
guest 29.05.2012 12:25 # 0
defecate-plusplus 29.05.2012 12:43 # 0
1) это должно быть через специализации сделано, а не отдано на откуп компиляторной оптимизации if (0) stmt1; else stmt2; --> stmt2;
2) размер в байтах на сколько надо вырасти известен аллокатору, не нужно подсовывать никаких sizeOfTypedData() и sizeof(T)
как всегда Qt блещет вылизанностью, не то, что мерзкий стандарт для лохов, ага
bormand 29.05.2012 15:46 # 0
Т.е. вы предлагаете растащить специализации, сосредоточенные в QTypeInfo, по всем подряд контейнерам?
defecate-plusplus 29.05.2012 16:53 # +2
в голову приходит лишь объяснение, что Qt мол собралась компилироваться компилятором вообще без поддержки partial specialization
<наброс>а взрослую библиотеку информации по типам можно посмотреть вот тут http://bit.ly/Jyomed </наброс>
bormand 29.05.2012 17:01 # 0
Согласен
Steve_Brown 30.05.2012 10:58 # +1
Точно, некоторые фичи в Qt не используются, потому что не поддерживаются всеми компиляторами.
TarasB 29.05.2012 21:37 # 0
defecate-plusplus 29.05.2012 23:31 # 0
если что и ковырять - так это менеджер кучи, т.е. либо идти в обход того, который реализован в рантайме, либо надстраиваться поверх malloc
что должен делать такой менеджер кучи? на каждый чих сохранять адрес копирующего конструктора для каждого выделяемого пойнтера, либо признак что конструктора нет (== plain old data, достаточно побитового копирования)
что такое кастомный менеджер кучи в понятии С++ - в первом приближении - свой аллокатор, но типичное для stl stateless использование аллокатора печалит и отторгает
тем не менее, myalloc<T>::construct(ptr, T &) и myalloc<T>::destroy(ptr, count) предоставляют понимание какой конкретно тип создается по конкретному указателю, так что можно составлять таблицу типов, привязывать пойнтер к записи в таблице, там искать указатель на копирующий конструктор. как-то так
можно избавить контейнер от не очень то сложных действий in place, зато очень сильно усложнить кастомный менеджер кучи, + наверняка вся эта конструкция будет работать еще и медленнее
выхлоп не тот, всего то ради выбора memcpy/copy(dest, first, last)
вот если в менеджер еще запихать функциональность сборщика мусора и кофеварки, тогда можно и за валидным копированием элементов следить, да
roman-kashitsyn 28.05.2012 14:25 # +2
Lure Of Chaos 29.05.2012 00:21 # 0
rat4 29.05.2012 08:12 # +2