Re: Когда new, a koгда можно без? - .NET

Здравствуйте, Jack128, Вы писали:

J>Здравствуйте, varenikAA, Вы писали:

J>В С++ new использует не для создания объекта, а для выделения динамической памяти. А так как сборщиков мусора там нема, то и отдельные ключ слова для выделения/освобождения памяти там очень кстати были.
J>А во всякие шарпы потащили new — чтоб было похоже на плюсы.

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

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, varenikAA, Вы писали:

S>Чем newPerson лучше new Person?

newPerson — функция. new Person — по смыслу тоже самое, но синтаксически отличается. Даже затрудняюсь сказать, new это оператор, выражение или инструкция...

AA>>Но в C# по-моему, нужно было разрешить вызывать конструкторы как статические методы. Это логичнее.

S>А почему не различать создание объекта здесь и сейчас и делегацию создания -- builder, fabric?
В управляемом коде это совершенно излишне. Даже с++ рекомендуют использовать библиотеки по управлению памятью(временем жизни объектов).

Здравствуйте, alexzzzz, Вы писали:

A>Здравствуйте, varenikAA, Вы писали:

AA>>Чисто визуально даже, приятней было бы:
AA>>

AA>>let d = DateTime()
AA>>

A>Возможно, я просто привык, но мне нравится, когда вызов конструктора типа визуально отличается от вызова какого-то метода. Не вижу тут каких-то особых неудобств и вопросом, нужно в конкретном месте писать new или не нужно, никогда не задавался.

Для сравнения:

            void Proc1(Func<DateTime> r)
            {
                WriteLine(r());
            };

            Proc1(() => new DateTime());
            _ = ReadLine();
            return;

— близко, но не так хорошо как:


        def Proc1(a) {
            WriteLine(a());
        };
        
        Proc1(DateTime);
 
        _ = ReadLine();

Такое решение также позволяет использовать конструктор там, где требуется функция (или делегат).

И да, в C кажется нет new.

Здравствуйте, IT, Вы писали:

IT>

int a=new int(1);

Вот, и у меня в голове такая же формула сидела. Сунулся проверить — хвать, а нет у Инта конструкторов с параметрами (.Net 4.0, старее не установлены).
Так что:

int a=new int();
a=1;

Здравствуйте, Mihas, Вы писали:

M>Так что:
M>

int a=new int();
M>a=1;

Так тоже сойдёт. Главное — не забивать себе голову ненужными деталями.

Здравствуйте, varenikAA, Вы писали:

AA>- близко, но не так хорошо как:
AA> def Proc1(a) {
AA> WriteLine(a());
AA> };
AA> Proc1(DateTime);
AA> _ = ReadLine();

Не люблю питоноподобный синтаксис. Функция неизвестно что принимает и неизвестно что возвращает, если вообще возвращает. Вместо полезных типов имеем ключевое слова def, которое по сути бесполезно.

Вызов выглядит так, будто мы передаём в функцию Proc1 переменную или константу DateTime.

Здравствуйте, alexzzzz, Вы писали:

A>Здравствуйте, varenikAA, Вы писали:

AA>>- близко, но не так хорошо как:
AA>> def Proc1(a) {
AA>> WriteLine(a());
AA>> };
AA>> Proc1(DateTime);
AA>> _ = ReadLine();

A>Не люблю питоноподобный синтаксис. Функция неизвестно что принимает и неизвестно что возвращает, если вообще возвращает. Вместо полезных типов имеем ключевое слова def, которое по сути бесполезно.

A>Вызов выглядит так, будто мы передаём в функцию Proc1 переменную или константу DateTime.
В том-то и дело, что передать можно все что угодно: от выражения до константы т.к. функции в ФП обощенные по умолчанию и специализируются
в момент использования.

Здравствуйте, varenikAA, Вы писали:

AA>>>- близко, но не так хорошо как:
AA>>> def Proc1(a) {
AA>>> WriteLine(a());
AA>>> };
AA>>> Proc1(DateTime);
AA>>> _ = ReadLine();

A>>Не люблю питоноподобный синтаксис. Функция неизвестно что принимает и неизвестно что возвращает, если вообще возвращает. Вместо полезных типов имеем ключевое слова def, которое по сути бесполезно.

A>>Вызов выглядит так, будто мы передаём в функцию Proc1 переменную или константу DateTime.
AA>В том-то и дело, что передать можно все что угодно: от выражения до константы т.к. функции в ФП обощенные по умолчанию и специализируются
AA>в момент использования.

Передать в Proc1 можно не что угодно, а только то, что Proc1/WriteLine смогут переварить без ошибок компиляции или ошибок в рантайме. Что конкретно они могут переваривать, из объявления Proc1 не видно.

Здравствуйте, alexzzzz, Вы писали:

A>Здравствуйте, varenikAA, Вы писали:

AA>>>>- близко, но не так хорошо как:
AA>>>> def Proc1(a) {
AA>>>> WriteLine(a());
AA>>>> };
AA>>>> Proc1(DateTime);
AA>>>> _ = ReadLine();

A>>>Не люблю питоноподобный синтаксис. Функция неизвестно что принимает и неизвестно что возвращает, если вообще возвращает. Вместо полезных типов имеем ключевое слова def, которое по сути бесполезно.

A>>>Вызов выглядит так, будто мы передаём в функцию Proc1 переменную или константу DateTime.
AA>>В том-то и дело, что передать можно все что угодно: от выражения до константы т.к. функции в ФП обощенные по умолчанию и специализируются
AA>>в момент использования.

A>Передать в Proc1 можно не что угодно, а только то, что Proc1/WriteLine смогут переварить без ошибок компиляции или ошибок в рантайме. Что конкретно они могут переваривать, из объявления Proc1 не видно.
Это просто, если вывод типа не справился или если передается невалидный аргумент, то компилятор выдаст подробную ошибку. В первом случае можно будет явно указать ожидаемый тип (уточнение). Но это требуется очень редко.

Здравствуйте, varenikAA, Вы писали:

A>>Передать в Proc1 можно не что угодно, а только то, что Proc1/WriteLine смогут переварить без ошибок компиляции или ошибок в рантайме. Что конкретно они могут переваривать, из объявления Proc1 не видно.
AA>Это просто, если вывод типа не справился или если передается невалидный аргумент, то компилятор выдаст подробную ошибку. В первом случае можно будет явно указать ожидаемый тип (уточнение). Но это требуется очень редко.

Игра в угадайку получается. Хорошо, когда ты функцию написал сам недавно и знаешь, что она хочет и что может. А когда берёшь чужой API, то сидишь и смотришь на него, как баран на ворота, потому что кто-то поленился типы прописать. Впрочем, питоновский синтаксис даже с типами не фонтан.

Здравствуйте, alexzzzz, Вы писали:

A>Здравствуйте, varenikAA, Вы писали:

A>>>Передать в Proc1 можно не что угодно, а только то, что Proc1/WriteLine смогут переварить без ошибок компиляции или ошибок в рантайме. Что конкретно они могут переваривать, из объявления Proc1 не видно.
AA>>Это просто, если вывод типа не справился или если передается невалидный аргумент, то компилятор выдаст подробную ошибку. В первом случае можно будет явно указать ожидаемый тип (уточнение). Но это требуется очень редко.

A>Игра в угадайку получается. Хорошо, когда ты функцию написал сам недавно и знаешь, что она хочет и что может. А когда берёшь чужой API, то сидишь и смотришь на него, как баран на ворота, потому что кто-то поленился типы прописать. Впрочем, питоновский синтаксис даже с типами не фонтан.

Если использовать ide, то типы в подсказках будут.
Если нет — подскажет компилятор(если это хороший компилятор). Вы же не пишите программу на листочке бумаге?
Ну и не знаю, вы на чем кодите? В C# обобщенное программирование и утиная типизация повсюду.

Вспоминаю старый слоган: "настоящий хакер кодит в notepad".

Здравствуйте, varenikAA, Вы писали:

AA>Если использовать ide, то типы в подсказках будут.
AA>Если нет — подскажет компилятор(если это хороший компилятор). Вы же не пишите программу на листочке бумаге?
AA>Ну и не знаю, вы на чем кодите? В C# обобщенное программирование и утиная типизация повсюду.

В C# если метод принимает T, значит он принимает любые T, чем бы они ни были. Если на T есть ограничения, то они явно заданы в виде type constraints.

int Foo<T>(T item) where T : struct, IComparable<T>

Метод принимает только те T, которые value-типы и реализуют интерфейс IComparable<T>. С такими T он работать точно умеет. Что-то другое в него хрен запихнёшь.

Здравствуйте, alexzzzz, Вы писали:

A>Здравствуйте, varenikAA, Вы писали:

AA>>Если использовать ide, то типы в подсказках будут.
AA>>Если нет — подскажет компилятор(если это хороший компилятор). Вы же не пишите программу на листочке бумаге?
AA>>Ну и не знаю, вы на чем кодите? В C# обобщенное программирование и утиная типизация повсюду.

A>В C# если метод принимает T, значит он принимает любые T, чем бы они ни были. Если на T есть ограничения, то они явно заданы в виде type constraints.

A>

int Foo<T>(T item) where T : struct, IComparable<T>

A>Метод принимает только те T, которые value-типы и реализуют интерфейс IComparable<T>. С такими T он работать точно умеет. Что-то другое в него хрен запихнёшь.

И что? Вы описали интерфейс. Языки с выводом типов автоматически сгенерят нужную версию функции, в отличии от C# 2-й версии, где надо было писать int x = Foo<Person>(null);
В последних можно так: var x = Foo((Person)null);
Вы до сих пор указываете параметр обобщенных методов?

Здравствуйте, varenikAA, Вы писали:

A>>

int Foo<T>(T item) where T : struct, IComparable<T>

A>>Метод принимает только те T, которые value-типы и реализуют интерфейс IComparable<T>. С такими T он работать точно умеет. Что-то другое в него хрен запихнёшь.
AA>И что? Вы описали интерфейс.

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

AA>в отличии от C# 2-й версии, где надо было писать int x = Foo<Person>(null);
AA>В последних можно так: var x = Foo((Person)null);

Не понял. В режиме C# 2.0 компилятор принимает оба варианта. Они равнозначны по смыслу и результату. У литералов null и default нет типа. Если вывести его неоткуда, надо указать вручную. Иначе какая из перегрузок WriteLine должна быть вызвана и что должен вернуть подобный метод, если передать в него null без типа:

T Recreate<T>(T x) where T : new() // любые типы с конструктором без параметров
{
    Console.WriteLine(x);
    return new T();
}

Здравствуйте, alexzzzz, Вы писали:

A>Не понял. В режиме C# 2.0 компилятор принимает оба варианта. Они равнозначны по смыслу и результату. У литералов null и default ]?

Я не совсем об этом.
Вот например, вы пишете метод:

bool Test<T>(T a, T b)
{
    return a>b;
}
WriteLine(Test(1,2));

Что получится?
Или в d:

bool Test(T)(T a, T b)
{
  return a>b;
}
writeln(Test(1,2));

Здравствуйте, varenikAA, Вы писали:

A>>Не понял. В режиме C# 2.0 компилятор принимает оба варианта. Они равнозначны по смыслу и результату. У литералов null и default ]?
AA>Я не совсем об этом.
AA>Вот например, вы пишете метод:
AA>

AA>bool Test<T>(T a, T b)
AA>{
AA>    return a>b;
AA>}

AA>Что получится?

Ничего не получится. C# не даст написать код, принимающий любые T, который не валиден для любых T.

Здравствуйте, alexzzzz, Вы писали:

A>Здравствуйте, varenikAA, Вы писали:

A>>>Не понял. В режиме C# 2.0 компилятор принимает оба варианта. Они равнозначны по смыслу и результату. У литералов null и default ]?
AA>>Я не совсем об этом.
AA>>Вот например, вы пишете метод:
AA>>

AA>>bool Test<T>(T a, T b)
AA>>{
AA>>    return a>b;
AA>>}

AA>>Что получится?

A>Ничего не получится. C# не даст написать код, принимающий любые T, который не валиден для любых T.

вот я и спрашиваю:

var x  = Test(1,2);

— это валидное выражение?

Здравствуйте, varenikAA, Вы писали:
A>>Ничего не получится. C# не даст написать код, принимающий любые T, который не валиден для любых T.

AA>вот я и спрашиваю:

var x  = Test(1,2);

— это валидное выражение?
Это выражение валидно, но до его компиляции дело не дойдёт.
Компиляция упадёт ещё на bool Test<T>(T a, T b) => a>b;, т.к. компилятору неизвестно, есть ли для T operator>().

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, varenikAA, Вы писали:
A>>>Ничего не получится. C# не даст написать код, принимающий любые T, который не валиден для любых T.

AA>>вот я и спрашиваю:

var x  = Test(1,2);

— это валидное выражение?
S>Это выражение валидно, но до его компиляции дело не дойдёт.
S>Компиляция упадёт ещё на bool Test<T>(T a, T b) => a>b;, т.к. компилятору неизвестно, есть ли для T operator>().

Согласен, но в случае если в контексте вызова только int комплятор вполне мог бы сообразить.
Забавно, что и Nemerle не справился с выводом типов, если подряд вызвать сначала с числами, а затем со строками.
Еще забавней выглядит Ди:

bool Test(T)(T a, T b) 
{
    return a > b;
}
void main()
{
    import std.stdio ;
    auto r1 = Test(10,20);
    auto r2 = Test("10","20");
    writeln(r1, r2);
}

Ну, а хитрее всех F#

let f a b = a > b //=> val f : a:'a -> b:'a -> bool when 'a : comparison

Здравствуйте, varenikAA, Вы писали:

S>>Компиляция упадёт ещё на bool Test<T>(T a, T b) => a>b;, т.к. компилятору неизвестно, есть ли для T operator>().
AA>Согласен, но в случае если в контексте вызова только int комплятор вполне мог бы сообразить.

Во время компиляции Test<T> у компилятора нет этого контекста. Он не знает, с какими аргументами Test будет вызываться. Объявление Test<T> может находиться в одной сборке, а десяток его вызовов с десятком разных типов аргументов ― в десятке других сборок (возможно, даже пока не существующих).

	От:	varenikAA
	Дата:	17.10.19 06:51
	Оценка:

	От:	varenikAA
	Дата:	17.10.19 06:55
	Оценка:

	От:	varenikAA
	Дата:	17.10.19 07:08
	Оценка:

	От:	Mihas
	Дата:	17.10.19 07:25
	Оценка:

От:	IT	linq2db.com
Дата:	17.10.19 12:32
Оценка:	-1

От:	Sinclair	https://github.com/evilguest/
Дата:	29.10.19 06:36
Оценка:

	От:	alexzzzz
	Дата:	21.10.19 00:37
	Оценка:

	От:	alexzzzz
	Дата:	21.10.19 14:46
	Оценка:

	От:	alexzzzz
	Дата:	22.10.19 11:56
	Оценка:	+1

	От:	alexzzzz
	Дата:	23.10.19 12:52
	Оценка: