Существует ли ограничение, которое ограничивает мой общий метод для числовых типов?

Нет никакого единственного интерфейсного или базового класса, который они все наследовали (который также не наследован другими классами), таким образом, простой ответ нет.

я действительно задаюсь вопросом, почему это - проблема все же. Что Вы желаете сделать в своем классе IntegerFunction, который может только быть сделан к целым числам?

Я думаю, что Вы неправильно понимаете дженерики. Если операция, которую Вы пытаетесь выполнить, только хороша для определенных типов данных тогда, Вы не делаете чего-то "универсального".

кроме того, так как Вы только желаете позволить функции работать над типами данных int тогда, Вам не должна быть нужна отдельная функция для каждого определенного размера. Просто взятие параметра в самом большом определенном типе позволит программу автоматически восходящему меньшие типы данных к нему. (т.е. передача Int16 автопреобразует в Int64 при вызове).

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

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

Какой смысл осуществления?

, Поскольку люди уже указали, у Вас могла быть неродовая функция, берущая самый большой объект, и компилятор автоматически преобразует меньший ints для Вас.

static bool IntegerFunction(Int64 value) { }

, Если Ваша функция находится на производительности критическом пути (очень вряд ли, IMO), Вы могли бы обеспечить перегрузки для всех необходимых функций.

static bool IntegerFunction(Int64 value) { }
...
static bool IntegerFunction(Int16 value) { }

Вероятно, самое близкое, которое можно сделать,

static bool IntegerFunction<T>(T value) where T: struct

Не уверено, если Вы могли бы сделать следующий

static bool IntegerFunction<T>(T value) where T: struct, IComparable
, IFormattable, IConvertible, IComparable<T>, IEquatable<T>

Для чего-то настолько определенного, почему не только имеют перегрузки для каждого типа, список так короток, и это возможно имело бы меньше объема потребляемой памяти.

К сожалению, Вы только в состоянии определить структуру в где пункт в этом экземпляре. Кажется странным, что Вы не можете определить Int16, Int32, и т.д. конкретно, но я уверен, что существует некоторая глубокая причина реализации, лежащая в основе решения не разрешить, чтобы значение ввело где пункт.

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

static bool IntegerFunction<T>(T value) where T : struct {
  if (typeof(T) != typeof(Int16)  &&
      typeof(T) != typeof(Int32)  &&
      typeof(T) != typeof(Int64)  &&
      typeof(T) != typeof(UInt16) &&
      typeof(T) != typeof(UInt32) &&
      typeof(T) != typeof(UInt64)) {
    throw new ArgumentException(
      string.Format("Type '{0}' is not valid.", typeof(T).ToString()));
  }

  // Rest of code...
}

, Который немного ужасен, я знаю, но по крайней мере обеспечивает необходимые ограничения.

я также изучил бы возможные последствия производительности для этой реализации, возможно, там существует более быстрый путь.

Нет никакого ограничения для этого. Это - реальная проблема для любого желающего использовать дженерики для числовых вычислений.

я пошел бы далее и сказал бы, что нам нужно

static bool GenericFunction<T>(T value) 
    where T : operators( +, -, /, * )

, Или даже

static bool GenericFunction<T>(T value) 
    where T : Add, Subtract

, К сожалению, у Вас только есть интерфейсы, базовые классы и ключевые слова struct (должен быть тип значения), class (должен быть ссылочный тип), и new() (должен иметь конструктора по умолчанию)

, Вы могли обернуть число во что-то еще (подобный INullable<T>) как здесь на codeproject.

Вы могли ввести ограничение во времени выполнения (путем отражения для операторов или проверки на типы), но это действительно теряет преимущество наличия дженерика во-первых.

Я задавался вопросом то же как samjudson, почему только к целым числам? и если это так, Вы могли бы хотеть создать класс помощника или что-то как этот для содержания всех типов, которые Вы хотите.

, Если все Вы хотите, целые числа, не используйте дженерик, который не универсален; или еще лучше, отклонение любой другой тип путем проверки его типа.

Этот вопрос относится к часто задаваемым вопросам, поэтому я публикую его как вики (поскольку я уже публиковал похожие сообщения раньше, но это более старый); в любом случае ...

Какую версию .NET вы используете? Если вы используете .NET 3.5, то у меня есть реализация общих операторов в MiscUtil (бесплатно и т. Д.).

У меня есть такие методы, как T Add ( T x, T y) и другие варианты арифметики для разных типов (например, DateTime + TimeSpan ).

Кроме того, это работает для всех встроенных, расширенных и заказных операторов и кешей делегат для производительности.

Некоторые дополнительные сведения о том, почему это сложно, можно найти здесь .

Вы также можете узнать, что динамический (4.0) вид решает эту проблему тоже косвенно - т.е.

dynamic x = ..., y = ...
dynamic result = x + y; // does what you expect

Я бы использовал универсальный, который вы могли бы обрабатывать внешние ...

/// <summary>
/// Generic object copy of the same type
/// </summary>
/// <typeparam name="T">The type of object to copy</typeparam>
/// <param name="ObjectSource">The source object to copy</param>
public T CopyObject<T>(T ObjectSource)
{
    T NewObject = System.Activator.CreateInstance<T>();

    foreach (PropertyInfo p in ObjectSource.GetType().GetProperties())
        NewObject.GetType().GetProperty(p.Name).SetValue(NewObject, p.GetValue(ObjectSource, null), null);

    return NewObject;
}