Здравствуйте, Сергей Губанов, Вы писали:

СГ>Внимание вопрос! А что произойдет если написать:
СГ>

СГ> format c:/

СГ>ИМХО, система ляжет, причем вся.

Ну, если ОС на Обероне написана, то несомненно. А в NT тебе скорее всего скажут, что форматирование раздела на который установлена ОС невозможно. Это я к вопросу об обработке внештатных ситуаций...

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Реальный кусок кода был бы, например, таким:
СГ>

СГ>  d := MathCalc.CalcSum();
СГ>  IF d > EPSILON THEN i := 100 / d; ....
СГ>

Ну, код чтения из файла мы уже видели. Там было строк 10 от силы. Не думаю, что в написанной тобой программе будет меньше строк. А стало быть ошибки неизбежны. И супер-надежная система Оберона дает крах приложения. А вот Шарповское, после выдачи окошка с сообщением об ошибке, продолжает работать как ни в чем не бывало. Вот ведь парадокс. Так кто тут безграмотный программист?

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

К>Для сборщика с волновым алгоритмом раскраски — мы просто создадим кучу мелких объектов, которые будут ссылаться друг на друга. Пока он их всех оббежит... там будут такие фантастические задержки при выделении памяти, ты расплачешься.

На то придуманы поколения. После того как ЖЦ не сможет собрать грах объектов один раз этот граф попадет в первое поколение. Оно уже собирается не так часто. После первой сборки первого поколения граф переедет во второе поколение. Второе поколение собирается только при катастрафической нехватке памяти, так что рельно эти объекты влиять на производительность приложения будут очень слабо.

Другое дело, что если исчерпать всю память то лягут любые приложения.

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

СГ>>С точки зрения самого Windows, система BlackBox — это обычное приложение Windows со всеми вытекающими последствиями... Так что нечему тут удивляться.
WH>А если это оберон-ос стоящая на АЭС?

Дык главное успеть лечь нагами к АЭС.

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

K>Ну на самом деле тут я бы уже не стал придиратся. Если падает программа управляющая реактором, то какое имеет значение в каком режиме она выполнялась в ядре или в юзер-спейс?

Разница конечно мелкая. Так включается программа аварийного останова реактора, так происходит небольшая неуправляемая реакция в народе именуемая "кирдык".

K>Сама идея оберон-системы на самом деле-то весьма любопытная. Все в одном кольце защиты и запрет на прямой доступ к памяти. В этом что-то есть.

А главное уникальа! VB, C#, Java, ...

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

EC>Здравствуйте, Mr. None, Вы писали:

MN>>Не знаю, почему они отказались от друзей, но имел я в гробу эту комбинацию ассемблей с protected... Это так чистое ИМХО и крик души, прошу на данное сообщение не отвечать — флеймить не буду...
EC>А можно развернуть мысль, для тех кто не в теме?
EC>Не флейма ради, а самообразования для.

Есть класс, скажем, Composite, с ним связан класс, скажем, Node. У класса Composite есть метод OnSomeMessageFromNode — некий обработчик некоторого сообщения, которое может приходить только от объектов класса Node. Как гарантировать в компайл-тайме, что подообное сообщение ни от кого другого не придёт, с одной стороны и запретить объектам типа Node доступ к защищённым и собственным методам класса Composite?
На плюсах так:

class Node;

class CompositeMessages
{
friend class Node;
protected:
    virtual void OnSomeMessageFromNode() = 0;
}

class Composite : public CompositeMessages
{
protected:
    virtual void OnSomeMessageFromNode() // Этот метод Node вызвать может через CompositeMessages::OnSomeMessageFromNode
    {
        // Обработчик
    }

    void SomeProtectedFunction() // А вот этот нет - звиняйте, обломс в компайл-тайме...
    {
    }
};

class Node
{
public:
    Node(CompositeMessages *parent) : parent_(parent)
    {
    }

    void SomeFunction()
    {
        parent_->OnSomeMessageFromNode();
    }

private:
    CompositeMessages *parent_;
};

main()
{
    Composite composite;
    Node node(composite);
    node.SomeFunction();
}

А ну ка, теперь на шарпе сварганьте что-нть подобное, с такиме же начальными условиями...

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


VD> А вот Шарповское, после выдачи окошка с сообщением об ошибке, продолжает работать как ни в чем не бывало. Вот ведь парадокс. Так кто тут безграмотный программист?
То есть, мы чего-то там считали, поделили на 0, выдали сообщение об ошибке и продолжаем считать дальше как ни в чем не бывало? А смысл?

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

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

S_>> Классы в C# это те же модули о которых ты говоришь, тоько возможностей побольше.

AVK>Не совсем. Вот классы джавы, те да — один класс, один модуль.

Допустим, класс Java, равно как и класс C#, написанный в одном файле есть модуль. Компилируем его в исполнимый файл и загружаем этот исполнимый файл в память — исполняться. Вопрос на засыпку: Что именно будет исполнять данная единица исполнения?

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

MN>Есть класс, скажем, Composite, с ним связан класс, скажем, Node. У класса Composite есть метод OnSomeMessageFromNode — некий обработчик некоторого сообщения, которое может приходить только от объектов класса Node. Как гарантировать в компайл-тайме, что подообное сообщение ни от кого другого не придёт, с одной стороны и запретить объектам типа Node доступ к защищённым и собственным методам класса Composite?


MN>А ну ка, теперь на шарпе сварганьте что-нть подобное, с такиме же начальными условиями...

А можно я на Delphi и на Component Pascal?

Delphi:

unit M1;

type  
  Composite = class
    procedure OnSomeMessageFromNode(); virtual; abstract;
  end;

  Node = class
    procedure SetComposite(composite: Composite); virtual; abstract;
  end;

  Carrier = class
    procedure ShareComposite(obj: TObject); virtual; abstract;
  end;
  (* Carrier - является владельцем (или носителем) Composite 
     в методе ShareComposite(obj: TObject)
     Carrier отдает свой приватный Composite объекту obj
     если, конечно, посчитает это разумным
  *)

end.

unit M2;

uses M1;

type  
  Carrier = class (M1.Carrier)
    private 
      composite: M1.Composite; (* приватное поле *)
    public
      procedure ShareComposite(obj: TObject); override;
  end;

procedure Carrier.ShareComposite(obj: TObject);
begin
  if (obj <> nil) and (obj is M1.Node) then M1.Node(obj).SetComposite(Self.composite)
  // Carrier отдает свой приватный composite только если тип obj есть тип M1.Node
end;

end.

####################################################################################################################

Component Pascal:

DEFINITION M1;

TYPE
  Composite = ABSTRACT RECORD 
    (Self: Composite) OnSomeMessageFromNode(), NEW, ABSTRACT;
  END;

  Node = ABSTRACT RECORD 
    (Self: Node) SetComposite(IN composite: Composite), NEW, ABSTRACT;
  END;

  Carrier = ABSTRACT RECORD 
    (Self: Carrier) ShareComposite(IN obj: ANYREC), NEW, ABSTRACT;
  END
  (* Carrier - является владельцем (или носителем) Composite 
     в методе ShareComposite(VAR obj: ANYREC) 
     Carrier отдает свой приватный Composite объекту obj
     если, конечно, посчитает это разумным
  *)

END M1.

MODULE M2;

IMPORT M1;

TYPE
  Carrier = RECORD (M1.Carrier)
    composite : M1.Composite; (* приватное поле *)
  END

PROCEDURE (Self: Carrier) ShareComposite(IN obj: ANYREC), NEW, ABSTRACT;
BEGIN
  WITH obj: M1.Node DO obj.SetComposite(Self.composite) ELSE (* ... *) END
  (* Carrier отдает свой приватный composite только если тип obj есть тип M1.Node *)
END PutCompositeToNode;

END M2.

Carrier владеет composite и никому его не дает кроме как Node.

P. S.
Поправочка. Код:

СГ>PROCEDURE (Self: Carrier) ShareComposite(IN obj: ANYREC), NEW, ABSTRACT;
СГ>BEGIN
СГ>  WITH obj: M1.Node DO obj.SetComposite(Self.composite) ELSE (* ... *) END
СГ>  (* Carrier отдает свой приватный composite только если тип obj есть тип M1.Node *)
СГ>END PutCompositeToNode;

прошу читать как:

PROCEDURE (Self: Carrier) ShareComposite(IN obj: ANYREC);
BEGIN
  WITH obj: M1.Node DO obj.SetComposite(Self.composite) ELSE (* ... *) END
  (* Carrier отдает свой приватный composite только если тип obj есть тип M1.Node *)
END ShareComposite;

в торопях очепятался.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Mr. None, Вы писали:

MN>>Есть класс, скажем, Composite, с ним связан класс, скажем, Node. У класса Composite есть метод OnSomeMessageFromNode — некий обработчик некоторого сообщения, которое может приходить только от объектов класса Node. Как гарантировать в компайл-тайме, что подообное сообщение ни от кого другого не придёт, с одной стороны и запретить объектам типа Node доступ к защищённым и собственным методам класса Composite?


MN>>А ну ка, теперь на шарпе сварганьте что-нть подобное, с такиме же начальными условиями...

СГ>А можно я на Delphi и на Component Pascal?

нет нельзя — вопрос был про шарп и плюсы...

СГ>

СГ>  if (obj <> nil) and (obj is M1.Node) then M1.Node(obj).SetComposite(Self.composite)
СГ>  // Carrier отдает свой приватный composite только если тип obj есть тип M1.Node
СГ>

Ну и где здесь compile-time?

Здравствуйте, Сергей Губанов, Вы писали:
СГ>Допустим, класс Java, равно как и класс C#, написанный в одном файле есть модуль. Компилируем его в исполнимый файл и загружаем этот исполнимый файл в память — исполняться.
Это невозможно. Нельзя загрузить в память и исполнить класс C#. Загружается сборка, которая может содержать N классов.
В Java единицей загрузки является именно class, а пакет является всего лишь организационной абстракцией. Дефолтный класс лоадер умеет загружать классы из архивов, что делает архив еще и единицей деплоймента.
Но с точки зрения теории, все это — детали реализации класс лоадера, которая может изменяться и расширяться произвольным образом. При помощи такой техники не изменяя ни языка ни джава-машины можно получать генерацию кода не только на лету, но и по требованию.
В .Net другая идеология. Единицей деплоймента, загрузки, а также области видимости является именно сборка. Эти понятия не "размазаны" по разным сущностям и не отданы на откуп прикладным разработчикам.

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

К>Представляешь себе, каким изощрённым должен быть обработчик проверочного исключения, чтобы обеспечить стабильную работу сервера?

Представляю, это все таки моя работа. Ничего особенного.

К>

К>void stable_work()
К>{
К>  int attempts = 0;
К>  while(true)
К>  {
К>    try
К>    {
К>      unstable_work();
К>      break;
К>    }
К>    catch(assertion_fault& ex)
К>    {
К>      if(++attempts < treshold) continue; // а может, со второго захода повезёт?
К>      throw; // пускай клиент разбирается
К>    }
К>  }
К>}
К>

К>Маразматически выглядит, правда?

Правда. Потому что к реальным серверам этот код никакого отношения не имеет. На самом деле все проще — валится обслуживающий клиента поток, клиент разумеется получает отказ (впрочем несложно сделать так что клиент будет сам несколько раз пытаться выполнить операцию, для ненадежного соединения это полезная фича, вне зависимости от стабильности сервера), но сервер при этом остается в нормальном состоянии. А вот при порче стека ты вполне можешь затронуть чужие данные и обрушить сервер целиком. А можешь, пользуясь переполнением буфера, заслать вредоносный код.

К> А как вообще можно реагировать на assertion fault? Abort Retry Ignore.

Завершать текущую операцию. Ты запусти янус и посмотри как он ведет себя из-за багов — он почему то не рушится.

К>Abort — возьмём да и прибьём программу.
К>Retry — перезапустим. Вопрос, что именно? (всю программу, или сглючившую функцию). Откуда у нас такая уверенность, что перезапуск исправит свежеобнаруженный баг?
К>Ignore — ну правильно. Обнаружили выход за границы массива, и бог с ним. Следующим ходом будет расстрел памяти.
К>Под дебаггером Retry и Ignore — это ради бога. Потрассируем, регистры ручками выставим... там, глядишь и исправим. А в релизе?

Мы вроде бы об исключениях говорим, не так ли?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, AndrewVK, Вы писали:

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

S_>>> Классы в C# это те же модули о которых ты говоришь, тоько возможностей побольше.

AVK>>Не совсем. Вот классы джавы, те да — один класс, один модуль.

СГ>Допустим, класс Java, равно как и класс C#, написанный в одном файле есть модуль. Компилируем его в исполнимый файл и загружаем этот исполнимый файл в память — исполняться.

Блин, прям анекдот получается. Помните?
Инженера-практика и математика-теоретика заперли в разных комнатах в каждой комнате сундук, задание — открыть сундук за 30 минут. Через 30 минут заглядывают к инженеру — то сделал из подручных средств ломик и за 5 минут вскрыл сундук. Заглядывают к математику — сундук закрыт, но все стены исписаны формулами, а математик бормочит под нос: Ладно, давайте доказывать от противного, допустим, что сундук открыт!

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Извините, конечно, но!

ЗХ>В этом форуме еще есть модераторы?

Есть, но лучше без крайней необходимости их не призывать

Здравствуйте, Сергей Губанов, Вы писали:

AVK>>Не совсем. Вот классы джавы, те да — один класс, один модуль.

СГ>Допустим, класс Java, равно как и класс C#, написанный в одном файле есть модуль. Компилируем его в исполнимый файл и загружаем этот исполнимый файл в память — исполняться. Вопрос на засыпку: Что именно будет исполнять данная единица исполнения?

Не понял вопроса

Здравствуйте, Mr. None, Вы писали:
MN>Есть класс, скажем, Composite, с ним связан класс, скажем, Node. У класса Composite есть метод OnSomeMessageFromNode — некий обработчик некоторого сообщения, которое может приходить только от объектов класса Node. Как гарантировать в компайл-тайме, что подообное сообщение ни от кого другого не придёт, с одной стороны и запретить объектам типа Node доступ к защищённым и собственным методам класса Composite?
Вот так:
1. Защитная сборка с Node и CompositeMessages:

using System;

namespace TestMethodVisibility
{

    public abstract class CompositeMessages
    {
        abstract protected internal void OnSomeMessageFromNode();
    }
    public class Node
    {
        public Node(CompositeMessages parent) 
        {
            _parent = parent;
        }
        public void SomeFunction()
        {
            _parent.OnSomeMessageFromNode();
        }
        private  CompositeMessages _parent;
    }

}

2. Сборка с Composite:

using System;
using TestMethodVisibility;

namespace Client
{
    public class Composite : CompositeMessages
    {
        protected override void OnSomeMessageFromNode() // Этот метод Node вызвать может через CompositeMessages::OnSomeMessageFromNode
        {
            System.Console.WriteLine("Got message from Node");
        }
        protected void SomeProtectedFunction() // А вот этот нет - звиняйте, обломс в компайл-тайме...
        {
            System.Console.WriteLine("Node broke through the protection");
        }
    };
    class Class1
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        static void Main(string[] args)
        {
            Composite composite = new Composite();
            Node node = new Node(composite);
            node.SomeFunction();
        }
    }
}

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

ЗХ>>Извините, конечно, но!

ЗХ>>В этом форуме еще есть модераторы?

AVK>Есть, но лучше без крайней необходимости их не призывать

то есть она, типа, еще не крайняя? уй...

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

MN>Есть класс, скажем, Composite, с ним связан класс, скажем, Node. У класса Composite есть метод OnSomeMessageFromNode — некий обработчик некоторого сообщения, которое может приходить только от объектов класса Node. Как гарантировать в компайл-тайме, что подообное сообщение ни от кого другого не придёт, с одной стороны и запретить объектам типа Node доступ к защищённым и собственным методам класса Composite?

Точного соответствия нет. Вариантов навскидку два:

public class CompositeMessages
{
    protected internal abstract void OnSomeMessageFromNode();
}

public class Composite : CompositeMessages
{
    protected override void OnSomeMessageFromNode()
    {
        // Обработчик
    }
    
    protected void SomeProtectedFunction()
    {
    }
}

public class Node
{
    private CompositeMessages _parent;

    public Node(CompositeMessages parent)
    {
        _parent = parent;
    }
    
    void SomeFunction()
    {
        _parent.OnSomeMessageFromNode();
    }
}

class Program
{
    void Main()
    {
        Composite composite = new Composite();
    Node node = new Node(composite);
    node.SomeFunction();
    }
}

public class CompositeMessages
{
    public class Node
    {
        private CompositeMessages _parent;
    
        public Node(CompositeMessages parent)
        {
            _parent = parent;
        }
        
        void SomeFunction()
        {
            _parent.OnSomeMessageFromNode();
        }
    }
    
    protected abstract void OnSomeMessageFromNode();
}

public class Composite : CompositeMessages
{
    protected override void OnSomeMessageFromNode()
    {
        // Обработчик
    }
    
    protected void SomeProtectedFunction()
    {
    }
}

class Program
{
    void Main()
    {
        Composite composite = new Composite();
    CompositeMessages.Node node = new CompositeMessages.Node(composite);
    node.SomeFunction();
    }
}

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

S>Здравствуйте, Mr. None, Вы писали:
MN>>Есть класс, скажем, Composite, с ним связан класс, скажем, Node. У класса Composite есть метод OnSomeMessageFromNode — некий обработчик некоторого сообщения, которое может приходить только от объектов класса Node. Как гарантировать в компайл-тайме, что подообное сообщение ни от кого другого не придёт, с одной стороны и запретить объектам типа Node доступ к защищённым и собственным методам класса Composite?
S>Вот так:
S>1. Защитная сборка с Node и CompositeMessages:
S>2. Сборка с Composite:

Ну этот вариант сработает. Но мне не нравится следующее:
1) CompositeMessages и Composite фактически разделены, что не логично (хотя этот пункт весьма спорный);
2) для каждой такой пары (Composite — Node) придётся делать 2 отдельный сборки, этак мы придёи к идее господина Губанова о 500 независимых модулей...
3) но самое главное — небольшое усложенени исходной задачи сводит на нет эту реализацию... а ну ка, при сохранении прежних условий, сделайте так, чтобы от CompositeMessages никто, кроме Composite или Node унаследоваться не смог с проверкой опять-таки в компайл-тайме (строгую проверку — никто кроме Composite, даже на плюсах сделать сложно — так на вскидку не скажу, нужно эксперементировать, поэтому предлагаю упрощённый вариант задачи)...

для плюсов решение банальное:

class Composite;

class CompositeMessages
{
friend class Node;
friend class Composite;

protected:
    virtual void OnSomeMessageFromNode() = 0;

private:
    CompositeMessages(){}
    ~CompositeMessages(){}
};

class Composite : public CompositeMessages
{
// как и раньше
};