.Net

[belugin]

Вот это я не понял, это про что:

Про "тормознутость" разработки: нужно все контролировать без помощи компилятора, переписывать базовые классы/методы, прописывать "линейки" конструкторов и др методов, предназначенных для одного и того же и проч, проч, проч.

можете разжевать?

2 belugin
Не уверен, что смогу подробнее раскрыть , подобрав другие слова, но попробую: Рихтер указывает, что многие методы базовых объектов (System.Object) реализованы не самым эффективным с точки зрения скорости выполнения образом и их нужно заменять. Также приводит в пример , кажется, System.Decimal и System.String (у стринга это методы Concat), в которых "правильно" реализованы линейки перегруженных методов с тем, чтобы не использовать стандартный массив параметров ( params ). Создавая конструкторы, нужно тщательно продумывать, будут ли создаваться объекты по значению, в какой момент сработают конструкторы типов. Для методов: будут ли генерироваться параметры как динамические объекты в куче, минимизировать их число, вынося генерацию объектов из методов. если можно обойтись одним объектом; советует перегружать методы только из-за того, чтобы они возвращали различные типы значений (и не было операции конвертации, уж больно дюже она неэффективна) , что-то еще , что сейчас вечером уже не в силах вспомнить.

Да прочтите, там 650 страниц этого жевания. Я только до 224 дошел, а советов по оптимизации кода - вагон и маленькая тележка. Книга ими просто пронизана. Неспроста это, недовольны разработчики скоростью.

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

[_scorp_]

Цитата:

Сообщение от otkudao

2 belugin
Не уверен, что смогу подробнее раскрыть , подобрав другие слова, но попробую: Рихтер указывает, что многие методы базовых объектов (System.Object) реализованы не самым эффективным с точки зрения скорости выполнения образом и их нужно заменять. Также приводит в пример , кажется, System.Decimal и System.String (у стринга это методы Concat), в которых "правильно" реализованы линейки перегруженных методов с тем, чтобы не использовать стандартный массив параметров ( params ). Создавая конструкторы, нужно тщательно продумывать, будут ли создаваться объекты по значению, в какой момент сработают конструкторы типов. Для методов: будут ли генерироваться параметры как динамические объекты в куче, минимизировать их число, вынося генерацию объектов из методов. если можно обойтись одним объектом; советует перегружать методы только из-за того, чтобы они возвращали различные типы значений (и не было операции конвертации, уж больно дюже она неэффективна) , что-то еще , что сейчас вечером уже не в силах вспомнить.

ааа, Вы про упаковку... Не все объекты получится разместить в стеке потока, от кучи никуда не уйти. В C++, например, у разработчика вообще нет контроля над тем куда разместить объект в стек потока или в кучу. Так что в .NET это плюс - у разработчика больше свободы.

На самом деле, я считаю, что .NET в аксапте не нужен. В таких приложениях большую часть времени занимают операции ввода-вывода, и зачастую, временем, за которое выполняется код можно вообще пренебречь - настолько мизерную часть от общего времени он составляет. Поэтому, мне кажется, не стоит ждать того, что после перехода с x++ на c# аксапта "залетает".

А еще я думаю, что читать код на c# будет сложнее, т.к. нужно будет следить за всякими нюансами .NET, а не только за бизнес логикой. Вот примерчик, для демонстрации того, о чем я говорю:

class Program
    {
        static void Main(string[] args)
        {
            Shape shape1 = new Shape(1, 2, 3, 4, "descr1", 5);
            Console.WriteLine(shape1.ToString());
            Shape shape2 = shape1;
            shape2.description = "descr2";
            shape2.intValue = 6;
            shape2.p1.x = 7;
            shape2.p1.y = 8;
            Console.WriteLine(shape1.ToString());
            Console.WriteLine(shape2.ToString());
            Console.ReadLine();
        }

        public class Point
        {
            public int x;
            public int y;

            public Point(int x, int y)
            {
                this.x = x;
                this.y = y;
            }
        }

        public struct Shape
        {
            public Point p1;
            public Point p2;
            public string description;
            public int intValue;

            public Shape(int x1, int y1, int x2, int y2, string descr, int i)
            {
                p1 = new Point(x1, y1);
                p2 = new Point(x2, y2);
                description = descr;
                intValue = i;
            }
            public override string ToString()
            {
                return String.Format("p1 = {0}:{1}, p2 = {2}:{3} descr: {4} int: {5}", p1.x, p1.y, p2.x, p2.y, description, intValue);
            }
        }        
    }

Вот результат выполнения:

Цитата:

p1 = 1:2, p2 = 3:4 descr: descr1 int: 5
p1 = 7:8, p2 = 3:4 descr: descr1 int: 5
p1 = 7:8, p2 = 3:4 descr: descr2 int: 6

[Diman]

Цитата:

Сообщение от _scorp_

В C++, например, у разработчика вообще нет контроля над тем куда разместить объект в стек потока или в кучу.

В С++ как раз есть куча способов, куда разместить объект. Смотрите malloca() + placement new, а еще есть регистровые переменные, а еще можно делать ассемблерные вставки....

Цитата:

Сообщение от _scorp_

На самом деле, я считаю, что .NET в аксапте не нужен. В таких приложениях большую часть времени занимают операции ввода-вывода, и зачастую, временем, за которое выполняется код можно вообще пренебречь - настолько мизерную часть от общего времени он составляет. Поэтому, мне кажется, не стоит ждать того, что после перехода с x++ на c# аксапта "залетает".

Ну в некоторых местах залетает, только, к сожалению, мало таких мест.

[_scorp_]

Цитата:

Сообщение от Diman

В С++ как раз есть куча способов, куда разместить объект. Смотрите malloca() + placement new

В C++ я не силен. Основывался на том что писал Рихтер

Цитата:

Многим разработчикам (в частности тем, кто пишет неуп
равляемый код на C/C++) деление на ссылочные и значимые типы по
началу будет казаться странным. В неуправляемом коде C/C++ вы объяв
ляете тип, и уже код решает, куда поместить экземпляр типа: в стек по
тока или в кучу приложения. В управляемом коде иначе: разработчик, опи
сывающий тип, указывает, где разместятся экземпляры данного типа, а
разработчик, использующий тип в своем коде, управлять этим не может.

Получается он наврал?

Сам чуть-чуть покопал по ключевым словам. Вроде бы _alloc() действительно может выделить память для переменной в стеке. Но так же пишется, что в стек ограничен где-то 1 МБ, и если активно им пользоваться, то можно поймать переполнение. В .NET про такое ограничение не слышал.

Цитата:

Сообщение от Diman

а еще есть регистровые переменные

Почитал... Как я понял, много туда не сохранишь.

Цитата:

Сообщение от Diman

а еще можно делать ассемблерные вставки....

Ну так много не напрограммируешь

[Diman]

Цитата:

Сообщение от _scorp_

В C++ я не силен. Основывался на том что писал Рихтер


Получается он наврал?

Нет, не наврал. Под неуправляемым поведением, здесь имеелось ввиду, что по умолчанию оптимизатор С++ пытается положить в стек, если не получается, то в кучу.

Цитата:

Сообщение от _scorp_

Сам чуть-чуть покопал по ключевым словам. Вроде бы _alloc() действительно может выделить память для переменной в стеке. Но так же пишется, что в стек ограничен где-то 1 МБ, и если активно им пользоваться, то можно поймать переполнение. В .NET про такое ограничение не слышал.

Это по умолчанию 1Мб, если правильно помню.
Надо глянуть, что на счет стека в .Net говорит стандарт, или на соотв. форумах поискать.
Можно поймать переполнение, но если программист уж связался со стеком, значит сделал это сознательно и должен, как порядочный человек, ухаживать за ним до конца.

Цитата:

Сообщение от _scorp_

Почитал... Как я понял, много туда не сохранишь.

Зависит от задачи, иногда хватает.

Цитата:

Сообщение от _scorp_

Ну так много не напрограммируешь

Много не надо, надо в меру

[belugin]

Допустим есть код

void f()
{
Ascii io = new AsciiIo(@'c:\myFile.txt','r');
io.read();
}

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

При каждом присваивании поля класса надо пробежать по всем достижимым из поля класса объектам и посмотреть не образовалось ли новых циклов (типа A ссылается на B, который ссылается на С которрый ссылается обратно на А) и увеличить счетчик циклов. А припотери ссылки - уменьшить. В результате все тормозит на больших графах объектов.

В .NET такого обязательсятва нет - мустор собирается только время от времени или если память кончается. Но при этом дорогие ресурсы (типа открытых файлов) приходится освобождать явно

Ascii io=new AsciiIO...
try
{
    io.read();
}
finally
{
   io.Dispose();
}

для этого в C# введен даже синтаксичесикй сахар:

using(AsciiIO io= new AsciiiIO(...))
{
    io.read();
}

[belugin]

я бы вопросы по .NET задавал на http://rsdn.ru или http://gotdotnet.ru

[KindDog]

Нашел тут примерчики работы с Net-ом. Может кому интересно будет.

http://www.codeproject.com/KB/cs/IntegrateAxapta.aspx
http://www.codeproject.com/KB/cs/Int...xaptPart2.aspx