@dlangru

Страница 450 из 719
 
Stanislav
11.03.2018
17:54:57
щас ковырнем, спасибо ?

 
да, то что надо, спасибо еще раз!

 
Denis
11.03.2018
18:04:52
немного вклинюсь не в ту сторону. ковыряю немного vibe-core. примеров встроенных чет мало. вайбовский TCPConnection чет разочаровал. (или я неправильно его готовлю) делаю так: void test_collback( TCPConnection c ) { try { if( !c.empty && c.connected ) { ubyte[] buf; c.read( buf ); } и он не заполняет динамический массив. если массив фиксированного размера создать - то всё ок - заполняет. но если его размер больше чем есть данных в сокете - ждет ? я думал он может все данные которые были пропушены (tcp flag PSH) может как-то отдать сразу. но пока чет не выходит каменный цветок. еще и сайт вайбда сломался походу
так и должно быть, имхо. оно предназначено для заполнения структур

 
Dmitry
11.03.2018
18:05:13
А само ядро ОС в один поток работает?
Оно многопоточное

Google
 
Dmitry
11.03.2018
18:06:11
Я имел ввиду, что переключается либо по переходу в ждущее состояние потока, либо по таймауту
Обычные потоки и процессы ОС так и делают. Так что это все еще к вытесняющей относится.

 
Dark
11.03.2018
18:06:57
Оно многопоточное
Если его можно вытеснить, то да

 
Обычные потоки и процессы ОС так и делают. Так что это все еще к вытесняющей относится.
Мне это известно

 
Stanislav
11.03.2018
18:13:28
так и должно быть, имхо. оно предназначено для заполнения структур
интересное замечание. надо попробовать сразу заполнить таким образом структуру) но это если вся структура имеет фиксированный размер, а если там всякие опциональные параметры, то уже не получится, так как неизвестен конечный размер датаграммы. в этом случае проще прочитать все данные в ubyte[] и дальше его парсить

 
Denis
11.03.2018
18:14:35
интересное замечание. надо попробовать сразу заполнить таким образом структуру) но это если вся структура имеет фиксированный размер, а если там всякие опциональные параметры, то уже не получится, так как неизвестен конечный размер датаграммы. в этом случае проще прочитать все данные в ubyte[] и дальше его парсить
Структура всегда имеет фиксированный размер

 
Stanislav
11.03.2018
18:17:10
структура да, но сам сетевой пакет может быть с опциональными полями всякими.

 
Evgeny
11.03.2018
18:19:10
для такого полезны всякие сериализации, вроде MessagePack

 
Pavel
11.03.2018
18:27:50
щас ковырнем, спасибо ?
Используй peek

 
Stanislav
11.03.2018
18:34:51
Используй peek
о, прям то что хотел, спасибо ? но вариант с read и структурами тож щас напишу, посмотрю как красивее в итоге получится.

 
Pavel
11.03.2018
19:17:21
Только что весьма отвратно - в TCPCOnnection захардкожен буфер 4кб и увеличить его никак нельзя

 
Denis
12.03.2018
02:28:12
структура да, но сам сетевой пакет может быть с опциональными полями всякими.
если правильно разбить такой пакет на несколько структур то всё будет ок же?

 
Stanislav
12.03.2018
02:36:33
Да, но тогда код парсинга будет в месте где чтение. Пока склоняюсь чтобы парсинг внутри класса спрятать. Там просто нетривиальный парсинг. В хедере пакета указывается тип сообщения. Там внутри всякие капабилити, которые могут быть, а могут и не быть. И дальше ещё опциональные поля всякие.

 
Denis
12.03.2018
02:37:31
> Да, но тогда код парсинга будет в месте где чтение Не обязательно, можно исхитриться чтобы так не было

Google
 
Denis
12.03.2018
02:37:52
коллбэки

 
Pavel
12.03.2018
09:29:42
Классы работают сильно медленнее структур, так что имеет смысл структурой парсить

 
Evgeny
12.03.2018
09:54:43
Эм, что значит классы медленнее структур? Имеются в виду виртуальные методы?

 
Denis
12.03.2018
09:58:46
вообще всё медленнее. структуры бесплатные, классы создаются на куче и наследуются ещё иногда

 
Maxim
12.03.2018
10:01:51
ну, т.е. накладные расходы на создание и на вызовы виртуальных методов?

 
Denis
12.03.2018
10:04:26
на создание экземпляра даже

 
Stanislav
12.03.2018
10:06:25
я думал классы от структур отличаются только конструктором и наследованием. надо еще раз книжку александреску всё-таки перечитать.

 
Maxim
12.03.2018
10:08:21
на создание экземпляра даже
собственно, я про это и говорю: создание и вызов виртуального метода

 
final методы, вроде, как и в C++ работают, не?

 
Pavel
12.03.2018
10:10:12
c++ может девиртуализировать всё что возможно

 
Denis
12.03.2018
10:11:10
final методы, вроде, как и в C++ работают, не?
их там не было вроде раньше

 
Maxim
12.03.2018
10:13:36
вроде с C++11 были)

 
Pavel
12.03.2018
10:18:17
Кто-нибудь может сказать, есть ли весомые преимущества D перед Nim, или наоборот?

 
Maxim
12.03.2018
10:22:44
зависит от стуации, наверное

 
Pavel
12.03.2018
10:23:22
Мне показалось, они играют на одном поле.

 
Maxim
12.03.2018
10:24:18
nim — это некая вундервафля, которая генерит код на C, C++, Obj C или javascript, а потом это всё компилируется

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

 
Pavel
12.03.2018
10:24:53
Это делается за один вызов транслятора. Я уже попробовал.

 
Maxim
12.03.2018
10:25:16
hello world под винду сколько весит?)

 
Pavel
12.03.2018
10:25:29
~100 кб

Google
 
Pavel
12.03.2018
10:26:33
mingw бекенд

 
Maxim
12.03.2018
10:27:15
ну так-то в идеале nim должен компилироваться на любой платформе, где есть Си

 
Dark
12.03.2018
10:27:45
Nim вообще создало у меня впечатление языка разметки :D

 
NullSanya
12.03.2018
10:28:13
а еще там есть макросы, но чет я в него не смог

 
Maxim
12.03.2018
10:30:44
что-то я с ходу даже базовые типы в nim нагуглить не могу

 
Pavel
12.03.2018
10:31:17
https://nim-lang.org/docs/tut1.html#basic-types

 
Maxim
12.03.2018
10:32:22
что-то про битность не написано ничего)

 
наследует ли nim все прелести Си, и что будет, если на 16-битной системе использовать int64?

 
Pavel
12.03.2018
10:34:26
кто его знает

 
Evgeny
12.03.2018
10:36:46
вообще всё медленнее. структуры бесплатные, классы создаются на куче и наследуются ещё иногда
final-методы такие же быстрые, как и методы структур, классы можно создавать на стеке, а структуры на куче.

 
Кто-нибудь может сказать, есть ли весомые преимущества D перед Nim, или наоборот?
Nim совсем сырой. Остальное дело вкуса.

 
Denis
12.03.2018
10:40:40
сырее ди, причём

 
Pavel
12.03.2018
10:41:37
Nim совсем сырой. Остальное дело вкуса.
Вот это интересовало больше всего.

 
Dmitry
12.03.2018
11:13:52
У меня пол года назад он даже не завелся

 
Dark
12.03.2018
11:14:38
Ну может сейчас заведется, но нужна ли помесь D с питоном?

 
NullSanya
12.03.2018
11:19:37
У меня пол года назад он даже не завелся
совсем?

 
просто я года 2 назад пробовал

 
вроде работал

 
Dmitry
12.03.2018
11:20:33
Да я не помню что было, но вроде даже известный баг. В итоге я забил на него.

 
NullSanya
12.03.2018
11:21:16
ну я забил из-за того, что с инструментами было хуже, чем в ди

Google
 
NullSanya
12.03.2018
11:21:34
а на то время был mono-d, хорошая штука

 
Dmitry
12.03.2018
11:21:48
Да и там дикая мешанина концепций. Понадергали всего. Зачем то регистрозависимость убрали. Странное решение для языка программирования.

 
Pavel
12.03.2018
11:25:56
final-методы такие же быстрые, как и методы структур, классы можно создавать на стеке, а структуры на куче.
Можно только зачем? Делать методы final и создавать на стеке вместо того чтобы использовать структуру?

 
Maxim
12.03.2018
11:27:06
если наследование не нужно, то в принципе нет смысла использовать классы)

 
Igor
12.03.2018
11:33:53
ну есть еще разница в виде семантики ссылка/значение

 
Maxim
12.03.2018
11:36:24
структуры тоже можно по ссылке передавать, если нужно)

 
NullSanya
12.03.2018
11:37:32
структуры тоже можно по ссылке передавать, если нужно)
лишние 3 буквы писать

 
Pavel
12.03.2018
11:38:10
Ладно можно не перечислять в сотый раз чем структура отличается от класса, просто факт классы без допиливаний и извратов намного медленнее

 
Maxim
12.03.2018
11:38:47
при создании и вызове виртуальных функций)

 
в остальном они такие же быстрые, как структуры, и передаются по ссылке по умолчанию)

Admin
ERROR: S client not available

 
Pavel
12.03.2018
11:41:52
Так я писал точно такой же парсер протокола через TCP. Самая первая версия когда я еще фактически только начинал на D писать была на структурах. Потом мне не понравилось что нельзя сделать общего предка у структур и выделить туда общее поведение. Я переделал на классы. Потом я измерил производительность и оказалось что классы чуть ли не в 100 раз медленее. Переделал обратно на структуры.

 
Потом приделал к ним статическую проверку интерфейса, а общий код вынес в миксин. Но оставалась еще одна проблема - в структуре добавились новые поля которые не надо было сериализовать. Это я решил созданием в структуре вложенной структуры :)

 
Maxim
12.03.2018
11:48:56
если на каждый запрос создавать по объекту, то, конечно, проблемы будут)

 
но в сложной логике в любом случае трудно обойтись без наследования)

 
Pavel
12.03.2018
12:12:38
В моем случае на каждый запрос помимо объекта TcpSocket создавался еще объект треда и десяток объектов пакетов.

 
Ну а 10 структур создать вообще не жалко.

 
Maxim
12.03.2018
12:16:33
наверняка еще быстрее было бы прочитать в ubyte[] и потом распарсить через указатели)

 
Pavel
12.03.2018
12:19:04
А я и так это делаю. Поскольку там есть данные длина которых передается через сокет же, то нельзя просто так взять и считать фиксированный кусок данных в структуру

 
Где-то читаю байт длины, потом создаю буфер через ubyte[] buf = new ubyte[length]

Google
 
Pavel
12.03.2018
12:20:58
Но эта ужасная аллокация впринципе тоже решаема, можно в структуру добавить поле ubyte[255], да структура сразу увеличится в размере на 255 байт, но зато аллокаций не будет :)

 
Maxim
12.03.2018
12:21:15
логичнее было бы тогда по размеру узнавать, что за структуру передают, и потом уже в нее читать из сокета, не?)

 
Pavel
12.03.2018
12:22:19
Там переменная длина от 1 до 255

 
Может быть любая. Но в подавляющем большинстве случаев это 1-2-3 байта всегда

 
Maxim
12.03.2018
12:23:16
тогда я не понимаю, зачем это разруливать структурами вообще)

 
Dark
12.03.2018
12:24:40
Желание поизвращаться?

 
Pavel
12.03.2018
12:24:53
А как это разруливать?

 
Maxim
12.03.2018
12:25:06
зависит от ситуации)

 
Pavel
12.03.2018
12:25:16
Ну вот в моем случае стурктура оптимальна

 
Maxim
12.03.2018
12:25:35
это ты про socks5?)

 
Pavel
12.03.2018
12:25:41
да

 
Maxim
12.03.2018
12:25:57
ну это я не знаю, прокси не делал)

 
на уровне клиента разруливал всё буферами байтов)

 
Pavel
12.03.2018
12:26:21
Она легковесная и дает хорошую инкапсуляцию логики для каждого пакета.

 
Igor
12.03.2018
12:46:14
Но эта ужасная аллокация впринципе тоже решаема, можно в структуру добавить поле ubyte[255], да структура сразу увеличится в размере на 255 байт, но зато аллокаций не будет :)
я это решаю читая в иммутабельный буфер и потом создавая над ним нужные слайсы

 
Pavel
12.03.2018
12:47:56
Ну то есть это то же поле фиксированного размера у структуры как бы

 
Igor
12.03.2018
12:51:13
типа того, да

 
Pavel
12.03.2018
12:54:09
Кстати лол-прикол. У Thread есть поле name которое в документации описано как поле через которое можно читать и устанавливать название треду. Но если заглянуть в исходники то это просто сеттер для свойства m_name и он ничего не делает ;)

 
Dmitry
12.03.2018
13:00:18
Еще каменить в огород Python. На больших проектах его отладка превращается в какой-то ад. Невозможно внести изменение не сломав чего-то. И отловить ошибку крайне сложно. В этом плане на Ди хоть и дольше писать, но зато поддерживать код куда проще. Сейчас в проекте 60 тыс строк кода на Python и скорость разработки просто дико медленная т.к. вылезают очень трудноуловимые ошибки.

 
Pavel
12.03.2018
13:01:11
Надо типизацию везде где можно + юнит тесты

 
А 60 тыс. строк на D думаешь будет проще? =)

 
Уж тут ошибки - всем ошибкам ошибки. Утечет что-нибудь и все, гроб-гроб-кладбище.

Страница 450 из 719