Там эквивалентно из <? расширяется T>, <? супер T> в C++?
Я не знаю ни о каком API, чтобы сделать, заставляют планировщик ОС делать то, что Вы хотите (даже если Ваш поток будет неактивным приоритетом, если не будет никакого более высокого приоритета готовые потоки, Ваш будет работать). Однако я думаю, что можно импровизировать довольно изящную функцию регулировки на основе того, что Вы уже делаете. По существу (у меня нет Windows dev машиной удобный):
Выбор количество времени по умолчанию поток будет спать каждое повторение. Затем на каждом повторении (или на каждом энном повторении, таком, что функция регулировки самостоятельно не становится значительной загрузкой ЦП),
- , Вычисляют сумму процессорного времени Ваш поток, используемый с прошлого раза, когда Ваша функция регулировки была вызвана (я назову этот dCPU). Можно использовать GetThreadTimes () API для получения количества времени, которое выполнял поток.
- Вычисляют сумму реального времени, истекшего с прошлого раза, когда Ваша функция регулировки была вызвана (я назову этот dClock).
- dCPU / dClock является использованием ЦП процента (одного ЦП). Если это выше, чем Вы хотите, увеличиваете свое время сна, если ниже, уменьшите время сна.
- Имеют Ваш сон потока в течение вычисленного времени.
В зависимости от того, как Ваш сторожевой таймер вычисляет использование ЦП, Вы могли бы хотеть использовать GetProcessAffinityMask () для обнаружения, сколько центральных процессоров система имеет. dCPU / (dClock * центральные процессоры) является процентом общего доступного процессорного времени.
необходимо будет все еще выбрать некоторые магические числа в течение начального времени сна и инкрементной/декрементной суммы, но я думаю, что этот алгоритм мог быть настроен для поддерживания потока в рабочем состоянии в справедливо близко к решительному проценту ЦП.
4 ответа
В нем нет такого хорошего синтаксического сахара, как в Java, но он хорошо управляется с помощью boost / type_traits . См. http://www.boost.org/doc/libs/1_40_0/libs/type_traits/doc/html/index.html для получения дополнительной информации.
#include <boost/type_traits.hpp>
#include <boost/static_assert.hpp>
class Base {};
class Derived_from_Base : public Base {};
class Not_derived_from_Base {};
template<typename BASE, typename DERIVED>
void workOnBase()
{
BOOST_STATIC_ASSERT((boost::is_base_of<BASE, DERIVED>::value));
}
int main()
{
workOnBase<Base, Derived_from_Base>(); // OK
workOnBase<Base, Not_derived_from_Base>(); // FAIL
return 0;
}
1> d: ... \ main .cpp (11): ошибка C2027: использование неопределенного типа 'boost :: STATIC_ASSERTION_FAILURE' 1> с 1> [ 1> x = ложь 1>]
Отвечу на второй вопрос: да. Что касается дженериков, интерфейсы обрабатываются так же, как и реальные классы.
Я оставлю первый вопрос более опытным людям, разбирающимся в C ++.
Вы можете ограничить диапазон параметра шаблона в C ++, используя различные механизмы признаков, реализации которых доступны в boost.
Обычно вы этого не делаете - причина существования синтаксиса в Java и C # заключается в том, что они используют универсальные шаблоны, а не шаблоны.
Дженерики Java генерируют совместно используемый код, который использует виртуальную отправку из базового типа, а не генерирует код для каждого типа, используемого в качестве аргумента шаблона. Поэтому обычно вы используете ограничение, чтобы позволить вам вызывать методы для объектов типа, используемого в качестве параметра шаблона.
Поскольку C ++ генерирует код для каждого типа, используемого в качестве параметра шаблона, ему не нужно знать о базовый тип для них.
Например, шаблонный класс для матрицы будет использовать операторы +, -, * для своего целевого типа. Затем In может использоваться для любого типа, который поддерживает эти операторы. Если он был произвольно ограничен double s и int s, то вы не могли бы использовать шаблон с комплексным или запустить тест с тип, который поддерживает интервальную арифметику, даже если эти типы предоставляют эти операторы, и библиотека матриц будет действительна при их использовании.
Возможность работать с произвольными типами, имеющими одинаковую форму, является силой шаблонов и делает их более полезными . Код клиента должен решить, допустимо ли использовать этот шаблон с этим типом (пока он компилируется), и клиент всегда прав. Невозможность работать с произвольными типами, имеющими одинаковую форму, и требование указать ограничения на вызов методов, отличных от тех, что указаны в java. lang.Object является слабым местом дженериков.
Это расширение , которое, к сожалению, было удалено из проекта стандарта C ++ 0x, поскольку оно «не было готово». Однако можно смоделировать это, используя статические утверждения (которые, как уже упоминалось, являются частью C ++ 0x и Boost).