Можно конечно. Если нужно.
Дело не в читабельности предложенного решения, а в том, что оно постулируется как корректное, основываясь на ничем не обоснованном инварианте sizeof(int) <= sizeof(WPARAM).
Во-первых, blocking используется для обеспечения так называемой temporal locality of reference, во-вторых, во 2-м шаге используется не blocking, а техника обеспечивающая spatial locality of reference.
Писать код так, чтобы замедляться в 60, а не в 180 раз вполне имеет практический смысл.
Примечание. Я шокирован. Я знаю, что код, созданный с использованием STL, обычно на порядок медленней работает в отладочных версиях. Однако, я не ожидал здесь такого падения скорости.
Что такое субнормальные денормализованные (subnormal) числа рассмотрим на простом примере. Пусть имеем нормализованное представление с длиной мантиссы P=3 (бита) и диапазоном значений экспоненты -1≤E≤2. В этом случае получим 16 чисел:
В вашем примере длина мантиссы 2 бита.
float a=0.5;
int n = *((int*) &a);
float b = *((int*) &(++n));
...
s/float b = *((int*) &(++n));/float b = *((float*) &(++n));/
Для первой задачи:
c = x2 + y2
c / 2 = ( x2 + y2 ) / 2
Среднее ( x2 + y2 ) / 2 можно определить высотой середины отрезка соединяющего две точки ( x, x2 ) и ( y, y2 ). Соответственно середины всех отрезков соединяющих точки ординаты которых удовлетворяют указанному выше равенству будут лежать на прямой c / 2. Поскольку абсцисса середины данного отрезка есть среднее абсцисс точек, которые соединяет отрезок, искомые пары чисел следует искать следующим образом:
Выбираем некоторое рациональное число в интервале [ sqrt( c ) / 2, sqrt( c / 2 ) ], симметричное относительно соседних целых;
Выбираем, симметричные относительно выбранного ранее числа, целые числа, проверяем удовлетворяют ли целевому равенству и повторяем итерацию;
Отрезок [ sqrt( c ) / 2, sqrt( c / 2 ) ] образуется абсциссами точек пересечения прямой c / 2 с прямой f( x ) = c x / sqrt( c ) и параболой g( x ) = x2.
Итого, требуется порядка k * N сравнений, где k удвоенное число целых в интервале [ sqrt( c ) / 2, sqrt( c / 2 ) ], а N число целых в интервале [ 0, sqrt( c ) ].
template< class TFunctor >
inline void CallWithType( const TFunctor &rcFunctor, int nTypeDescriptor );
...
template< class TObject >
inline bool IsKindOf( int nTypeDescriptor )
{
return CallWithType( IsKindOfHelper< TObject >(), nTypeDescriptor );
}
Возвращаемые значения IsKindOf и CallWithType не соответствуют друг другу.
// TypeDescriptor is virtual func, which returns descriptor of the real object type.
// Implementation shown in previous example (you don't need to write this function by hands)
if( IsKindOf< ISettable >( TypeDescriptor() ) )
Если TypeDescriptor виртульная функция, то где имя объекта?
// IsWrapperApplicable converts nType to the real type TObject using CallWithType,
// calls WrapperTraits::CSomeWrapper::MakeWrappedType< TObject >::type metafunction
// in order to resolve wrapped type, then calls MakeDescriptor for this type.
return MakeWrappedType< WrapperTraits::CSomeWrapper >( nType ) );
Задача в данной постановке является аналогичной задаче об упаковке ранца, которая, в свою очередь являясь NP-полной, решается за псевдо-полиномиальное время методом динамического программирования.
Построенная с помощью жадного алгоритма аппроксимация решения задачи об упаковке ранца с неограниченными числом изделий(unbounded problem) гарантированно составляет не менее 1/2 оптимального решения. В случае ограниченности числа изделий(bounded problem) полученная аппроксимация может быть далека от оптимума.
Поэтому патетика в духе:
Конечно, невозможно гарантировать, что это решение будет наилучшем, но оно точно будет достаточно хорошим.
Это естественный путь снижения как time complexity так и space complexity задачи об упаковке ранца(т.н. knapsack problem). В данном случае наибольший общий делитель — 1 миллион.
Действительно. Прошу прощения, стандарт читал бегло, и, увидев, что начинается с примера с шаблонами не стал дочитывать до конца. Предыдущее же утверждение целиком опиралось на Страуструпа.
inline функции обычно определяются в заголовочных файлах (.h), чтобы все единицы трансляции могли видеть реализацию функции и подставить ее по месту вызова. Соответственно, как только вы включите заголовочный файл с такой функцией в более чем одну единицу трансляции, ODR будет формально нарушено, но… никакой индикации ошибки вы не получите.
Это не нарушает ODR.
Consequently, the rule in the standard that says that there must be a unique definition of a class,
template, etc., is phrased in a somewhat more complicated and subtle manner. This rule is com-
monly referred to as ‘‘the one-definition rule,’’ the ODR. That is, two definitions of a class, tem-
plate, or inline function are accepted as examples of the same unique definition if and only if
[1] they appear in different translation units, and
[2] they are token-for-token identical, and
[3] the meanings of those tokens are the same in both translation units.
B.Stroustrup, The C++ Programming Language, 3rd. ed., P. 9.2.3
Будет ли это работать? Какая реализация HandleErrorCondition() – с вызовом _exit() или с вызовом CustomHandleErrorCondition()– будет вызываться?
Неизвестно.
Как это неизвестно? Вполне даже известно. SomeUsefulFunction в staticlib.obj во время линковки будет заменён на аналогичный символ из example.obj; почему — описано в комментарии DustCn. Таким образом из обоих модулей будет вызываться реализация определённая в example.obj, которая, в свою очередь, будет вызывать реализацию HandleErrorCondition с CustomHandleErrorCondition.
При линковке возникает описанная выше ситуация с нарушением ODR, но теперь две inline функции, идентичные с точки зрения политики, используемой линкером, имеют разные реализации. Линкер выберет какую-то одну и не факт, что выбор не будет меняться от одной линковки к другой.
Это нарушение стандарта, а не ODR. Поскольку inline-функции с одинаковой сигнатурой должны иметь одинаковые реализации в различных единицах трансляции. И то, что пример удачно компилируется, является скорее отступлением компилятором MSVC от стандарта.
Чтобы избежать подобных неоднозначных ситуаций стоит делать заголовочные файлы настолько автономными, насколько это возможно.
Вместо послесловия:
It is wise not to be too clever about the use of #include. My recommendation is to #include
only complete declarations and definitions and to do so only in the global scope, in linkage specifi-
cation blocks, and in namespace definitions when converting old code. As usual, it is wise
to avoid macro magic. One of my least favorite activities is tracking down an error caused by a
name being macro-substituted into something completely different by a macro defined in an indi-
rectly #include'd header that I have never even heard of.
B.Stroustrup, The C++ Programming Language, 3rd. ed., P. 9.2.1
Репрезентативность выборки, вследствие её конечности как подмножества, либо ограниченности относительно генеральной совокупности, определяется не только «объёмом» выборки, но и способом её построения. Таким образом сравнение репрезентативности выборок лишь на основе их объёмов, несколько некорректно.
Дело не в читабельности предложенного решения, а в том, что оно постулируется как корректное, основываясь на ничем не обоснованном инварианте sizeof(int) <= sizeof(WPARAM).
Ваш вариант ненамного более корректен, чем исходный: стоит изменить typedef так, что:
sizeof(int) > sizeof(WPARAM)
К примеру, так:
И вернётесь к тому с чего начали.
А что вы хотели при /Od против /O2?
В вашем примере длина мантиссы 2 бита.
Для знаковых целых:
Поэтому должна быть либо сумма:
либо разность с обратным знаком:
Ну, или:
c = x2 + y2
c / 2 = ( x2 + y2 ) / 2
Среднее ( x2 + y2 ) / 2 можно определить высотой середины отрезка соединяющего две точки ( x, x2 ) и ( y, y2 ). Соответственно середины всех отрезков соединяющих точки ординаты которых удовлетворяют указанному выше равенству будут лежать на прямой c / 2. Поскольку абсцисса середины данного отрезка есть среднее абсцисс точек, которые соединяет отрезок, искомые пары чисел следует искать следующим образом:
Отрезок [ sqrt( c ) / 2, sqrt( c / 2 ) ] образуется абсциссами точек пересечения прямой c / 2 с прямой f( x ) = c x / sqrt( c ) и параболой g( x ) = x2.
Итого, требуется порядка k * N сравнений, где k удвоенное число целых в интервале [ sqrt( c ) / 2, sqrt( c / 2 ) ], а N число целых в интервале [ 0, sqrt( c ) ].
Возвращаемые значения IsKindOf и CallWithType не соответствуют друг другу.
Если TypeDescriptor виртульная функция, то где имя объекта?
Последняя закрывающая скобка — лишняя.
"сделай меня паспортом" будет «make myself passport».
Построенная с помощью жадного алгоритма аппроксимация решения задачи об упаковке ранца с неограниченными числом изделий(unbounded problem) гарантированно составляет не менее 1/2 оптимального решения. В случае ограниченности числа изделий(bounded problem) полученная аппроксимация может быть далека от оптимума.
Поэтому патетика в духе:
мне кажется совершенно неуместной.
Это не нарушает ODR.
Как это неизвестно? Вполне даже известно.
SomeUsefulFunction в staticlib.obj во время линковки будет заменён на аналогичный символ из example.obj; почему — описано в комментарии DustCn. Таким образом из обоих модулей будет вызываться реализация определённая в example.obj, которая, в свою очередь, будет вызывать реализацию HandleErrorCondition с CustomHandleErrorCondition.
Это нарушение стандарта, а не ODR. Поскольку inline-функции с одинаковой сигнатурой должны иметь одинаковые реализации в различных единицах трансляции. И то, что пример удачно компилируется, является скорее отступлением компилятором MSVC от стандарта.
Чтобы избежать подобных неоднозначных ситуаций стоит делать заголовочные файлы настолько автономными, насколько это возможно.
Вместо послесловия: