Была ссылка в чате? https://isocpp.org/files/papers/p0636r0.html

Несправедливо пихнули P0031R0 в раздел "прочее"/"что-то специфичное" :(

Конечно, лол.

Могли б и открыть, ценности они уже давно не представляют

Несправедливо пихнули P0031R0 в раздел "прочее"/"что-то специфичное" :(

Ого, я и не знал что теперь так можно

Хотя вот что С++14, что С++17, очень мало фишек дали которые реально используются постоянно, в отличии от

М-да. В языке который я пилю таких проблем не будет :)

Хотя вот что С++14, что С++17, очень мало фишек дали которые реально используются постоянно, в отличии от

Вот в с++20 заживём точно

М-да. В языке который я пилю таких проблем не будет :)

Ну как бы нет пользователей - нет проблем:)

Лол. Нет, просто там by design всё что может быть вычислено в compile time — будет там вычислено.

Была ссылка в чате? https://isocpp.org/files/papers/p0636r0.html

Ща по ней пишу статейку

А пользователи скоро будут.

Александреску, залогиньтесь

Лол. Нет, просто там by design всё что может быть вычислено в compile time — будет там вычислено.

То есть если я пишу везде где можно constexpr, то профита 0?

То есть если я пишу везде где можно constexpr, то профита 0?

В том-то и дело, что в плюсах ты не можешь везде писать constexpr.

Пропозал Антона, к примеру, об этом. В стандартной библиотеке не всё еще переползло на constexpr

это канеш прикольная тема, что они хотят побольше вычислений перетянуть на компилятор, но учитывая скорость работы этого плюсового компилятора...

Давайте просто всё это перепишем?)

В том-то и дело, что в плюсах ты не можешь везде писать constexpr.

Ну большую часть можно. Звучит как велосипедостроение

Как раз таки большую часть нельзя. И вообще вызывает вопрос, зачем писать то, что по-хорошему должно было бы быть by design.

Энивей, это не кор фича языка вокруг которой всё строится. Просто приятный бонус.

Ну не знаю. А если мне нужны строки, которые шифруются в компилтайме, а дешифруются в рантайме? Мне добрый компилятор всё испортит?

Да и проще написать плагины к имеющимся компиляторам c++, чем язве новый изобретать

Его скорость тож опьимтзируют, чуть ли не на уровне стандарта

Кстати, в D by design все constexpr, не?

кто-то использует D?)

вопрос без подвоха

кто-то использует D?)

Александреску же

Норм язык, просто не популярен

Как раз таки большую часть нельзя. И вообще вызывает вопрос, зачем писать то, что по-хорошему должно было бы быть by design.

Имплементации стандартной библиотеки сильно различаются.В некоторых есть например goto, который нельзя в constexpr пихать. Если автоматом считать constexpr, то код перестанет быть переносимым (например std::sort на libstdc++ будет constexpr, а вот на libc++ - не будет). Поэтому автоматом не считают пока и размечают всё ручками. Лет через 10-15 может сделают автоматом, когда ЛЮБЫЕ выражения компиялторы научатся выполнять как constexpr

Через 15 лет мне будет 39, интересно, будет меня это еще интересовать? :D

Конечно, будет!

В общем надеюсь, что в ближайший год это уже будет сделано.

Так сделайте :) Хотя бы в GCC

Уже делаем, только не на базе плюсов. Это реально не самая большая проблема с которой хотелось бы совладать.

Есть как минимум метапрограммирование, которое язык в языке.

Не хватает паттерн-матчинга.

При всех плюсовых достоинствах — эти два пункта довольно серьёзные.

Не хватает паттерн-матчинга.

посмотрите на concepts TS

Смотрел же. Проблема в том, что пока это доберется до стандарта и попадёт в компиляторы — пройдет много времени.

в GCC уже есть, в C++20 будет

* должно быть в с++20

Смотрел же. Проблема в том, что пока это доберется до стандарта и попадёт в компиляторы — пройдет много времени.

Так уже ж)

Ребят, кто нибудь boost::process использует у себя? Есть вопрос один. Не охота использовать асинхронный pipe для чтения из stdout порождённого процесса, однако обычное чтение вызывает lock (вызывающий поток ждёт поступления данных из stream, если данных нет). Можно ли как то деликатно (по типу stream.rdbuf()->in_avail()) узнать, есть ли данные и если есть, прочесть без блокирования потока?

Или по любому нужно выделять поток для каждого процесса на обслуживание IO?

Есть платформозависимое асинхронное IO в консоль.

Как это делать без асинхронщины — не очень понятно.

я хочу в сипипи чтобы можно было роботать с шелом ОС

select можно делать наверное из STDIN

Есть платформозависимое асинхронное IO в консоль.

На самом деле нет. На винде точно нет асинхронной работы с консолью.

Ребят, кто нибудь boost::process использует у себя? Есть вопрос один. Не охота использовать асинхронный pipe для чтения из stdout порождённого процесса, однако обычное чтение вызывает lock (вызывающий поток ждёт поступления данных из stream, если данных нет). Можно ли как то деликатно (по типу stream.rdbuf()->in_avail()) узнать, есть ли данные и если есть, прочесть без блокирования потока?

Пишите сюда http://lists.boost.org/mailman/listinfo.cgi/boost-users + можете копию послать лично автору библиотеки. Все адресса разрабов есть вот тут https://github.com/boostorg/boost/blob/master/libs/maintainers.txt

На самом деле нет. На винде точно нет асинхронной работы с консолью.

Самая печальская печаль для всех вин юзеров

На самом деле нет. На винде точно нет асинхронной работы с консолью.

А разве ты что-то с APC не придумал?

@AndreiKr мне не интересны системные платформозависимые вызовы. Меня интересуют возможности boost::process

Самая печальская печаль для всех вин юзеров

Увы. На винде вообще по-уродски сделана консоль. Для неё запускается отдельный процесс, с которым приходится коммуницировать методами ReadConsole/WriteConsole. Можно через ReadFile/WriteFile, но асинхронные режимы при этом не работают, потому что на самом деле эти методы служат просто обёрткой к тем же ReadConsole/WriteConsole.

А разве ты что-то с APC не придумал?

Нет, вся асинхронщина не работает для консольных буферов.

@AndreiKr мне не интересны системные платформозависимые вызовы. Меня интересуют возможности boost::process

А boost::process вообще часть boost-а?

Увы. На винде вообще по-уродски сделана консоль. Для неё запускается отдельный процесс, с которым приходится коммуницировать методами ReadConsole/WriteConsole. Можно через ReadFile/WriteFile, но асинхронные режимы при этом не работают, потому что на самом деле эти методы служат просто обёрткой к тем же ReadConsole/WriteConsole.

это да.... У меня большая боль с вим, поэтому приходиться использовать другие))

А boost::process вообще часть boost-а?

скоро будет, как я понимаю. С 1.64

А boost::process вообще часть boost-а?

начная с boost 1.64

@AndreiKr мне не интересны системные платформозависимые вызовы. Меня интересуют возможности boost::process

А что не так с async_pipe?

На самом деле нет. На винде точно нет асинхронной работы с консолью.

а разве через OVERLAPPED нельзя работать с HANDLE'ами стдина/аута/етц?

Увы. На винде вообще по-уродски сделана консоль. Для неё запускается отдельный процесс, с которым приходится коммуницировать методами ReadConsole/WriteConsole. Можно через ReadFile/WriteFile, но асинхронные режимы при этом не работают, потому что на самом деле эти методы служат просто обёрткой к тем же ReadConsole/WriteConsole.

а.тьфу. не дошел еще до этого сообщения

ERROR: S client not available

Ещё один момент. Разве здесь не должен возвращаться const указатель? Или отсутствовать модификатор const... https://github.com/klemens-morgenstern/boost-process/blob/develop/include/boost/process/pipe.hpp#L265

А что не так с async_pipe?

Не хочу для пачки процессов городить пачку io_context и потоков. Как я понимаю один процесс обслуживает 1 поток. Может не прав, ещё не трогал

Если кроссплатформа с учетом винды, то судя по всему придётся.

Короче имхо лучше пропихивать в компиляторы/стандарт фичи чем пилить свой язык

а разве через OVERLAPPED нельзя работать с HANDLE'ами стдина/аута/етц?

Увы. Самое близкое, что можно сделать - на этих хэндлах можно ждать/поллить методами WaitFor*/MsgWaitFor*. Что я, собственно, и делал для "асинхронной" консоли. Отдельный поток плюс ожидание на всех хэндлах, которые нельзя OVERLAPPED.

очень интересная инфа, спасибо. запишу в телеграф-заметки #windows #console #async #io

Короче имхо лучше пропихивать в компиляторы/стандарт фичи чем пилить свой язык

к тому же у нас есть возможность ?

Ещё один момент. Разве здесь не должен возвращаться const указатель? Или отсутствовать модификатор const... https://github.com/klemens-morgenstern/boost-process/blob/develop/include/boost/process/pipe.hpp#L265

Не должен. Метод точно const. А указатель не const, потому что underflow очевидным образом двигает указатели.

к тому же у нас есть возможность ?

В компилятор интереснее)

а народ из варгейминга тут бывает?

Не должен. Метод точно const. А указатель не const, потому что underflow очевидным образом двигает указатели.

А каким образом я могу получить этот указатель, имя ссылку на этот объект на руках?

А каким образом я могу получить этот указатель, имя ссылку на этот объект на руках?

Не понял вопроса.

rdbuf возвращает указатель на буффер.

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

Релиз системы сборки CMake 3.8 Состоялся релиз кроссплатформенного открытого генератора сценариев сборки CMake 3.8, выступающего в качестве альтернативы Autotools и используемого в таких проектах, как KDE, LLVM/Clang, MySQL, MariaDB, ReactOS и Blender. Код CMake написан на языке C++ и распространяется под лицензией BSD.

Не понял вопроса.

https://pastebin.com/DhyL3HD4

Они внутри себя как правило всегда вызывают setg

setp

Которые явно не константные.

https://pastebin.com/DhyL3HD4

Какая-то фигня, я отчетливо вижу, что _buf неконстантный.

253 строчка

Которые явно не константные.

Я наверно где то косячу) не могу понять, почему я не могу вызвать этот метод

Я наверно где то косячу) не могу понять, почему я не могу вызвать этот метод

Амперсанд забыл кто-то по-моему.

А вот вам ещё мегабыстрый логгер https://github.com/RafaGago/mini-async-log

А вот вам ещё мегабыстрый логгер https://github.com/RafaGago/mini-async-log

#repo #log

Ещё один момент. Разве здесь не должен возвращаться const указатель? Или отсутствовать модификатор const... https://github.com/klemens-morgenstern/boost-process/blob/develop/include/boost/process/pipe.hpp#L265

Косячокс!

Сразу видно код, который даже не пытаются компилировать после изменений.

Сразу видно код, который даже не пытаются компилировать после изменений.

? го в цитатник

Сразу видно код, который даже не пытаются компилировать после изменений.

У меня тимлид так часто делает