- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
auto getMaxSize = [](const auto &vec) {
if (vec.size() == 0)
return 0;
const auto &max = *std::max_element(
vec.begin(),
vec.end(),
[](const auto &lhs, const auto &rhs){
return lhs.size() < rhs.size();
});
return max.size();
};
с другой стороны, для меня как раз это всегда и было показательным примером того что С++ компилятор "не понимает" С++: `.size() == 0` это очевидно `.empty()` но соптимизировать это компилер просто в принципе не способен.
ЗЫ тут еще давеча пытался асфильтировать граблевое поле std::sort() vs .sort(). тоже не приятно. у листа есть .sort(), а вектор надо std::sort(). специализации std::sort() для листа - нет. `std::sort( container )` тоже нет. просто мля сказка: в одном месте поменял vector на list - и я уже не помню сколько мегов/гигов был лог ошибок билда.
... а что если попробовать питоновый вариант? .size() возвращает класс, в котором перекрыты операции сравнения? там же понадобится и оператор конверсии в число. вопрос у чего будет приоритет: операторов сравнения или оператора конверсии.
в С++99 контейнеры не кэшировали колво элементов, почему вызов .size() для дерева или связного списка был тупым проходом по структуре. а .empty() это всего лишь проверка есть ли вообще элементы. в дереве - root == NULL, в связном списке - head == NULL.
Бля, он переполнение что ли ожидает и из-за этого боится выбрасывать цикл?
Сайзтэбляди соснули! Вот что UB животворящий делает!
ЗЫ не только переполнение - вечный цикл так же возможен.
ЗЗЫ переключился на icc - тот генерит цикл в обоих случаях.
што
Например:
Так как инт переполняться не может, условие всегда положительное, то есть цикл эквивалентен
Так как бесконечные циклы — UB, компилятор имеет право выкинуть его нахуй.
В результате вместо вектора наполненного числами [0, INT_MAX), можно получить bad_alloc, либо нихуя. А также ещё пару сотен весёлых случаев.
К примеру с size_t, переполнение беззнаковых отлично определено. И size() == 0 может быть true в двух случаях: если сравнение провалилось в первый же раз, или если нод настолько много, что size_t переполнилось (возможно неоднократно) и вернулось к 0. Поэтому компилятор не выкидывает цикл.
В случае с int, вариант всего один: если первое сравнение провалилось. Так как большинство компьютеров использует дополнительный код, то физически переменная может переполнится и дойти опять до нуля, но с точки зрения языка, это произойдёт только в случае наступления UB, а компилятор имеет право такие случаи игнорировать.
https://godbolt.org/g/lAi87k
Да, походу он реально пытается не потерять бесконечный цикл.
Тем более size не сохранять это вообще тупо
нет, мы делаем vec.size() === 0