dot NET

← →
ferr © (2007-04-27 15:01) [120]

> С чего это? Я этой фигней пользоваться добровольно не собираюсь.

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

← →
Alkid © (2007-04-27 15:26) [121]

> Если LINQ таки доведут до ума, то конкурентов у c# поубавится.
> =)

Ага.
Кстати, а оно уже вышло в каком-либо виде, который можно пощупать? Типа Express-версия Visual C#?

← →
Александр Иванов © (2007-04-27 16:21) [122]

> [121] Alkid © (27.04.07 15:26)

Доступна для скачивания следующая версия VS

← →
Александр Иванов © (2007-04-27 16:22) [123]

> [122] Александр Иванов © (27.04.07 16:21)

Но по слухам, сам не проверял - 16 Гб.

← →
Alkid © (2007-04-27 18:38) [124]

> Но по слухам, сам не проверял - 16 Гб.

Что-то многова-то... :-/

← →
oxffff © (2007-04-28 09:27) [125]

> alex_*** © (27.04.07 11:11) [115]
>
> > procedure of object это есть ни что иное, как реализация
>
> > делегатов в Delphi
>
> делегаты умеют асинхронно запускаться. А если сделать event
> из него, то будет поддерживать мультикаст. Так что procedure
> of object - жалкое подобие

Кострукция procedure of object появились раньше. Так что это не подобие.
Delphi позволит запустить эту конструкцию так, как хочет разработчик.
Хочь синхронно\хочешь асинхронно\ хочешь еще как нибудь.

Так что это довод, не в пользу .NET

> ferr © (27.04.07 14:04) [118]
> Если LINQ таки доведут до ума, то конкурентов у c# поубавится.
> =)

Ого. Теперь и запросы.
Что теперь ВСЕ можно реализовать на .NET?
Или у вас везде fixed и unsafe.

P.S.
Рихтера не читайте. Читайте сразу ECMA-335.

← →
Alkid © (2007-04-28 09:34) [126]

> Кострукция procedure of object появились раньше. Так что
> это не подобие.
> Delphi позволит запустить эту конструкцию так, как хочет
> разработчик.
> Хочь синхронно\хочешь асинхронно\ хочешь еще как нибудь.
>
> Так что это довод, не в пользу .NET

Это довод, поскольку реализация асинхронного и мультикастного вызова в Delphi на прямую не поддерживается и это надо будет делать самому ручками. А в .NET это уже реализовано :)

> Что теперь ВСЕ можно реализовать на .NET?

Не всё, но на .NET можно реализовать всё, что можно на дельфи :)

← →
oxffff © (2007-04-28 09:53) [127]

> Это довод, поскольку реализация асинхронного и мультикастного
> вызова в Delphi на прямую не поддерживается и это надо будет
> делать самому ручками. А в .NET это уже реализовано :)

public delegate void Del(string message);

А что насчет других механизмов вызова?

>Не всё, но на .NET можно реализовать всё, что можно на дельфи :)

А динамические структуры данных?
Ах да везде fixed и unsafe.

Зачем себя так мучить?

Почитай ECMA-335

For every value type, the CTS defines a corresponding reference type called the boxed type. The reverse is not
true: In general, reference types do not have a corresponding value type. The representation of a value of a
boxed type (a boxed value) is a location where a value of the value type can be stored. A boxed type is an
object type and a boxed value is an object.
A boxed type cannot be directly referred to by name, therefore no field or local variable can be given a boxed
type. The closest named base class to a boxed enumerated value type is System.Enum; for all other value types
it is System.ValueType. Fields typed System.ValueType can only contain the null value or an instance of a
boxed value type. Locals typed System.Enum can only contain the null value or an instance of a boxed
enumeration type.

Все конечно делают за тебя.
То есть для каждого value типа есть его managed синоним.

И это еще не предел.

Я тебе говорю Рихтера не читай, читай ECMA-335.

P.S.

Пространство System.Assemblerx86 не добавили?

← →
Alkid © (2007-04-28 10:08) [128]

> А что насчет других механизмов вызова?

Поясни? Каких других?

> А динамические структуры данных?
> Ах да везде fixed и unsafe.

Кстати, ни разу fixed и unsafe не использовал. И что ты понимаешь под "динамическими структурами данных"? Я обычно под этим понимаю списки, деревья и проч. А ты?

> Все конечно делают за тебя.
> То есть для каждого value типа есть его managed синоним.

А, собственно, чего такого в том, что для каждого value-типа есть его reference (не managed! все они managed) аналог?

> Я тебе говорю Рихтера не читай, читай ECMA-335.

Я читаю MSDN.

> Пространство System.Assemblerx86 не добавили?

Не видел пока :)

← →
oxffff © (2007-04-28 10:30) [129]

> Alkid © (28.04.07 10:08) [128]
>
> > А что насчет других механизмов вызова?
>
> Поясни? Каких других?
>
>
> > А динамические структуры данных?
> > Ах да везде fixed и unsafe.
>
> Кстати, ни разу fixed и unsafe не использовал. И что ты
> понимаешь под "динамическими структурами данных"? Я обычно
> под этим понимаю списки, деревья и проч. А ты?

То же что и ты.
Скажи ты их сам реализовывал?
Или берешь из System.Collections?

Реализация на managed объектах относительно "медленна".

Что и доказывает Programming Guide

The .NET Framework class library contains several new generic collection classes in the System.Collections.Generic namespace.
These should be used whenever possible in place of classes such as ArrayList in the System.Collections namespace.

Более подробно google
Design and Implementation of Generics for the .NET Common Language Runtime

А unsafe реализация будет еще быстрее. IMHO

>Я читаю MSDN.

Этого не достаточно. :)

Кстати DynamicInvoke часто используешь?

P.S.
Что там у вас насчет dynamic методов. Или вы на основе Hash Таблицы их реализовываете?

← →
oxffff © (2007-04-28 10:33) [130]

Пора на работу. А то уже на два часа задержался.

Буду вечером.

> То же что и ты.
> Скажи ты их сам реализовывал?
> Или берешь из System.Collections?

Ну сейчас я generic-и активно использую. В частности списки. Деревья обычно сам, ибо они, как правило, замешаны на специфике.

> Реализация на managed объектах относительно "медленна".

Она медленна, если хранить ссылки типа System.Object и потом кастовать их в свой тип каждый раз. Учитывая, что при такой работе идут постоянные run-time проверки на кастуемость... Generic`и устарняют эту проблему.

> Кстати DynamicInvoke часто используешь?

До сих пор - ни разу.

> Что там у вас насчет dynamic методов. Или вы на основе
> Hash Таблицы их реализовываете?

Не приходилось. Средств, предоставляемых статической типизацей мне вполне достаточно :)

> А unsafe реализация будет еще быстрее. IMHO

не факт. Если не использовать boxing/unboxing то особой разницы я думаю не будет. unsafe тоже, знаете ли, по-разному можно реализовать.

Вообще странно выискивать какие-то копейки, когда основные тормоза происходят при взаимодействии с внешними системами и/или при неправильном алгоритме. До вылизывания кода до степени оптимизации коллекций, у меня, по кр. мере, практически не доходит.

>public delegate void Del(string message);
>А что насчет других механизмов вызова?

Я тоже не понял. Чего не хватает для жизни?

а насчет струкур - при вызове WinAPI помогает pinvoke.net Ничего изобретать не надо.

> а насчет струкур - при вызове WinAPI помогает pinvoke.net
> Ничего изобретать не надо.

Я вообще WinAPI из C# никогда не использую. Мне это кажется сильно неправильным (да и жизнь ещё не припёрла :) )

> То же что и ты.
> Скажи ты их сам реализовывал?
> Или берешь из System.Collections?

Я реализовывал их много раз, в том числе и generic"ами. Например различные балансированные деревья с разными свойствами, очереди по приоритету, системы непересекающихся множеств, полиномы(очень удобно Polynom<frac> vs Polynom<double>) ...

dot NET Найти похожие ветки