@AnreyKazakov

Объясните, пожалуйста, зачем нужны адаптеры контейнеров. Не понимаю смысл их существования, у них и функции какие-то кривые по сравнению с функциями контейнеров... И вообще непонятно, зачем, допустим, deque запихивать в stack, если она в первоначальном варианте обрабатывается намного лучше и легче?

0

@ForEveR

AnreyKazakov, stack это stack. Он работает по несколько другому принципу, нежели дек. Адапторы контейнеров вполне удобная вещь.

1

@AnreyKazakov

Спасибо ForEveR, за такой Конкретыный ответ

0

@Andsteadur

Stack != Deque

0

@ForEveR

AnreyKazakov, Просто вы задаетет странные вопросы. Как реализован стек - дело 10-е. Это абсолютно отдельная структура данных никак не относящаяся к деку.

1

@AnreyKazakov

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

Добавлено через 1 минуту
Тем более стек как раз на базе очереди двухсторонней и реализован (по умолчанию)

0

@ForEveR

AnreyKazakov, Стек - это абсолютно отдельная структура данных (я не про С++, а вообще). Если задача требует (по логике) использовать стек - используют стек, а не дек. Это же логично, разве нет? Плюс к тому, адапторы не имеют итераторов, они имеют ограниченный доступ к элементам и ограниченное кол-во функций. Собственно, несколько не логично пытаться забрать из стека 3-й элемент, не кажется?

1

@AnreyKazakov

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

0

@I.M.

AnreyKazakov,
Например задача разбора мат/выражения - подсчета открывающих/закрывающих скобок. Используется стэк.
Пример очереди - какое-нибудь клиент-серверное игровое приложение, которое формирует сессионные игры в порядке живой очереди подключившихся.

С вашей логикой - вы выкинете все контейнеры, кроме какого-то одного. Зачем нам vector и queue, если есть deque?

1

@AnreyKazakov

Ага
Кстате, я одну задачу в таком роде так и не решил ....
Надо было найти количество возможных вариантов расположения скобок в уравнении, если 3 пары, то варианты возм: ()()() , (())() , ()(()), (()()) , ((())) . Ну, я думаю, сейчас то уж точно решу, с адапторами.... =)

Добавлено через 1 минуту
А там количество пар по моему 7 равно было, так и не придумав вариант написания программы я перебрал вручную, минут за десять, но не угадал с ответом =((

0

maxon887

Вот! Тот же вопрос зачем он нужен не понимаю? Суй везде vector и list да и всё? нет?
Надо тогда какую нибудь статистику провести чтоле, по производительности. Или про реализацию его почитать?

0

Croessmah

Нарисуйте себе на листе бумаги дек, вектор, лист и стек. Разница будет видна.

0

silent_1991

Когда программа пишется на высоком уровне, тем более с использованием ООП, необходимо понимать, что программист работает с программными объектами на некотором уровне абстракции. Если по логике задачи нужна именно стековая структура - логичнее, нагляднее, и, главное, с сохранением уровня абстракции нужно выбрать именно стек. Можно и вектором не пользоваться (абстракция, представляющая чёрный ящик-динамически расширяющуюся последовательность однотипных элементов), а использовать динамические или вообще здоровенные статические массивы. Но если задача по логике требует контейнер, динамически расширяющийся во время исполнения программы, то стоит использовать вектор. Ведь это тоже абстракция - динамическое расширение. На самом деле ничего не расширяется, а просто когда места не хватило - создаётся новая, большая по размеру область памяти, и туда копируются все старые данные, а старая область памяти удаляется. Но на некотором уровне абстракции мы видим именно динамическое расширение.

2

maxon887

"Абстракция" - не нравиться мне это слово.Мол не твоё это дело как оно там работает(((((

0

Croessmah

откройте фаил и посмотрите =)

0

@Kastaneda

Так и есть, программиста не волнует, что внутри контейнера, главное, что он работает так, как задокументировано.
Другими словами абстракция позволяет программисту абстрагироваться от внутреннего устройства контейнера (или чего-то дргугого).
Например потоки в/в тоже абстракция. Чтоб вывести слово на консоль мы используем оператор <<, этот же оператор мы используем, чтобы записать слово в файл. А то, что там вызываются совершенно разные функции, нас это не волнует. А то, что это ни какие не потоки, а объекты совершенно определенных классов, там это вообще дело десятое.

0

silent_1991

В этом заключается суть ООП, в частности, одного из его китов - инкапсуляции. Как бы вы логичнее всего организовали std::vector, что вам приходит в голову? Мне лично сразу приходит в голову хранить его как указатель на начало выделенной памяти и размер. Ан нет, разработчики, например, реализации stl в gcc посчитали, что удобнее хранить вектор как адреса начала и конца памяти. Таким образом, при вызове метода std::vector::size размер вычисляется как разность этих адресов. Но программисту-то на эту подробность наплевать, ему главное, чтобы вектор свои задачи выполнял, не больше, не меньше.

0

@diagon

Хотя бы для быстродействия. Допустим, что вам нужен именно стек(может понадобиться для различных алгоритмов). Допустим, что вы пишите под gcc и внезапно вам нужно перейти на студию. Если в gcc стек, реализованный через дек, был в несколько раз быстрее стека, реализованного через вектор, то в студии дек реализован через опу и беспощадно тормозит.
Тогда вы просто изменяете объявление своего стека с stack<int> на stack< int, vector<int> >
...
Профит.

0