Size: a a a

2020 April 17

M

Mxxx in pro.cxx
У меня есть допустим 500 портов для соединений.
Я с помощью bind определяю, какой порт сейчас свободен.
Но после closesocket почему-то целых две минуты проходит, пока на этот порт можно будет прибиндится. Вот это странное поведение
источник

CC

Chris Calvin in pro.cxx
Mxxx
У меня есть допустим 500 портов для соединений.
Я с помощью bind определяю, какой порт сейчас свободен.
Но после closesocket почему-то целых две минуты проходит, пока на этот порт можно будет прибиндится. Вот это странное поведение
SO_REUSEPORT позволит биндить на один порт несколько сокетов и проблемы не будет. Но вообще странное поведение, да.
Как говорил известный человек "Причин может быть множество, а последствия могут быть самые разные"
источник

ES

Egor Suvorov in pro.cxx
А должен ли компилироваться следующий код?
#include <iosfwd>
#include <string>

void foo(std::ostream &os, const std::string &s) {
   os << s;
}

Вот clang и libc++ считают, что компилироваться — да, а линковаться — нет: https://wandbox.org/permlink/0V1jdpPbUFS2tR6I

Это выглядит довольно странно. Если добавить <iostream>, то компилируется и линкуется.

Формально, кажется, <iosfwd> никаких operator<< не определяет, а вот <string> как раз определяет нужный.
источник

M

Mxxx in pro.cxx
Chris Calvin
SO_REUSEPORT позволит биндить на один порт несколько сокетов и проблемы не будет. Но вообще странное поведение, да.
Как говорил известный человек "Причин может быть множество, а последствия могут быть самые разные"
А не знаешь, почему такой тайм-аут и порт не отпускается сразу?
источник

CC

Chris Calvin in pro.cxx
Mxxx
А не знаешь, почему такой тайм-аут и порт не отпускается сразу?
А как ты закрываешь их?
источник

M

Mxxx in pro.cxx
Через closesocket
источник

CC

Chris Calvin in pro.cxx
Что такое closesocket? Не помню такого в сокетах Беркли. Ну да ладно.
Ядро держит еще какое-то время ресурсы твоего сокета после того как ты его закрыл, так что время до следующего бинда мягко говоря не 0нс. Просто переиспользуй адреса/порты и не парся :)
Если хочешь узнать почему ядро так делает - читай его исходники, так проще и быстрее всего
источник

TS

Till Schneider in pro.cxx
Egor Suvorov
А должен ли компилироваться следующий код?
#include <iosfwd>
#include <string>

void foo(std::ostream &os, const std::string &s) {
   os << s;
}

Вот clang и libc++ считают, что компилироваться — да, а линковаться — нет: https://wandbox.org/permlink/0V1jdpPbUFS2tR6I

Это выглядит довольно странно. Если добавить <iostream>, то компилируется и линкуется.

Формально, кажется, <iosfwd> никаких operator<< не определяет, а вот <string> как раз определяет нужный.
источник

ES

Egor Suvorov in pro.cxx
Да, такой компилировать я тоже умею. Проблема возникает, когда используем operator<<(ostream&, const string&), причём на этапе линковки. Вообще выглядит как баг toolchain, но, может, я чего-то не понимаю.
источник

TS

Till Schneider in pro.cxx
Egor Suvorov
Да, такой компилировать я тоже умею. Проблема возникает, когда используем operator<<(ostream&, const string&), причём на этапе линковки. Вообще выглядит как баг toolchain, но, может, я чего-то не понимаю.
ostream откуда берется?
источник

ES

Egor Suvorov in pro.cxx
<iosfwd>
источник

TS

Till Schneider in pro.cxx
Egor Suvorov
<iosfwd>
там только forward declaration
источник

ES

Egor Suvorov in pro.cxx
Да. И? Ссылку-то я взять могу. И даже делать с ней что угодно, кроме вызовов методов. Но методы я и не вызываю: я зову свободный operator<<, который определён в <string>.
источник

TS

Till Schneider in pro.cxx
Egor Suvorov
Да. И? Ссылку-то я взять могу. И даже делать с ней что угодно, кроме вызовов методов. Но методы я и не вызываю: я зову свободный operator<<, который определён в <string>.
os << s; // это что?!
источник

ES

Egor Suvorov in pro.cxx
Это вызов std::operator<<(os, s)
Это не метод os.
источник

TS

Till Schneider in pro.cxx
Egor Suvorov
Это вызов std::operator<<(os, s)
Это не метод os.
где реализация ostream ?
источник

ES

Egor Suvorov in pro.cxx
Till Schneider
где реализация ostream ?
В <iostream>, в этой единице трансляции её нет. Зачем мне реализация ostream?

Упрощённый пример, который, я считаю, полностью валиден:
struct A;
struct B;
void bar(A&, B&);
void foo(A& a, B& b) { bar(a, b); }

Тут нет никаких определений структур, но они и не нужны, чтобы вызвать bar из foo.
источник

IL

Ignat Loskutov in pro.cxx
Кажется, что в <string> как раз декларация, а реализация в <iostream>, видимо
источник

IL

Ignat Loskutov in pro.cxx
(оператора в смысле)
источник

TS

Till Schneider in pro.cxx
Egor Suvorov
А должен ли компилироваться следующий код?
#include <iosfwd>
#include <string>

void foo(std::ostream &os, const std::string &s) {
   os << s;
}

Вот clang и libc++ считают, что компилироваться — да, а линковаться — нет: https://wandbox.org/permlink/0V1jdpPbUFS2tR6I

Это выглядит довольно странно. Если добавить <iostream>, то компилируется и линкуется.

Формально, кажется, <iosfwd> никаких operator<< не определяет, а вот <string> как раз определяет нужный.
сейчас проверил на своей машине - все норм 🤔
источник