Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > C/C++: Для новичков > Какое зло может нести в себе STL ?


Автор: TupDub 10.12.2012, 22:28
Часто использую stl, да почти всегда! Лениво пишу после инклудов
Код

using namespace std;


И наслаждаюсь процессом. Но слышал, что так делать не хорошо, особенно в больших проектах!

Собственно почему ? 

И в общем, какое зло может нести в себе STL ? Какие он имеет минусы ?

Спасибо!

Автор: NoviceF 10.12.2012, 22:34
саттер александреску стандарты программирования на с++

Правило 59. Не используйте using для пространств имён в заголовочных файлах или перед дидективой #include

Добавлено через 1 минуту и 38 секунд
И кстати, при чём здесь STL? )

Автор: TupDub 10.12.2012, 22:38
ОК, STL как частный случай. Просто я его очень часто юзаю, не задумываясь глубоко. Можете пояснить свой ответ примером ? 

Автор: NoviceF 10.12.2012, 22:50
Цитата(TupDub @ 10.12.2012,  23:38)
ОК, STL как частный случай. Просто я его очень часто юзаю, не задумываясь глубоко. Можете пояснить свой ответ примером ?

Открой, плс, указанную книжечку, там толковое пояснение с примерами. Но вкратце, если помещаешь объявление using, перед какой-либо директивой #include, тем самым ты распространяешь действие using на весь включённый #include код, который к этому может быть совсем не готов. Например, может вызываться не то, что ты рассчитываешь, если конкретное имя есть в #include и в std::. Лично на практике не сталкивался (т.к. её пока толком нет), но смысл мне видится таким.

Автор: TupDub 10.12.2012, 22:54
Ок, книгу почитаю, спасибо! Но у меня остался вопрос про STL ? Форумчане, так ли хороша эта библиотека, везде ли или может, где-то лучше без неё ?

Автор: Фантом 10.12.2012, 23:48
Цитата(TupDub @  10.12.2012,  23:28 Найти цитируемый пост)

И наслаждаюсь процессом. Но слышал, что так делать не хорошо, особенно в больших проектах!
Собственно почему ? 


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

Цитата(TupDub @  10.12.2012,  23:54 Найти цитируемый пост)
Но у меня остался вопрос про STL ? Форумчане, так ли хороша эта библиотека, везде ли или может, где-то лучше без неё ?

Где-то, безусловно, лучше без нее. Где-то лучше с ней. В общем случае, без уточнения области применения, вопрос лишен смысла. 

Автор: NoviceF 11.12.2012, 07:21
Цитата(Фантом @  11.12.2012,  00:48 Найти цитируемый пост)
Где-то, безусловно, лучше без нее. 


Я вот немного сталкивался с кьютом, и там часть функционала STL дублируется (может быть и весь, сильно не вникал), вот есть смысл использоваться STL с кьютом (там всё таки есть какая-то обратная совместимость)? Или стоит учить функционал кьюта и по максимум использовать его (ну в приложениях на кьюте ессно)?

Автор: kosmonaFFFt 11.12.2012, 07:29
Например написав using namespace stl; using namespace boost; рискуешь нарваться на конфликты имен... Я например так сталкивался с конфликтом boost::exception и std::exception...

Автор: azesmcar 11.12.2012, 09:48
Цитата(NoviceF @  11.12.2012,  07:21 Найти цитируемый пост)
Я вот немного сталкивался с кьютом, и там часть функционала STL дублируется (может быть и весь, сильно не вникал), вот есть смысл использоваться STL с кьютом

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

Цитата(TupDub @  10.12.2012,  22:54 Найти цитируемый пост)
Форумчане, так ли хороша эта библиотека, везде ли или может, где-то лучше без неё ?

Где-то лучше, но в 90% случаев с ней лучше smile
Скажем так: пока ты не знаешь в каких случаях он НЕ нужен - смело его используй. STL может здорово облегчить жизнь.

Автор: TupDub 11.12.2012, 11:51
Всем спасибо! Буду читать внимательно стандарты! Вопрос решён! 

Автор: NoviceF 12.12.2012, 12:04
Кстати о примерах, только что столкнулся с конфликтом имён функций bind из API сокетов и STL - вот и using namespace std. В моих микрозадачах это, конечно, не критично.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)