Вопрос такой. Почему запись в файлы есть в std, а вот сетевых операций никаких нет?
Можно сказать что сеть нельзя представить в виде простых функций. Однако же и работа с диском, по большому счету, тоже достаточно сложная вещь и std все не охватывает.
Что мешало хотя бы для tcp добавить поддержку в std?
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой. Почему запись в файлы есть в std, а вот сетевых операций никаких нет?
S>Можно сказать что сеть нельзя представить в виде простых функций. Однако же и работа с диском, по большому счету, тоже достаточно сложная вещь и std все не охватывает.
S>Что мешало хотя бы для tcp добавить поддержку в std?
Как по мне, то и файловый ввод-вывод тоже не стоило тащить в стандартную библиотеку. Я думаю, это сделали скорее по историческим соображениям и совместимости с С. Вот именно потому, что все это вещи сложные и у разных программ могут быть разные требования по детальности, по кроссплатформенности и пр, я считаю, что весь такой сервис лучше иметь в виде внешних библиотек из которых можно выбрать ту, которая наилучшим образом соответствует решаемой задаче. Вообще я сторонник более строгого разграничения — язык — это язык, прикладная область — это прикладная область.
P.S. Нужны сетевые операции — boost::asio в помощь.
S>Вопрос такой. Почему запись в файлы есть в std, а вот сетевых операций никаких нет? S>Можно сказать что сеть нельзя представить в виде простых функций. Однако же и работа с диском, по большому счету, тоже достаточно сложная вещь и std все не охватывает.
Ты не с дисколм работаешь, а с файловой системой. Которая может быть и не на дисках.
Файловые системы имеют гораздо большую историю, чем сети. S>Что мешало хотя бы для tcp добавить поддержку в std?
В последующих версиях стандарта добавят на основе boost.asio
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
С другой стороны, кто сказал, что сеть будет в ближайшие например 40 лет на всё тех же основах? Если придолбаться, там сколько проблем дизайна, что ну его нафиг.
А верхняя прослойка, которая всё упрощает, ещё больше всё испортит.
S>Можно сказать что сеть нельзя представить в виде простых функций. Однако же и работа с диском, по большому счету, тоже достаточно сложная вещь и std все не охватывает.
Так и там только самое тупое и кривое. Где, например, хотя бы простое асинхронное чтение?
S>Что мешало хотя бы для tcp добавить поддержку в std?
Здравствуйте, rg45, Вы писали:
R>Как по мне, то и файловый ввод-вывод тоже не стоило тащить в стандартную библиотеку. Я думаю, это сделали скорее по историческим соображениям и совместимости с С. Вот именно потому, что все это вещи сложные и у разных программ могут быть разные требования по детальности, по кроссплатформенности и пр, я считаю, что весь такой сервис лучше иметь в виде внешних библиотек из которых можно выбрать ту, которая наилучшим образом соответствует решаемой задаче. Вообще я сторонник более строгого разграничения — язык — это язык, прикладная область — это прикладная область.
С одной стороны конечно всё верно и не поспоришь. Может быть по этому и нет стандартов, потому-что их просто не было на момент создания стандартной библиотеки. Были зоопарки разных файловых систем и разных сетевых коммуникаций. В Windows свои, в Nix — свои. Даже парадигма работы изменилась: раньше I/O и Сеть были на многие порядки медленнее CPU bound и синхронные интерфейсы были вполне норм. Потом стало всё выравниваться и async понадобился, а его не было ни в каком виде, т.к. опять же sync всех утсраивал. Сейчас, мне кажется, всё устаканилось и можно попробовать еще раз .
С другой стороны, наличие стандартной инфраструктуры задает канву, задает стандартизацию интерфейсов и предотвращает хаос, когда ты не может просто скрестить одну библиотеку с другой, потому что, там разные слои абстракции, банально. В этом, я считаю, плюс хоть какой-то, но стандартной поддержи I/O во всех его проявления.
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой. Почему запись в файлы есть в std, а вот сетевых операций никаких нет?
Потому, что коммитет по стандартизации языка кокетливо делает вид, что он OS-нейтрален, а OS-нейтрального API сети не существует в природе.
S>Можно сказать что сеть нельзя представить в виде простых функций. Однако же и работа с диском, по большому счету, тоже достаточно сложная вещь и std все не охватывает.
Пиши на Go. Там есть сеть прям в стандартной библиотеке, и он кроссплатформенен и весь API стандартной библиотеки тоже вполне себе кроссплатформенен.
Здравствуйте, Pzz, Вы писали:
S>>Вопрос такой. Почему запись в файлы есть в std, а вот сетевых операций никаких нет? Pzz>Потому, что коммитет по стандартизации языка кокетливо делает вид, что он OS-нейтрален, а OS-нейтрального API сети не существует в природе.
Здравствуйте, wl., Вы писали:
Pzz>>Потому, что коммитет по стандартизации языка кокетливо делает вид, что он OS-нейтрален, а OS-нейтрального API сети не существует в природе.
wl.>А можно поконкретнее? bsd сокеты же есть везде?
Ну, в вендовых достаточно много своей специфики...
Здравствуйте, wl., Вы писали:
S>>>Вопрос такой. Почему запись в файлы есть в std, а вот сетевых операций никаких нет? Pzz>>Потому, что коммитет по стандартизации языка кокетливо делает вид, что он OS-нейтрален, а OS-нейтрального API сети не существует в природе.
wl.>А можно поконкретнее? bsd сокеты же есть везде?
У них масса проблем дизайна, которые не хотелось бы фиксировать ещё на 50 лет вперёд.
Хотя, если интерфейс стиля BSD sockets будет переходником к чему-то исправленному, это ещё терпимо.
Здравствуйте, netch80, Вы писали:
wl.>>А можно поконкретнее? bsd сокеты же есть везде? N>Хотя, если интерфейс стиля BSD sockets будет переходником к чему-то исправленному, это ещё терпимо.
ну да, я это и имел в виду, примерно, как std::thread, на нижнем уровне использует pthreads API, а наверху всё красиво
Медленност и временная непрдесказуемость сетевых операций всегда были аргументом в пользу асинхронного подхода. Тут ничего не поменялось. Соотношение задержек CPU и сети тоже принципиально не поменялось.
Здравствуйте, netch80, Вы писали:
S>>Что мешало хотя бы для tcp добавить поддержку в std? N>Наличие всего что нужно в Boost?
Boost не всегда подходит по лицензии. (Хотя те, для кого это проблема, обычно уже свои велосипеды написали.)
Здравствуйте, Maniacal, Вы писали:
Pzz>>Ну, в вендовых достаточно много своей специфики...
M>Из напрягающих изредка это только, что select не возвращает время, сколько он ждал данных от сокета. В остальном, жить можно.
Он, вроде, и в BSD не возвращает, только в линухе.
Но в венде, если у тебя что-то шибко высоконагруженное и работающее с большим количеством соединений, лучше использовать overlapped I/O с completion port-ом. А значит, не имитацию берклевский сокетов, а нативно-вендовый сетевой API.
Здравствуйте, Pzz, Вы писали:
Pzz>Но в венде, если у тебя что-то шибко высоконагруженное и работающее с большим количеством соединений, лучше использовать overlapped I/O с completion port-ом. А значит, не имитацию берклевский сокетов, а нативно-вендовый сетевой API.
Меня еще на курсах повышения квалификации в направлении кросс-платформенного программирования научили, как в одном сетевом потоке и пуле рабочих запилить полноценный HTTP-север на кучу соединений. Но да, не кросс-платформенный подход всяко побыстрее будет.
Здравствуйте, Maniacal, Вы писали:
M>Меня еще на курсах повышения квалификации в направлении кросс-платформенного программирования научили, как в одном сетевом потоке и пуле рабочих запилить полноценный HTTP-север на кучу соединений. Но да, не кросс-платформенный подход всяко побыстрее будет.
Полноценный — это с HTTP 0.9/1.0/1.1/2.0, многострочными полями в заголовке, connection keep-alive, chunked encoding, с поддержкой TLS, MIME, виртуальных серверов, IDN, HTTP trailers, data streaming-а и т.п.?
Здравствуйте, Pzz, Вы писали:
Pzz>Полноценный — это с HTTP 0.9/1.0/1.1/2.0, многострочными полями в заголовке, connection keep-alive, chunked encoding, с поддержкой TLS, MIME, виртуальных серверов, IDN, HTTP trailers, data streaming-а и т.п.?
Pzz>HTTP — обманчивый протокол. Он выглядит простым.
Не, это я загнул. Домашнее задание было HTTP 1.0 поддержать, если на четвёрку, на пятёрку с поддержкой CGI с проверкой безопасности запросов.
В общем браузер нормально с моим сервером работал. Речь даже не про HTTP больше (там исходников строк 200 всего), а про кучу соединений, обрабатываемых в одном потоке.
. 
