Похоже, что bytes.Buffer и пакет binary

маршал/анмаршал бинарных данных.

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

Типа binary.BigEndian.Read

та может там и liitle endian & mixed

или bcd & gsm7

Конечно. Это просто пример, который не сразу виден в документации

Типа binary.BigEndian.Read

это для числовых то использую binary.LittleEndian.Uint16([]byte(raw)[20:22]),

Там есть Read, который может читать сразу много полей в структуру

Ну и bytes.Buffer тоже поможет

Там есть Read, который может читать сразу много полей в структуру

а вот это я не использую. ща почитаю

А в обратку он умеет?

Write тоже есть

https://golang.org/pkg/encoding/binary/#Read

а, он от пакета пляшет, спс.

https://blog.golang.org/survey2017-results

https://golang.org/pkg/encoding/binary/#Read

со string как я понимаю не полетит? или поймет 0x00 как конец строки?

Не будет работать со строками, скорее всего

Со слайсами байт – будет

со string как я понимаю не полетит? или поймет 0x00 как конец строки?

само по себе не поймет. надо заводить bufio.Reader и на нем запускать ReadBytes

само по себе не поймет. надо заводить bufio.Reader и на нем запускать ReadBytes

Там фикс длинна, так что вполне позовлительно

Но [n]byte как тип человечески к стрингам кажется не приводился к стрингам по моему посдлденему опыту. Пойду попробую еще раз

https://blog.golang.org/survey2017-results

я всё еще ржу насчёт

cannot convert data.Mine (type [3]byte) to type string ?

это не слайс, а массив

cannot convert data.Mine (type [3]byte) to type string ?

string(data.Mine[:]), например

а мог бы дать парню погуглить

а мог бы дать парню погуглить

вот одновременно с этим и прогуглил)

string(data.Mine[:]), например

Спасибо)

а мог бы дать парню погуглить

ну - извините, иногда помогаю людям, я исправлюсь :)

?

-200 строк из кода, хороший вечер)

кстати, @onokonem, мне нужны твои ~мозги~ мысли по одному поводу)

давай

в личку закину, минуту

ок

закинул

народ, а что будет быстрее и правильнее? 1) if strings.HasPrefix('xe') || strings.HasPrefix('ge') || strings.HasPrefix('te') ............... { } 2) регулярка типа ^(xe|ge|te|....) ?

я бы делал, грубо говоря, len(str) >= 2 && str[1] == 'e' && (str[0] == 'x' || str[0] == 'g' || str[0] == 't')

не

но, возможно, за такой код меня уже кто-то ненавидит :))

пример тебя ввел в заблуждение, там совсем не обязательно [1] == 'e' )

любые 2-3 первых символа могут быть, которые необходимо отматчить

до десятка в одном if

но, возможно, за такой код меня уже кто-то ненавидит :))

я бы возненавидел

я бы возненавидел

я такой код документирую и объясняю, почему надо было так :))

Switch по первым двум символам, в case их можно перечислить

народ, а что будет быстрее и правильнее? 1) if strings.HasPrefix('xe') || strings.HasPrefix('ge') || strings.HasPrefix('te') ............... { } 2) регулярка типа ^(xe|ge|te|....) ?

откуда взялся этот вопрос? были замеры, и регулярки оказались медленными? в любом случае, быстрее всего будет, наверное switch str[:2] { case "xe": ... case "ge": ... case "te": ... }

откуда взялся этот вопрос? были замеры, и регулярки оказались медленными? в любом случае, быстрее всего будет, наверное switch str[:2] { case "xe": ... case "ge": ... case "te": ... }

- нет, замеров не было ; решил спросить, что оптимальнее, т.к. неочевидно. - за свитч спасибо, так и сделаю

откуда взялся этот вопрос? были замеры, и регулярки оказались медленными? в любом случае, быстрее всего будет, наверное switch str[:2] { case "xe": ... case "ge": ... case "te": ... }

тоже вариант, если не учитывать то, что str eq не самый быстрый в гошке, тогда уж быстрее byteshash(str[:2]) и в кейсах xeHash etc.

но это не так читаемо

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

да не, не упрусь-то точно

блин

да это ващщщще некритичный участок

просто решил спросить, как оптимальнее :)

Ну, регулярка тут оверкилл страшный

Ну, регулярка тут оверкилл страшный

зато самое удобное

Тоже верно

тоже вариант, если не учитывать то, что str eq не самый быстрый в гошке, тогда уж быстрее byteshash(str[:2]) и в кейсах xeHash etc.

binary.BigEndian.Uint16([]byte(str[:2]))

если кому-то охота упороться

просто решил спросить, как оптимальнее :)

Кстати, всегда можно сделать бенч, если не лень. Заодно попрактиковаться делать бенчи

ну да, вариант

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

binary.BigEndian.Uint16([]byte(str[:2]))

скорее всего, шустрее будет https://godoc.org/github.com/gramework/runtimer#BytesHash :)

строго говоря, там обычный memhash

ERROR: S client not available

но 14 операций + 7 конвертаций - больше, чем 6 конвертаций (которые оптимизируются compile-time) и 11 операций

(ref: runtime/hash64.go#L31, encoding/binary/binary.go#L77-78)

Вопрос обратный возник - как перегнать string в [n]bytes? я сходу ответ ненагуглил

ваиринат с copy не позволяет это почеловечески записать в структуру без временных переменных

[strlen(...)]byte(str)

Как нибудь так

[4]byte("ABCD"),

не летит

Демку сделай

ща

https://play.golang.org/p/rfPHOyi7PJP

ваиринат с copy не позволяет это почеловечески записать в структуру без временных переменных

да ладно? https://play.golang.org/p/gPQJEXH3OSL

в формат header := Header{ Type: [4]byte("ABCD"), } это не ложится, но тоже вариант, спс

блин, Ник

а ты не думал, что обёртку написать можно, например?

Да я сижу переламываю работу с сообщениями на binary.Read. И вылезают вот коллизии, дщумаю как крассивее их собрать

а ты не думал, что обёртку написать можно, например?

Не люблю обертки, особенно если без них можно обойтись. Но тут уже наверно никак(

(а такой красивый был)

сеттеры и геттеры еще с явы вызывают у меня ненависть

https://play.golang.org/p/U32tU1-9jnb

https://play.golang.org/p/U32tU1-9jnb

спс, пойду пилить обертки на поля)

ого

сюрприз для меня

парсю огромный аутпут ; по мере парсинга - всё дико замедляется и тормозит

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

типа result += currentString

(просто мысли вслух :)

Чем конкатенацию заменил в итоге?

а bytes buffer например? или string buffer из 1.10?

Чем конкатенацию заменил в итоге?

lines []string

типа result += currentString

а проверял, что быстрее? контактинация или Sprintf двух строк?

Вопрос обратный возник - как перегнать string в [n]bytes? я сходу ответ ненагуглил

никак. из массива в слайс - пожалуйста, а из слайса в массив - только копированием