Ivan
Внутри объявления цикла можно
Ivan
for (unsigned i = 0; auto& x : thing.items(); ++i) {
// ...
}
вот так чё не сделали?
Aidar
Aidar
Достаточно enumerate
Anatoly
Это слишком ява-питонно)
Я бы предложил идею с огранизацией неких потоков.
Вот эта конструкция auto &item : container - это как-бы поток.
А я в цикле таких потоков хочу несколько как-бы
for ( auto &item : container, auto &z : vect, auto &i : int_generator )
Я параллельно иду по двум контейнерам container и vect и ещё у меня есть i сгенерированное генератором - это мой номер итерации)
Трёхпоточный цикл, мать его за ногу.
Один из потоков просто поток интов от нуля.
И генератор может быть не простой, а озорной - например от -100 до +1000 с шагом 5
Цикл останавливается когда минимальной длины поток сдох.
дык юзай range:
using ranges::v3::view::zip;
using ranges::v3::view::ints;
for(auto &&[element, idx]: zip(container, ints(0u))){
...
}
Igor
Ребят, есть ли у кого-то на примете хорошая либа для решения разреженных СЛАУ больших размерностей?
Я возможно неправ, но Blaze?
Igor
Дык есть же https://habrahabr.ru/company/yandex/blog/342354/
Можно писать в С++20
for (unsigned i = 0; auto& x : thing.items()) {
++i;
// ...
}
Чет ой. Товарищ выше про множественные continue прав; не было пропозалов про автоинкремент или что-нибудь вроде ipairs из луа?
Igor
А так это получается тот же сахар что и if (auto x=f(); if x.flag), только тут от него проку чуть меньше //как оно называется то, про переменные в ифах свичах и циклах, все время забываю
Anatoly
будем надеяться на введение ranges и эта проблема решится сама собой, см. выше
Igor
А в каком они состоянии? До TS хоть дошло?
Anatoly
А в каком они состоянии? До TS хоть дошло?
http://en.cppreference.com/w/cpp/experimental/ranges
Igor
> The Ranges TS modifies the specification of the range-based for loop to permit differently typed begin and end iterators.
и это упрощает процесс работы с "легковесные надстройками" над классическими контейнерами? zip(vector) создаёт пустышку, в которой итератор бежит по собираемым "на лету" парам?
Anatoly
> The Ranges TS modifies the specification of the range-based for loop to permit differently typed begin and end iterators.
и это упрощает процесс работы с "легковесные надстройками" над классическими контейнерами? zip(vector) создаёт пустышку, в которой итератор бежит по собираемым "на лету" парам?
дык, изучай, все же открыто: https://github.com/ericniebler/range-v3/blob/master/include/range/v3/view/zip.hpp
Vitaliy
Послали сюда)
Vitaliy
Есть кто-нибудь кто в OpenCV горазд ?
Anonymous
@zamazan4ik мб...
Anonymous
Рассказывай свою беду.
Vitaliy
Беда следующая: у cv::Mat есть метод at, у которого стоят ассерты на выход за пределы картинки. Но когда я ему передаю координаты, например (-1, -1), то всё хорошо и программа отрабатывает без фэйла. Что в дебаг, что в релизе, соответственно UB И ответы у функции разные. А теперь вопрос, когда же всё-таки эти ассерты работают ?
Vitaliy
А свои ассерты поверх at, навешивать не хочется.
Berkus
ассерты сишные работают когда задефайнено _NDEBUG
Berkus
у тебя задефайнено?
Vitaliy
у тебя задефайнено?
Я в явном виде ничего не дефайнил, разве что коллега мог намудрить с дебаг флагами в CMakeLists
Anatoly
он спит, а не завис
Vitaliy
Такой ассерт отрабатывает
Berkus
я картофель
Vitaliy
А те ассерты, что внутри at - нет.
Vitaliy
ща
Vitaliy
А код чего ? Внутренностей at или моего метода ?
Vitaliy
#ifdef _DEBUG
# define CV_DbgAssert(expr) CV_Assert(expr)
#else
# define CV_DbgAssert(expr)
#endif
Vitaliy
template<typename _Tp> inline
const _Tp& Mat::at(Point pt) const
{
CV_DbgAssert(dims <= 2);
CV_DbgAssert(data);
CV_DbgAssert((unsigned)pt.y < (unsigned)size.p[0]);
CV_DbgAssert((unsigned)(pt.x * DataType<_Tp>::channels) < (unsigned)(size.p[1] * channels()));
CV_DbgAssert(CV_ELEM_SIZE1(DataType<_Tp>::depth) == elemSize1());
return ((const _Tp*)(data + step.p[0] * pt.y))[pt.x];
}
Vitaliy
Тут он конечно хитрый
Aidar
CV_Assert это чо
Anonymous
Вот собери OpenCV с определенными _DEBUG .
Aidar
а это опенцв
Anonymous
И будут ассерты работать.
Aleksei
template<typename _Tp> inline
const _Tp& Mat::at(Point pt) const
{
CV_DbgAssert(dims <= 2);
CV_DbgAssert(data);
CV_DbgAssert((unsigned)pt.y < (unsigned)size.p[0]);
CV_DbgAssert((unsigned)(pt.x * DataType<_Tp>::channels) < (unsigned)(size.p[1] * channels()));
CV_DbgAssert(CV_ELEM_SIZE1(DataType<_Tp>::depth) == elemSize1());
return ((const _Tp*)(data + step.p[0] * pt.y))[pt.x];
}
Там что-то с беззнаковыми сравнивается. Не в этом ли дело?
Vitaliy
Там что-то с беззнаковыми сравнивается. Не в этом ли дело?
Это, кстати, хорошее замечание, но даже если передаю координаты большие, чем размер картинки, то не фейлится
Vitaliy
собирал Cmake'ом с соответствующими опциями
Vitaliy
Может он по дефолту не впилил этот флаг
Anonymous
По логике, в дебажном билде должен быть определен _DEBUG, а значит ассерты должны работать.
Vitaliy
Win 10, mingw 6.3
Vitaliy
Что меня смущает, так это то, что assert работает как ожидалось, в дебаге - фейл, в релизе - ок
Vitaliy
Заменил стандартный ассерт, на тот, что в OpenCV и в дебаге ничего не зафейлилось, видимо он действительно не работает
Max
Знатоки. Есть смысл писать Class(Class&&) noexcept = default; или default сам дает гарантию noexcept?
Anonymous
Я думаю, что дефолт будет noexcept, если все члены имеют noexcept конструктор перемещения.
Anonymous
Но это же C++, там далеко не всё так очевидно.
Max
Я вот нануглил, но однозначного ответа не нашел
Vitaliy
#ifdef _DEBUG
#pragma message(DEBUG)
#else
#pragma message(NO DEBUG)
#endif
не дебаг у меня, странно
Max
Ты читал? Если кинул, значит наверно да, тогда покажи пожалуйста, где именно в том доке про иключения написано о том, о чем я спрашивал?
Berkus
make VERBOSE=1 вы значит отрицаете?
Berkus
UNLESS
Vitaliy
Какой-то умелец в CMakeLists.txt написал вот так:
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -g -DDEBUG")
Vitaliy
Нижнего подчеркивания не было
Max
Спасибо, вчитался
Vitaliy
Вот теперь всё работает, то есть фейлится как и положено
Berkus
Какой-то умелец в CMakeLists.txt написал вот так:
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -g -DDEBUG")
это АБСОЛЮТНО бесполезные флаги, не надо их писать, cmake и так их добавит
Vitaliy
это АБСОЛЮТНО бесполезные флаги, не надо их писать, cmake и так их добавит
Эту строчку можно выкинуть считаешь ?
Berkus
можно
Vitaliy
Видимо где-то в проекте ещё налажали
Berkus
-g не нужен
Berkus
если я праивльно помню в релизе добавляется -DNDEBUG и от него имеет смысл плясать
Berkus
ща проверю
Berkus
message(STATUS ${CMAKE_CXX_FLAGS_DEBUG_INIT})
message(STATUS ${CMAKE_CXX_FLAGS_RELEASE_INIT})
дает
-- -g
-- -O3 -DNDEBUG
на cmake 3.10
Berkus
да, и он добавляется по дефолту в DEBUG и в RELWITHDEBINFO конфиги
Berkus
для этого есть -DCMAKE_BUILD_TYPE=RelWithDebInfo
Vitaliy
-DDEBUG по идее надо оставить, если он у вас используется
Не используется, просто ошиблись в CMakeLists.txt
Vitaliy
Надо -D_DEBUG
Berkus
это проще сделать через отдельный
if (CMAKE_BUILD_TYPE STREQUAL "Debug")
add_definitions(-D_DEBUG)
endif()
так по-моему понятней что это ваш личный левый флаг
Vitaliy
Berkus
стандартный NDEBUG
Berkus
Is NDEBUG standard?
Yes it is a standard macro with the semantic "Not Debug" for C89, C99, C++98, C++2003, C++2011, C++2014 standards. There are no _DEBUG macros in the standards.
Alexander "SonnySlave"
Так, кто меня звал?)
Vitaliy
Забавно, то есть OpenCV использует в качестве детектора дебага нестандартный флаг _DEBUG. Не зря день прожил )