using namespace std и std:: надоело смотреть!

Про вызов статического метода...

A data or function member of a class may be declared static in a class definition, in which case it is a static member of the class. A static member s of class X may be referred to using the qualified-id expression X::s; it is not necessary to use the class member access syntax (5.2.5) to refer to a static member. A static member may be referred to using the class member access syntax, in which case the object expression is evaluated. [ Example: C++ 1 2 3 4 5 6 7 8 struct process { static void reschedule(); }; process& g(); void f() { process::reschedule(); // OK: no object necessary g().reschedule(); // g() is called } — end example ]

Вообщем никакого временного объекта естественно нет. Ну ты бы хоть книжку почитал что-ли или стандарт, прежде чем спорить, право.

Pure, о нет. Ты дико не прав. Это управление на этапе написания/компиляции, никак не на этапе выполнения. И код некомпилябельный чуть более чем полностью http://liveworkspace.org/code/... ebb185395a

пример для 1 http://codepad.org/mdbeqZHP

пример для 2 http://codepad.org/KZXSSJMW

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

в использовании пространства имен и статических функций/данных классов есть определенное сходство за исключением того, что для статических членов класса нет аналога using. на это сходство я и указал где-то в начале. в рамках такого подхода использование префиксов с указанием области видимости выглядит гармоничным и полностью вписывается в объектно-ориентированный подход. использование using, при таком рассмотрении, напоминает хук наподобие goto. может поэтому люди и пишут std::

Сообщение от vxg в использовании пространства имен и статических функций/данных классов есть определенное сходство за исключением того, что для статических членов класса нет аналога using. на это сходство я и указал где-то в начале. в рамках такого подхода использование префиксов с указанием области видимости выглядит гармоничным и полностью вписывается в объектно-ориентированный подход. использование using, при таком рассмотрении, напоминает хук наподобие goto. может поэтому люди и пишут std::

А вы сами собственно как пишите? Часто используете using? Я например пишу на работе, мы не используем директив/деклараций using (почти) потому как используем достаточно много различных пространств имен и базового по большому счету нет да и код без using мне нравится куда больше, чем такой же, но с using-ом, по крайней мере сразу понятно что к чему.

Pure, о нет. Ты дико не прав. Это управление на этапе написания/компиляции, никак не на этапе выполнения. И код некомпилябельный чуть более чем полностью

не совсем. однако в ++ namespace сделан иначе. Признаю изначально первый CHOICE был вынесен над main, от этого первая распечатка была корректна, затем внутри мэйна еще один нэймспэйс перекрывал глобальный и отрабатывала вторая распечатка, т.е. было 2 спэйса с одинаковым именем, это ввело меня в заблуждение (радостное), что в ++ так же как в АС этим можно управлять и я переместил первый спэйс внутрь, и естественно все стало на свои места). печаль)). но язык развивается и думается мне, что это поправят, если возникнет надобность. Ну а про остальное, от своих слов не отказываюсь. конфликты - это скорее от несогласованности разработки. уж это вполне очевидно. это некий "костыль" который исправляет последствия человеческого фактора

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

Сообщение от Pure не совсем. однако в ++ namespace сделан иначе. Признаю изначально первый CHOICE был вынесен над main, от этого первая распечатка была корректна, затем внутри мэйна еще один нэймспэйс перекрывал глобальный и отрабатывала вторая распечатка, т.е. было 2 спэйса с одинаковым именем, это ввело меня в заблуждение (радостное), что в ++ так же как в АС этим можно управлять и я переместил первый спэйс внутрь, и естественно все стало на свои места). печаль)). но язык развивается и думается мне, что это поправят, если возникнет надобность. Ну а про остальное, от своих слов не отказываюсь. конфликты - это скорее от несогласованности разработки. уж это вполне очевидно.

Но в любом случае это не этап выполнения. Это этап компиляции.

Сообщение от vxg часов угнетало обилием двоеточий и невозможностью впихнуть все в одну строку.

это по сути вечный спор, как и в смежных темах. УДОБСТВО.
специально что СКРЫТЬ длинные конструкции в язык ввели typedef. Поскольку длинные конструкции усложняю восприятие.
Поэтому вопрос выглядит так:
какой выбор, облегчить написание кода (в плане отсутствия конфликтов с тем что писали другие) или облегчить восприятие кода, теми кто будет его читать.
Что чаще делают пишут или читают код? Ответ даст результат в пользу одного или второго

Сообщение от Pure это по сути вечный спор, как и в смежных темах. УДОБСТВО. специально что СКРЫТЬ длинные конструкции в язык ввели typedef. Поскольку длинные конструкции усложняю восприятие. Поэтому вопрос выглядит так: какой выбор, облегчить написание кода (в плане отсутствия конфликтов с тем что писали другие) или облегчить восприятие кода, теми кто будет его читать. Что чаще делают пишут или читают код? Ответ даст результат в пользу одного или второго

Рулит в таких случаях auto (С++11).

читают чаще. поэтому и пишут std:: - сопровождение всегда ставиться на первое место.

Сообщение от ForEveR Но в любом случае это не этап выполнения. Это этап компиляции.

да. и там и там время компиляции. все верно

Сообщение от vxg читают чаще. поэтому и пишут std:: - сопровождение всегда ставиться на первое место.

читают чаще поэтому и пишут typedef стараясь уйти от громоздких конструкций вида std::kuku::boost
поскольку современные среды позволят интерактивно отобразить, что спрятано за typedef, выгодно спятать монстроконструкцию и очистить код

Сообщение от -=ЮрА=- Касательно call-ов функций и временных объектов http://codepad.org/cMk2cX9l т.е наличие объекта предполагается. Вообще же мой пост о CDialog:: преследовал следующие цели в коде можем записать CDialog::SetWindowText CDialog::GetClientRect и т.д. а можем сразу пользоваться тем что все эти функции уже унаследованы - т.е просто вызывать их по имени. Причём если мы их не перегрузим сами как я проделал это с SetWindowText то будет работать прототип CDialog::SetWindowText -> CWnd::SetWindowText но это не значит что я не могу перегрузить CDialog::SetWindowText равно как и такую же для послдеующих классов котороые наследуют CDialog. Т.е таким же образом можно использовать using namespace которая явно указывает компилятору функциями какого спейса надо оперировать и в space:: уже нет надобности

У тебя функция не статическая в твое примере (по url-у).

Юра, вы смотрели мои объяснения в чем были не правы ваши преподаватели и примеры написанные во время вашего обеда? там никаких временных объектов нет.

-=ЮрА=-,временного объекта там нет. Умей признавать ошибки.
потомок содержит в себе весь хлам от предка. при вызове функции предка, специально предок не создается, потому что предок - часть потомка и уже создан.

Но самое важное во всем этом не упорство Юры. А то, что привело к этому. Его сбило именно явное квалифицирование, что лишний раз подтверждает факт того как воспринимаются замусоренные квалификаторами тексты. И стоит все таки признать, что using это классная фича призванная очистить код, то о чем говорит Юра, НО увы человеческий фактор может свести на нет все удобства языка.

Т.е. по хорошему те книжки, которые учат писать std:: по каждому чиху, призывают не к продуманному проектированию и согласованию действий разработчиков, а к некому ИЗБЕГАНИЮ тех проблем, которые уже наворочали задавая одинаковые имена имеющие глобальную видимость и подключая к проектам разные либы содержащие ОДИНАКОВЫЕ имена переменных и функций. Бишь если вы пишете программу и подключаете сторонние либы, содержащие ОДИНАКОВЫЕ имена функций, вы должны понимать что вы делаете и зачем вам оное.