- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
template< typename _Data >
void
Foo< _Data >::deduceNumberOfSignificant( _Data _field )
{
switch( sizeof( _Data ) )
{
case sizeof( field32 ):
m_significantNumber = 7;
break;
case sizeof( field64 ):
m_significantNumber = 16;
break;
case sizeof( field128 ):
m_significantNumber = 34;
break;
default:
BOOST_ASSERT( "Improper field size" );
}
}
Follow us!
да и стиль говёный, спору нет
но на мой взгляд больше говнокод в том, что непонятным методом явно изменяют состояние члена класса - хранят число от левого аргумента, полезность этого вызывает много вопросов
пробелы внутри скобок, нижние подчеркивания перед именами
17.4.3.1.2 Global names
- Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
это здорово, когда местечковый кодинг-стандарт переопределяет стандарт языка
Each name that contains a double underscore (_ _) or begins with an underscore followed by an upper-case letter (2.11) is reserved to the implementation for any use.
окей, компилятор делает у себя в заголовке, т.к. for any use
#define _Data int
проблема остается
А вот следующий пункт как раз раскрывает что зарезервировано за for any use, что зарезервировано за global names. Плюс где то отдельным пунктом сделана отсылка к сишному наследию в виде va_* и т.д.
В итоге:
Reserved in any scope, including for use as implementation macros:
--- identifiers beginning with an underscore and an uppercase letter
--- identifiers containing adjacent underscores (or "double underscore")
Reserved in the global namespaces:
--- identifiers beginning with an underscore
Also, everything in the std namespace is reserved. (You are allowed to add template specializations, though.)
И всё же, в стандарте говорится отдельно про глобальные имена, и про макроимена отдельно, хотя могли бы не заморачиваться, а написать identifer.
можно ссылку?
template <class _Elem, class _Tr>
polymorphic_iarchive_route(
http://svn.boost.org/svn/boost/trunk/boost/gil/utilities.hpp
template <typename _D1, typename _D2> deref_compose(const deref_compose<_D1,_D2>& dc) : _fn1(dc._fn1), _fn2(dc._fn2) {}
http://svn.boost.org/svn/boost/trunk/boost/pending/queue.hpp
http://svn.boost.org/svn/boost/trunk/boost/typeof/typeof_impl.hpp
И т.д., искать не сложно.
Я уже молчу про хедергарды типа #ifndef _BOOST_UBLAS_EXPRESSION_TYPE_, которые тоже ни-ни.
я вообще ожидал будет хуже, если честно
Аркадий в typeof погорячился один раз в _Typeof_iteration, зато попробуй реализуй в 2004 году аналог auto и decltype
gil == Adobe Inc., спасибо что подарили
pending - если бы не grep, об этой папке не узнал бы даже - осиротевший в 2002/2004 какой-то проект
archive - пацаны подглядели шаблон для basic_(i/o)stream в MSVC, два раза
в общем то не слишком густо
более-менее стараются люди всё же следовать несчастным 4 требованиям naming conventions из
http://www.boost.org/development/requirements.html#Design_and_Programming, хорошие, годные требования
хедергарды да, проблема, даже в наших конторских кодах этого наследия диких 90-х __MYCOOLHEADER_H__ навалом
странная арифметика, почему не 8,16,32?
kn=(kn-1+1)*2