System.String - почему он не реализует конструктор без параметров?

Если бы вы могли использовать

string s = new string();

Что бы вы с ним сделали? Строки неизменны.

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

Не забывайте, что ОП сказал, что хочет сделать:

public void SomeMethod<T>() where T : new()
{
    var t = new T();
    // Do _what_ now?
}

// Call:
SomeMethod<string>();

Я не понимаю, что вы могли сделать с t после того, как он был построен.

Как вы думаете, почему новая строка () бесполезна и, например, new int () не бесполезен.

Вернемся к основам и поговорим о ссылочных типах и типах значений.

Когда вы создаете int, long, point или что-то еще, тип значения выделяется в стеке, поэтому int резервирует 4 байта в стеке, long - 8 байтов и так далее. Пространство стека, зарезервированное для типа значения, обнулено - невозможно когда-либо сослаться на адрес типа значения в стеке и получить нуль. Таким образом, конструкторы по умолчанию для типов значений, вероятно, являются результатом скорее причуд при распределении стека, чем полезности (возможно, кто-то в MS может дать больше информации).

В любом случае я думаю, что System.String не имеет конструктора по умолчанию из-за паршивого дизайна API.

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

Я думаю, что у Microsoft были добрые намерения: лучше использовать "" или String.Empty всякий раз, когда вам нужна пустая строка, потому что они интернированы, и не так полезно каждый раз обновлять new String() - но это встречается для меня как способ Microsoft «спасти разработчиков от самих себя».

(Спасибо, Microsoft, я ценю вашу патерналистскую поддержку, но я вполне способен позаботиться о себе. Если я не хочу создавать несколько экземпляров одного и того же объекта, я кэширую его так же, как и для bagillion других типов с конструктором по умолчанию.)

На данный момент вам нужно рассматривать объекты без конструкторов по умолчанию как особый случай из всего остального. Переписать

public void DoSomething<T>() where T : new() { ... }

Как два метода:

public void DoSomething<T>() where T : new() { DoSomething(() => new T()); }

public void DoSomething<T>(Func<T> constructor) { }

Клиенты вашего кода должны решить, какую функцию вызывать для себя.

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

public void DoSomething<T>(T obj) { ... }

Могут быть причины, например, если не гарантируется вызов метода конструктора. Я работал со сложным приложением winform, в котором при нажатии кнопок или пунктов меню всплывала форма - или, если форма уже была открыта, мы вместо этого фокусировали ее. Так получилось что-то вроде:

public T ShowForm<T>(Func<T> constructor) where T : Form
{
    T res = default(T);
    foreach(Form f in Application.OpenForms)
    {
        if (f is T)
        {
            res = (T)f;
            break;
        }
    }

    if (res == null)
        res = constructor();

    res.Focus();
    return res;
}

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

Я предполагаю, что вы хотите определить класс примерно так:

public class SpecializedCollection<T> where T : new() {
    private List<T> _startingItems;

    public SpecializedCollection(int startingSize) {
        _startingItems = new List<T>(startingSize);
        for (int i = 0; i < startingSize; ++i)
            _startingItems.Add(new T());
    }

    // ... lots more code
}

Я прав? Если вы хотите, чтобы это было более гибким, чтобы разрешить типы, которые могут не иметь конструктора без параметров по умолчанию, вы всегда можете сделать это:

public class SpecializedCollection<T> {
    private List<T> _startingItems;

    // note: here we leave it up to the caller to specify
    // how T objects will be instantiated
    public SpecializedCollection(int startingSize, Func<T> generator) {
        _startingItems = new List<T>(startingSize);
        for (int i = 0; i < startingSize; ++i)
            _startingItems.Add(generator.Invoke());
    }
}

Тогда вы можете создать SpecializedCollection<string> вот так:

var strings = new SpecializedCollection<string>(10, () => string.Empty);

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

public SpecializedCollection(int startingSize)
    : this(startingSize, Activator.CreateInstance<T>()) { }

Вышеупомянутое, конечно, не сработало бы для string, но сработало бы для любого класса с конструктором без параметров (т. Е. Для всего, что работало бы со старым ограничением where T : new()).

Что такое строка без реальной строки?

Ты можешь это сделать:

  String s = "hello world";

И как только у вас есть строка, вы не можете изменить эту конкретную строку (strimgs неизменны). Если вы хотите объявить пустую строку, просто выполните:

string s = string.empty

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

Однако это не может быть сделано чисто на C # - лучше всего использовать вместо этого ограничение class, а затем использовать хак на основе отражения для построения по умолчанию T или использовать String.Empty, если T равно System.String. Вы потеряете проверку компилятора на использование других классов, которые, однако, не могут быть сконструированы по умолчанию.

Вот еще вариант:

class MyClass<T> where T : class
{
    public MyClass(T default)
    private T m_default;      
};

MyClass<object> instance = new MyClass<object>(new object());
MyClass<string> instance = new MyClass<string>(String.Empty);

И другой:

class MyClass<T> where T : class
{
    static SetDefault(T def)
    { 
       s_default = def;
    }
    static T s_default;      
};

MyClass<object> instance = new MyClass<object>(new object());
MyClass<string> instance = new MyClass<string>(String.Empty);

«[Почему] System.String ... не содержит [] конструктора без параметров?»

Потому что так оно и было задумано. Как вы можете видеть из множества ответов и мнений здесь, нет даже четкого консенсуса относительно необходимости или реализации конструктора без параметров. Очевидно, технически возможно иметь конструктор по умолчанию, который инициализируется значением String.Empty - так что либо команда BCL не подумала об этом (маловероятно), либо не сочла это стоящим сценарием (вероятно). FWIW, я согласен - я не вижу причин, по которым ctor по умолчанию на string важен.

«Как вы думаете, почему new string () бесполезен и, например, new int () не бесполезен. Я действительно не вижу разницы».

Разница в том, что int - это ValueType. ValueTypes требуется для использования по умолчанию конструктор, и он инициализирует тип значением по умолчанию. string является ссылочным типом - он уже имеет значение по умолчанию - null (такое же, как и все другие ссылочные типы).

Конечно, вы не согласны - у вас есть конкретный сценарий, который, по вашему мнению, лучше всего реализовать с помощью ctor по умолчанию на string. Не зная подробностей своего сценария, сложно его разумно прокомментировать. Но я предполагаю, что вы имеете дело с примитивной одержимостью. Если string.Empty имеет смысл для ваших конкретных данных, то вам, вероятно, следует создать для этого класс. Конструктор по умолчанию может инициализировать string.Empty.

Э: Почему примитивная одержимость?

Я собирался написать об ORM или других картографах (несколько мест, которые я могу придумать, что where T:new() полезно) и о том, как вместо попытки сопоставить strings вы должны использовать собственный бизнес-объект. Но, выполнив некоторый пример кода - я довольно застрял. Я не могу придумать ни одного сценария, который имел бы смысл с new string() == string.Empty.

Конкретно обращаясь к тому, как избежать проблемы ограничения new() при работе с универсальными типами:

Включите следующее поле, свойство и метод:

private readonly Func<T> _defaultValueFactory = (Func<T>)DefaultT;
private Func<T> DefaultValueFactory
{
    get
    {
        return _defaultValueFactory;
    }
}

private static T DefaultT()
{
    return default(T);
}

Также включите конструктор для вашего типа, который принимает Func<T> defaultValueFactory.

Везде, где вы обычно используете new T(), используйте вместо этого DefaultValueFactory().

Все пустые строки одинаковы. Почему вы хотите его создать? Вы можете использовать String.Empty или просто "".

Из http://msdn.microsoft.com/en-gb/library/system.string.aspx

Объект String называется неизменяемым (только для чтения), потому что его значение нельзя изменить после того, как он был создан. Методы, которые кажутся изменяющими объект String, фактически возвращают новый объект String, содержащий изменение. Если необходимо изменить фактическое содержимое строкового объекта, используйте класс System.Text.StringBuilder.

Так что конструктор без параметров не имеет смысла.

Что бы

String s = new String();

дать тебе

String s = String.Empty;

or

String s = null;

Int32 - это структура. У структур ВСЕГДА есть конструктор без параметров. Это не имеет ничего общего с его полезностью - даже если Microsoft решит, что конструктор без параметров Int32 полностью и совершенно бесполезен, они абсолютно ничего не могут с этим поделать. И если бы они захотели изменить поведение структур сейчас, это было бы огромным критическим изменением. Превращение Int32 в класс также вообще невозможно, поскольку существует причина, по которой .net поддерживает как тип значения, так и тип ссылки (я слышал от парней из Java, что тот факт, что Integer является классом, вызывает некоторые проблемы, но я не могу комментировать на то действительно).

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