Войти
ПрограммированиеФорумСеть

С++ UDP Какие есть библиотеки? (2 стр)

Страницы: 1 2 3 4 Следующая »
#15
5:49, 18 июня 2020

Zab
> Чем тебе поможет пример, если оно не работает,
а если работает, или у тебя по другому не бывает? Вот я взял ракнет, собрал подключил и всё сразу заработало. Представь до сих пор не одной проблемы.


#16
6:09, 18 июня 2020

Aroch
> а если работает, или у тебя по другому не бывает? Вот я взял ракнет, собрал
> подключил и всё сразу заработало. Представь до сих пор не одной проблемы.
Это говорит только о том, что использовать ты и не начинал. В реальных условиях, а не тесты на двух соседних компах в локальной сети.
Ну, или ты настолько крут, что все уже знаешь.
Большинство же проблем, они не в библиотеке и возможно не в твоем обрамлении к ней, они либо где-то в сети, либо вообще структурно-философские. Но жить в условиях этих проблем придется, выстраивая какие-то компенсирующие механизмы.

Не встречал справочника-учебника, где хотя бы большинство типовых неприятностей было перечислено. Каждый добывает сведения сам, по крохам.

#17
(Правка: 7:45) 7:44, 18 июня 2020

rcsim
>А почему это проблема для С++? Особенно если задача всего-лишь "достаточно посылки бинарных сообщений переменной длинны без каких-либо гарантий".

Си работает с указателями, в си нет конструктора, деструктора, но надобность в них всё так-же есть. В итоге имеем enet_packet_destroy enet_host_create

>Чисто для эстетики есть wrapper-ы типа https://github.com/xairy/enet-plus.
Это не враппер, а идиотизм какой-то.

enet::Event* event = enet.CreateEvent();
delete event;
Зачем вообще нужен такой враппер, если как были указатели так и остались?

#18
8:54, 18 июня 2020

Я такое использую https://github.com/networkprotocol/yojimbo

#19
9:04, 18 июня 2020

Zab
> Большинство же проблем, они не в библиотеке и возможно не в твоем обрамлении к
> ней, они либо где-то в сети, либо вообще структурно-философские. Но жить в
> условиях этих проблем придется, выстраивая какие-то компенсирующие механизмы.
всё это можно решать на уровне выше, а не ковыряясь в реализации библиотек. И прочти уже что автор хотел, ему не нужен движок ммо на 5к+ клиентов, ему нужно банально отправить набор данных по udp. Любая библиотека написанная не васей пупкиным справится с этой задачей без всяких напильников и займет у него это даже если он не в теме и не разу этим не занимался часа три от силы. Больше потратишь на сборку библиотеки как было в момем случае с ракнет под gcc.

#20
10:55, 18 июня 2020

Если человек уже сам пробовал писать свою библиотеку, а потом взял чужую, то проблем нет, разберется, квалификация для лазания по потрохам есть. Или поймет что библиотека дерьмовая и возьмет другую.
Названий мы ему тут накидали, есть из чего выбирать, чтобы совсем уж на левые недоделки не попадаться.
Но может есть настолько хорошая, что можно пользоваться не заглядывая в реализацию?

#21
11:59, 18 июня 2020

samrrr
> Си работает с указателями

А не должен?
Так-то и С++ тоже понимает указатели (как и весь сишный код).
Может тебе джаву надо?

Winapi (да и все универсальные API) к примеру тоже под C написан, и это либо указатели, либо хэндлы
(что примерно то же самое, вид сбоку). И это никого не останавливает юзать Winapi из С++, да хоть из Экселя на VB.

#22
18:17, 18 июня 2020

>А не должен?
>Так-то и С++ тоже понимает указатели (как и весь сишный код).

Реализация либы не должна показывать наружу указатели.
Например, stl контейнеры позволяют ими не пользоваться.
С++ оперирует объектами, и всяких указателей торчать из либы не должно.
Если объект отделим, верни объект.
Если объект неотделим верни хендл/итертор.

А самое весёлое начинается, когда попытаешься мемсетами на структурах пользоваться в C++, рандомные краши непонятно от чего гарантированы!

>Может тебе джаву надо?
Мне бы rust, но вот переписывать игру долго. Вроде теперь physx и графику в него завезли, можно будет попробовать позже.

#23
20:47, 18 июня 2020

samrrr
> Реализация либы не должна показывать наружу указатели.
> и всяких указателей торчать из либы не должно.
Какие-то оккультные тезисы, без аргументов и ссылок на стандарт (С++).

> верни хендл/итертор.
Чем это "лучше" указателей?
Или тем более smart-pointer-ов - тут то хоть можно не "париться" с удалением.

samrrr
> С++ оперирует объектами
С++ оперирует тем, чем ему скажут. Если "не нравится" стрелочка,
сделай дереференс, получишь точку.

samrrr
> Например, stl контейнеры позволяют ими не пользоваться.
stl любые контейнеры позволяют хранить что угодно, и никакого отношения
к догмам о (не)допустимости хранения в них указателей не имеют.

Мне вот кстати интересно, как ты в свете своей религии в N разных контейнерах
хранишь один объект, или ворочаешь туда-сюда объекты размерами в мега/гига байты?
Или используешь их за пределами скопа {}?

Если у программиста
> рандомные краши непонятно от чего
это точно не от указателей.

#24
23:37, 18 июня 2020

>Какие-то оккультные тезисы, без аргументов и ссылок на стандарт (С++).
Причём тут стандарт, я утверждаю, что у хоошей либы не требуется работать с указателями.

>Чем это "лучше" указателей?
>Или тем более smart-pointer-ов - тут то хоть можно не "париться" с удалением.
Тем, что хэндлом залезть куда не надо не получится.
Пусть хоть weak_ptr вернёт, но не указатель. указатель слишком опасен, неясно сколько он ещё будет жить...

>С++ оперирует тем, чем ему скажут. Если "не нравится" стрелочка,
>сделай дереференс, получишь точку.
https://en.cppreference.com/w/cpp/language/object
А в стандарте написано что только объектами.
Дело не в стрелочке, а в голых указателях.

>stl любые контейнеры позволяют хранить что угодно, и никакого отношения
>к догмам о (не)допустимости хранения в них указателей не имеют.
Я не против указателей внутри какой-то либы, я против того, чтобы они торчали из интерфейса.

>Мне вот кстати интересно, как ты в свете своей религии в N разных контейнерах
>хранишь один объект, или ворочаешь туда-сюда объекты размерами в мега/гига байты?
>Или используешь их за пределами скопа {}?
Мне пока только в 1 месте(в аллкаторе GPU) пришлось делать ссылки на объекты из другого контейнера.
Итого у меня вектор и 2 хеш-таблицы.
В таблице храню индекс из вектора. Из вектора же ссылки на ключи хеш-таблиц есть изначально(по архитектуре аллокатора).
И вообще объект размером в мегабайт это уже очень подозрительно.

>Если у программиста
>> рандомные краши непонятно от чего
>это точно не от указателей.
Хмм а от чего тогда? Вот я использую контейнеры, shared_ptr, weak_ptr.
Многопоточность по принципу двойного буфера и swap его происходит в тот момент, когда я останавливаю все потоки, кроме свапающего. Все данные чётко разделены по потокам. Голые указатели отсутствуют впринципе(.data() для опенжл, но это пару мест, которые я проверил не раз). Все сохраняемые ссылки только если класс содержится внутри другого класса(то есть он умрёт раньше чем эта ссылка). Объекты, которые живут вечно, просто доступны отовсюду.

И как в таком случае можно получить рандомные краши? За исключением ошибки в какой-то либе.
Выход за пределы массива? Невозможно, его отловит проверка в std.
Memory corrupt от невалидного указателя? Не получится, указателей то нет. А ссылки все только на предыдущий уровень.
Ассемблерных вставок нету.
Поменять контейнер внутри цикла? Такого я не делаю, да и итераторы покажут, что пошло что-то не-так сразу.

#25
0:28, 19 июня 2020

samrrr
> Тем, что хэндлом залезть куда не надо не получится.
Что значит "куда не надо"? У тебя руки неподконтрольны мозгу?
Есть API. Ему и следуй.

При этом указатели всё-таки (обычно) типизированные в отличии от хэндлов.
Кроме того, для хэндла нужна еще какая то функция-оператор.
А по указателю ты сразу можешь модифицировать (если надо) нужные члены структуры.

samrrr
> Мне пока только в 1 месте пришлось делать ссылки на объекты из
> другого контейнера.
Ну как появится соотв. опыт, может ты и пересмотришь свои догмы.

samrrr
> И вообще объект размером в мегабайт это уже очень подозрительно.
Медиафайл/поток в памяти. Вектор медиафайлов как один объект. Да мало-ли.

samrrr
> А в стандарте написано что только объектами.
- В приведенном тексте нет и намёка на слово "только".
- Приведенный текст нет является стандартом.
- Приведенный текст является разделом help-а по теме "Objects in C++".
Удивительно, если бы там писали например про приоритет операций или те же указатели.

Что совсем смешно, первый же пример на этой странице создает объект и возвращает указатель на него: X *MakeX().

#26
9:28, 19 июня 2020

samrrr

> Пусть хоть weak_ptr вернёт
Шаблоны из библиотеки возвращать - это вообще самая плохая идея из возможных.

#27
13:02, 19 июня 2020

rcsim
>Что значит "куда не надо"? У тебя руки неподконтрольны мозгу?
Есть API. Ему и следуй.
В идеальном мире программисты не делают ошибок. В идеальном, но не в нашем.

>При этом указатели всё-таки (обычно) типизированные в отличии от хэндлов.
Мои типизированные:

class H{
  int gen;
  int i;
};

>Кроме того, для хэндла нужна еще какая то функция-оператор.
>А по указателю ты сразу можешь модифицировать (если надо) нужные члены структуры.
Чем-то приходится жертвовать.

>Медиафайл/поток в памяти. Вектор медиафайлов как один объект. Да мало-ли.
Конструктор перемещения поможет.

>- В приведенном тексте нет и намёка на слово "только".
int - обект
класс - обект
>- Приведенный текст нет является стандартом.
>- Приведенный текст является разделом help-а по теме "Objects in C++".
Если cppreference не нравится то можно покопаться в этом документе на 54 странице.
https://isocpp.org/files/papers/N4860.pdf
Там есть ну очень похожий текст.

>Удивительно, если бы там писали например про приоритет операций или те же указатели.
Пишут:
https://en.cppreference.com/w/cpp/language/operator_precedence
https://en.cppreference.com/w/cpp/language/pointer

>Что совсем смешно, первый же пример на этой странице создает объект и возвращает указатель на него: X *MakeX().
Увы из самого языка указатели не выпилить. А вот обойтись без них вполне возможно.

В стандарте вряд ли когда-нибудь напишут что указатели deprecated, так как все реализации векторов, смарт соинтеров, итд используют внутри указатели. Но это не повод пользоваться ими в своём коде.

#28
13:03, 19 июня 2020

Ghost2
>Шаблоны из библиотеки возвращать - это вообще самая плохая идея из возможных.
С чего вдруг?

#29
14:07, 19 июня 2020

samrrr
> Пишут:
Ну да, в другом разделе.

samrrr
> В идеальном мире программисты не делают ошибок. В идеальном, но не в нашем.
В моём мире, программисты пользуются дебаггером, попробуй как нибудь.
Даже если крэш внутри чужого кода, всегда можно увидеть, что к этому привело.

Мне вообще странно это слышать, ты придумал (или скорее бездумно вычитал где-то) какие-то
свои представления что "указатели = плохо". Причём единственный аргумент - это то
что у тебя рандомно "что-то" крэшится, что как-бы говорит о твоих способностях отловить
ошибку.

Не осилил указатели - зачем тебе язык с низкоуровневыми возможностями (C/C++)?
Иди в джаву или похапэ, я реально знаю людей, проработавших там лет 5, и понятия не
имеющих как там запустить отладчик, но зато у них есть "заповеди".

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумСеть