Или по любому нужно выделять поток для каждого процесса на обслуживание 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.

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

Ещё один момент. Разве здесь не должен возвращаться 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

Косячокс!

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

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

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

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

а ну да, я даже и не заметил в ошибке, что там каст от указателя

а его что, нужно еще компилировать?

Вот вам и boost::process, и кто после этого скажет, что велосипеды не нужны :D

у вас не всегда с первого раза все получается7

блин, а я думал быть может это мне поможет проверить буфер стрима на наличие данных

Вот вам и boost::process, и кто после этого скажет, что велосипеды не нужны :D

А он же еще не в бусте, не?

Или уже приняли

Сам только что спрашивал тремя постами выше.

Или уже приняли

во второй бетте 1.64 версии есть

блин, а я думал быть может это мне поможет проверить буфер стрима на наличие данных

Бери код с master-а, у них же написано в readme даже, что девелоп не собирается.

а ну да, я даже и не заметил в ошибке, что там каст от указателя

Нашел ошибку - молчи ни кому не говори, автору библиотеки не намекай! Ты старался, работал и искал - другие люди тоже должны страдать. Бонусом получишь весёлое занятие по накладыванию своих фиксов при переезде на след релиз библиотеки. </sarcasm>

Ну в любом случае пилят его уже кучу времени и брать не хотели долго, видимо не просто так

Бери код с master-а, у них же написано в readme даже, что девелоп не собирается.

я не с репозитория брал)) вместе со второй беттой буста установил)

Нашел ошибку - молчи ни кому не говори, автору библиотеки не намекай! Ты старался, работал и искал - другие люди тоже должны страдать. Бонусом получишь весёлое занятие по накладыванию своих фиксов при переезде на след релиз библиотеки. </sarcasm>

спер в цитатник

Нашел ошибку - молчи ни кому не говори, автору библиотеки не намекай! Ты старался, работал и искал - другие люди тоже должны страдать. Бонусом получишь весёлое занятие по накладыванию своих фиксов при переезде на след релиз библиотеки. </sarcasm>

ну я вроде не собирался молчать) issue на github сделаю, проблем в этом нет)

Нашел ошибку - молчи ни кому не говори, автору библиотеки не намекай! Ты старался, работал и искал - другие люди тоже должны страдать. Бонусом получишь весёлое занятие по накладыванию своих фиксов при переезде на след релиз библиотеки. </sarcasm>

В мемориз

Ну в любом случае пилят его уже кучу времени и брать не хотели долго, видимо не просто так

Надеюсь что когда оно в стейбл версию попадет наконец, её быстренько допилят

ну я вроде не собирался молчать) issue на github сделаю, проблем в этом нет)

спасибо! Все бы были такими сознательными :)

Сразу пулреквест.

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

ну я вроде не собирался молчать) issue на github сделаю, проблем в этом нет)

Надо PR👍

Нее, я только issue сделаю. Мне помимо всего прочего нужно описать другие проблемы и вопросы, которые возникли при работе. Если кто то хочет PR сделать с отсутствующим амперсантом - welcome.

desu, [12.04.17 14:49] привет desu, [12.04.17 14:50] кто работал с камерой usb с помощью qt desu, [12.04.17 14:52] для cvcapture есть установка исо? desu, [12.04.17 14:53] я вижу только iso speed desu, [12.04.17 14:53] и установка AWB

a iso speed != iso ?

desu, [12.04.17 14:49] привет desu, [12.04.17 14:50] кто работал с камерой usb с помощью qt desu, [12.04.17 14:52] для cvcapture есть установка исо? desu, [12.04.17 14:53] я вижу только iso speed desu, [12.04.17 14:53] и установка AWB

Чем iso speed плох?)

Чем iso speed плох?)

ну это может не то что просто исо)

ну это может не то что просто исо)

То же самое

std::memcpy((uchar*)sourse_3c,(uchar*)cvQueryFrame( dlg->capture )->imageData,dlg->nHeight*dlg->nWidth*3);

что-то мне кажется я какуюто глупость написал

как вы думаете)

чета подтормаживает

для распикам сразу было в буфер хм

Привет всем, вопрос про SFINAE. Как обычно есть функция поведение которой зависит от свойств типов передаваемых параметров (наличие/отсутсвие некоторых методов, арифметрический ли это тип, и т.д.) сейчас пачка специализаций через enable_if template<typename T> typename enable_if_t<has_method_foo<T>::value, bool> doSomething(T t) template<typename T> typename enable_if_t<has_method_bar<T>::value, bool> doSomething(T t) и т.д. Вопрос как добавить поведение по-умолчанию?, т.е. если другие enable_if не специализировали функцию, то использовать эту реализацию Я знаю что это можно делать через тот же enable_if, но с исключающими условиями: template<typename T> typename enable_if_t<!has_method_bar<T>::value && !has_method_foo<T>::value, bool> doSomething(T t) { doDefault(t); } Такой способ подходит, до тех пор пока специализаций мало. Существует ли более удобный способ использовать SFINAE, где можно было бы удобно указать реализацию по-умолчанию?