Думай Головой: Книжки про успешных людей - все лажа. Не говоря о критериях "успешности" - сегодня о нем книжку лживую пишут о том, почему он такой успешный и сказки сочиняют, как про дедушку Ленина - а завтра, глядишь, он компанию до банкротства довел и от кредиторов бегает.
Такие книжки хороши только для тех, кто их продает.
link00: И по поводу 8000 или 8000000 полей. Там, где они объективно нужны, нужна СУБД, которая их поддерживает. Даже если ее самому писать придется. Только где они объективно нужны? Для интернет-магазина?! Зачем?!
link00: Не вижу связи. Если мы создаем отдельные таблицы для отдельных категорий, то о какой вообще основной таблице идет речь? Ее не будет. Если мы ее хотим иметь, то должны четко определиться с теми полями, которые принципиальны для поиска. По ним она будет разрежена, ибо они будут не у всех товаров. Что непринципиально для поиска - сериализовать.
По поводу изменчивых данных - так ведь не так-то они и изменчивы. И не могут быть изменчивы. Не должны. Иначе получается описанный мной позор - два смартфона сравнить нельзя - из-за того, что изменчивость прикручена там, где ею и пахнуть не должно. Фейспалм.
link00: А тут ведь так вопрос и стоит - школота SQL освоить не может и что такое нормализация не понимает - еще бы, читать то он ничего не хочет. Какой тут noSQL. Я так думаю, что noSQL для грамотных.
link00: Конечно, речи о том, чтобы походу кроить таблицу не шло. Речь шла о том, что при желании можно выделить столбцы, необходимые для поиска, остальное хранить в отдельном поле. А таблицу больше не трогать никогда (т.е. до следующей версии).
Другая альтернатива - создавать отдельные таблицы для отдельных категорий и их обрабатывать отдельно. Внутри одной категории структура таблицы очевидна.
По поводу noSQL - штука, наверное, мощная, но, согласитесь - это бред, когда школьник неспособен освоить эвклидову геометрию и кричит, что будет использовать геометрию Лобачевского - ему де евклидовы аксиомы мешают.
link00: Ага, и потом плавать в этой неструктурированной штуке, которая будет выдавать что попало. Куча, куча примеров - заходишь вроде в крупный магазин, а у них два смартфона по характеристикам сравнить нельзя - потому что каждый пишет что попало и куда попало, создавая для этого все новые и новые поля. А в итоговой таблице сравнения то одного нет, то другого - а то и то же самое в разных параметрах написано.
Если база требует 8000 таких обязательных полей, то там должно быть 8000 обязательных полей, да еще и проверки вводимых значений не помешали бы. А раздолбайство в заполнении базы до добра еще никого ни разу не доводило.
Ага, разделит работу по кускам, организует субподряд, а потом его этот дурной работодатель кинет :) Выйдет он такой к коллегам и скажет - не судите строго, платить нечем, я теперь сам с голой попой. Подайте на поддержку штанов до первой получки...
Верно. Пусть тот, кто дает невыполнимое задание, даст его в письменном виде. Где и отдельно укажет, что с тем, что это непрофильный язык и документация отсутствует ознакомлен.
Adamos: С этим не согласен. Практика вторична. Концепция первична. Может, завтра практика концепцию STL поломает, что же теперь, вместе со всеми в колодец прыгать?
MiiNiPaa: Тут, конечно, нельзя не признать, что ходить по кругу, чтобы набирать порядок тоже не менее странная затея - отчего бы тогда не отсортировать для начала? :)
Может, для поиска циклических перестановок фрагментов и правда сгодился бы :)
Вообще, для одномерного контейнера сомнительно как-то, чтобы нужно было. Просто альтернативный взгляд на запрятывание цикла в алгоритм получается. Но я б не стал бы, наверное, его туда прятать - неожиданно слишком, засада прям, ребус, читателей кода с толку сбивать :))) Читаешь так код - ну, алгоритм какой-то задали, хрен знает, наверное, что-то поэлементно с контейнером делать собрались, а рекурсия-то где? :)))
MiiNiPaa: Да, но налицо его избыточные функции. Зачем ему знать пределы контейнера и текущее положение в нем? Это вроде как не его функция.
То есть действительно получается, что циклический контейнер был бы избыточен, циклический итератор недопустим, а вот алгоритму всякими фокусами, рекурсиями и повторными циклами заниматься никто не запрещает, правильно? :)
Сначала оно меня заинтересовало просто так, как диковина - почитал книжку Сферляндия, а там Циркуляндия описана, с жителями, которые убеждены, что живут на бесконечной прямой, а сами сидят в замкнутой окружности. Сразу стало интересно, а в STL контейнерах такое возможно? :) Поглядел что на stackoverflow народ пишет, забавно оказалось.
По поводу функций для этого чуда. Тоже думаю, дело для него может найтись. Все-таки если сидеть и ждать пока кто что добавит... Ну может быть, хотя добавлять туда, думаю, несколько сложно. Чтобы знать, куда добавить, надо знать где он сейчас, а снаружи это не очень удобно. Есть ведь более совершенные средства ждать, чем просто по старинке ходить по кругу.
Мне почему-то видится std::list из которого выбирают элементы, на вылет, вне зависимости от текущего положения, но в соответствии с порядком уже выбранных элементов до тех пор, пока алгоритм не обнаружит, что выбрал все и контейнер пуст. Это задачка с количеством циклов, зависящей от порядка в контейнере и его длины.
Человек, который на stackoverflow интересовался, хотел бы проверять строки на возможность циклических перестановок, таких, когда середина строки оказывается в начале, а начало оказывается в конце. Что-то в этом роде. Вряд ли ему бы для этого понадобилось больше двух циклов, хотя кто знает.
Главный же и удивительный для меня вывод из этой истории заключается в том, что алгоритмы STL могут быть более глубокой вещью, чем это кажется. Линейное устройство самых простых контейнеров провоцирует нас на то, чтобы и алгоритмы мы воспринимали как какую-то линейную штуку. А ведь он не обязательно должен быть линейным.
Интересное математическое рассуждение. Интересно, а где можно почитать о математике, лежащей в основе идеи STL контейнеров и generic programming в целом? Ну, чтобы не рушить их концепций, незаметно для себя. Ведь под этим подходом явно лежит какая-то алгебра. И в этом совершенство их подхода. К каким разделам математики это вообще относится?
Таким образом, исходя из Вашей формулировки, реализация соответствует критериям валидности и разыменовываемости, но условие достижения конца итератором не выполняется, что и определяет его непригодность.
Вообще, замечательная формулировка. Собственно, для практика, когда мы запускаем алгоритм по контейнеру, или просто хотим проитерировать его содержимое принятым способом, мы, естественно, не ожидаем, что запустим бесконечный цикл. Концепция STL вроде бы не подразумевает такой засады :) Но это одна и та же вещь, только в разных формулировках...
Кстати, а если мы хотим невозбранно гулять по кругу в STL контейнере, может быть, алгоритм мог бы взять на себя работу по отслеживанию положения итератора и его подмене в момент достижения конца контейнера? Он исполняет, ему бы и знать когда пойти на новый круг, а когда остановиться? Такой алгоритм нарушил бы концепцию STL, как Вы думаете?
fshp: Хех :) Кстати, понял, что упрекать multi_array в отсутствии у него возможности задать базовый одномерный контейнер как минимум забавно :) Семен Семеныч, он же и так уже array :)))