Здравствуйте, 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 или не нужно, никогда не задавался.
Вот, и у меня в голове такая же формула сидела. Сунулся проверить — хвать, а нет у Инта конструкторов с параметрами (.Net 4.0, старее не установлены).
Так что:
Здравствуйте, 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);
Вы до сих пор указываете параметр обобщенных методов?
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.
Здравствуйте, 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> может находиться в одной сборке, а десяток его вызовов с десятком разных типов аргументов ― в десятке других сборок (возможно, даже пока не существующих).
Если нам не помогут, то мы тоже никого не пощадим.
Вспоминаю старый слоган: "настоящий хакер кодит в notepad".
