так что std::initializer_list<const char*> ему не подходит

Но в случае vector<string>({"A", "B"}); семантика какая-то иная?

std::initializer_list<std::string> list = { "A", "B" }; std::make_unique<std::vector<std::string>>(std::move(list)); //OK

Но в случае vector<string>({"A", "B"}); семантика какая-то иная?

Там надо стандарт курить с типизацией {}

Интересно баг это стандарта или фича. В смысле планируется ли исправлять. Еще и move-ать initializer list нельзя, как я помню.

вероятно прикол в том, что нельзя мувать и создавать из ссылок

хотя это парадокс

std::initializer_list<std::string> list = { "A", "B" };

это же скомпилировалось

Так и vector<string> v = {"A", "B"}; компилируется

В жаве утечек нет, как и в C++. А вот в пользовательском коде на этих языках утечки есть.

йюп, чистил табы вот нашел как раз http://blog.nimbledroid.com/2016/05/23/memory-leaks.html

йюп, чистил табы вот нашел как раз http://blog.nimbledroid.com/2016/05/23/memory-leaks.html

Еще по теме https://stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java

к спору выше: все же помнят, что string умеет конструироваться из (const char* it_begin, const char* it_end), причем для литералов будет нерабочий код?

Еще по теме https://stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java

про неявные утечки памяти речь?

Moved to #holywar s

Алекс, что за фигня: вбросы про джаву и "си++ несовсместим с перформансом" - это ок, а разговор про смарты - холивар? dafuq?

Алекс, что за фигня: вбросы про джаву и "си++ несовсместим с перформансом" - это ок, а разговор про смарты - холивар? dafuq?

¯\_(ツ)_/¯

Алекс, что за фигня: вбросы про джаву и "си++ несовсместим с перформансом" - это ок, а разговор про смарты - холивар? dafuq?

это не ок, надо подчистить тож

Так нет же разницы между в С++ и яве

Так нет же разницы между в С++ и яве

откуда в жаве множественное наследование?

откуда в жаве множественное наследование?

ну они там говорят про то, что интерфейс не наследуется, а реализуется, но ничо не меняется же

Не факт. В даже фактически унаследоваться можно не более, чем от одного класса, но реализовать сколь угодно много интерфейсов

А какая разница снизу? Будет тот же самый QueryInterface код, только в С++ это будет QuerySomeBase

ну они там говорят про то, что интерфейс не наследуется, а реализуется, но ничо не меняется же

Разница в том, что интерфейсы не имеют state'а, а значит не возникает проблем из-за наследования одного и того же базового класса несколько раз

Разница в том, что интерфейсы не имеют state'а, а значит не возникает проблем из-за наследования одного и того же базового класса несколько раз

А что ява делает, если несовместимые перегрузки получаются?

А что ява делает, если несовместимые перегрузки получаются?

Не компилит, думаю

Не компилит, думаю

йеп

Список книг, видео и курсов по машинному обучению и математике, всё на русском языке. Большая, качественная подборка. Почти все pdf'ки книг гуглятся. https://ru.stackoverflow.com/a/683632/1084

Список книг, видео и курсов по машинному обучению и математике, всё на русском языке. Большая, качественная подборка. Почти все pdf'ки книг гуглятся. https://ru.stackoverflow.com/a/683632/1084

Русскоязычные источники обычно уже устаревшие (кроме самой базы)

Вообще то в топе там самый свежак

Но есть и классика да, она может быть старая, но никогда не теряет акутальности, её просто надо знать

Русскоязычные источники обычно уже устаревшие (кроме самой базы)

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

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

вот да)

бред изучать мл на русском

макрос: #define $Test(casename) void casename (testing::TestCase* test) используется так: $Test(verifyCase) { //... } $Add(verifyCase) хотелось бы исбавиться от $Add и при вызове макроса $Test зарегистрировать созданную функцию в глобальном объекте типа: ... testing::Test::getInstance().define( casename ) ... но к сожалению ДО определения функции этого сделать не получается по очевидной причине, взять function body в качестве параметра макроса не могу, ибо тогда весь body inline'ится в одну строку и __LINE__ отображает конечную строку макроса есть какой нибудь Workaround?

бред изучать мл на русском

основы, почему нет?

макрос: #define $Test(casename) void casename (testing::TestCase* test) используется так: $Test(verifyCase) { //... } $Add(verifyCase) хотелось бы исбавиться от $Add и при вызове макроса $Test зарегистрировать созданную функцию в глобальном объекте типа: ... testing::Test::getInstance().define( casename ) ... но к сожалению ДО определения функции этого сделать не получается по очевидной причине, взять function body в качестве параметра макроса не могу, ибо тогда весь body inline'ится в одну строку и __LINE__ отображает конечную строку макроса есть какой нибудь Workaround?

есть, взять нормальный тестинг фреймворк в котором это уже сделано все, например gunit

есть, взять нормальный тестинг фреймворк в котором это уже сделано все, например gunit

на то что я сейчас делаю есть причина, а именно асинхронность кода, асинхронный код в существующих фреймах неудобно тестить

мне норм

мне норм

в смысле?

основы, почему нет?

Но зачем?

язык пушкина, есенина и маяковского

язык пушкина, есенина и маяковского

... который непригоден в сфере программирования :)

зря вы так

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

в смысле?

в смысле тестирую асинхронный код в Catch и boost.test и все норм

язык пушкина, есенина и маяковского

У кого из них клёвые статьи по машинлернингу стоит почитать?

в смысле тестирую асинхронный код в Catch и boost.test и все норм

а как именно, поясни плиз

давай зачётку

Английский сейчас - как латынь раньше, изучать что-то на других языках (научно/техническое) - контрпродуктивно

Английский сейчас - как латынь раньше, изучать что-то на других языках (научно/техническое) - контрпродуктивно

??

Да это ясно, я ж шучу

Просто есть такая штука как языковой барьер

Просто есть такая штука как языковой барьер

И чтобы побороть его, необходимо практиковаться

а как именно, поясни плиз

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

короче суть в том, что мой вопрос относится не к unit-testing'у а functional testing'у в котором доказывается верная работоспособность асинхронных сущностей.. придам пример (грубый, но пойдёт) testCase() { readFile("/this/file.txt", [](std::string result) { // will never execute ASSERT(result, expected) }); } testCase не дождётся результата и завершится, ASSERT никогда не проверится

для того чтоб тест правильно выполнился нужно изменить его немного: testCase(test) { readFile("/this/file.txt", [](std::string result) { ASSERT(result, expected) test.finish() }); }

в данном случае тест либо дождётся вызова асинхронного callback'а либо timeout'ит

testCase() { readFile("/this/file.txt", [](std::string result) { ASSERT(result, expected) future.set(true); }); future.waitWithTimeout(); }

в данном случае тест либо дождётся вызова асинхронного callback'а либо timeout'ит

не вижу где его просят таймаутить в данном случае, тут finish() такой же кривой костыль как done() в моче и прочем джаваскриптовом чае

ERROR: S client not available

библиотека которую я хочу протестить не столь проста streams.create([](handle) { handle.close("data") }) .attach([](data, handle) { ASSERT(data, "data") handle.fail("fuck") }) .failure([](error, handle) { ASSERT(error, "fuck") }) в данном случае мы создаём асинхронный объект, который при закрытии запускает при'attach'енный второй объект

короче говоря: нужно доказать, что control flow шёл правильным путём и что данные были верно переданы

и ты пишешь для этого тестинг фреймворк?

я пытаюсь протестировать код)) но не могу найти правильный подход

т.е. создать просто несколько future'ов и ими блокировать завершение тестовой функции?

а с макросами я просто эксперементирую, может и так можно решить проблему

кстати.. почему finish() это костыль, интересен аргумент(ы)

я бы разложил фьючеры по пути следования и в конце подождал чтобы они все стали с верными значениями

кстати.. почему finish() это костыль, интересен аргумент(ы)

я уже не помню как оно работало в моче или в чае, но когда начали его портировать на промисы и асинхронщину, любой забытый done() превращал отладку в ад - тест мог не закончиться или закончиться с непонятной совершенно ошибкой глубоко в кишках тест фреймворка. в ++ типизация построже конечно, но лучше не делать _специальный_флаг_завершения_теста_ пушо его всяко кто-нибудь забудет вызвать в замороченном случае и будет плеваться. с твоим вложенным путем исполнения где надо finish() а где не надо? да пофиг на самом деле, он ведь асинхронный, а ожидать выполнения мы должны в основном треде если толково это делать

в моём эксперементальном решении это невозможно, ставится определённый timeout, по истечению которого кейс убивается, т.е. если кто-то где-то забыл done() вызвать то этот кейс в результатах будет помечен как fail (timeout)

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

что если одни асинхронные операции завершаются за 1 секунду а другие за 100?

есть default timeout, который определяется всем кейсам, да

У кого из них клёвые статьи по машинлернингу стоит почитать?

Вапник, Червоненкис внесли большой вклад в машинное обучение, и книги написали, втом числе и на русском есть.

ну то есть ты не можешь сделать в одном тест кейсе три фьючера и ждать один с таймаутом 1, второй с таймаутом 10 и третий с таймаутом 100?

что если одни асинхронные операции завершаются за 1 секунду а другие за 100?

в таком случае можно определённым кейсам определять индивидуальный timeout, который перепишет default'ный

кейсам да

а путям внутри одного кейса?

кейс он неделимый

ну ок, твои кейсы тебе и решать

ты ему определяешь таймаут, если кейс не завершается, например по причине забытого done(), тогда - failure (timeout)

кейсы не должны быть слишком большими, забыть done() не так легко, ибо просто будет постоянно таймаутить, а значит что-то не так

я уже не помню как оно работало в моче или в чае, но когда начали его портировать на промисы и асинхронщину, любой забытый done() превращал отладку в ад - тест мог не закончиться или закончиться с непонятной совершенно ошибкой глубоко в кишках тест фреймворка. в ++ типизация построже конечно, но лучше не делать _специальный_флаг_завершения_теста_ пушо его всяко кто-нибудь забудет вызвать в замороченном случае и будет плеваться. с твоим вложенным путем исполнения где надо finish() а где не надо? да пофиг на самом деле, он ведь асинхронный, а ожидать выполнения мы должны в основном треде если толково это делать

а нельзя такой флаг толкать как shared_ptr

или тестирование такое, что наличие лишнего барьера памяти все поломает?

а нельзя такой флаг толкать как shared_ptr

это было в джаваскрипте, там нету shared_ptr в принципе

с future'ами проблема идентичная... если неправильно выставить timeout'ы или забывать завершать future... но там будет больше boiler plate кода чем с done()

это было в джаваскрипте, там нету shared_ptr в принципе

ну мы-то за плюсы

у future уже есть флаг, done() вводит глобальный стейт в тесткейсы, который в целом не нужен

на уровне тест-фреймворка это ненужная сущность