чем тут не нравится подход Алгоритмы + Контейнеры + Итераторы?

Вынесение алгоритмов наружу — это как бы не самоцель, а вынужденный ход.

нет, это цель

так как тебе никто не мешает наговнокодить алгритм внутри контейнера

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

а по контейнеру пусть ходит итераторами

каково альтернативное предложение?

а нафига наследование для контейнеров? тут же duck typing. есть begin, end, size, ... - вот тебе контейнер. Всё решается во время компиляции, а не тормозится виртуальными функциями

Ну, мягко говоря, вляпывание dug typing в язык, где его нет, — странное решение, особенно для стандартной библиотеки этого языка. Виртуальные функции не особенно то и тормозят, косвенный вызов вместо обычного по адресу — ой, нашли блин тормоза.

Ну, мягко говоря, вляпывание dug typing в язык, где его нет, — странное решение, особенно для стандартной библиотеки этого языка. Виртуальные функции не особенно то и тормозят, косвенный вызов вместо обычного по адресу — ой, нашли блин тормоза.

don't pay for what you don't you use

нет, это цель

Нет, это из-за того, что нельзя полиморфно было представить доступ к членам абстраткной коллекции.

Ну, мягко говоря, вляпывание dug typing в язык, где его нет, — странное решение, особенно для стандартной библиотеки этого языка. Виртуальные функции не особенно то и тормозят, косвенный вызов вместо обычного по адресу — ой, нашли блин тормоза.

вирт. вызовы тормозят. Ты забыл главную идею языка С++ что ле?))

don't pay for what you don't you use

Ну это слова всё.

Нет, это из-за того, что нельзя полиморфно было представить доступ к членам абстраткной коллекции.

да, нельзя без лишних накладных расходов, которые никому не нужны

Ну это слова всё.

это не слова. Это идеология

посмотри, как на это дрочат в комитете

и лично я поддерживаю их позицию.

каково альтернативное предложение?

Не, сейчас STL менять не надо. никаких предложений нет. А, есть — внедрить BOOST:::RANGES туда , с ними контейнеры и алгоритмы заметно выпрямляются.

Не, сейчас STL менять не надо. никаких предложений нет. А, есть — внедрить BOOST:::RANGES туда , с ними контейнеры и алгоритмы заметно выпрямляются.

Rangesv3 стараются попасть в С++20

посмотри, как на это дрочат в комитете

Ну это вообще извращение — смотреть , как другие ....

Eric Niebler сказал, что забивает на буст ради С++20

Ну это вообще извращение — смотреть , как другие ....

на вкус и цвет ?

Rangesv3 стараются попасть в С++20

Так почему не в 11-ом?

вместо полиморфизма идеально заходит разрешение всего на шаблонах и концептах, без нагрузки в рантайм

Главную кривизну стандартной библиотеки — и НЕ ХОТЯТ ИСПРАВЛЯТЬ!

Так почему не в 11-ом?

Причина в том, что С++11 и так получился очень большим релизом. Много фичей просто туда не пихали

где-то статья была на эту тему

А люди это говно учат, привыкают, и уже думают , ЧТО ТАК И ДОЛЖНО БЫТЬ!

А люди это говно учат, привыкают, и уже думают , ЧТО ТАК И ДОЛЖНО БЫТЬ!

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

Я попробую ... ?

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

нет, не будем. Потому что меня, как пользователя, концепция STL устраивает целиком и полностью. А после ввода концептов пртенезии и вовсе уйдут

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

нет, не будем. Потому что меня, как пользователя, концепция STL устраивает целиком и полностью. А после ввода концептов пртенезии и вовсе уйдут

не будем конечно, не напишет же

Ну , это конечно да. Это просто супер тоже решение было — вляпать в стандартную библиотеку решение , которое языком не очень и поддерживается.

Ну , это конечно да. Это просто супер тоже решение было — вляпать в стандартную библиотеку решение , которое языком не очень и поддерживается.

а что ты хочешь альтернативное?

Ну ладно, холиварить больше не буду...

Ну это вообще извращение — смотреть , как другие ....

Как что-то плохое.

твоя идея на полиморфизме не пройдёт

когда Степанов предложил свой подход, СТЛ был почти готов

Rangesv3 стараются попасть в С++20

А чем Rangesv3 от обычных отличается ? Или это просто версия ?

когда Степанов предложил свой подход, СТЛ был почти готов

?

Ну , это конечно да. Это просто супер тоже решение было — вляпать в стандартную библиотеку решение , которое языком не очень и поддерживается.

степанов пытался эту концепцию на разных языках реализовать и именно на плюсах это получилось и было наиболее естественно.

но как увидели его идею, то всё депрекейте=нули и взяли вариант степанова

степанов пытался эту концепцию на разных языках реализовать и именно на плюсах это получилось и было наиболее естественно.

++

А чем Rangesv3 от обычных отличается ? Или это просто версия ?

версия. в ренджах я несилён

степанов пытался эту концепцию на разных языках реализовать и именно на плюсах это получилось и было наиболее естественно.

Боюсь, что вы выдаёте желаемое за действительное.

Боюсь, что вы выдаёте желаемое за действительное.

у меня и пруфы были где-то, или в чем имено сомнение?

Сомнения в двух вещах: что это на С++ получилось естественно. Это НИХЕРА не естественно, особенно было тогда, когда он появился (язык С++ слегка поменялся). И 2) — что самая естественная реализация была именно на С++.

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

А чем Rangesv3 от обычных отличается ? Или это просто версия ?

Ну... тем, что они работают с C++11,14,1z хорошо ;)

Я как бы хочу напомнить, что достаточно долгое время STL-я во многих компиляторах просто не было, потому что компиляторы не могли его скомпилировать.

Ну... тем, что они работают с C++11,14,1z хорошо ;)

Дизайн другой, если помню правильно

Я как бы хочу напомнить, что достаточно долгое время STL-я во многих компиляторах просто не было, потому что компиляторы не могли его скомпилировать.

и это проблема STL?

если либа соответствует стандарту, а компилятор нет, то это его проблемы

И говорить, что тогда, в те времена, это решение было именно ЕСТЕСТВЕННО для языка, когда компиляторы его просто тупо не поддерживают ещё — это как-то странно.

и это проблема STL?

Это проблема языка С++. и его стандартной библиотеки

Это проблема языка С++. и его стандартной библиотеки

нет, это проблема компиляторов языка С++

если либа соответствует стандарту, а компилятор нет, то это его проблемы

Ты 80-90-е то вспомни, сейчас легко такое говорить, да...

Ты 80-90-е то вспомни, сейчас легко такое говорить, да...

какие к чёрту 80-90? я 1997 года рождения. Я толком С++03 не видывал в жизни

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

Взял один компилятор, не понравилось, взял другой...

какие к чёрту 80-90? я 1997 года рождения. Я толком С++03 не видывал в жизни

А, молодой ищщо....

ну тут такое дело, как всегда. не нравится - не юзай. это не кор язык, а библиотека, которую ты волен выкинуть и юзать все, что душе угодно

И, кстати, STL -то появился, елси я правильно помню, ещё и ДО стандарта.

и не наговаривать на хороших людей

Это Степанов-то хороший ?

Это Степанов-то хороший ?

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

А это что ? http://www.cplusplus.com/reference/vector/vector/empty/

Что это за уродство?

ERROR: S client not available

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

Это пример как во всех книжках пишут про то, как не надо называть методы.

Что это за уродство?

А что не так?

А что не так?

надо is_empty()

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

Ага, КТО МЕШАЕТ БЛИН СДЕЛАТЬ ОДИН ПРОСТОЙ СИНОНИМ ФУНКЦИИ ?

надо is_empty()

А, ну так, был ли ваще в те времена такой путь?)

Ага, КТО МЕШАЕТ БЛИН СДЕЛАТЬ ОДИН ПРОСТОЙ СИНОНИМ ФУНКЦИИ ?

НЕ КРИЧИ

ахахахахха

Какой блин путь, англицкий язык не знают? три буквы дописать было лень ?

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

там были реально поломанные функции вроде, std::max?

С max были долго другие проблемы — реализовался макросами во всех (не очень) стандартных библиотеках, и перекрывал std-шный в жопу...

надо is_empty()

надо как в руби empty? :)

Можно и так

Итак.

Кто мешал max назвать greatest?

Делаем пропозал для переименования методов?)

Кто мешал max назвать greatest?

А это не синонимы?

Нет. ПОздно уже.

Нет. ПОздно уже.

Почему?

Никогда не поздно.

Вот Ranges надо поддержать. В 17-ом

Ну, хотя, можно и добавить.

Пускай на пару версий языка будут депрекейтед empty всякие и введены дублем is_empty

И всё будет ништяк.

Ну, в общем хорошее решение.

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

Ну, в общем хорошее решение.

Пиши пропозал!

Вот прям щас!

и дешёвое.

да, закидывай свои идеи в Google Groups [std-proposals]

там тебе Thiago Maciere всё расскажет