это обозначает, что в многопоточной среде в условиях когда доступ к объектам stl'a идет раздельно ничего само не взорвется

alexvs11, и какое нам дело до "The SGI implementation of STL" ?

alexvs11

1. В visual C++ (по умолчанию) стоит dinkumware, а не SGI.
2. 

это означает, что доступ к разным контейнерам, разными потоками безопасен (еще бы, только этого нам не хватало  )


чтение общих контейнеров потокобезопасно, это гарантия реализации от SGI, тем не менее стандарт такой гарантии не дает.


Вот он! Контейнер потокобезопасен для чтение, но не для записи. Если мы вернемся к исходнику в первом посте, мы увидем, что ТС пытается удалить элемент из контейнера, что никак нельзя назвать чтением.

и к std::istream ?
если говорить только о SLT-контейнерах, то понятно, что вызsвать функции для чтения можно из разных потоков, правда никто не гарантирует, что сами потоки не будут изменять содержимое. Например, если вызывать ф-цию begin() из разных потоков, то она гарантировано вернёт одно и то же, если же в самом потоке писать в этот инетратор, то ...

так что говорить, что

некорректно


в студии используют Hewlett-Packard implementation, насколько я знаю.

вы не поверите

alexvs11

Заметье, я ничего не писал по поводу второго сообщения. Я возразил против первого. Или вы продолжаете утверждать, что студийная реализация STL потокобезопасна?

они прародители стандартного стла, привык читать маны оттуда, согласен что он не является стандартным на текущий момент
http://www.sgi.com/tech/stl/
внизу подпись 

между прочем

Добавлено @ 16:11

я неправильно выразился, этим имел в виду, что если синхронизация правильная, то проблемы у автора, а не у stl'a
а в многопоточной среде бывает что и при синхронизации работает не так, взять тот же небезопасный CreateThread и безопасный _beginthread

Это сообщение отредактировал(а) alexvs11 - 17.2.2011, 16:13

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

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

Это сообщение отредактировал(а) alexvs11 - 17.2.2011, 16:50

а почему, если я добавлю в deque такие ф-ции

я "нарушу локическую полноценность" ?
mes, если не сложно, можете на конкретном примере пояснить, почему же наследоваться от stl - не есть хорошо ? Объяснение "а вот тут ты сам можешь потом забыть и (не)использовать эту штуку" - принимаются. Спасибо.

да, так. хотя телепатия подсказала что break там скорее для оптимизации.

Добавлено @ 17:11
перенесено в соответствующую тему.. 



Это сообщение отредактировал(а) mes - 17.2.2011, 19:07

borisbn, концептуально наследование должно использоваться для специализации одной сущности к другой, общему deque к конкретному MyDeque, так чтобы конкретный MyDeque мог использоваться как специализированный MyDeque и как общий deque
но тут возникают две концептуальные проблемы
1) стандартный deque не предназначен для специализации ( отсутствие виртуальных функций, protected полей итп ).
2) само отсутствие виртуальных функций делает невозможное использование вашего MyDeque как общего deque

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

Это сообщение отредактировал(а) alexvs11 - 17.2.2011, 17:20

тут больше подходит не "связанность", а "сцепление" или "зависимость".. 


Это сообщение отредактировал(а) mes - 17.2.2011, 17:32

согласен на 99,9(9). создал