N>В FILE*? Нет, я люблю stdio по-своему, но почему не iostreams?
Я так понимаю, что от наследия С вообще никак не избавиться, а перегрузка std::print(FILE*) полезна для печати в stderr.
Так что можно забыть про std::cerr из #include <iostream>, который известен своим гигантским размером и замедлением компиляции.
N>Наконец, какого хрена, если stdio уже дополнять стали, в нём нет funopen/fopencookie, если все нормальные реализации сделали их 20 лет назад и забыли о проблеме? N>С ними stdio замыкается, превращаясь во что угодно — хоть в строку пиши, хоть внутренний пайп делай, хоть на устройство через I/O порты отправляй сразу — а без него какого лешего я на ОС завязан? В iostreams это тоже изначально решили...
По-моему, std::format() это не часть stdio, которой скорее должен заниматься комитет языка C.
Здравствуйте, PM, Вы писали:
PM>Так что можно забыть про std::cerr из #include <iostream>, который известен своим гигантским размером и замедлением компиляции.
Вроде бы когда переведут стандартную библиотеку на модули это перестанет быть проблемой. Или нет?
N>Да, я знаю, что Event того типа, который в Windows, для каких-то вещей кажется удобнее. Только вот он за пределы Windows не вышел, в то время как в Windows начиная с XP втащили CV.
С висты. Как и slim rwlock и прочие современные примитивы.
N>Люди, сделавшие это, не просто смотрят на 1-2 ближайших конкурента, они ещё и книги с журналами читают, на профильные конференции ездят, и всё такое. Я не собирал точные данные, но из этого уже становится очевидно (в смысле apparent, ещё не obvious), что что-то с этим ивентом не то.
Он ядерный, следовательно, много их не создашь. А народ настолько разошёлся с транжированием ресурсов, что даже critical sections пришлось оптимизировать, чтобы не предсоздавали объекты ядра при инициализации. Ну и другая проблема, что на событиях нельзя было атомарно отпустить один лок, захватив другой — был PulseEvent, но работал криво. В общем, плюнули и надёргали современных решений. Так-то keyed event (прародитель CV) давно существовал в винде, но лишь в ядре (с 2k или xp).
Здравствуйте, johny5, Вы писали:
BFE>>А как по расходу памяти? Мне так кажется, чисто из теоретических соображений, что память будет расходоваться в 1.1—4 раза больше, чем в С++. Так ли это?
J>Там нет никакого GCC, или подсчёта ссылок.
Так не бывает. Вернее бывает, но тогда приходится эмулировать указатели через целочисленные массивы индексов — то ещё занятие, но если это сделано на уровне языка, то тогда это просто замечательно.
Впрочем, выяснить это довольно просто, достаточно посмотреть на описание графа или чего-нибудь вроде двунаправленного списка... Почитал про Rust и не понял: как сделать двунаправленный список?
J>Владение памяти очень похоже на С++, только сделано более прямолинейно что ли.. В хорошем смысле. По сути те же стековые пироги с отдельным типом для объектов в куче.
Не хорошо. Стеки и куча не удобны для параллельной не потоковой работы.
J>Vec<> в Rust точно так же устроен как std::vector в С++. По остальным контейнерам не скажу.
std::vector — это, извините, примитивный динамический массив, это совсем не показатель.
Впрочем, всё это довольно интересно, но что с расходом памяти?
S>А если программа долго что-то считает, потом выводит строчку, затем опять что-то долго считает, то << '\n' без последующего flush -- это уже не есть хорошо.
Вот если бы кто-то за 50+ лет существования std::cout сделал сброс буфера по таймеру (и соответствующий флаг для выключения) — этого обсуждения даже не существовало бы.
Ах, мечты-мечты...
Ведь бороться с трудностями и обсуждать хитровыверты C++ в виде отличий "\n" от "std::endl" — это гораздо более в стиле C++.
Ну, а главный вопрос C++ — отсутствие менеджера пакетов (щас их три: conan, vcpkg, build2) никто даже не пытается решить. А без этого C++ неуклонно летит под откос (монорепозиторий не всем по силам, да и костыль это, а не решение). В результате язык маргинализируется, костенеет и в языке остаются только ретрограды, потому что лучшие кадры уходят. Остаются "Я прав, я всегда прав, только я всегда прав". В общем, C++ постепенно плывет туда же, куда и Ваза.
Здравствуйте, PM, Вы писали:
N>>В FILE*? Нет, я люблю stdio по-своему, но почему не iostreams? PM>Я так понимаю, что от наследия С вообще никак не избавиться, а перегрузка std::print(FILE*) полезна для печати в stderr. PM>Так что можно забыть про std::cerr из #include <iostream>, который известен своим гигантским размером и замедлением компиляции.
А за счёт чего гигантский размер, и в каких реализациях?
N>>Наконец, какого хрена, если stdio уже дополнять стали, в нём нет funopen/fopencookie, если все нормальные реализации сделали их 20 лет назад и забыли о проблеме? N>>С ними stdio замыкается, превращаясь во что угодно — хоть в строку пиши, хоть внутренний пайп делай, хоть на устройство через I/O порты отправляй сразу — а без него какого лешего я на ОС завязан? В iostreams это тоже изначально решили...
PM>По-моему, std::format() это не часть stdio, которой скорее должен заниматься комитет языка C.
Stdio — C. Print такого рода — C++. Как-то оно на стыке. У семи нянек дитя без глазу?
Здравствуйте, Reset, Вы писали:
S>>А если программа долго что-то считает, потом выводит строчку, затем опять что-то долго считает, то << '\n' без последующего flush -- это уже не есть хорошо.
R>Вот если бы кто-то за 50+ лет существования std::cout
Интересно, откуда взялось 50 лет?
R>сделал сброс буфера по таймеру (и соответствующий флаг для выключения) — этого обсуждения даже не существовало бы.
Меньше всего мне бы хотелось, чтобы у меня в программе существовали какие-то неконтролируемые мной таймеры, которые бы что-то подобное делали бы.
R>Ну, а главный вопрос C++ — отсутствие менеджера пакетов (щас их три: conan, vcpkg, build2) никто даже не пытается решить.
Это второстепенный вопрос, а то и третьестепенный. Кроме того, опыт использования vcpkg говорит о том, что у подобного подхода есть свои фатальные недостатки.
Гораздо более насущный вопрос -- это отсутствие нормальной де-юре и де-факто стандартной системы сборки. Как раз то, что сейчас их целый зоопарк, намного больше препятствует вменяемому управлению зависимостями, чем отсутствие пакетного менеджера. А то, что такой системой может стать угребищный CMake делает ситуацию еще печальнее. ИМХО, если у коммьюнити не хватает мозгов, здравого смысла и инстинкта самосохранения для того, чтобы послать CMake туда, где ему самое место, то такое коммьюнити не имеет права на выживание. Если C++ников устраивает жрать CMake, то C++ должен сдохнуть.
Но, может быть, еще и повезет.
R>В результате язык маргинализируется, костенеет
Сейчас C++ развивается намного быстрее, чем следовало бы. Мы можем оказаться в ситуации, когда C++23 уже принят, но нет ни одного компилятора, который бы полностью и качественно бы поддерживал C++20.
R>потому что лучшие кадры уходят.
Думается, что ваш уход из C++ поднял средний IQ и в C++коммьюнити, и в Rust-коммьюнити.
R>Остаются "Я прав, я всегда прав, только я всегда прав".
Здравствуйте, so5team, Вы писали:
PM>>Так что можно забыть про std::cerr из #include <iostream>, который известен своим гигантским размером и замедлением компиляции.
S>Вроде бы когда переведут стандартную библиотеку на модули это перестанет быть проблемой. Или нет?
Не очень слежу за модуляризацией стандартной бибилотеки, когда ее переводят в C++23? А print(stdout) уже есть и работает в fmtlib.
Both print and printf are ~3 times faster than cout even with synchronization to the standard C streams turned off. print is 14% faster when printing to stdout than to cout. For this reason and because print doesn’t use formatting facilities of ostream we propose using stdout as the default output stream and providing an overload for writing to ostream.
Здравствуйте, Reset, Вы писали:
S>>А если программа долго что-то считает, потом выводит строчку, затем опять что-то долго считает, то << '\n' без последующего flush -- это уже не есть хорошо.
R>Вот если бы кто-то за 50+ лет существования std::cout сделал сброс буфера по таймеру (и соответствующий флаг для выключения) — этого обсуждения даже не существовало бы.
R>Ах, мечты-мечты...
Вроде бы стандартный вывод по-умолчанию и так делает сброс буфера в конце строки. По крайней мере, не один я так думаю:
Although not mandated by the C standard, stdout is line-buffered by default on many implementations. This means, that a call to fflush is not necessary after printf("...\n") or puts("..."), and thus, fmt::print("...\n") would indeed flush the stream.
The same applies for std::cout, which is mandated to be line-buffered, so writing a '\n' would flush the stream no matter what.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, PM, Вы писали:
PM>>Так что можно забыть про std::cerr из #include <iostream>, который известен своим гигантским размером и замедлением компиляции.
S>Вроде бы когда переведут стандартную библиотеку на модули это перестанет быть проблемой. Или нет?
В 20-ом стандарте уже можно писать import <iostream>; И заголовочный файл один раз скомпилируется в модуль.
Здравствуйте, netch80, Вы писали:
N>>>В FILE*? Нет, я люблю stdio по-своему, но почему не iostreams? PM>>Я так понимаю, что от наследия С вообще никак не избавиться, а перегрузка std::print(FILE*) полезна для печати в stderr. PM>>Так что можно забыть про std::cerr из #include <iostream>, который известен своим гигантским размером и замедлением компиляции.
N>А за счёт чего гигантский размер, и в каких реализациях?
Честно говоря, точно не знаю. Могу только предположить, что из-за включения locale, streambuf и шаблонной природы всего этого добра. Не от хорошей жизни ведь пришлось вводить iosfwd.
% g++ --version
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
# The following commands create a source file that includes a single header
# file (on stdout), preprocess it with g++ -E, and then count how many lines
# are in the resulting preprocessed output
% echo '#include <iosfwd>' | g++ -E -xc++ — | wc
1504 4916 57789
% echo '#include <iostream>' | g++ -E -xc++ — | wc
46225 133508 1703951
PM>>По-моему, std::format() это не часть stdio, которой скорее должен заниматься комитет языка C.
N>Stdio — C. Print такого рода — C++. Как-то оно на стыке. У семи нянек дитя без глазу?
Да, не академично, но ведь работает же. Методы гибкой разработки теперь везде Выкатили новую фичу std::print() в C++20; собрали фидбэк; выкатят std::println() в C++23 , возможно с перегрузкой для std::stream
S>Сейчас C++ развивается намного быстрее, чем следовало бы. Мы можем оказаться в ситуации, когда C++23 уже принят, но нет ни одного компилятора, который бы полностью и качественно бы поддерживал C++20.
Видимо, с модулями повторится та же ситуация, как и с export template — приняли давно, но никто не поддерживал, в итоге забили болт.
N>>Stdio — C. Print такого рода — C++. Как-то оно на стыке. У семи нянек дитя без глазу?
PM>Да, не академично, но ведь работает же. Методы гибкой разработки теперь везде Выкатили новую фичу std::print() в C++20; собрали фидбэк; выкатят std::println() в C++23 , возможно с перегрузкой для std::stream
Здравствуйте, Sm0ke, Вы писали:
PM>>>Так что можно забыть про std::cerr из #include <iostream>, который известен своим гигантским размером и замедлением компиляции.
S>>Вроде бы когда переведут стандартную библиотеку на модули это перестанет быть проблемой. Или нет?
S>В 20-ом стандарте уже можно писать import <iostream>; И заголовочный файл один раз скомпилируется в модуль.
Речь не столько про то, что описано в стандарте, а про то, как оно будет, когда во всех трех основных компиляторах это все будет полноценно реализовано.
Здравствуйте, flаt, Вы писали:
S>>Сейчас C++ развивается намного быстрее, чем следовало бы. Мы можем оказаться в ситуации, когда C++23 уже принят, но нет ни одного компилятора, который бы полностью и качественно бы поддерживал C++20.
F>Видимо, с модулями повторится та же ситуация, как и с export template — приняли давно, но никто не поддерживал, в итоге забили болт.
Я более оптимистичен, уж очень сильно модули нужны были Google и Microsoft-у.
Другое дело, что потребуется не один год, чтобы хотя бы 80% активно разрабатываемых на C++ проектов полностью бы перешли на модули.
Здравствуйте, johny5, Вы писали:
J>Rust не разрешит тебе расшаренный доступ к объекту из разных потоков, в этом и весь фикус.
В чём это "не разрешит" физически проявляется?
J> Компилятор проверит что ты это правило нигде случайно не нарушаешь.
Т.е. не скомпилирует если думает что тут может быть многопоточный доступ? А как он узнает что к этому объекту полезет больше чем один поток, когда нить потом в рантайме?
J>Есть расщаренный доступ необходим, да, ручками оборачиваем объекты в мьютексы, в interior mutability обёртки и т.д..
Ну т.е. как и раньше.
J> При этом опять же достигается 100% гарантия racing bug free.
Как именно, физически.
J>Т.е. компилятор за тебя ничего писать не будет, но не даст тебе сделать ошибку, если например, ты этот мьютекс забудешь написать.
Как он поймёт что в будущем этого потока не будет создано больше чем один экземпляр одновременно?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
J>>Rust не разрешит тебе расшаренный доступ к объекту из разных потоков, в этом и весь фикус. CC>В чём это "не разрешит" физически проявляется?
Когда ты в расте присваиваешь один указатель другому, то старая переменная "уничтожается", т.е. её использовать больше нельзя, компилятор следит за этим. В том числе если это использование переменной в качестве аргумента при вызове функции. Так называемая семантика передачи владения. В первую очередь это используется для освобождения памяти (кто последний взял владение, тот и освобождает, грубо говоря), но и в том числе для многопоточности используется. Это отслеживается на уровне компиляции, а не на уровне исполнения. Это я всё очень грубо описал, но на практике как ты хочешь писать код — так не выйдет, раст тебе не даст. Многопоточность в основном делается через передачу иммутабельных данных между потоками, message passing, вот это вот всё. Другие варианты слишком неудобные. Их можно использовать в unsafe коде для реализации каких-то низкоуровневых механизмов, интерфейсы которых потом будут выставлены для высокоуровневого кода. Но unsafe кода по определению должно быть очень мало, иначе ты теряешь основной смысл использования Rust-а.
Здравствуйте, CreatorCray, Вы писали:
J>>Rust не разрешит тебе расшаренный доступ к объекту из разных потоков, в этом и весь фикус. CC>В чём это "не разрешит" физически проявляется?
