Все остальное, что я видел до сих пор в стандартной библиотеке C++, находится в пространстве имен std. Если я использую что-то из std::chrono, я обычно превышаю лимит в 80 символов на строку — это не проблема, просто неудобно.
Итак, вот мой простой вопрос: почему заголовок хроно имеет собственное пространство имен?
Я был ведущим автором предложения по хронологии. Подпространство имен не было моим первым выбором только из-за многословия. Я ловлю себя на том, что пишу using namespace std::chrono почти каждый раз, когда использую это средство.
Однако это было очень спорное предложение. И многие люди, в том числе некоторые из моих соавторов, считали подпространство имен уместным. Я не возражал сильно против подпространства имен, потому что мы были в ситуации необходимости идти на компромисс или оказаться в таком же тупике, как Конгресс США. :-) Результатом такого тупика, вероятно, был бы timespec C11.
Boost экспериментировал с подпространствами имен гораздо более агрессивно, чем std, и один из ключевых авторов этой статьи также является автором библиотеки даты и времени boost, на основе которой развился chrono. Так что это, очевидно, будет иметь сильное влияние в направлении использования подпространства имен.
Забегая вперед, вполне возможно, что подпространство имен станет абсолютно необходимым. Представьте, если мы добавим календарные службы, которые включают аббревиатуру декабря: dec. Это будет напрямую противоречить:
ios_base& dec(ios_base& str);
в <ios>. В общем, я, вероятно, был не прав, не настаивая на подпространстве имен с самого начала. :-) В будущем будет интересно посмотреть, где комитет создает и не создает подпространства имен.
Обновление (6 лет спустя...)
Правда всегда удивительнее вымысла...
Поэтому я действительно предложил std::chrono::dec в качестве сокращения для December, думая, что это будет безопасно из-за вложенного пространства имен chrono. Но нет, комитет решил переименовать std::chrono::dec в std::chrono::December в процессе стандартизации из-за потенциальных конфликтов.
Так стоят ли вложенные пространства имен?
Я не знаю. Это обновление является точкой данных, а не мнением.
std (для обратной совместимости)? Обычно рекомендуется не использовать using namespace. Изменят ли это подпространства имен под std, и хорошо ли это? Есть законные причины не использовать его, но chrono слишком громоздко без using namespace std::chrono.
- person David; 28.02.2013
time_point и duration
- person ceztko; 30.05.2017
timespec (struct с полем для секунд и полем для наносекунд). Это решение было простым и основывалось на большом практическом опыте. И у него есть совместимость с C. Когда был написан N2661, была аудитория, для которой я писал. По сравнению с гораздо более сложной спецификацией <chrono> продать ее было непросто. Я попытался подчеркнуть, что пользовательский интерфейс будет проще и менее подвержен ошибкам.
- person Howard Hinnant; 28.06.2018
Есть и другие пространства имен, например std::placeholders. В конечном счете, в C++03 комитет не пошел на подпространства имен, но теперь совершенно очевидно, что пространство имен std становится сильно перегруженным. Таким образом, я ожидаю, что многие предложения библиотек для C++14 будут использовать подпространство имен для более крупных организаций компонентов.
std. Но я не вижу причин, по которым, например, a в std::subnamespace, если a в std еще нет.
- person cschwan; 18.11.2012
std::a и std::sub::a вместо std::sub1::a и std::sub2::a. Что еще более важно, просто уже используется целая куча a.
- person Puppy; 18.11.2012
namespace sc = std::chrono;- person KitsuneYMG schedule 19.11.2012