cmake --build build_dir куда мне здесь воткнуть сед, вручную процессить оутпут смака?

я отпутю... ...вывод мейка

https://github.com/zaizupro/dotfiles/blob/master/scripts/makek.sh

https://github.com/zaizupro/dotfiles/blob/master/scripts/makek.sh

а интересный вариант но я про то, что современный шланг и гцц самостоятельно красит сообщения, и при сборке мейком всё ок, а вот ниндзя съедает всю подсветку и выплёвывает простой текст вроде как у ниндзи бывает какой-то флаг для поддержки цвета, но как его быстро вкрутить в смак я не нашёл вчера

а интересный вариант но я про то, что современный шланг и гцц самостоятельно красит сообщения, и при сборке мейком всё ок, а вот ниндзя съедает всю подсветку и выплёвывает простой текст вроде как у ниндзи бывает какой-то флаг для поддержки цвета, но как его быстро вкрутить в смак я не нашёл вчера

ну да, современные технологии, про ниндзи это к спецам надо да

хождение в кучу операция дорогая. Таким "костылём" я уменьшаю их число вдвое. Не смог найти способ лучше.

прости, а ты уже замерил стоимость этой операции в твоей задаче? график покажи

сенсей, научите, как в этой связке цветные сообщения от шланга/гцц настроить?

ээ у меня в iterm2 это включено, если тебе надо - погугли

а интересный вариант но я про то, что современный шланг и гцц самостоятельно красит сообщения, и при сборке мейком всё ок, а вот ниндзя съедает всю подсветку и выплёвывает простой текст вроде как у ниндзи бывает какой-то флаг для поддержки цвета, но как его быстро вкрутить в смак я не нашёл вчера

запускай нинзю рукой

прости, а ты уже замерил стоимость этой операции в твоей задаче? график покажи

Не покажу. Средства рисования подобных графиков толстоваты, не помещаются в микроконтроллер с 64кБ озу. Уменьшение числа вызовов malloc также уменьшает число остановок шедулера RTOS, это тоже важно.

запускай нинзю рукой

работает, да, думал может для смака тоже что-нибудь придумали --build вообще православно или так себе?

Не покажу. Средства рисования подобных графиков толстоваты, не помещаются в микроконтроллер с 64кБ озу. Уменьшение числа вызовов malloc также уменьшает число остановок шедулера RTOS, это тоже важно.

ок, тогда пиши на чистом си, согласен

если микроконтроллер то тут вопросов нет

вообще без маллока можно обойтись

на Це приходится слишком много велосипедов писать. Лучше на крестах останусь.

зачем вообще использовать malloc() на микроконтроллере с 64Кб?

зачем вообще использовать malloc() на микроконтроллере с 64Кб?

my point exactly!

Это как использовать free на ракете

тем более если ОСРВ, то все равно половина памяти уйдет под стеки задач и очереди/fifo

зачем вообще использовать malloc() на микроконтроллере с 64Кб?

Позволяет некоторые вещи писать сильно проще и переносимей между проектами. К тому же я взял реализацию работающую за О(1), позволяет получить прогнозируемые времянки.

а фрагментация?

а фрагментация?

Склеивание свободных блоков тоже за о1.

Загугли tlsf

tlsf хороший да

тем более если ОСРВ, то все равно половина памяти уйдет под стеки задач и очереди/fifo

А ещё я использую динамическое создание/удаление задач. И всё потому что конечные автоматы хороши только до определенного момента.

https://wiki.qt.io/New_Features_in_Qt_5.10

https://wiki.qt.io/New_Features_in_Qt_5.10

Для меня это выглядит как хороший знак: стандартная библиотека С++ в некоторых вещах ушла вперёд и теперь Qt догоняет (например QStringView, QSemaphoreReleaser, QRandomGenerator)

Для меня это выглядит как хороший знак: стандартная библиотека С++ в некоторых вещах ушла вперёд и теперь Qt догоняет (например QStringView, QSemaphoreReleaser, QRandomGenerator)

ну стандартная либа развивается же ? Всё больше и больше вещей можно юзать прямо из STL

Для меня это выглядит как хороший знак: стандартная библиотека С++ в некоторых вещах ушла вперёд и теперь Qt догоняет (например QStringView, QSemaphoreReleaser, QRandomGenerator)

будет хорошо если в 6.0 выкинут свои контейнеры :)

https://wiki.qt.io/New_Features_in_Qt_5.10

Ох, а qstringref?

будет хорошо если в 6.0 выкинут свои контейнеры :)

никогда этого не будет

никогда этого не будет

чо вдруг?

потому что обратная совместимость

потому что обратная совместимость

ну так в 6.0 же)

и давай, выкидывай QString

потому что обратная совместимость

Они могут скрыть за своим интерфейсом легко

удачи пользоваться std::string

ну лан, оставить QString

будет хорошо если в 6.0 выкинут свои контейнеры :)

Возможно заменят QContainerName на class ContainerName { shared_ptr<std::ContainerName> holder_; } Qt очень сильно подсел на COW, и слезть врядли получится

Про ASPX нигде чатика нет?

ASP.NET

Возможно заменят QContainerName на class ContainerName { shared_ptr<std::ContainerName> holder_; } Qt очень сильно подсел на COW, и слезть врядли получится

Ну тем не менее Qt обеспечивает приемлемую производительность там где его юзают

Возможно заменят QContainerName на class ContainerName { shared_ptr<std::ContainerName> holder_; } Qt очень сильно подсел на COW, и слезть врядли получится

угу местами можно ногу прострелить из за этого

Ох, а qstringref?

Я реально не понял нафига им qstringview

Про ASPX нигде чатика нет?

@pro_net

Сенкс

Я реально не понял нафига им qstringview

QStringView is designed as an interface type; its main use-case is as a function parameter type. When QStringViews are used as automatic variables or data members, care must be taken to ensure that the referenced string data (for example, owned by a QString) outlives the QStringView on all code paths, lest the string view ends up referencing deleted data. When used as an interface type, QStringView allows a single function to accept a wide variety of UTF-16 string data sources. One function accepting QStringView thus replaces three function overloads (taking QString, QStringRef, and (const QChar*, int)), while at the same time enabling even more string data sources to be passed to the function, such as u"Hello World", a char16_t string literal.

Ммм... один стрингвью на все

Красиво, только вот они опоздали :(

имеешь ввиду boost::string_ref ?

имеешь ввиду boost::string_ref ?

QStringRef

В смысле опоздали с QStringRef из-за буста? Или какая-то иная причина?

В смысле опоздали с QStringRef из-за буста? Или какая-то иная причина?

Опоздали с qstringview

А, сорр, я по диагонали прочел походу.

В смысле опоздали с QStringRef из-за буста? Или какая-то иная причина?

Откуда вообще буст?

А, сорр, я по диагонали прочел походу.

Вот да

https://wiki.qt.io/New_Features_in_Qt_5.10

Introduced new QML types: Action, ActionGroup, MenuBar 4 года ждал

Красиво, только вот они опоздали :(

почему опоздали?

почему опоздали?

Опоздали вперёд комитета это выкатить

будет хорошо если в 6.0 выкинут свои контейнеры :)

было бы разумно

удачи пользоваться std::string

есть u16string + алгоритмы

есть u16string + алгоритмы

Ничего не придумали лучше std::wstring_convert?

Для UTF-8 <-> UTF-16.

ERROR: S client not available

codecvt::utf8_to_utf16 же

Ох, это где?

последняя строчка

последняя строчка

Вечер рычагов :(

последняя строчка

Депрекейтнули же.

Ничего не придумали лучше std::wstring_convert?

Вместе с ним.

1. As the Unicode standard and security experts point out, ill-formed UTF can be and has been used as an attack vector. Yet the <codecvt> facets don't provide the safe forms of error handling as their defaults, and it is far to hard to use them in a safe way. 2. I've wanted to use <codecvt> in production code three or four times where turned out to not be suitable, but because the spec is so obscure, it took far too much time to realize that. 3. In the couple of cases where <codecvt> would have been suitable, I couldn't use it because the code had to be portable, yet libstdc++ didn't support until very recently. That, coupled with the fact that is a new header, means there just aren't a lot of users. 4. In published usage surveys like BuiltWith, use of formerly popular non-UTF encodings like Shift-JIS and Big5 is plummeting compared to UTF encodings. The standard library badly needs modern C++ UTF conversion facilities, yet <codecvt> is an embarrassment. Let's deprecate it to clear the path for the future.

Депрекейтнули же.

таки депрекейтнули не убрали

Ну тем не менее, никто не предложил, как лучше подойти к этому вопросу, учитывая пункты выше?

написать нормальный конвертор, это несложно для юникодовых пойнтов

если тебе нужно ренормализацию или любой другой процессинг кроме переконвертации - бери ICU, не ошибешься

почему на гитхабе выделяется не весь код??? после скобочек

и картунку что

только избранным можно сюда скинуть?

нажми кнопочку Raw

только избранным можно сюда скинуть?

Не нужно сюда кидать простыни кода. Просто ссылку опубликуй на нужную строку прямо с GitHub.

Не нужно сюда кидать простыни кода. Просто ссылку опубликуй на нужную строку прямо с GitHub.

он пытается показать что у него не выделяется текст, а надо было всего лишь на Raw нажать

незнаю там один гравис, тут три чтоб выделенно было

а там посередине получилось

ninja успевает проэвальюэйтить обновление LLVM c 6500 файлами меньше чем за секунду, вжух

плюсую за ninja

ninja успевает проэвальюэйтить обновление LLVM c 6500 файлами меньше чем за секунду, вжух

только иногда когда завершится с ошибкой бывает заколебешься искать где ошибка была) особенно если ворнингов тьма

только иногда когда завершится с ошибкой бывает заколебешься искать где ошибка была) особенно если ворнингов тьма

так он наоборот не показывает ничего где не было варнингов

если выключить CMAKE_VERBOSE_MAKEFILES

ну и я сейчас чисто про evaluate changes говорил, а это внутренняя штука

никаких ворнингов она не вызывает

не, в этом плане нинзя крутая да

https://www.codeplay.com/portal/12-06-17-computecpp-ce-0-5-0-released-and-sycl-1-2-1-ratified

Есть вопрос по cmake, надеюсь, по адресу. В основном прогаю в xcode, запускаю на ubuntu. Вручную дублировать списки файлов при рекомпиляции на линуксе - слишком долго, писать отдельный скрипт для этого - выглядит как костыль. Есть ли в cmake возможность добавить все файлы из директории, у которых нету специфического префикса или суффикса в названии? Скажем, я помечу все ненужные файлы префиксом «_» и заставлю собрать все остальное в единый проект.

http://mobile.opennet.ru/opennews/art.shtml?num=47701