Задать вопрос
Qubc
@Qubc
Ненавижу полисемию.

(Вопрос без однозначного ответа) Почему в window socket 2 используется так много различных дефайнов и псевдонимов?

Прошу сильно не пинать, понимаю, что вопрос немного нарушает правила тостера.
Но просто интересно - а зачем так много различных макросов и типов? Почему обычных стандартных типов было недостаточно? Для чего создаватьtypedef struct addrinfo{}? Только ради того, чтобы не писать struct в Си? Для чего определять *PADDRINFOA; -только ради того, чтобы не писать * ? И главное - всё идёт вперемешку. Где-то спокойно используется int, а где-то используетсяtypedef unsigned __int64 UINT_PTR, опять же вместо того, чтобы просто писать unsigned __int64.
Разве это удобно?
  • Вопрос задан
  • 118 просмотров
Подписаться 1 Простой Комментировать
Решения вопроса 3
@Wexter
Какой смысл задавать вопросы к причинам существования древнего легаси? Написал когда-то студент за миску риса, с тех пор и кочует для обратной совместимости
Ответ написан
Комментировать
mayton2019
@mayton2019
Bigdata Engineer
Я тоже до конца не понимаю цели и задачи которые ставились для winsock2 но вот можно
почитать аннотацию здесь https://learn.microsoft.com/en-us/windows/win32/wi...

С моей точки зрения было время большого разлада между лагерем Microsoft и Unix. И вместо того
чтобы просто позаимстовать сетевые библиотеки или купить лицензии, MS как всегда стал делать
что-то свое, "сумчатое" и ни на что не похожее. Яркий пример Component-Object Model (COM).
Нигде такого нет.

Для чего создаватьtypedef struct addrinfo{}? Только ради того, чтобы не писать struct в Си?

Да все верно. Именно для такого юзкейса typedef и создавался. Плюс еще можно примитивы определять.

Для чего определять *PADDRINFOA

Вот здесь не знаю для чего. Хотя подобный подход я видел не только у Microsoft но и у других.
Вообще иногда мы не догадываемся но код может быть сгенерирован кросс-компилляторами
и в этом случае названия идентификаторов могут быть очень длинными и причудливыми.
А удаление звездочки из синтаксиса сужает возможности разработчика тоесть не дает
допустить ошибку. Такая себе строгая типизация в квадарате.

Где-то спокойно используется int, а где-то используетсяtypedef unsigned __int64 UINT_PTR, опять же вместо того, чтобы просто писать unsigned __int64.

Это очень старый технический долг языка С++ и его уже нельзя исправить. Дело в том
что спецификация языка не объясняет какой разрядности должен быть int. Он может быть
16, 32 бит в зависимости от целевого железа. По сути он - синоним регистра процессора.
И когда мы делаем цикл от 1 до 10 и нам по сути неважна разрядность параметра цикла - мы просто заказываем
int чтоб долго не думать. И компиллятор собирает очень быстрый и оптимальный код.
sizeof(int), или константы в в limits.h могут дать подсказку по вашей текущей архитектуре.

typedef unsigned __int64 UINT_PTR

Здесь идет форсирование разрядности в 64 бита. Такие потребности возникают
в момент когда у нас есть например жестко заданный формат (сетевой протокол
или дисковый формат файла) и мы должны гарантировать что другие архитектуры
микрокотноллеры, мобилы и прочее правильно смогут интерпретировать эту структуру.
Тут еще и порядок байтов внутри слова тоже важен. В наше время даже есть сет
стандартов на описание таких структур ASN, AVRO, Protobuf, Thrift.
Ответ написан
Видимо разработчикам из MS действительно было удобно такое выкатить.
А может и для обратной совместимости что-то.
Если не устраивает - ты всегда можешь написать свою библиотеку, которая будет это оборачивать.
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы