- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
class Matrix
{
double[,] matrix;
int rows, columns;
// Не вызывается до закрытия приложения
~Matrix()
{
Console.WriteLine("Finalize");
}
public Matrix(int sizeA, int sizeB)
{
rows = sizeA;
columns = sizeB;
matrix = new double[sizeA, sizeB];
}
// Индексатор для установки/получения элементов внутреннего массива
public double this[int i, int j]
{
set { matrix[i,j] = value; }
get { return matrix[i,j]; }
}
// Возвращает число строк в матрице
public int Rows
{
get { return rows; }
}
// Возвращает число столбцов в матрице
public int Columns
{
get { return rows; }
}
}
Обоснуй.
Просто Complex — это первое, что приходит в голову, когда надо найти отличие Фортрана от других языков.
Обидно, что кватернионов в Фортране нет...
Почти никогда не нужно.
В clr/.net дохрена с этим мороки.
Расчитывать на удаление им ресурсов -- глупо и наивно
> А может вообще не вызваться.
В особых случаях типа нестабильности проги (креши, failfast-закрытие). При нормальном ходе программы на выходе запускаются все оставшиеся финализаторы (есть, правда, таймаут).
или инспекция "Нету вызова close в блоке finally для объекта класса, импементирующего close" в одном известном IDE для джавы)
"есть using() в дотнете." -- бред.
"есть using() в сишарпе." -- ок.
Если класс вызван языком, где нет аналога using (функциональные? какой-то third-party-язык?), то юзер мог забыть проставить Dispose (или даже не знать о нём, потому что индус). clr - это мультиязыковая среда, не то что убогонькая java, нужно подстраиваться под всех.
с помощью костылей всегда мождно связать одно с другим. правда, ценой тормозов, например.
Я говорю про мультиязыковость изначальную, нативную.
в жабе мультиязыковость прибита позднее, разнокалиберными гвоздами, скорее всё маркетологической болтовнёй.
В clr можно реализовать больше языком, чем в java. Напр., в java технически не реализовать C#.
Если язык работает с указателями -- опять же, java не пустит.
Если в языке есть хотя бы такая мелочь как unsigned числа - всё, java громко пердит и накрывается тазом.
Что такое "нативная"? Вы опять термины не по назначению употребляете?
>>в жабе мультиязыковость прибита позднее, разнокалиберными гвоздами, скорее всё маркетологической болтовнёй.
Смешно слышать о "маркетологической болтовне" от адепта .NETа)
>>Напр., в java технически не реализовать C#.
да ну?:) А проект такой есть. Правда кому он нужен? Стараниями linq и extension methods си шарп стремительно превращается в говноязык по хлеще php, так что не думаю что этот проект кому-то нужен.
>>Если язык работает с указателями -- опять же, java не пустит.
Да, при наличии управляемой кучи это очень важно) Вы видели работу с указателями в .NET где нить, кроме PInvoke?
Так как PInvoke автоматически привязывает нас к платформе -- его в джаве и нет.
>>Если в языке есть хотя бы такая мелочь как unsigned числа -
Их можно сэмулировать.
Чего реально не хватает в джаве -- так это структур (хранящихся в стеке)
а зачем?
посмотри, что значит native в англ. никогда выражения "native support" не слышал, дурашка неграмотная? То же, что и "out of box support".
> Смешно слышать о "маркетологической болтовне" от адепта .NETа)
Я не адепт .NET'а, я адепт mono, а там маркетология просто НУЛЕВАЯ.
> да ну?:) А проект такой есть.
Ну вот например в java-машине не просто так раеализовать структуры. Скорей всего в Grasshopper'е постоянно идёт clone(). Я не спорю, что на тюринг-полной машине можно реализовать что угодно, но это будут жуткие костыли + тормоза. Поэтому я и говорю, что clr изначально лучше для мультиязыковой поддержки.
> Вы видели работу с указателями в .NET где нить, кроме PInvoke?
Да, в классе String, например. Или аргументы out и ref.
Плюс, опять же, если указатели не нужны в C#, это не значит, что есть теоретически язык, которому они не понадобятся. clr - мультиязыковая среда, поэтому она предоставляет и указатели, т.к. какой-нибудь язык их может требовать.
> Так как PInvoke автоматически привязывает нас к платформе -- его в джаве и нет.
Работа с указателями никак не привязывает к платформе. Указатели это не PInvoke. Кстати, если ты не в курсе, то в clr два типа указателей: managed pointers и unmanaged pointers. Синтаксис в ilasm разные: int* и int&.
Так-то. Не то что в ограниченной жаба гыгы.
> Их можно сэмулировать.
Интересно, как? Да и тормозами. И костылями. И велосипедами.
Напр., в .NET есть официально поддерживаемый слой абстракции для динамических языков - DLR. Там есть определения для Tuple<>, Func<> и многое другое.
В яве же, чтобы реализовать язык, нужно всеё велосипедить вручную.
Плюс напр. два дингамических языка не смог нормально общаться друг с другом, потому что тупли у них разные, списки у них разные, и так далее.
Одно дело - сделать компилятор языка в java-байткод, другое деол - сделать так, чтобы байткод, написанный на разных языках, мог нормально друг с другом общаться.
Вот ты пиздел про PInvoke, а структукры в сишарпе чисто для PInvoke'а сделаны. Не быо бы PInvoke'а, их бы и не вставили.
Кстати, здесь ты жёстко тупишь. Если вызываемая пинвоком либа сама по себе кроссплатформенная, то пинвок нас никуда не привязывает.
Напр. PInvoke к функциям GTK -- будет работать на всех процессорах, на всех ОСях.
А в жабе мы бы делали JNI-слой, и компилировали бы нативную glue-либу под каждую архитектуру, как мудни. Не это ли привязка к платформе? Если мы не сделали GTK-glue под ARM -- то всё, не пашет java-GTK под ARM. И так далее.
А в mono один раз написал - и радуйся.