Про API

[cd_riper]

Евгений Кирпичев затронул тему, о которой рано или поздно задумывается любой мало-мальски опытный программист -- тему о том, должен ли быть доступ к относительно низкоуровневым вещам в объектно-ориентированном стиле

Comments

[usovalx]

> Неужели случится что-то страшное, если к функции socket() добавить еще функцию socket_ipv6()?

И заодно socket_local, socket_ipx, ... (man 2 socket). Много их.

[cd_riper]

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

[blueher]

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

[blueher]

> Но есть и другая сторона проблемы.
> Си это стандарт де-факто в огромном числе случаев.

IMHO никто не мешает делать типизированые API даже на чистом C
Делать API нетипизированым это скорее одна из тех вещей которую все делают "по инерции".

[blueher]

Кстати, в сторону типизации API потихоньку движутся - к примеру в WinAPI появились типизированые хэндлы что уже неплохо.

[waqur]

Одно из преимуществ Win32 API перед UNIX - это как раз то, что хендлы не типизированы

И следовательно такие функции как WaitForMultipleObjects могут ждать одновременно событий на пачке сетевых сокетов, OVERLAPPED файловых хендлов и нескольких семафорах, а можно ещё и завершения нескольких тредов/процессов там же подождать. Из всех этих объектов, кто первый "выстрелит", тот и разбудит спящий поток.

Юниксу ещё сто лет говном плыть до такого. Только в Linux есть нормальный epoll(), возможность ждать в нём файлы, возможность как-то подогнать под него семафоры - eventfd(), правда над ожиданием процессов и тредов в общем пакете красноглазики ещё работают.

А вот стандартные для юниксов POSIX threads и ихние местные мутексы/семафоры, не говоря уже про такое страхопадло как семафоры из SysV IPC, никак не натягиваются на poll/select/epoll/eselect и другие функции пакетного ожидания.

[cd_riper]

> это как раз то, что хендлы не типизированы

типизация она разная бывает.
можно сделать Handle.
а потом FileHandle : Handle и MutexHandle : Handle, ну ты понял :)

[waqur]

Да, исключения и динамически распределяемая память не должны пересекать границы модулей (DLLек). В этом смысле в винде (Win32 API) всё правильно сделано.

Классы, возвращаемые из функций смарт-указатели, исключения - всё это должно линковаться строго статически. Или иметь сишный экспортный интерфейс и двойные обёртки - при экспорте с C++ на С, при импорте - обратно.

[waqur]

M$, кстати, пр*ебала отличную возможность стандартизировать C++ный ABI (те же исключения, операции с кучей) при переходе на 64 бита, так же, как они в своё время стандартизировали Сишный ABI при переходе на Win32 - предлагаю вспомнить такие прелести DOS'а как calling convention (C/Pascal/...) и memory model (Small/Compact/.../Large/Huge).