Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 09:00
Оценка: -5
Для затравки: Как функции, не являющиеся методами, улучшают инкапсуляцию Скотт Мейерс (Scott Meyers) Перевод А. И. Легалова Статья опубликована в C/C++ user Journal (February, 2000) http://www.softcraft.ru/coding/sm/sm01.shtml


Скотт Мейерс предлагает следующий алгоритм:
if (f необходимо быть виртуальной)
   сделайте f функцией-членом C;
else if (f - это operator>> или operator<<)
{
   сделайте f функцией - не членом;
   if (f необходим доступ к непубличным членам C)
      сделайте f другом C;
}
else if (f необходимо преобразовывать тип его крайнего левого аргумента)
{
   сделайте f функцией - не членом;
   if (f необходимо иметь доступ к непубличным членам C)
      сделайте f другом C;
}
else if (f может быть реализована через доступный интерфейс класса)
   сделайте f функцией - не членом;
else
   сделайте f функцией-членом C;



Вопрос: а зачем так сложно? Давайте проще:
IF f необходимо быть виртуальной THEN сделайте f функцией членом ELSE сделайте f внешней функцией END


Все связанные с типом процедуры — виртуальны, а если нужны не виртуальные, а обычные, то для этого есть обычные процедуры не связываемые с типом.

1) X.f(); Вызов связанной с типом "виртуальной" процедуры f()
2) g(X); Вызов не связанной с типом обычной процедуры g()
3) третьего не дано, так как все остальное излишне

С аргументами:
  X.f(a, b, c);
  g(X, a, b, c);


Пример:
PROCEDURE MovePoint(VAR p: Point; dx, dy: INTEGER);
BEGIN
  p.SetX(p.GetX() + dx); (* Вызов виртуальных методов GetX/SetX *)
  p.SetY(p.GetY() + dy); (* Вызов виртуальных методов GetY/SetY *)
END;



Короче, если метод не виртуальный, то зачем он метод? Пусть он будет не методом, а внешней процедурой. А все оставшиеся методы — все поголовно виртуальны.
Re: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.11.04 09:14
Оценка: +3
Здравствуйте, Сергей Губанов, Вы писали:

{поскипано к чертям}

СГ>Короче, если метод не виртуальный, то зачем он метод? Пусть он будет не методом, а внешней процедурой. А все оставшиеся методы — все поголовно виртуальны.


И что это даст? Какие положительные аспекты такого подхода?
Отрицательные я вот вижу сразу:
1. переполнение безымянного пространства имён излишними ф-циями (аля MoveLine, MovePoint, MoveCircle вместо объектов с простым методом Move)
2. неинтуитивность семантики работы таких методов, т.е. "не ООП-ориентированность", если можно так сказать, т.е. не понятно, к какому объекту применяется операция (e.g. почему к 1-му в списке, а не к последнему???)

Вот тебе 2 минуса (на мой взгляд), приведи хоть 1 плюс.
Re: Связанные с типом процедуры должны быть виртуальными
От: XopoSHiy Россия http://cleancodegame.github.io/
Дата: 10.11.04 09:19
Оценка: +4
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Короче, если метод не виртуальный, то зачем он метод? Пусть он будет не методом, а внешней процедурой. А все оставшиеся методы — все поголовно виртуальны.


Причины, по которым невиртуальные методы стоит делать именно методами, а не внешней подпрограммой:

1. Это логично. Невиртуальную процедуру UpdateContents удобно поместить в класс TSuperVisualControl
Иначе нам придётся иметь процедуры GridUnpdateContents(g: TGrid), TreeUnpdateContents(t: TTree), UnpdateContentsOfEdit(e: TEdit), и тд...

2. Внешние подпрограммы засоряют пространство имён. Придётся вводить всякие суффиксы, либо разносить по пакетам:
Grids.UpdateContents(grid)
Edits.UpdateContents(edit)
или
GridUpdateContents(grid)
EditUpdateContents(edit)

и тд.
Ну так это и есть какое-то убогое эмулирование методов! Лучше сразу методом и делать.

3. Во многих языках нет такого понятия, как friend! Тогда ничего не остаётся, как делать подпрограмму методом, если нужен доступ к закрытым полям и методам класса.

Наверное ещё придумать можно... Но уже и этих трёх достаточно.

Просто так рубить с плеча — нехорошо... Вот Мейерс более аккуратен, хотя я бы и с ним поспорил, была бы возможность
---
http://twitter.com/xoposhiy
http://xoposhiy.moikrug.ru
Re: Связанные с типом процедуры должны быть виртуальными
От: AndreyFedotov Россия  
Дата: 10.11.04 09:24
Оценка:
Ну уж если упрощать, то так как язык-таки ООП — надо к бабушке выкинуть обычные функции
Я не вижу — что мы упростим — выкинув не-виртуальные функции. Не надо будет писать слово virtual? По-моему главным результатом такого упрощения станет то, что всякий раз, когда не виртуальный изначально метод будет становиться виртуальным (или наборот) — придётся править код. Кроме того в силу этого усложнится написание шаблонов. Ну а количество ошибок как минимум не уменьшится.
Re[2]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 09:27
Оценка: -2
Здравствуйте, Курилка, Вы писали:

К>Отрицательные я вот вижу сразу:

К>1. переполнение безымянного пространства имён излишними ф-циями

Извините, но еще со времен Модулы (70-тые годы) "безымянных пространств имен" не существует. Все процедуры пишутся внутри модулей. Так что Ваше замечание относится только к еще более древним языкам программирования чем Модула.

К>2. неинтуитивность семантики работы таких методов, т.е. "не ООП-ориентированность", если можно так сказать, т.е. не понятно, к какому объекту применяется операция (e.g. почему к 1-му в списке, а не к последнему???)


Не совсем понял, можно поподробнее?
IMPORT Lists;

VAR L: Lists.List;
...

  Lists.FirstElementUpdate(L);
  Lists.BackElementUpdate(L);
Re[2]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 09:32
Оценка:
Здравствуйте, XopoSHiy, Вы писали:

XSH> Невиртуальную процедуру UpdateContents удобно поместить в класс TSuperVisualControl

XSH>Иначе нам придётся иметь процедуры GridUnpdateContents(g: TGrid), TreeUnpdateContents(t: TTree), UnpdateContentsOfEdit(e: TEdit), и тд...

Вы сами дали ответ на свой вопрос:
Grids.UpdateContents(grid)
Edits.UpdateContents(edit)




XSH>2. Внешние подпрограммы засоряют пространство имён. Придётся вводить всякие суффиксы, либо разносить по пакетам:


Какое еще пространство имен засоряет? Ничего не засоряет! Есть модуль Grids в котором определена процедура:
MODULE Grids;

PROCEDURE UpdateContents(grid: Grid);
...


Вызов:
Grids.UpdateContents(grid)



XSH>3. Во многих языках нет такого понятия, как friend! Тогда ничего не остаётся, как делать подпрограмму методом, если нужен доступ к закрытым полям и методам класса.


А в других многих языках инкапсуляция осуществляется на уровне модуля. Все описанное внутри одного модуля "дружит" друг с другом.
Re: Связанные с типом процедуры должны быть виртуальными
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.11.04 09:33
Оценка: 37 (4) +5
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Вопрос: а зачем так сложно? Давайте проще:

Очень странный вопрос для программиста на С++. Методы отличаются от функций прежде всего тем, какой доступ они имеют к содержимому класса.
Поэтому просто "вынести" невиртуальный метод, использующий приватную часть, за пределы класса не выйдет — придется сделать его другом. А это ничем, кроме синтаксической путаницы, не отличается от нормального метода класса.
Мейерс предлагает выносить за пределы класса те методы, которым достаточно доступа через его публичный интерфейс. Их можно назвать утилитными, т.к. клиент класса может и сам воспроизвести их функциональность, и их применение — не более чем вопрос удобства.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 09:37
Оценка:
Здравствуйте, AndreyFedotov, Вы писали:


AF> По-моему главным результатом такого упрощения станет то, что всякий раз, когда не виртуальный изначально метод будет становиться виртуальным (или наборот) — придётся править код.


Это как это? Что за мутация такая виртуальный в невиртуальный или наоборот? Это такая последняя мода проектировать надежные системы?
Re[2]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 09:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


СГ>>Вопрос: а зачем так сложно? Давайте проще:

S>Очень странный вопрос для программиста на С++. Методы отличаются от функций прежде всего тем, какой доступ они имеют к содержимому класса.
S>Поэтому просто "вынести" невиртуальный метод, использующий приватную часть, за пределы класса не выйдет — придется сделать его другом. А это ничем, кроме синтаксической путаницы, не отличается от нормального метода класса.

Это исключительно проблемы языков С++ family. В модульных языках программирования инкапсуляция осуществляется на уровне модуля. Внутри модуля все друг с другом "дружат".
Re[3]: Связанные с типом процедуры должны быть виртуальными
От: AndreyFedotov Россия  
Дата: 10.11.04 09:49
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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



AF>> По-моему главным результатом такого упрощения станет то, что всякий раз, когда не виртуальный изначально метод будет становиться виртуальным (или наборот) — придётся править код.


СГ>Это как это? Что за мутация такая виртуальный в невиртуальный или наоборот? Это такая последняя мода проектировать надежные системы?


А что тебя удивляет — если в одном классе метод виртуальный, а в другом — нет — но при этом они оба используются в одном и том же шаблоне? И то, что результатом станет комбинаторный рост числа шбалонов и как следствие такого "упрощения" — бессмысленность использования шаблонов вообще?
Или то, что код не проектируется разом от начала и до конца?
Re: Ну ты посмотри - его через дверь так он в окно лезет...
От: AndreyFedotov Россия  
Дата: 10.11.04 09:51
Оценка: :))) :))
Со своим Обероном...
Re[3]: Связанные с типом процедуры должны быть виртуальными
От: XopoSHiy Россия http://cleancodegame.github.io/
Дата: 10.11.04 09:52
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:


XSH>>2. Внешние подпрограммы засоряют пространство имён. Придётся вводить всякие суффиксы, либо разносить по пакетам:


СГ>Какое еще пространство имен засоряет? Ничего не засоряет! Есть модуль Grids в котором определена процедура:

СГ>
СГ>MODULE Grids;

СГ>PROCEDURE UpdateContents(grid: Grid);
СГ>...
СГ>


СГ>Вызов:

СГ>
СГ>Grids.UpdateContents(grid)
СГ>


Ну да! Вместо того, чтобы писать

grid.UpdateContents;

Вы предлагаете

Grids.UpdateContents(grid)

Что-то мне это напоминает...

Методы в Perl-e реализованны именно с помощью такой конструкции!
Я к тому, что то, что вы предлагаете, это всего лишь способ эмулировать работу с методами.
И способ вполне жизнеспособный, как показал Perl

XSH>>3. Во многих языках нет такого понятия, как friend! Тогда ничего не остаётся, как делать подпрограмму методом, если нужен доступ к закрытым полям и методам класса.


СГ>А в других многих языках инкапсуляция осуществляется на уровне модуля. Все описанное внутри одного модуля "дружит" друг с другом.


Много бы я отдал, чтобы этого не было в Delphi. Все ноги переломаешь, пока разберёшься в таком "дружественном" коде...
Frien-ы — вообще ненужная вещь
---
http://twitter.com/xoposhiy
http://xoposhiy.moikrug.ru
Re: Связанные с типом процедуры должны быть виртуальными
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 10.11.04 09:58
Оценка: 29 (3)
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Для затравки: Как функции, не являющиеся методами, улучшают инкапсуляцию Скотт Мейерс (Scott Meyers) Перевод А. И. Легалова Статья опубликована в C/C++ user Journal (February, 2000) http://www.softcraft.ru/coding/sm/sm01.shtml


Для затравки прочитайте ещё его же книги "Эффективное использование C++" и "Более эффективное использование C++". В данной статье Мейерс продолжает свою теорию относительно минимальности и достаточности интерфейса:
интерфейс класса должен быть минимальным, но полным, то есть набор открытых методов класса должен быть минимальным, ограниченный абсолютно необходимыми, но при этом точно покрывать всю доступную открытую функциональность класса. Согласно этому подходу, если интерфес класса удовлетворяет свойству минимальности и полноты, любой новый метод, будет реализовываться через уже имеющиейся методы, и это нарушит данный принцип. Именно такие "методы" Мейерс и предлагает делать внешними. Чувствуете разницу между этими словами и вашим предложением?
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[4]: Связанные с типом процедуры должны быть виртуальными
От: hrg Россия  
Дата: 10.11.04 10:04
Оценка: :)
XopoSHiy -> "Re[3]: Связанные с типом процедуры должны быть виртуальными"

Grids.UpdateContents(grid)

X> Методы в Perl-e реализованны именно с помощью такой конструкции!

X> Я к тому, что то, что вы предлагаете, это всего лишь способ
X> эмулировать работу с методами.
X> И способ вполне жизнеспособный, как показал Perl

"Не позволю с Вами согласится"(с) хз чей

$grid->UpdateContents();

без всяких лишних телодвижений и лишних параметров.

Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно гармонист
Posted via RSDN NNTP Server 1.9 gamma
Re[3]: Связанные с типом процедуры должны быть виртуальными
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.11.04 10:06
Оценка: 2 (2) +3 :)
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Это исключительно проблемы языков С++ family.

Пардон, ты берешся критиковать фрагмент, посвященный эффективному программированию на плюсах. Это что, такое раздвоение сознания?
СГ>В модульных языках программирования инкапсуляция осуществляется на уровне модуля. Внутри модуля все друг с другом "дружат".
Ну, я бы на твоем месте избегал столь широких обобщений. В виртовских языках — да. А вообще нет никакого определения "модульного языка", которое бы требовало дружбы всего подряд внутри модуля.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Связанные с типом процедуры должны быть виртуальными
От: bkat  
Дата: 10.11.04 10:06
Оценка: 6 (2)
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Это исключительно проблемы языков С++ family. В модульных языках программирования инкапсуляция осуществляется на уровне модуля. Внутри модуля все друг с другом "дружат".


Нафиг нафиг такую дружбу всех со всеми, хоть и в пределах одного модуля...
Re[3]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.11.04 10:26
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>Отрицательные я вот вижу сразу:

К>>1. переполнение безымянного пространства имён излишними ф-циями

СГ>Извините, но еще со времен Модулы (70-тые годы) "безымянных пространств имен" не существует. Все процедуры пишутся внутри модулей. Так что Ваше замечание относится только к еще более древним языкам программирования чем Модула.


Вот не надо, Сергей, только опять навязывать все вирт. языки как "единственно верные"...
Скажи мне, где в Java, к примеру, есть модули?
Или на каждый класс нужно в пр-во имён заворачивать? А потом указывать именно пр-во имён вместо класса?

К>>2. неинтуитивность семантики работы таких методов, т.е. "не ООП-ориентированность", если можно так сказать, т.е. не понятно, к какому объекту применяется операция (e.g. почему к 1-му в списке, а не к последнему???)


СГ>Не совсем понял, можно поподробнее?

СГ>
СГ>IMPORT Lists;

СГ>VAR L: Lists.List;
СГ>...

СГ>  Lists.FirstElementUpdate(L);
СГ>  Lists.BackElementUpdate(L);
СГ>


При чём тут этот псевдокод?
Что я имел в виду:

X.f(a, b, c);
/* 1-й элемент */
g(X, a, b, c);
/* последний элемент */
g(a, b, c, X);


так понятней?
Re[2]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 10:28
Оценка: -1
Здравствуйте, Mr. None, Вы писали:

MN>...любой новый метод, будет реализовываться через уже имеющиейся методы, и это нарушит данный принцип. Именно такие "методы" Мейерс и предлагает делать внешними. Чувствуете разницу между этими словами и вашим предложением?


Да, чувствую. Слово интерфейс — широко в своем значении. У того что обозначается interface в Delphi, C#, Java — у него все методы "виртуальные". Не виртуальных методов в таком интерфейсе нет. Вот и Вы тоже почувствуйте разницу.
Re[4]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 10:38
Оценка: -1
Здравствуйте, Курилка, Вы писали:

К>Вот не надо, Сергей, только опять навязывать все вирт. языки как "единственно верные"...

К>Скажи мне, где в Java, к примеру, есть модули?
К>Или на каждый класс нужно в пр-во имён заворачивать? А потом указывать именно пр-во имён вместо класса?

Как одновременно: "1) Вот не надо, Сергей, только опять..." и "2) Скажи мне, где в Java..."? На второй пункт я бы мог ответить, но первый пункт запрещает это сделать. Вот если бы он не запрещал, то я бы ответил, что пространства имен — тупиковая ветвь в развитии языков программирования появившаяся из-за отсутсвия модульности. Куда ни ткни везде с модульностью — ни каких проблем, а с пространствами имен сплошные грабли. Вот и тут опять же такие грабли они подложили. Из-за namespace выходит нельзя делать методы обычными не связанными с типом процедурами...


К>
/* 1-й элемент */
g(X, a, b, c);
/* последний элемент */
g(a, b, c, X);

К>так понятней?

Так понятней. А какая разница-то? Можно и так: g(a, X, b, Y, c, Z); — для трех объектов X, Y, Z...
Re[5]: Связанные с типом процедуры должны быть виртуальными
От: XopoSHiy Россия http://cleancodegame.github.io/
Дата: 10.11.04 10:46
Оценка:
Здравствуйте, hrg, Вы писали:

X>> Методы в Perl-e реализованны именно с помощью такой конструкции!

hrg>"Не позволю с Вами согласится"(с) хз чей

hrg>$grid->UpdateContents();

hrg>без всяких лишних телодвижений и лишних параметров.

Это синтаксические навороты языка. Фактически это эквивалентно следующей записи:
GridsPackage::UpdateContents($grid);

То есть стрелка "->" интерпретируется именно так! Она подыскивает нужный пакет и вызывает оттуда указанную функцию с объектом в качестве первого параметра. При этом, как Вы наверное знаете, в самой функции придется таки писать так:

sub UpdateContents
{
  my $self = shift;
  ...

}


Что эквивалентно следующему коду на Паскале:

procedure UpdateContents(self: TObject);
begin

end;


// и вызов:
UpdateContents(grid);


Ещё разик: В перле методы реализованы именно как внешние функции. В частности у одного объекта можно вызывать совершенно не его методы. Но всё это обёрнуто в "удобную" синтаксическую конструкцию, напоминающую вызов метода в других языках.

Собственно там даже метод класса (статический в терминах С++) не отличается от обычных методов: если первым параметром пришёл объект, то метод обычный, если первым параметром пришёл пакет — то это метод класса.


К слову, Перл позиционируется как язык не скрывающий от программиста ничего! Там крайне сложно (если вообще возможно) создать private или protected метод. Видимо, из-за такой идеологии языка, и появилась возможность реализовать методы именно так — в методах есть полный доступ ко всем членам и методам класса.
---
http://twitter.com/xoposhiy
http://xoposhiy.moikrug.ru
Re[5]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.11.04 10:54
Оценка: 28 (3) +1
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>Вот не надо, Сергей, только опять навязывать все вирт. языки как "единственно верные"...

К>>Скажи мне, где в Java, к примеру, есть модули?
К>>Или на каждый класс нужно в пр-во имён заворачивать? А потом указывать именно пр-во имён вместо класса?

СГ>Как одновременно: "1) Вот не надо, Сергей, только опять..." и "2) Скажи мне, где в Java..."? На второй пункт я бы мог ответить, но первый пункт запрещает это сделать.

Прочитай ещё раз и убедись, что они нисколечки друг другу не противоречат.
Просто пиши, что ты говоришь только о виртовских языках, а остальное чушь, иначе нельзя твои реплики воспринимать иногда — бред получается, имхо
СГ>Вот если бы он не запрещал, то я бы ответил, что пространства имен — тупиковая ветвь в развитии языков программирования появившаяся из-за отсутсвия модульности. Куда ни ткни везде с модульностью — ни каких проблем, а с пространствами имен сплошные грабли. Вот и тут опять же такие грабли они подложили. Из-за namespace выходит нельзя делать методы обычными не связанными с типом процедурами...

Почему нельзя? Объясни!
Не надо заявлять о недостатках чего-то, если ты не можешь этого доказать
В жабе нельзя (как и в C#), потому что они "pure OOP", т.е. там свободных ф-ций не может быть вообще по определению. В C++ спокойно может, так что ты опять что-то придумал и выдаёшь за правду, не хорошо это...


К>>
СГ>/* 1-й элемент */
СГ>g(X, a, b, c);
СГ>/* последний элемент */
СГ>g(a, b, c, X);
СГ>

К>>так понятней?

СГ>Так понятней. А какая разница-то? Можно и так: g(a, X, b, Y, c, Z); — для трех объектов X, Y, Z...


Вопрос в том используешь ли ты ООП или нет, если нет — то ради бога, но тогда и не заикайся про него, плиз.
А если в соотв. с ООП, то у тебя:
1. есть объект
2. есть операции, применяемые к этому объекту
Соотв-но ты должен понимать к какому из объектов относится операция.

Другое дело, что такой подход есть несколько "узкая" часть ООП, с той т.зр., что иногда операция не определяется лишь 1 объектом, но мультиметоды — это тема для отдельного обсуждения (имхо, в реальной жизни они встречаются далеко не так часто, хотя это зависит от т.зр. естественно)

З.Ы. ты путаешь "модульность" виртовскую с ООП и поэтому у тебя получается одно на другое налезает, но это очень пересекающиеся идеи, поэтому вместе их рассматривать не очень корректно.
Re[6]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 11:08
Оценка:
Здравствуйте, Курилка, Вы писали:

СГ>> ... Из-за namespace выходит нельзя делать методы обычными не связанными с типом процедурами...


К> Почему нельзя? Объясни!


Ах все-таки можно, тогда о чем разговор? Можно ведь.


К> З.Ы. ты путаешь "модульность" виртовскую с ООП и поэтому у тебя получается одно на другое налезает, но это очень пересекающиеся идеи, поэтому вместе их рассматривать не очень корректно.


То-то и оно. Объединение "ООП + МОДУЛЬНОСТЬ" не может оставить само ООП в своем прежнем виде. Многие вещи в нем становятся излишними. Так например, те же самые невиртуальные методы — зачем они нужны если они заменяются простыми процедурами? Не нужны они и все тут. Метод от того и метод что он связан с типом, а значит может быть переопределен при расширении типа, другими словами он всегда виртуален. А если не собираешься его переопределять, то есть не собираешься делать его виртуальным, так и используй для этого простые процедуры того же модуля в котором определен тип. Честно признаться, этот топик был затеян мной как ответ на вопрос Vlad2: "Почему в Oberon-2 все методы виртуальные?". А затем, что не виртуальные и так есть — это простые процедуры того же самого модуля в котором определен тип. В расширении языка Oberon-2 в Component Pascal создатели все-таки добавили в язык и не виртуальные методы тоже, видимо пошли на поводу у современной ООП моды...
Re[6]: Связанные с типом процедуры должны быть виртуальными
От: hrg Россия  
Дата: 10.11.04 11:08
Оценка:
XopoSHiy -> "Re[5]: Связанные с типом процедуры должны быть виртуальными"

X>>> Методы в Perl-e реализованны именно с помощью такой конструкции!

hrg>>"Не позволю с Вами согласится"(с) хз чей

hrg>>$grid->UpdateContents();

hrg>>без всяких лишних телодвижений и лишних параметров.

X> Это синтаксические навороты языка. Фактически это эквивалентно

X> следующей записи:
X> GridsPackage::UpdateContents($grid);

Ну я как бы в теме

X> Ещё разик: В

X> перле методы реализованы именно как внешние функции. В
X> частности у
X> одного объекта можно вызывать совершенно не его методы.
X> Но всё это
X> обёрнуто в "удобную" синтаксическую конструкцию,
X> напоминающую вызов
X> метода в других языках.

X> Собственно там даже метод класса (статический в

X> терминах С++) не
X> отличается от обычных методов: если первым параметром
X> пришёл объект,
X> то метод обычный, если первым параметром пришёл пакет -
X> то это метод
X> класса.

Может и ничего не приходить первым параметром. Если вызов Package::method.
Ну это так, к слову

X> К слову, Перл позиционируется как язык не

X> скрывающий от программиста
X> ничего! Там крайне сложно (если вообще
X> возможно) создать private или
X> protected метод. Видимо, из-за такой

Можно. Причем сделать проверку этого как в рунтайме, так и на этапе
компиляции.

X> идеологии языка, и появилась

X> возможность реализовать методы именно так
X> — в методах есть полный
X> доступ ко всем членам и методам класса.


Все успешно реализуется и раграничивается при желании. Если оно есть

Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева
Posted via RSDN NNTP Server 1.9 gamma
Re[7]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.11.04 11:18
Оценка: 2 (2)
Здравствуйте, Сергей Губанов, Вы писали:

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


СГ>>> ... Из-за namespace выходит нельзя делать методы обычными не связанными с типом процедурами...


К>> Почему нельзя? Объясни!


СГ>Ах все-таки можно, тогда о чем разговор? Можно ведь.

Вот и я говорю — всё нормально, а ты где-то грабли нашёл, а теперь сам говоришь: "так нет же их", ты ужасно последователен


К>> З.Ы. ты путаешь "модульность" виртовскую с ООП и поэтому у тебя получается одно на другое налезает, но это очень пересекающиеся идеи, поэтому вместе их рассматривать не очень корректно.


СГ>То-то и оно. Объединение "ООП + МОДУЛЬНОСТЬ" не может оставить само ООП в своем прежнем виде. Многие вещи в нем становятся излишними. Так например, те же самые невиртуальные методы — зачем они нужны если они заменяются простыми процедурами? Не нужны они и все тут. Метод от того и метод что он связан с типом, а значит может быть переопределен при расширении типа, другими словами он всегда виртуален. А если не собираешься его переопределять, то есть не собираешься делать его виртуальным, так и используй для этого простые процедуры того же модуля в котором определен тип. Честно признаться, этот топик был затеян мной как ответ на вопрос Vlad2: "Почему в Oberon-2 все методы виртуальные?". А затем, что не виртуальные и так есть — это простые процедуры того же самого модуля в котором определен тип. В расширении языка Oberon-2 в Component Pascal создатели все-таки добавили в язык и не виртуальные методы тоже, видимо пошли на поводу у современной ООП моды...


Имхо это не мода, а нормальное человеческое понимание предметной области, про модули ты так и не объяснил — на кой оно надо и что это такое? Вот с объектами гораздо понятней:
есть объект и он есть чёрный ящик, есть только "ручки, за которые его тыркать можно", т.е. его операции.
А вот модуль — есть очень искусственная конструкция, имхо, не чем не обоснованно введённая в язык, не более того...
И эта "искусственность" портит всю картину, вылезая из всех щелей...
Re[3]: Связанные с типом процедуры должны быть виртуальными
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 10.11.04 11:22
Оценка: 18 (3) +4
Здравствуйте, Сергей Губанов, Вы писали:

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


MN>>...любой новый метод, будет реализовываться через уже имеющиейся методы, и это нарушит данный принцип. Именно такие "методы" Мейерс и предлагает делать внешними. Чувствуете разницу между этими словами и вашим предложением?


СГ>Да, чувствую. Слово интерфейс — широко в своем значении. У того что обозначается interface в Delphi, C#, Java — у него все методы "виртуальные". Не виртуальных методов в таком интерфейсе нет. Вот и Вы тоже почувствуйте разницу.


Слушайте, давайте говорить по существу или хотя бы внимательно читать сообщения. Я ни где ни разу не обмолвился о ключевом слове interface или виртуальной функции. Публичный интерфейс класса — это список его публичных методов, если вы не знали, а уж виртуальные они или нет — это дело уже десятое. Интерфейсом вообще называют всё, с помощью чего происходит общение двух субъектов или один субъект использует возможности другого. Я не поднимал дискуссии насчёт понятий интерфейсов в ООП и поднимать больше не хочу — мы с вами уже не раз диспутировали по этому вопросу и в своё время я сказал всё, что хотел, если не помните, воспользуйтесь поиском.
Если уж на то пошло то ваше обобщение вообще не корректно, потому что всё что предложено Мейрсом в части реализации его идей касается впервую очередь языка C++. Сама теория минимальности и полноты интерфесов, а также доказательство того, что дополнительные методы уменьшают инкапсуляцию расширима на многие языки, но приведённый им и процитированный вами алгоритм касается исключительно языка C++.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re: Связанные с типом процедуры должны быть виртуальными
От: 0xDEADBEEF Ниоткуда  
Дата: 10.11.04 11:22
Оценка: 20 (1)
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Короче, если метод не виртуальный, то зачем он метод? Пусть он будет не методом, а внешней процедурой. А все оставшиеся методы — все поголовно виртуальны.

Кстати, не ты первый об этом задумался...
— У Александреску в "MC++D" (7.4 Smart Pointer Member Functions) есть следующий абзац:

For reasons of clarity, SmartPtr does not have any named member functions. The only functions that access the pointee object are GetImpl, GetImplRef, Reset, and Release, which are defined at the namespace level.

— В boost наблюдается похожая тенденция: функции-экстракторы из различных контейнеров (boost::any,boost::variant,boost:shared_ptr) реализованы как не-члены.

Александреску свое решение мотивирует тем, что smart pointer служит заменой обычному пойнтеру, а у обычного пойнтера функций-членов нету. Чем мотивируется решения в Бусте — не знаю, но подозреваю что они прислушались к Александреску.
__________
16.There is no cause so right that one cannot find a fool following it.
Re[2]: Связанные с типом процедуры должны быть виртуальными
От: Зверёк Харьковский  
Дата: 10.11.04 11:37
Оценка:
Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>- В boost наблюдается похожая тенденция: функции-экстракторы из различных контейнеров (boost::any,boost::variant,boost:shared_ptr) реализованы как не-члены.


DEA>Чем мотивируется решения в Бусте — не знаю, но подозреваю что они прислушались к Александреску.

Тем, что по-другому невозможно. У функции-члена нельзя явно прописывать инстанциацию (тьфу, о чем я? короче, в терминах запутался, вот пример: )
any.get<int>(); //так низзя
get<int>(any); //а так - мона.

Если только я ничего не путаю
сам слушаю и вам рекомендую: Guano Apes — Money & Milk
FAQ — це мiй ай-кью!
Re[2]: Связанные с типом процедуры должны быть виртуальными
От: Кодт Россия  
Дата: 10.11.04 11:54
Оценка:
Здравствуйте, XopoSHiy, Вы писали:

XSH>Просто так рубить с плеча — нехорошо... Вот Мейерс более аккуратен, хотя я бы и с ним поспорил, была бы возможность


Мейерс, очевидно, смотрит на язык С++, а не на "языки вообще". Это существенно, поскольку именно в С++ широко распространена практика перегрузки, в том числе операторов.

Если, к примеру, мы реализуем операцию вывода в поток (оператор <<) без перегрузки — то мы должны
* или родить новое имя Print_XXX(var strm:TextStream, const data:XXX) — неважно, в глобальном пространстве имён или в подпространстве — XXX_tools.Print
* или добавить новый метод в уже готовый класс TextStream (что, как правило, невозможно)
* или добавить метод в класс XXX (что тоже не всегда возможно) и получить "страдательный залог" — data.BePrintedWith(strm)

Что же касается friend'ов и т.п.

Внешняя функция, разумеется, обращается к членам аргументов. Можно сократить это общение до вызова методов (особенно — полиморфных), и более того, можно превратить эту функцию в диспетчера, вызывающего нужный метод одного из аргументов — в действительном или страдательном залоге, как повезёт
Роль функции-диспетчера двояка:
1) придаёт вызову метода удобный вид (читаемый, осмысленный, согласованный с перегрузкой этого имени)
2) абстрагирует реализацию, задействуя runtime- или compiletime-полиморфизм если он есть, даёт больше возможностей для модификации программы.

Однако, если функция проектируется одновременно с классом, метод которого будет вызван из неё, то встаёт вопрос:
а кому ещё нужен этот метод?
Если больше никому (пресловутый страдательный залог), то есть смысл сделать его приватным, а функцию — другом.
Впрочем, это дело вкуса.
Перекуём баги на фичи!
Re[4]: Связанные с типом процедуры должны быть виртуальными
От: Кодт Россия  
Дата: 10.11.04 11:57
Оценка: 9 (2) :)))
Здравствуйте, XopoSHiy, Вы писали:

СГ>>А в других многих языках инкапсуляция осуществляется на уровне модуля. Все описанное внутри одного модуля "дружит" друг с другом.


XSH>Много бы я отдал, чтобы этого не было в Delphi. Все ноги переломаешь, пока разберёшься в таком "дружественном" коде...

XSH>Frien-ы — вообще ненужная вещь

А вот неправда. Дельфи навязывает дружбу. И получается не дружба, а коммуналка.
В С++ приходится заявлять — этот и этот мне друзья, со всей ответственностью. Просто не дружите с кем попало, и будет вам щастье.
Перекуём баги на фичи!
Re[8]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 12:22
Оценка:
Здравствуйте, Курилка, Вы писали:

К>А вот модуль — есть очень искусственная конструкция, имхо, не чем не обоснованно введённая в язык, не более того...


Единица исполнения — структурная динамически загружаемая единица системы, единица расширения системы, единица компиляции, единица инкапсуляции, единица хранения кода, и много чего еще единица — и все это искусственная конструкция? Как же так?
Re[9]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.11.04 12:25
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>А вот модуль — есть очень искусственная конструкция, имхо, не чем не обоснованно введённая в язык, не более того...


СГ>Единица исполнения — структурная динамически загружаемая единица системы, единица расширения системы, единица компиляции, единица инкапсуляции, единица хранения кода, и много чего еще единица — и все это искусственная конструкция? Как же так?


Вот так — искусственная, про то, что единица кода есть лишь только текстовый файл тебе писали не 1 раз, про остальное тоже. Никаких членораздельных аргументов я так и не услышал
Re[2]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 12:29
Оценка:
Здравствуйте, 0xDEADBEEF, Вы писали:

СГ>> Короче, если метод не виртуальный, то зачем он метод? Пусть он будет не методом, а внешней процедурой. А все оставшиеся методы — все поголовно виртуальны.


DEA> Кстати, не ты первый об этом задумался...


Знаю что не я первый об этом задумался. Например, в языке Oberon-2 все методы виртуальные потому, что не виртуальные и так есть — это простые процедуры того же самого модуля в котором определен тип.

http://www.rsdn.ru/Forum/Message.aspx?mid=892123&amp;only=1
Автор: Сергей Губанов
Дата: 10.11.04
Re[10]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 12:50
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Вот так — искусственная, про то, что единица кода есть лишь только текстовый файл тебе писали не 1 раз, про остальное тоже. Никаких членораздельных аргументов я так и не услышал


Вот членораздельный аргумент:

В модульной системе количество динамически загружаемых модулей в точности равно количеству текстовых файлов с исходным кодом. Если есть 500 файлов исходников, значит есть 500 динамически загружаемых модулей, каждый из которых, в принципе, может быть от разного производителя.

Внес изменение в 1 текстовый файл, скомпилировал его в 1 маленький исполнимый файл, заменил старый исполнимый файл на этот новый во всех уже проданных по всему миру системах и спишь спокойно. А можно заменить его не на один, а, например, на три новых модуля.

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

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


Еще вдобавок: Понадобилось добавить в систему новую функциональность — это элементарно, создаешь несколько дополнительных модулей расширяющих данную систему и рассылаешь их всем заинтересованным в расширении своей системы потребителям. Причем разных расширений модульной системы может быть очень и очень много. Третьи фирмы могут штамповать эти расширения на ура! А если бы был только 1 гигантский исполнимый файл, то Вы бы запутались в экспоненциально большом количестве всевозможных версий этй монолитной программы, а третьи фирмы вообще ничего не могли бы делать, так как у них нет исходного кода (в случае модульных систем третьим фирмам исходные коды не нужны, им нужно знать только интерфейсы модулей).
Re[5]: Связанные с типом процедуры должны быть виртуальными
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.11.04 13:01
Оценка: +1
Здравствуйте, Кодт, Вы писали:

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


СГ>>>А в других многих языках инкапсуляция осуществляется на уровне модуля. Все описанное внутри одного модуля "дружит" друг с другом.


XSH>>Много бы я отдал, чтобы этого не было в Delphi. Все ноги переломаешь, пока разберёшься в таком "дружественном" коде...

XSH>>Frien-ы — вообще ненужная вещь

К>А вот неправда. Дельфи навязывает дружбу. И получается не дружба, а коммуналка.

К>В С++ приходится заявлять — этот и этот мне друзья, со всей ответственностью. Просто не дружите с кем попало, и будет вам щастье.
Интересно, а почену в Net отказались от столь эффективных друзей в пользу ассембли и комбинации её с protected ????
... << RSDN@Home 1.1.3 stable >>
и солнце б утром не вставало, когда бы не было меня
Re[11]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.11.04 13:30
Оценка: 1 (1) +1
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>Вот так — искусственная, про то, что единица кода есть лишь только текстовый файл тебе писали не 1 раз, про остальное тоже. Никаких членораздельных аргументов я так и не услышал


СГ>Вот членораздельный аргумент:


[поскипано, ибо больно дохрена]

Сергей, всё равно это есть искусственное деление, сколько ты не говори, модульность и ООП — вещи ортогональные должны быть, т.е. с т.зр. "невиртовских" языков есть процедуры, классы и проч. с 1 стороны, которые могут быть далеко не в 1 файле, а с др. стороны есь DLL, SO или любой другой "модуль", ну и соотв-но описывается программером, что же запихивать туда. И, соотв-но в этой схеме нет никаких особых противоречий с ООП — всё довольно стройно. И нет гигантских эгзешников ибо уже давным давно найдены механизмы (причём множество) создания модульных программ. И даже в C (без плюсов) можно этой модульности добиться, возможно с заморочками, но далеко не такими страшными...
Т.е. вынесение "модуля" на уровень языка я считаю плохой идеей ибо с т.зр. предметной области это совсем уж искусственное понятие и имеет лишь отношение к распространению бинарников, не более того...
Re: Связанные с типом процедуры должны быть виртуальными
От: Kluev  
Дата: 10.11.04 13:37
Оценка: 31 (4)
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Вопрос: а зачем так сложно? Давайте проще:


СГ>Все связанные с типом процедуры — виртуальны, а если нужны не виртуальные, а обычные, то для этого есть обычные процедуры не связываемые с типом.


СГ>Короче, если метод не виртуальный, то зачем он метод? Пусть он будет не методом, а внешней процедурой. А все оставшиеся методы — все поголовно виртуальны.


Больная идея.
Например возьмем такой полезный класс string, который юзается повсеместно и должен быть удобным.
В нем есть методы:


// метод 1
// присваивает строку str длинной size
// допустим он виртуальный
void string::assign( const char *str, uint size ); 

// метод 2
// это для удобства вызывает метод 1
void string::assign( const char *str )
{
   assign( str, strlen(str) );
}

// метод 3
// тоже для удобства
void string::assign( const char *begin, const char *end )
{
   assign( begin,end-begin );
}


Вот и спрашивается зачем метод 2 и 3 должны быть виртуальными? Более того такие методы делают инлайнами и они фактически раскрываются в метод 1. Получается что следуя логике (все виртуальное) я должен писать либо всегда:

void test( const char *s1, const char *s2_beg, const char *s2_end )
{
  string s;
  s.assign( "zzzzz", strlen("zzzzz") ); // бррр
  s.assign( s1, strlen(s1) );
  s.assign( s2_beg, s2_end - s2_beg );
}

либо:

void test( const char *s1, const char *s2_beg, const char *s2_end )
{
  string s;
  string_assign(s,"zzzzzz"); // перегруженные процедуры хелперы
  string_assign(s,s1);
  string_assign(s,s2_beg,s2_end);
}

и зачем этот гемор когда можно написать просто:
void test( const char *s1, const char *s2_beg, const char *s2_end )
{
  string s;
  s.assign( "zzzzz" );
  s.assign( s1 );
  s.assign( s2_beg, s2_end );
}
Re[2]: Связанные с типом процедуры должны быть виртуальными
От: AndreyFedotov Россия  
Дата: 10.11.04 13:46
Оценка:
Вот и я об этом певцу оберона говорю...
Пример со строкой, кстати — очень хороший.
Re[4]: Связанные с типом процедуры должны быть виртуальными
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 10.11.04 14:27
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Скажи мне, где в Java, к примеру, есть модули?


Прошу прощения, по-моему, package'ы в Java выполняют именно функцию модулей.
Разве нет?
Re[2]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 14:36
Оценка: :)
Здравствуйте, Kluev, Вы писали:

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


1) Зачем строке иметь виртуальный метод? Тип строки описывается один раз и навсегда, зачем его потом расширять?

2) А строки, вообще-то, нехорошо в качестве примера приводить, так как работа со строками обычно встроена в сам язык программирования... Давайте лучше вместо строк рассмотрим тип целых чисел произвольного размера. У них тоже нет ни одного виртуального метода — зачем он им?

DEFINITION Integers;

    IMPORT Files;

    TYPE
        Integer = POINTER TO IntegerDesc;

    PROCEDURE Abs (x: Integer): Integer;
    PROCEDURE Compare (x, y: Integer): INTEGER;
    PROCEDURE ConvertFromString (IN s: ARRAY OF CHAR; OUT x: Integer);
    PROCEDURE ConvertToString (x: Integer; OUT s: ARRAY OF CHAR);
    PROCEDURE Difference (x, y: Integer): Integer;
    PROCEDURE Digits10Of (x: Integer): INTEGER;
    PROCEDURE Entier (x: REAL): Integer;
    PROCEDURE Externalize (w: Files.Writer; x: Integer);
    PROCEDURE Float (x: Integer): REAL;
    PROCEDURE GCD (x, y: Integer): Integer;
    PROCEDURE Internalize (r: Files.Reader; OUT x: Integer);
    PROCEDURE Long (x: LONGINT): Integer;
    PROCEDURE Power (x: Integer; exp: INTEGER): Integer;
    PROCEDURE Product (x, y: Integer): Integer;
    PROCEDURE QuoRem (x, y: Integer; OUT quo, rem: Integer);
    PROCEDURE Quotient (x, y: Integer): Integer;
    PROCEDURE Remainder (x, y: Integer): Integer;
    PROCEDURE Short (x: Integer): LONGINT;
    PROCEDURE Sign (x: Integer): INTEGER;
    PROCEDURE Sum (x, y: Integer): Integer;
    PROCEDURE ThisDigit10 (x: Integer; exp10: INTEGER): CHAR;

END Integers.




IMPORT StdLog, Integers;

VAR n: Integers.Integer; s: POINTER TO ARRAY OF CHAR;
BEGIN
  n := Integers.Power( Integers.Long(123456789),  2323232);  (* n = 123456789 ^ 2323232 *)
  NEW(s, Integers.Digits10Of(n) + 1);
  Integers.ConvertToString(n, s);
  StdLog.String("123456789 в степени 2323232 = "); StdLog.String(s);
Re[3]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.11.04 14:40
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


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


СГ>1) Зачем строке иметь виртуальный метод? Тип строки описывается один раз и навсегда, зачем его потом расширять?


СГ>2) А строки, вообще-то, нехорошо в качестве примера приводить, так как работа со строками обычно встроена в сам язык программирования... Давайте лучше вместо строк рассмотрим тип целых чисел произвольного размера. У них тоже нет ни одного виртуального метода — зачем он им?


[поскипано]

Сергей ты намеренно приводишь не корректные примеры? Ты знаешь разницу между "примитивными" типами (они же value-типы) и классами "обычными?
Если да (на что я очень надеюсь), то посмотри в исходное сообщение своё — что там объектом было? Класс или целые числи или что-либо подобное?
Re[4]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 14:52
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Сергей ты намеренно приводишь не корректные примеры? Ты знаешь разницу между "примитивными" типами (они же value-типы) и классами "обычными?

К>Если да (на что я очень надеюсь), то посмотри в исходное сообщение своё — что там объектом было? Класс или целые числи или что-либо подобное?

Смотрим внимательно:
DEFINITION Integers;

    IMPORT Files;

    TYPE
        Integer = POINTER TO IntegerDesc;
    ...

Есть какой-то скрытый (инкапсулированный, приватный) тип под названием IntegerDesc и есть (публичный) экспортируемый тип Integer, который нужен для работы с целыми числами ПРОИЗВОЛЬНО БОЛЬШОГО размера. Это не примитивный тип. Тем не менее, у этого типа нет ни одного метода. Есть только "внешние" простые процедуры. Например,
PROCEDURE GCD (x, y: Integer): Integer;


Чего такого некорректного-то по сравнению со строками предложенными Клюевым?
Re[3]: Связанные с типом процедуры должны быть виртуальными
От: Kluev  
Дата: 10.11.04 14:53
Оценка: 6 (1)
Здравствуйте, Сергей Губанов, Вы писали:

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


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


СГ>1) Зачем строке иметь виртуальный метод? Тип строки описывается один раз и навсегда, зачем его потом расширять?


Хорошо перейдем от абстрактных примеров к реальным. Вот к примеру интерфейс IBinaryStream

struct IBinaryStream
{
    virtual uint    read( void *buf, uint size )            = 0;
    virtual void    write( const void *buf, uint size )    = 0;

public: // хелперы
    template <class T> inline void 
        get( T value )
    {
        read( &value, sizeof(T) );
    }

    template <class T> inline void
        get( T ary[], uint n )
    {
        read( ary, sizeof(T) * n );
    }

    template <class T> inline void 
        put( const T value )
    {
        write( &value, sizeof(T) );
    }

    template <class T> inline void
        put( T ary[], uint n )
    {
        write( ary, sizeof(T) * n );
    }

};

void usaem_strim( IBinaryStream &stm, int a, double b, int c[], uint c_size )
{
    stm.get( a );
    stm.get( b );
    stm.put( c, c_size );
    stm.put( 10UL );
    // удобно однако!
}

// теперь в твоем стиле через процедуры:
void usaem_strim( IBinaryStream &stm, int a, double b, int c[], uint c_size )
{
    IBinaryStream_get( stm, a );
    IBinaryStream_get( stm, b );
    IBinaryStream_put( stm, c, c_size );
    IBinaryStream_put( stm, 10UL );
    // и к чему нам этот геморой на ровном месте?
}
Re[5]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.11.04 14:56
Оценка:
Здравствуйте, Alxndr, Вы писали:

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


К>>Скажи мне, где в Java, к примеру, есть модули?


A>Прошу прощения, по-моему, package'ы в Java выполняют именно функцию модулей.

A>Разве нет?

Модуль модулю рознь
Обероновским модулем не является (может быть Сергей меня поправит, если я вру...)
Re[6]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 15:07
Оценка:
Здравствуйте, Курилка, Вы писали:

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


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


К>>>Скажи мне, где в Java, к примеру, есть модули?


A>>Прошу прощения, по-моему, package'ы в Java выполняют именно функцию модулей.

A>>Разве нет?

К>Модуль модулю рознь

К>Обероновским модулем не является (может быть Сергей меня поправит, если я вру...)

Да я в Java не так сильно разбираюсь... Но на сколько я понимаю, единицей исполнения, единицей расширения системы и единицей компиляции в Java кажется является файл с классом, а не пакет. Если так, то значит пакет — не модуль.
Re[4]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 15:16
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Хорошо перейдем от абстрактных примеров к реальным. Вот к примеру интерфейс IBinaryStream

...
K> // и к чему нам этот геморой на ровном месте?

Я конечно понимаю, что писанины получается больше. Вместо кода:
  stm.ReadInteger(a);

надо писать код:
  Streams.ReadInteger(stm, a);

однако никакого гемороя, признаться, в этом не вижу. Ну и что такого-то, что чуток (на 1 слово — "Streams.") побольше написать? По существу замечания будут или нет?
Re[12]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 15:20
Оценка:
Здравствуйте, Курилка, Вы писали:

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


А вот, интересно, с точки зрения предметной области такие термины как class, private, protected, property get/set, случайно не являются искусственными понятиями?
Re[5]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.11.04 15:20
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>Сергей ты намеренно приводишь не корректные примеры? Ты знаешь разницу между "примитивными" типами (они же value-типы) и классами "обычными?

К>>Если да (на что я очень надеюсь), то посмотри в исходное сообщение своё — что там объектом было? Класс или целые числи или что-либо подобное?

СГ>Смотрим внимательно:

СГ>
СГ>DEFINITION Integers;

СГ>    IMPORT Files;

СГ>    TYPE
СГ>        Integer = POINTER TO IntegerDesc;
СГ>    ...
СГ>

СГ>Есть какой-то скрытый (инкапсулированный, приватный) тип под названием IntegerDesc и есть (публичный) экспортируемый тип Integer, который нужен для работы с целыми числами ПРОИЗВОЛЬНО БОЛЬШОГО размера. Это не примитивный тип. Тем не менее, у этого типа нет ни одного метода. Есть только "внешние" простые процедуры. Например,
СГ>
СГ>PROCEDURE GCD (x, y: Integer): Integer;
СГ>


СГ>Чего такого некорректного-то по сравнению со строками предложенными Клюевым?


Вопрос — что есть тут Integer? Примитивный тип, аля Int32? Или же имя класса? Как они будут соотноситься и т.п.?
Имхо некорректный пример с недостаточными комментариями...
Re[13]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.11.04 15:31
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


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


СГ>А вот, интересно, с точки зрения предметной области такие термины как class, private, protected, property get/set, случайно не являются искусственными понятиями?


Имхо нет, ес-но в сфере рассмотрения предметной области сквозь призму ООП (которая гораздо ближе к человеческим понятиям, чем какой-то абстрактный "модуль")
Re[6]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.11.04 15:42
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Вопрос — что есть тут Integer? Примитивный тип, аля Int32? Или же имя класса? Как они будут соотноситься и т.п.?


Примитивный целочисленный тип пишется заглавными буквами INTEGER, а класс представляющий целые числа произвольно большого размера обозначени идентификатором Integer (первая буква заглавная, остальные маленькие)
DEFINITION Integers;

    IMPORT Files;

    TYPE
        Integer = POINTER TO IntegerDesc;
    ...

Класс IntegerDesc — не экспортируется модулем Integers, и поэтому в его интерфейсе не показан. На самом деле, если раздобыть исходник модуля Integers (у меня нет исходника), то в нем можно будет увидеть предположительно следующую реализацию класса IntegerDesc:
TYPE
  IntegerDesc = LIMITED RECORD
    (* поля данных представляющие целое число неограниченного размера *)
  END;
Re[7]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.11.04 15:48
Оценка: 2 (2) +1
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>Вопрос — что есть тут Integer? Примитивный тип, аля Int32? Или же имя класса? Как они будут соотноситься и т.п.?


СГ>Примитивный целочисленный тип пишется заглавными буквами INTEGER, а класс представляющий целые числа произвольно большого размера обозначени идентификатором Integer (первая буква заглавная, остальные маленькие)


Вот ещё один супераргумент в пользу Вирта
Ты не думаешь, что если к каждой программе нужно писать далеко не 1 абзац комментариев, то это не есть хорошо? Просто есть некоторые вещи, которые уже особенно сильно не обсуждаются, ибо все принимают их "по дефолту", так вот встроенные типы БОЛЬШИМИ буквами писать имхо — маразм
Re[5]: Связанные с типом процедуры должны быть виртуальными
От: Зверёк Харьковский  
Дата: 10.11.04 15:49
Оценка: 1 (1) +3
Здравствуйте, Сергей Губанов, Вы писали:

СГ>однако никакого гемороя, признаться, в этом не вижу. Ну и что такого-то, что чуток (на 1 слово — "Streams.") побольше написать? По существу замечания будут или нет?

Это запросто! Недостаток твоего подхода — надо лишнее слово написать.
А преимущество? Ну хоть одно? Ну маааааалюююююююсенькое....
сам слушаю и вам рекомендую: в тишине сижу
FAQ — це мiй ай-кью!
Re[3]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.11.04 15:51
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

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


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


СГ>1) Зачем строке иметь виртуальный метод? Тип строки описывается один раз и навсегда, зачем его потом расширять?


СГ>2) А строки, вообще-то, нехорошо в качестве примера приводить, так как работа со строками обычно встроена в сам язык программирования... Давайте лучше вместо строк рассмотрим тип целых чисел произвольного размера. У них тоже нет ни одного виртуального метода — зачем он им?


СГ>
//поскипано к чертям
СГ>


Пример у тебя не корректный ибо часть процедур не есть операции собственно класса "целое", а некоторые я бы в нём оставил (e.g. ConvertToString, только я бы убрал первый параметр, ибо он смысла не несёт, если мы операцию к известному объекту применяем)
Re[5]: Связанные с типом процедуры должны быть виртуальными
От: Kluev  
Дата: 10.11.04 15:51
Оценка: 16 (2)
Здравствуйте, Сергей Губанов, Вы писали:

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


K>>Хорошо перейдем от абстрактных примеров к реальным. Вот к примеру интерфейс IBinaryStream

СГ>...
K>> // и к чему нам этот геморой на ровном месте?

СГ>Я конечно понимаю, что писанины получается больше. Вместо кода:

СГ>
СГ>  stm.ReadInteger(a);
СГ>

СГ>надо писать код:
СГ>
СГ>  Streams.ReadInteger(stm, a);
СГ>

СГ>однако никакого гемороя, признаться, в этом не вижу. Ну и что такого-то, что чуток (на 1 слово — "Streams.") побольше написать? По существу замечания будут или нет?

Ага всего на одно слово больше.... почти в каждой строчке кода.
К тому же такой подход нарушает инкапуляцию. С какой это стати buffer_read находится в классе, а int_read уже глобальная процедура в модуле? Ничего кроме путаницы это не даст.

ИМХО это просто примитивизм, ктоторый пытаются протолкнуть как простоту. Если уж так хочется отличать виртуальную функцию от невиртуалной в классах то надо делать так, как я всегда делаю:

struct IBinaryStream
{
protected: // зашишенная виртуальная функция (только для наследования)
   virtual void IBinaryStream$read( void *buf, uint size ) = 0;

public: // хелпер для вызова
   void read( void *buf, uint size ) { IBinaryStream$read(buf,size); }
};

// В классе наследнике от IBinaryStream
class MyClass : public IBinaryStream
{
protected:
// видно что функция переопределена и видно из какого класса ноги растут:
  void IBinaryStream$read( void *buf, uint size ); 

};

// Даже если наследование углубилось и не видно что класс занаследован от IBinaryStream:
class AnotherClass : public MyClass
{
protected:
// все равно видно что функция переопределана и видно из какого класса.
  void IBinaryStream$read( void *buf, uint size ); 

  void MyClass$foo(); // здесь тоже все понятно без слов.
};

// А юзается это дело через хелпер:
void test( AnotherClass &ac )
{
   int x;
   ac.read( &x, sizeof(x) ); // транслируется в IBinaryStream$read
}


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

А то что предлагается в обероне так это просто курам на смех. Оберону надо всю кровь сменить и все органы пересадить (начиная с БЕГИН,ЭНД,ПРОЦЕ-ДУРА), тогда глядишь на него и будут смотреть программеры. А так его имхо юзают люди которые не смогли с паскаля слезть, как говориться старую собаку не обучишь новым штукам.
Re[6]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 10.11.04 16:16
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

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


СГ>>однако никакого гемороя, признаться, в этом не вижу. Ну и что такого-то, что чуток (на 1 слово — "Streams.") побольше написать? По существу замечания будут или нет?

ЗХ>Это запросто! Недостаток твоего подхода — надо лишнее слово написать.
ЗХ>А преимущество? Ну хоть одно? Ну маааааалюююююююсенькое....

Ну и ещё я бы добавил, что "обычный вариант стройнее, т.к. там выделяется что мы именно в стрим пишем, хотя это не такой уж и хороший пример (в отл., например, от операций с геом. фигурами и т.п.)
Re[13]: Связанные с типом процедуры должны быть виртуальными
От: mister-AK Россия  
Дата: 10.11.04 16:28
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


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


СГ>А вот, интересно, с точки зрения предметной области такие термины как class, private, protected, property get/set, случайно не являются искусственными понятиями?


служебное слово class — да искуственное, теримин — нет, потому что можно подразумевать и другие списковые, как запись или интерфейс или даже метод


type
  A = class (TObject)
  // здесь содержатся поля типа
  end;

  B = class (A)
  // здесь содержатся поля типа
  end;


вполне можно бы записать на придуманном языке и так:


type

object is // так можно сказать, что списковый тип декларируем, т.е. задаём
// здесь содержатся поля типа
end;

A is object
// здесь содержатся поля типа
end;

B is A
// здесь содержатся поля типа
end;

Re[5]: Связанные с типом процедуры должны быть виртуальными
От: Silver_s Ниоткуда  
Дата: 10.11.04 18:56
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>.... Куда ни ткни везде с модульностью — ни каких проблем, а с пространствами имен сплошные грабли. Вот и тут опять же такие грабли они подложили. Из-за namespace выходит нельзя делать методы обычными не связанными с типом процедурами...



А в чем проблема то непонятно все же есть например в том же C#
Я согласен что функции-члены иногда нарушают инкапсуляцию. Особенно если они крупные и сложные.
Ну дык для этго эти функции нужно вынести в другой класс, и сделать их статическими, да еще и конструктор этого класса закрыть и получится
ИМХО, совершенно нормальное яление если есть класс только с одной функцией (статической), если у этой функции больше 100 строк да еще и если ее удобно разбить на вспомогательные функции, тогда конечно нужно выносить, еще и закрыть можно вспомогательные функции.

Классы в C# это те же модули о которых ты говоришь, тоько возможностей побольше.
Re[3]: Связанные с типом процедуры должны быть виртуальными
От: Шахтер Интернет  
Дата: 10.11.04 20:30
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Здравствуйте, 0xDEADBEEF, Вы писали:


DEA>>- В boost наблюдается похожая тенденция: функции-экстракторы из различных контейнеров (boost::any,boost::variant,boost:shared_ptr) реализованы как не-члены.


DEA>>Чем мотивируется решения в Бусте — не знаю, но подозреваю что они прислушались к Александреску.

ЗХ>Тем, что по-другому невозможно. У функции-члена нельзя явно прописывать инстанциацию (тьфу, о чем я? короче, в терминах запутался, вот пример: )
ЗХ>
ЗХ>any.get<int>(); //так низзя
ЗХ>get<int>(any); //а так - мона.
ЗХ>

ЗХ>Если только я ничего не путаю

Путаешь -- можно, использую в некоторых случаях ключевое слово template.

any. template get <int>();
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[11]: Связанные с типом процедуры должны быть виртуальными
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 11.11.04 05:42
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


СГ>Вот членораздельный аргумент:


СГ>Если есть 500 файлов исходников, значит есть 500 динамически загружаемых модулей...


И плюём на производительность — не наша это проблема, нехай юзверя покупают 2-ух процессорные системы на основе четвёртых пней, дабы загружать и динамически линковать всё это добро...

СГ>Внес изменение в 1 текстовый файл, скомпилировал его в 1 маленький исполнимый файл, заменил старый исполнимый файл на этот новый во всех уже проданных по всему миру системах и спишь спокойно. А можно заменить его не на один, а, например, на три новых модуля.


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

СГ>Вдобавок, некоторые системы могут использовать разные модули от различных производителей.


Угу, были такие эксперименты — нафиг нафиг. Сторонний производитель меняет что-нибудь в своём модуле, клиент ставит обновлённую версию и на следующий день заявляет вам — ваше приложение падает когда я кликаю мышкой и ищи потом почему оно падает (клиенты очень редко удосуживаются сообщать даже код ошибкм, не то что информацию об установленых модулях). В случае MS Windows это называется DLL Hell...

СГ>Еще вдобавок: Понадобилось добавить в систему новую функциональность — это элементарно, создаешь несколько дополнительных модулей расширяющих данную систему и рассылаешь их всем заинтересованным в расширении своей системы потребителям. Причем разных расширений модульной системы может быть очень и очень много. Третьи фирмы могут штамповать эти расширения на ура!


Только не забудьте наладить производтсво хрустальных шаров, чтобы ваша система могла с их помощью узнавать о новой незапланированной в ней функциональности...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[6]: Связанные с типом процедуры должны быть виртуальными
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 11.11.04 05:47
Оценка:
Здравствуйте, Serginio1, Вы писали:

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


К>>В С++ приходится заявлять — этот и этот мне друзья, со всей ответственностью. Просто не дружите с кем попало, и будет вам щастье.

S> Интересно, а почену в Net отказались от столь эффективных друзей в пользу ассембли и комбинации её с protected ????
Не знаю, почему они отказались от друзей, но имел я в гробу эту комбинацию ассемблей с protected... Это так чистое ИМХО и крик души, прошу на данное сообщение не отвечать — флеймить не буду...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[12]: Миф
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 06:52
Оценка: -4 :)
Здравствуйте, Mr. None, Вы писали:

MN> И плюём на производительность...

MN> Далее прогоняешь тучу тестов...
MN> Сторонний производитель меняет что-нибудь в своём модуле...
MN> Только не забудьте наладить производтсво хрустальных шаров...

Это всё мифы появившиеся в результате использования опасных языков программирования Си/Си++ и им подобным. Для таких языков даже невозможно написать компилятор, который мог бы предотвратить buffer overflow. Вот, совсем недавно, Владимир Лось, переписывая аудиокодек с C на Active Oberon в очередной раз столкунулся с порочностью языка Си:

С точки зрения Оберона, то, что творили операторы со структурами данных в сишной программе было маразмом и извратом. И если бы это только вело к эффективности!!! Переписанная мной процедура обратного Фурье-преобразования на порядок эффективнее оказалась сишного исходника.
....то, что было наворочено в сишнике, обероновский компилятор бы просто как ахинею не пропустил бы. И ещё раз на поверку оказалось, что таки да, там туфта была... Например по их алгоритму индекс ИНОГДА (“ну не всегда же!” :о) ) выходил за верхний предел. Знаете, как оне из этого трабла вышли? ГОСПОДА ДОБАВИЛИ ТРИ ДОПОЛНИТЕЛЬНЫХ ЭЛЕМЕНТА В МАССИВЕ С НУЛЕВЫМИ ЗНАЧЕНИЯМИ!!! Как вам такое “проектное решение”? Видимо у них рантайм-ероры начали сыпаться и они, вместо того, что бы пересмотреть алгоритм формирования индекса, просто добавили столько элементов (“какой максимальный индекс “получается по статистике”?” :о) ). А и правда – а нафига? — слушатель всё равно раз в пять секунд вкрапление “лишнего нулевого значения” в амплитуде сигнала не заметит при 48 тысячах выборок в секунду... :о)))

http://www.delphikingdom.com/asp/talktopic.asp?ID=285&amp;Order=0&amp;Count=10&amp;pNo=3

Использование безопасных (safety) языков программирования таких как языки Oberon family позволяет создавать надежные расширяемые модульные операционные системы (не пользующиеся виртуальными адресными пространствами, а работающие всего лишь с одним единственным адресным пространством, в результате чего производительность таких систем превосходит производительность Linux в десятки раз). Кстати, на счет юникса — там разработчики даже на виртуальные адресные пространства не шибко надеются, оказывается там делают специальные "щели" в адресном пространстве между ядром и программами — это на тот случай если вдруг случайно будет небольшой buffer overflow, то чтоб он данные у других программ не попортил.

Модульная расширяемая система от того и называется расширяемой, что добавление в нее нового модуля не может привести к поломке в уже установленных модулях. Добавление нового модуля не обязывает проводить полный integrity check. Если каждое добавление нового модуля обязывало бы проводить полную проверку целостности, то такая система не могла бы называться РАСШИРЯЕМОЙ просто по определению расширяемых систем.
Re[8]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 07:04
Оценка: :)
Здравствуйте, Курилка, Вы писали:

К> Просто есть некоторые вещи, которые уже особенно сильно не обсуждаются, ибо все принимают их "по дефолту", так вот встроенные типы БОЛЬШИМИ буквами писать имхо — маразм


По default еще со времен Модулы (70-тые годы) служебные слова пишутся заглавными буквами. Программистам не рекомендуется использовать в своих программах идентификаторы состоящие из заглавных букв, поскольку идентификаторы из заглавных букв зарезервированы на служебные слова, которые, быть может, могут быть добавлены в язык программирования. Так например, существует множество разных версий оберонов (включая версии с generic) чтобы программы были чуть-чуть более удобно переносить между такими версиями, надо просто избегать использование идентификаторов написанных заглавными буквами. Кроме того, существуют экспериментальные системы, в которых есть только простой текстовый редактор, а вот IDE с подсветкой синтаксиса пока нету, в случаях plain text служебные слова из заглавных букв сразуже видны, в результате чего в подсветке синтаксиса нет особо сильной нужды.
Re[13]: Миф
От: AndreyFedotov Россия  
Дата: 11.11.04 07:17
Оценка: +3
Миф? Н-да... Остапа занесло... Где вы доктор Фрейд?
Хороший профи сделает код на C/С++ как минимум столь же эффективным, а скорее всего — более эффективным, чем на обероне. Хотя бы потому, что при правильном алгоритме формирования индексов — проверки в RunTime не требуется, а в Обероне она всё-равно будет. Следовательно код на C/C++ окажется эффективнее. Кроме того, я просто не верю, что Оберон распознает нарушение границ массива на этапе компиляции. Это может быть просто не возможно именно в силу модульности системы.
Не возможно — и это математически было доказано ещё в 60-х проводить полные математические доказательства правильности хоть сколько-нибудь крупных программ. А именно это свойство ты и приписываешь оберону — хотя он им очевидно не обладает.
Мифом, причём доказанным и уже давно, является как раз утверждение о том, что компилятор может предотвратить ошибки в программе. Синтаксические — да, может. Смысловые — только в самых редких случаях.
Приведённый пример — ярчайшее доказательство несостоятельности оберона как практически используемого языка. Так как фактически ты только подтверждаешь этим примером, что кроме фанатов, которые, конечно, великолепно разбираются в обероне и умеют хорошо программировать — больше на обероне никто не пишет... Доберись до оберона ребята, которые писали твой C-код — они просто добавили бы в массив те же три элемента и париться не стали. А мы бы потом, следуя, кстати, именно твоей логике — возили бы оберон мордой об стол и насмехались бы над языком.
А вот зависимость целостности модульных систем от языка програмирования — это бред даже не сивой а блондинистой кобылы. Если — соблюдая внешнюю форму интерфейсов, я тем не менее наделаю в них смысловых ошибок — то ни одна модульная система — хоть на обероне 99th edition — этого не заметит и правильно работать не станет. Или ты и это станешь оспаривать?
Re[4]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 07:18
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Пример у тебя не корректный ибо часть процедур не есть операции собственно класса "целое", а некоторые я бы в нём оставил (e.g. ConvertToString, только я бы убрал первый параметр, ибо он смысла не несёт, если мы операцию к известному объекту применяем)


Можно попросить пальцем показать где некорректность:

MODULE TestTest;
IMPORT StdLog, Integers; 

PROCEDURE Test1*;
VAR n: Integers.Integer; s: POINTER TO ARRAY OF CHAR; 
BEGIN 
  n := Integers.Power( Integers.Long(123456789), 23); (* n = 123456789 ^ 23 *) 
  NEW(s, Integers.Digits10Of(n) + 1); Integers.ConvertToString(n, s); 
  StdLog.String("123456789 в степени 23 = " + s);
END Test1;

END TestTest.


Log:

123456789 в степени 23 = 1273047108741566448925177913751616696945898387964743103636779445049184442828420773403202324032930504017546460440185735271601405046465292219398244646351144254623692836888914694403194587869

Re[6]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 07:21
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Это запросто! Недостаток твоего подхода — надо лишнее слово написать.

ЗХ>А преимущество? Ну хоть одно? Ну маааааалюююююююсенькое....

Компилятор и runtime становится еще более простой ведь все связанные с типом процедуры виртуальны — все единообразно. Например. для встроенных систем чем проще, тем компактнее, тем лучше.
Re[9]: Связанные с типом процедуры должны быть виртуальными
От: AndreyFedotov Россия  
Дата: 11.11.04 07:23
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

Хорошие и правильные слова, устаревшие однако на 10-15 лет...
В наше время код для эксперементальных систем пишут под обычными, а уж следать подсветку ключевых слов ЛЮБОГО языка под Winux — дело ерундовое...
Re[14]: Миф
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 07:31
Оценка: :)
Здравствуйте, AndreyFedotov, Вы писали:

AF> Кроме того, я просто не верю, что Оберон распознает нарушение границ массива на этапе компиляции.


В общем случае, естественно, на этапе компиляции — нет. Это runtime проверка.

AF> Приведённый пример — ярчайшее доказательство несостоятельности оберона как практически используемого языка.


Значит если язык ОФИЦИАЛЬНО РАЗРЕШАЕТ buffer overflow, утечку памяти, повисшие указатели, неправильное приведение типов то он практически состоятельный, а если языке В ПРИНЦИПЕ НЕВОЗМОЖНЫ такие явления то этот язык практически не состоятельный, так да?

AF> Если — соблюдая внешнюю форму интерфейсов, я тем не менее наделаю в них смысловых ошибок — то ни одна модульная система — хоть на обероне 99th edition — этого не заметит и правильно работать не станет. Или ты и это станешь оспаривать?


Если Вы испортите свой модуль, то изломается только то что от него зависит (а как же иначе?), но остальная система от этого не изломается. А вот если будет buffer overflow, то изломаться может все что угодно.
Re[15]: Миф
От: AndreyFedotov Россия  
Дата: 11.11.04 07:47
Оценка: +2
Здравствуйте, Сергей Губанов, Вы писали:

СГ>В общем случае, естественно, на этапе компиляции — нет. Это runtime проверка.

То есть трата ресурсов — тогда, когда этого не нужно. Что особенно полезно для БФП преобразования.

AF>> Приведённый пример — ярчайшее доказательство несостоятельности оберона как практически используемого языка.


СГ>Значит если язык ОФИЦИАЛЬНО РАЗРЕШАЕТ buffer overflow, утечку памяти, повисшие указатели, неправильное приведение типов то он практически состоятельный, а если языке В ПРИНЦИПЕ НЕВОЗМОЖНЫ такие явления то этот язык практически не состоятельный, так да?


Именно. См. ассемблер. Самые критичные по времени выполнения алгоритмы пишутся на нём. И уж затем C/С++. А вот оберон там рядом не стоял...
Кроме того, если речь идёт о безопасности — то абсолютно никто не мешает использовать smart поинтеры или массивы с контролем пересечения границ. Что до стека — то это вопрос к компилятору, а не к языку.

AF>> Если — соблюдая внешнюю форму интерфейсов, я тем не менее наделаю в них смысловых ошибок — то ни одна модульная система — хоть на обероне 99th edition — этого не заметит и правильно работать не станет. Или ты и это станешь оспаривать?


СГ>Если Вы испортите свой модуль, то изломается только то что от него зависит (а как же иначе?), но остальная система от этого не изломается. А вот если будет buffer overflow, то изломаться может все что угодно.

По поводу модуля — это зависит от сложности данных, и степени того, насколько глубоко закопана ошибка. Простейший пример — модуль, который планирует форматирование диска раз в 30 минут. Синтаксически всё корректно — а по смыслу пострадает вся система.
А вот и нет. При buffer overflow возможно много пакостей, но не более — чем при других ошибках в модуле. Кроме того — вопрос опять-таки к компилятору, а не к языку.
Re[7]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 11.11.04 07:49
Оценка: 2 (2) +2
Здравствуйте, Сергей Губанов, Вы писали:

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


ЗХ>>Это запросто! Недостаток твоего подхода — надо лишнее слово написать.

ЗХ>>А преимущество? Ну хоть одно? Ну маааааалюююююююсенькое....

СГ>Компилятор и runtime становится еще более простой ведь все связанные с типом процедуры виртуальны — все единообразно. Например. для встроенных систем чем проще, тем компактнее, тем лучше.


Ну зашибись, теперь заботимся о писателях компиляторов — приехали!
Нас очень сильно заботит, чтобы они получали большие деньги за элементарную работу...
Re[7]: Связанные с типом процедуры должны быть виртуальными
От: Клапауций Ниоткуда  
Дата: 11.11.04 07:57
Оценка: 1 (1) +1
Здравствуйте, Сергей Губанов, Вы писали:

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


ЗХ>>Это запросто! Недостаток твоего подхода — надо лишнее слово написать.

ЗХ>>А преимущество? Ну хоть одно? Ну маааааалюююююююсенькое....

СГ>Компилятор и runtime становится еще более простой ведь все связанные с типом процедуры виртуальны — все единообразно. Например. для встроенных систем чем проще, тем компактнее, тем лучше.


Странно как-то. Как дело касается GC и рантайм проверок всяких (великий Оберон) это не влияет на сложность компилятора и компактность кода, а невиртуальные ф-ии уж так усложняют всё.....
Re[13]: Миф
От: WolfHound  
Дата: 11.11.04 08:13
Оценка: 41 (6) +3
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Это всё мифы появившиеся в результате использования опасных языков программирования Си/Си++ и им подобным.

Это ты можешь расказывать ведущим физикам... но не профессиональным программистам.
УРОНИТЬ МОЖНО ВСЕ!
Этот код конечно не роняет .НЕТ но программа примерно на 9 миллионах итераций уходит в глубокий ГЦ... но из него всеравно не вернется...
class Class1
{
    Class1 next;
    int i1 = 1;//Заведем несколько переменных(чтобы память быстрее заканчивалась)
    int i2 = 1;
    int i3 = 1;
    int i4 = 1;
    int i5 = 1;
    int i6 = 1;
    int i7 = 1;
    int i8 = 1;
    int i9 = 1;
    int i0 = 1;
    static void Main(string[] args)
    {
        Class1 c = null;
        int i = 0;
        while(true)
        {
            Class1 n = new Class1();
            n.next = c;
            c = n;
            ++i;
            if(i%1000 == 0)//Консоль штука тормозная :(
                Console.WriteLine(i);
        }
    }
}

Уверен что на обероне будет тотже результат.
Ты скажешь а какое отношение это имеет к реальным программам? Да очень простое. В реальных программах будет граф ссылок и если этот грав гденибудь недай бог случайно зацепится за стек то произойдет... см код выше.
Короче ничего оберон гарантаровать не может ибо куда ему до человека которого хлебом не корми дай гденибудь ошибиться...

СГ>Для таких языков даже невозможно написать компилятор, который мог бы предотвратить buffer overflow.

Предотвратить попытку доступа за приделы массива не возможно.

Ее можно только оноружить, а вот что с ней делать когда ее обнаружили. Вот в .НЕТ происходит генерация исключения. А что делать в обероне?

СГ>Вот, совсем недавно, Владимир Лось, переписывая аудиокодек с C на Active Oberon в очередной раз столкунулся с порочностью языка Си:

С его слов можно судить лишь о компетентности того программера который писал тот код.
А остальное лишь не корректные обобщения.(выводы о тех кто делает такие обобщения поскипаны)

СГ>Использование безопасных (safety) языков программирования таких как языки Oberon family позволяет создавать надежные расширяемые модульные операционные системы

Иди втирай это физикам.
Практика показывает что ламеры могут уронить чтоугодно.

СГ>Модульная расширяемая система от того и называется расширяемой, что добавление в нее нового модуля не может привести к поломке в уже установленных модулях.

АГАЩАЗБЛИН
СГ> Добавление нового модуля не обязывает проводить полный integrity check.
Разказывай это гденибудь на ввв.физики.ру Чудес не бывает. УРОНИТЬ МОЖНО ВСЕ!
СГ>Если каждое добавление нового модуля обязывало бы проводить полную проверку целостности, то такая система не могла бы называться РАСШИРЯЕМОЙ просто по определению расширяемых систем.
Значит расширяемых систем не существует.
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 09:11
Оценка: -3 :))) :)
Здравствуйте, WolfHound, Вы писали:

WH>Этот код конечно не роняет .НЕТ но программа примерно на 9 миллионах итераций уходит в глубокий ГЦ... но из него всеравно не вернется...

WH>
WH>class Class1
WH>{
WH>    Class1 next;
WH>    int i1 = 1;//Заведем несколько переменных(чтобы память быстрее заканчивалась)
WH>    int i2 = 1;
WH>    int i3 = 1;
WH>    int i4 = 1;
WH>    int i5 = 1;
WH>    int i6 = 1;
WH>    int i7 = 1;
WH>    int i8 = 1;
WH>    int i9 = 1;
WH>    int i0 = 1;
WH>    static void Main(string[] args)
WH>    {
WH>        Class1 c = null;
WH>        int i = 0;
WH>        while(true)
WH>        {
WH>            Class1 n = new Class1();
WH>            n.next = c;
WH>            c = n;
WH>            ++i;
WH>            if(i%1000 == 0)//Консоль штука тормозная :(
WH>                Console.WriteLine(i);
WH>        }
WH>    }
WH>}
WH>

WH>Уверен что на обероне будет тотже результат.

А я не уверен — я знаю, что такая программа на любом языке программирования исчерпает всю память.
Давайте разберемся что делает Ваша программа:
  Class1 n = new Class1(); (* Создаем новый элемент списка   *)
  n.next = c; c = n;       (* Записываем этот элемент в список первым *)

Таким образом, на каждом шаге цикла список увеличивается на 1 элемент. Если мы сделаем 9 миллионов итераций, то список будет включать в себя 9 миллионов элементов. Со временем у нас кончиться оперативная память. Однако, какое это имеет отношение к сборщику мусора? Абсолютно никакого отношения не имеет. Вы намеренно создаете длинный список, создаете и создаете и ничего не удаляете, а если ничего не удалять, то в конце концов, у компьютера кончается память.

То что Вы привели такой пример пытаясь в чем-то уличить сборщик мусора, лишь лишний раз поддтверждает тезис о малограмотности большинства современных программистов. Я склонен, в некоторой части, обвинять в этом (само)образование полученное на основе недисциплинированных языков программирования таких как Си++ когда на изучение принципов создания грамотных алгоритмов уже не остается времени, так как все время уходит на заучивание чрезмерно сложного языка.
Re[15]: Грамотность
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 11.11.04 09:15
Оценка: 1 (1) +3
Здравствуйте, Сергей Губанов, Вы писали:

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


СГ>То что Вы привели такой пример пытаясь в чем-то уличить сборщик мусора, лишь лишний раз поддтверждает тезис о малограмотности большинства современных программистов. Я склонен, в некоторой части, обвинять в этом (само)образование полученное на основе недисциплинированных языков программирования таких как Си++ когда на изучение принципов создания грамотных алгоритмов уже не остается времени, так как все время уходит на заучивание чрезмерно сложного языка.


Линейку в студию — будем мерить у кого длиннее. А вообще-то такие нападки запрещены правилами форумов RSDN...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[8]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 09:21
Оценка:
Здравствуйте, Клапауций, Вы писали:

К>Странно как-то. Как дело касается GC и рантайм проверок всяких (великий Оберон) это не влияет на сложность компилятора и компактность кода, а невиртуальные ф-ии уж так усложняют всё.....


Нет не странно. Без рантайма и сборщика мусора невозможно создать модульную расширяемую систему. Поэтому такие усложнения компилятора необходимы, в то время как, создание невиртуальных методов (и без того реализуемых с помощью простых процедур) не является необходимым — это всего лишь вопрос удобства — писать на 1 идентификатор поменьше. Поэтому не удивительно, что в языке Oberon-2 было сделано именно так. Как я уже говорил, в потомке Oberon-2 в языке Component Pascal невиртуальные методы все же были добавлены — пользуйтесь полученным удобством на здоровье.
Re[5]: Связанные с типом процедуры должны быть виртуальными
От: Kluev  
Дата: 11.11.04 09:25
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>Пример у тебя не корректный ибо часть процедур не есть операции собственно класса "целое", а некоторые я бы в нём оставил (e.g. ConvertToString, только я бы убрал первый параметр, ибо он смысла не несёт, если мы операцию к известному объекту применяем)


СГ>Можно попросить пальцем показать где некорректность:


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

Если опять вернутся к тому же примеру IBinaryStream и взять реальный случай записи массива пользовательских структур в поток то что же мы видим?

void points_write( IBinStream &stm, Point pts[], uint pts_size )
{
    // сначала запишем длинну, заюзав хелпер
    IBinStream_int_put( stm, pts_size );
    // опаньки, для типа Point никто хелпер не написал, юзаем вирт. метод через класс
    stm.write( pts, sizeof(Point) * pts_size );
}

// что же получилось? код в котором нет никакого однообразия.
// хотя операции одни и те же: запись в поток
// плохо читается да и писать такое не очень приятно

// можно переписать так:
void points_write( IBinStream &stm, Point pts[], uint pts_size )
{
    IBinStream_int_put( stm, pts_size );
    for ( int i = 0; i < pts_size; i++ ) {
        IBinStream_real_put( stm, pts[i].x );
        IBinStream_real_put( stm, pts[i].y );
        IBinStream_real_put( stm, pts[i].z );
    }
}

// более однообразно, но производительность будет ниже унитаза

// получается что в итоге надо либо полностью отказатся от хелперов:
void points_write( IBinStream &stm, Point pts[], uint pts_size )
{
    stm.write( &pts_size, sizeof(uint) ); // юзаем вирт. методы
    stm.write( pts, sizeof(Point) * pts_size );
}

// тем самым лишив себя всякого удобства,
// и постоянно контролируя себя правильный ли sizeof передан

// либо юзать только хелперы:
void points_write( IBinStream &stm, Point pts[], uint pts_size )
{
    IBinStream_int_put( stm, pts_size ); // хелпер для "удобства"
    IBinStream_write( pts, sizeof(Point) * pts_size ); // хелпер обертка
}

// а теперь посмотрите на этот вариант и сравните его со всеми остальными:
void points_write( IBinStream &stm, Point pts[], uint pts_size )
{
    stm.put( pts_size );
    stm.put( pts, pts_size );
}

// и что же мы видим? видим, что на сложном плюс-плюсе можно действительно писать простой код
// а на простом обероне код получается примитивным и плохочитаемым.
// плюсовое решение и красивое и однообразное и быстрое и легкочитаемое
// а в обероне либо однообразно, но не быстро. Или однообразно, но не удобно и т.п.
Re[15]: Грамотность
От: Клапауций Ниоткуда  
Дата: 11.11.04 09:25
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

СГ>То что Вы привели такой пример пытаясь в чем-то уличить сборщик мусора, лишь лишний раз поддтверждает тезис о малограмотности большинства современных программистов. Я склонен, в некоторой части, обвинять в этом (само)образование полученное на основе недисциплинированных языков программирования таких как Си++ когда на изучение принципов создания грамотных алгоритмов уже не остается времени, так как все время уходит на заучивание чрезмерно сложного языка.



Модульная расширяемая система от того и называется расширяемой, что добавление в нее нового модуля не может привести к поломке в уже установленных модулях. Добавление нового модуля не обязывает проводить полный integrity check. Если каждое добавление нового модуля обязывало бы проводить полную проверку целостности, то такая система не могла бы называться РАСШИРЯЕМОЙ просто по определению расширяемых систем.


И вот допустим есть модуль A.
Модуль А содержит вышеприведённую ошибку, которую не смогли найти и которая не проявлялась в версии 1, т.к. никто не использовал этот модуль соответствующим образом.
Затем добавляем модуль B, который начал использовать A так что ошибка начала проявлятся.
И как это соотносится с "...добавление в нее нового модуля не может привести к поломке в уже установленных модулях. Добавление нового модуля не обязывает проводить полный integrity check." ?
Или вы предполагаете писать программы "сразу без ошибок" ?
Re[16]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 09:27
Оценка:
Здравствуйте, Mr. None, Вы писали:

MN>Линейку в студию — будем мерить у кого длиннее. А вообще-то такие нападки запрещены правилами форумов RSDN...


Извините, но в чем проблема-то? Форум RSDN как раз и создан для того чтобы общаясь друг с другом, мы могли повышать уровень нашей грамотности. Если бы все были грамотными на 100%, то зачем форум? Например, лично я, сам себя тоже не считаю шибко грамотным. Есть вещи в которых я полный ламер, и надеюсь что с помощью подобных форумов мне удастся повысить свой уровень грамотности.
Re[16]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 09:30
Оценка:
Здравствуйте, Клапауций, Вы писали:

К>И вот допустим есть модуль A.

К>Модуль А содержит вышеприведённую ошибку, которую не смогли найти и которая не проявлялась в версии 1, т.к. никто не использовал этот модуль соответствующим образом.
К>Затем добавляем модуль B, который начал использовать A так что ошибка начала проявлятся.
К>И как это соотносится с "...добавление в нее нового модуля не может привести к поломке в уже установленных модулях. Добавление нового модуля не обязывает проводить полный integrity check." ?

В том-то и дело, что ошибка уже была в системе. Добавление модуля В лишь ВЫЯВИЛО ее, но не СОЗДАЛО.

К>Или вы предполагаете писать программы "сразу без ошибок" ?


Да, предлагаю. Удивлены?
Re[5]: Связанные с типом процедуры должны быть виртуальными
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 11.11.04 09:31
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


СГ>Я конечно понимаю, что писанины получается больше. Вместо кода:

СГ>
СГ>  stm.ReadInteger(a);
СГ>

СГ>надо писать код:
СГ>
СГ>  Streams.ReadInteger(stm, a);
СГ>

СГ>однако никакого гемороя, признаться, в этом не вижу. Ну и что такого-то, что чуток (на 1 слово — "Streams.") побольше написать? По существу замечания будут или нет?

Будут, это правда на C#, но понятно я думаю будет всё равно:
Microsoft.Web.Services2.Security.X509.X509CertificateStore store = Microsoft.Web.Services2.Security.X509.X509CertificateStore.CurrentUserStore(Microsoft.Web.Services2.Security.X509.X509CertificateStore.MyStore);

это всё одна строка...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[9]: Связанные с типом процедуры должны быть виртуальными
От: Клапауций Ниоткуда  
Дата: 11.11.04 09:37
Оценка: +2 :))
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>Странно как-то. Как дело касается GC и рантайм проверок всяких (великий Оберон) это не влияет на сложность компилятора и компактность кода, а невиртуальные ф-ии уж так усложняют всё.....


СГ>Нет не странно. Без рантайма и сборщика мусора невозможно создать модульную расширяемую систему.

Забавно. А я на основе многочисленных споров понял совершенно обратное — можно. Так что приводить это как аксиому по крайней мере странно.

СГ>Поэтому такие усложнения компилятора необходимы, в то время как, создание невиртуальных методов (и без того реализуемых с помощью простых процедур) не является необходимым — это всего лишь вопрос удобства — писать на 1 идентификатор поменьше.


И какие у вас претензии к удобству ? Разработчиков компиляторов жалко ? Так не жалейте ! Они деньги за это получают !

СГ> Поэтому не удивительно, что в языке Oberon-2 было сделано именно так.


Конечно не удивительно. Зачем в обероне удобства ? Им то и не пользуется прочти никто.

СГ> Как я уже говорил, в потомке Oberon-2 в языке Component Pascal невиртуальные методы все же были добавлены — пользуйтесь полученным удобством на здоровье.


Ах нехорошие люди. Добавили таки. Повелись на удобство....Не пострашилсь усложнения компилятора !
Re[17]: Грамотность
От: Клапауций Ниоткуда  
Дата: 11.11.04 09:47
Оценка: 12 (1) +2 :))) :))
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>И вот допустим есть модуль A.

К>>Модуль А содержит вышеприведённую ошибку, которую не смогли найти и которая не проявлялась в версии 1, т.к. никто не использовал этот модуль соответствующим образом.
К>>Затем добавляем модуль B, который начал использовать A так что ошибка начала проявлятся.
К>>И как это соотносится с "...добавление в нее нового модуля не может привести к поломке в уже установленных модулях. Добавление нового модуля не обязывает проводить полный integrity check." ?

СГ>В том-то и дело, что ошибка уже была в системе. Добавление модуля В лишь ВЫЯВИЛО ее, но не СОЗДАЛО.

Я про 2-ую часть. "Добавление нового модуля не обязывает проводить полный integrity check". Выпуск модуля B без тестирования его с остальным кодом — это просто безответственно. А если это была программа для АЭС (вроде на оберонах только их и пишут...). Вот ещё вопрос кто написал модуль B для Чернобыльской АЭС....

К>>Или вы предполагаете писать программы "сразу без ошибок" ?


СГ>Да, предлагаю. Удивлены?


Нет конечно. Вы отличный генератор песполезных идей. Но эта идея уже была:

Написание программы с помощью ИИ заключается в подаче команды "написать программу".
Отладка заключается в подаче команды "написать программу без багов"

Re[6]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 09:48
Оценка:
Здравствуйте, Kluev, Вы писали:

K>

void points_write( IBinStream &stm, Point pts[], uint pts_size )
{
    // сначала запишем длинну, заюзав хелпер
    IBinStream_int_put( stm, pts_size );
    // опаньки, для типа Point никто хелпер не написал, юзаем вирт. метод через класс
    stm.write( pts, sizeof(Point) * pts_size );
}



Я бы просто вот так написал и не парился понапрасну:
void WritePoints( IBinStream &stm, Point pts[], uint pts_size )
{
  stm.write(&pts_size, sizeof(pts_size)); 
  if( pts_size > 0 ){
    stm.write(pts,   sizeof(Point)*pts_size);
  }
}
Re[17]: Грамотность
От: Mamut Швеция http://dmitriid.com
Дата: 11.11.04 09:54
Оценка:
Код полугипотетический, бо синтаксиса я уже не помню.


IMPORT MathCalc;

MODULE MathTools;
    PROCEDURE ReturnComplexMathematicalComputation*: INT;
    
    {* *}
    
    PROCEDURE ReturnComplexMathematicalComputation    
    VAR:
        i: INT;
    BEGIN
        i := 100 / MathCalc.CalcSum;
        RETURN i;
    END;
    
END MathTools.



MODULE MathCalc;
    PROCEDURE CalcSum*: INT;
    
    {* *}
    
    PROCEDURE CalcSum    
    VAR:
        i: INT;
        {* other vars *}
    BEGIN
        {* we accept data from external sources and compute it *}
        RETURN ResultingSum;
    END;
    
END MathTools.




Внимание, вопрос! Что произойдет, если MathCalc.CalcSum вернет 0? На этапе компиляции это отловить невозможно, так как данные получаются извне. Кривые руки программиста не поставили проверку на ноль в модуле MathTools, а модуль MathTools и его методы активно используются для представления (например) статистической информации в десяти разных представлениях в десятке различных модулей. Что произойдет? ИМХО, система встанет, причем вся.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


dmitriid.comGitHubLinkedIn
Re[10]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 09:55
Оценка:
Здравствуйте, Клапауций, Вы писали:

СГ>>Нет не странно. Без рантайма и сборщика мусора невозможно создать модульную расширяемую систему.

К>Забавно. А я на основе многочисленных споров понял совершенно обратное — можно. Так что приводить это как аксиому по крайней мере странно.

Рантайм нужен (кроме всего прочего) для safety (проверка индексов, динамическое приведение типов, и т.д.), а рантаймовый сборщик мусора нужен для расширяемости. Потому что только во время работы системы можно принять решение об освобождении памяти, но невозможно это сделать во время написания отдельно взятого модуля, когда точно не известно в какой системе он будет запущен на выполнение и кто его будет использовать, какие модули в этот момент будут загружены в систему и т.д.
Re[6]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 10:01
Оценка:
Здравствуйте, Mr. None, Вы писали:


MN>Будут, это правда на C#, но понятно я думаю будет всё равно:

MN>Microsoft.Web.Services2.Security.X509.X509CertificateStore store = Microsoft.Web.Services2.Security.X509.X509CertificateStore.CurrentUserStore(Microsoft.Web.Services2.Security.X509.X509CertificateStore.MyStore);

А там, нету чтоли возможности для создания коротких псевдонимов для длинных имен? Странно, а Vlad2 тут еще C# во всю нахваливает....

В Component Pascal, по крайней мере, можно было бы так:
IMPORT MCSt := MicrosoftWebServices2SecurityX509X509;

VAR store: MCSt.CertificateStore;
BEGIN
  store := MCSt.CurrentUserStore(MCSt.MyStore);
Re[11]: Связанные с типом процедуры должны быть виртуальными
От: Клапауций Ниоткуда  
Дата: 11.11.04 10:01
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


СГ>>>Нет не странно. Без рантайма и сборщика мусора невозможно создать модульную расширяемую систему.

К>>Забавно. А я на основе многочисленных споров понял совершенно обратное — можно. Так что приводить это как аксиому по крайней мере странно.

СГ>Рантайм нужен (кроме всего прочего) для safety (проверка индексов, динамическое приведение типов, и т.д.), а рантаймовый сборщик мусора нужен для расширяемости. Потому что только во время работы системы можно принять решение об освобождении памяти, но невозможно это сделать во время написания отдельно взятого модуля, когда точно не известно в какой системе он будет запущен на выполнение и кто его будет использовать, какие модули в этот момент будут загружены в систему и т.д.


Замечательно ! Но всё же вопрос такой — зачем нужно это дополнительное неудобство для программиста ?

З.Ы. Насчёт GC можно сильно не нажимать. Я читал эти аргументы. И аргументы оппонентов. И ваши мне не показались убедительными.
Re[18]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 10:04
Оценка: -2
Здравствуйте, Mamut, Вы писали:

M>Код полугипотетический, бо синтаксиса я уже не помню.


M>Внимание, вопрос! ... Что произойдет? ИМХО, система встанет, причем вся.



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

format c:/

ИМХО, система ляжет, причем вся.
Re[19]: Грамотность
От: Mamut Швеция http://dmitriid.com
Дата: 11.11.04 10:10
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


M>>Код полугипотетический, бо синтаксиса я уже не помню.


M>>Внимание, вопрос! ... Что произойдет? ИМХО, система встанет, причем вся.



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

СГ>

СГ> format c:/

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

Нуу.... Это не ответ... Я привел реальный кусок кода. Не всякий программист, увы, будет делать проверки, надеясь на соседа, на бога или на карму. Так что же произойдет в Обероне, если перестанет работать модуль, импортируемый многими другими модулями?

Re[12]: Миф
Автор: Сергей Губанов
Дата: 11.11.04

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


Еще как может
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


dmitriid.comGitHubLinkedIn
Re[19]: Грамотность
От: Клапауций Ниоткуда  
Дата: 11.11.04 10:13
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

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

СГ>

СГ> format c:/

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

Неужели совсем не видно разницы в НАМЕРЕНОМ (специально пишу большими буквами — у оберонщиков там какой-то рефлекс на них вроде...) ОШИБОЧНОМ использовании ?
Re[20]: Грамотность
От: Клапауций Ниоткуда  
Дата: 11.11.04 10:15
Оценка:
Читать так:

К>Неужели совсем не видно разницы в НАМЕРЕНОМ (специально пишу большими буквами — у оберонщиков там какой-то рефлекс на них вроде...) и ОШИБОЧНОМ использовании ?
Re[7]: Связанные с типом процедуры должны быть виртуальными
От: Клапауций Ниоткуда  
Дата: 11.11.04 10:20
Оценка: 1 (1) +3 :))) :)))
Здравствуйте, Сергей Губанов, Вы писали:

СГ>В Component Pascal, по крайней мере, можно было бы так:

СГ>[pascal]
СГ>IMPORT MCSt := MicrosoftWebServices2SecurityX509X509;

Нууу... Зачем это ?
Без этой ерундв еомпилятор и runtime становится еще более простой — постоянное использование полного имени — все единообразно. Например. для встроенных систем чем проще, тем компактнее, тем лучше.
Re[13]: Миф
От: Кодт Россия  
Дата: 11.11.04 10:21
Оценка: +2
Здравствуйте, Сергей Губанов, Вы писали:

<>

Я бы на твоём месте не молился так на невозможность buffer overflow. Вылет за границы индекса — он и в африке вылет за границы индекса, только феерверки будут разными.
В случае языков со слабой защитой памяти — получим расстрел и наведённые ошибки. В случае языков с тотальным контролем — медленно и печально программа завершится, удивив пользователя.

К примеру, написал ты модуль для вычисления процентов по формуле
percentage(x,y) = x*100/y

всё законно, казалось бы.

Через некоторое время твой коллега воспользовался этим модулем для вывода прогресса при копировании файлов. Ну просто зашибись какая красивая программа получилась.

А потом юзер натравил эту программу на каталог, где есть файлы нулевой длины.

И юзеру наплевать, что программа при этом не отформатировала диск, не разослала адресную книгу 50 друзьям из Зимбабве и т.п.
Своё дело она не сделала, а если её дело было аварийный бэкап сервера, то ущерб получился не меньше, чем от расстрела памяти.
Перекуём баги на фичи!
Re[7]: Связанные с типом процедуры должны быть виртуальными
От: Kluev  
Дата: 11.11.04 10:27
Оценка: 1 (1) +2
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Я бы просто вот так написал и не парился понапрасну:

СГ>
СГ>void WritePoints( IBinStream &stm, Point pts[], uint pts_size )
СГ>{
СГ>  stm.write(&pts_size, sizeof(pts_size)); 
СГ>  if( pts_size > 0 ){
СГ>    stm.write(pts,   sizeof(Point)*pts_size);
СГ>  }
СГ>}
СГ>


Это вы не просто написали, это примитивно.
Просто — это вот так:
stm.put(pts_size);
stm.put(pts,pts_size);


В вашем коде все-таки есть небольшой шанс на ошибку в sizeof, а в моем нет.
Почувствуйте разницу между простотой и примитивизмом. С++ — действительно простой язык, на котором можно писать простой и понятный код, а тот оберон который вы продвигаете как простой на самом деле примитивный, начиная с синтаксиса.
Re[9]: Связанные с типом процедуры должны быть виртуальными
От: Кодт Россия  
Дата: 11.11.04 10:30
Оценка: +4
Здравствуйте, Сергей Губанов, Вы писали:

К>> Просто есть некоторые вещи, которые уже особенно сильно не обсуждаются, ибо все принимают их "по дефолту", так вот встроенные типы БОЛЬШИМИ буквами писать имхо — маразм


СГ>По default еще со времен Модулы (70-тые годы) служебные слова пишутся заглавными буквами. Программистам не рекомендуется использовать в своих программах идентификаторы состоящие из заглавных букв, поскольку идентификаторы из заглавных букв зарезервированы на служебные слова, которые, быть может, могут быть добавлены в язык программирования. Так например, существует множество разных версий оберонов (включая версии с generic) чтобы программы были чуть-чуть более удобно переносить между такими версиями, надо просто избегать использование идентификаторов написанных заглавными буквами. Кроме того, существуют экспериментальные системы, в которых есть только простой текстовый редактор, а вот IDE с подсветкой синтаксиса пока нету, в случаях plain text служебные слова из заглавных букв сразуже видны, в результате чего в подсветке синтаксиса нет особо сильной нужды.


Чем напрягать людей ВЫКРИКИВАТЬ КЛЮЧЕВЫЕ СЛОВА, пусть бы они брали не простой нотепад, а нормальные редакторы с подсветкой — FAR, MultiEdit, Vi, Emacs, SciTe...

По поводу разнообразия диалектов. Например, в С++ есть базовый набор ключевых слов (записанный в Стандарте), а всё, что добавляется в диалекте, должно начинаться с __. Идентификаторы с таким префиксом зарезервированы для нужд реализации — ключевых слов и идентификаторов идущей в комплекте стандартной библиотеки.

По поводу заметности. Если человек нормально форматирует код, то все ключевые слова более чем заметны, вне зависимости от регистра и раскраски.
А вычитывать, когда всё свалено в одну строку с минимумом пробелов — так без разницы, будет ли там {} или BEGIN END.
Перекуём баги на фичи!
Re[16]: Миф
От: Кодт Россия  
Дата: 11.11.04 10:37
Оценка: +1
Здравствуйте, AndreyFedotov, Вы писали:
AF> Именно. См. ассемблер. Самые критичные по времени выполнения алгоритмы пишутся на нём. И уж затем C/С++. А вот оберон там рядом не стоял...
AF> Кроме того, если речь идёт о безопасности — то абсолютно никто не мешает использовать smart поинтеры или массивы с контролем пересечения границ. Что до стека — то это вопрос к компилятору, а не к языку.

И между прочим, дебаг и релиз как раз отличаются проверками. Например, std::vector<> в дебаге отслеживает индексы, а в релизе — нет. Компилятор после каждого вызова процедуры в дебаге вставляет call CheckEsp, а в релизе — нет.
Подозреваю, что даже компиляторы Ada и Eiffel не насилуют компьютер повальными рантайм-проверками в релизе.

Потому что — ещё раз — смысла нет это делать.
Юзеру без разницы, каким именно способом рухнет его программа — получив исключение от несостоявшейся проверки или расстреляв стек возврата.
Перекуём баги на фичи!
Re[17]: Миф
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 10:50
Оценка:
Здравствуйте, Кодт, Вы писали:

К>И между прочим, дебаг и релиз как раз отличаются проверками. Например, std::vector<> в дебаге отслеживает индексы, а в релизе — нет. Компилятор после каждого вызова процедуры в дебаге вставляет call CheckEsp, а в релизе — нет.

К>Подозреваю, что даже компиляторы Ada и Eiffel не насилуют компьютер повальными рантайм-проверками в релизе.

За то что в релизе отключена runtime проверка приходится расплачиваться виртуальными адресными пространствами. Неотключаемая runtime проверка делает возможным использовать всего одно адресное пространство на всю операционку (следовательно один единственных сборщик мусора). Проигрывая в малом (небольшой оверхед на index check), оберон системы выигрывают на более крупном масштабе.


Хотя, я слышал, что в компиляторе от XDS, есть такой "экстремальный" режим в котором index check таки отключается (не смотря на то что это противоречит спецификации языка). Программа получается чуток более быстрой, но как знать чем это обернется....
Re[15]: Грамотность
От: Кодт Россия  
Дата: 11.11.04 10:54
Оценка: 37 (6) +2 :))
Здравствуйте, Сергей Губанов, Вы писали:

СГ>То что Вы привели такой пример пытаясь в чем-то уличить сборщик мусора, лишь лишний раз поддтверждает тезис о малограмотности большинства современных программистов. Я склонен, в некоторой части, обвинять в этом (само)образование полученное на основе недисциплинированных языков программирования таких как Си++ когда на изучение принципов создания грамотных алгоритмов уже не остается времени, так как все время уходит на заучивание чрезмерно сложного языка.


Гонево. Злое гонево.
На Обероне такую фигню спороть гораздо легче, чем на С++. Просто хотя бы потому, что программист С++ (и даже, отчасти, на VB6) изначально держит в голове вопросы использования памяти. А Оберон (и другие языки с GC) позволяют ему не париться.

Далее, насчёт наездов на сборщики.
У любого из них есть уязвимое место.

Самый глупый сборщик (например, реализованный в COM) не умеет разгребать циклические графы. Достаточно, чтобы два объекта сослались друг на друга, и всё. Это к упомянутому выше VB6.
Для сборщика с волновым алгоритмом раскраски — мы просто создадим кучу мелких объектов, которые будут ссылаться друг на друга. Пока он их всех оббежит... там будут такие фантастические задержки при выделении памяти, ты расплачешься.
Для ленивого сборщика, который ранжирует объекты по долгоживучести (предполагается, что львиная доля объектов живёт не более одного-двух цикла сборки) мы можем выжрать память, подержать её достаточно долго, чтобы убедить сборщика в безнадёжности её проверок, и только затем отпустить.

Поэтому любой серьёзный программист должен хоть капельку задумываться о том, что он себе позволяет. В документации по языку (и по конкретной реализации) должно рассказываться о таких вещах. А не "язык полупортативный, оснащён ручкой для переноски, на память болт забейте".
Перекуём баги на фичи!
Re[20]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 10:55
Оценка: :)
Здравствуйте, Mamut, Вы писали:

M>Нуу.... Это не ответ... Я привел реальный кусок кода.


Позвольте с Вами не согласиться. Вы привели как раз НЕРЕАЛЬНЫЙ кусок кода:
i := 100 / MathCalc.CalcSum;


Реальный кусок кода был бы, например, таким:
  d := MathCalc.CalcSum();
  IF d > EPSILON THEN i := 100 / d; ....


Или, на худой конец, таким:
  d := MathCalc.CalcSum();
  ASSERT(d > EPSILON);
  i := 100 / d; ....
Re[14]: Миф
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 11:00
Оценка:
Здравствуйте, Кодт, Вы писали:

К>К примеру, написал ты модуль для вычисления процентов по формуле

К>
percentage(x,y) = x*100/y


Уже проходили. Пример недействительный (я бы так не написал). Точно также, к примеру, не написал бы я format c:/
Re[21]: Грамотность
От: Mamut Швеция http://dmitriid.com
Дата: 11.11.04 11:05
Оценка: 33 (4) +1
Здравствуйте, Сергей Губанов, Вы писали:

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


M>>Нуу.... Это не ответ... Я привел реальный кусок кода.


СГ>Позвольте с Вами не согласиться. Вы привели как раз НЕРЕАЛЬНЫЙ кусок кода:


Нуу.... Это не ответ... Я привел реальный кусок кода. Не всякий программист, увы, будет делать проверки, надеясь на соседа, на бога или на карму. Так что же произойдет в Обероне, если перестанет работать модуль, импортируемый многими другими модулями?


Добавим к этому куски кода, написанные в пятницу вечером или в понедельник с утра. Куски кода написаные, когда deadline был вчера, а до milestone — как до Пекина пешком.

Также здесь
Автор: Кодт
Дата: 11.11.04
, также здесь
Автор: Mamut
Дата: 09.11.04
:

Решающим фактором в программировании остается человек (ака кривые ручки ака изобретатель велосипедов). И, увы, ни язык программирования, ни средства разработки не смогут излечить нас от этого. Они могут слегка подлечить симптомы — но не более.

... << RSDN@Home 1.1.4 beta 3 rev. 185>>


dmitriid.comGitHubLinkedIn
Re[15]: Грамотность
От: WolfHound  
Дата: 11.11.04 11:05
Оценка: +2
Здравствуйте, Сергей Губанов, Вы писали:

Обязательные правила

Невыполнение этих правил повлечёт за собой удаление либо перемещение топика модератором, а также (при достижении критической массы) включение отдельных личностей в так называемый бан-лист.

Пункт 5

Не допускается проявление грубого или неуважительного отношения к другим участникам форума. Оскорблять и обзывать собеседника, ставить под сомнение его профессиональную квалификацию, придираться к его нику, указывать на орфографические и синтаксические ошибки и т. д. запрещается.


ЗЫ Ты уже не первый раз пытаешься ставить под сомнение профпригодность собеседников.
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 11:08
Оценка:
Здравствуйте, Кодт, Вы писали:

К>На Обероне такую фигню спороть гораздо легче, чем на С++. Просто хотя бы потому, что программист С++ (и даже, отчасти, на VB6) изначально держит в голове вопросы использования памяти. А Оберон (и другие языки с GC) позволяют ему не париться.


Не парится над удалением объектов, а не над тем что оперативная память может быть исчерпана.
Re[11]: Связанные с типом процедуры должны быть виртуальными
От: Кодт Россия  
Дата: 11.11.04 11:19
Оценка: 13 (2)
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Рантайм нужен (кроме всего прочего) для safety (проверка индексов, динамическое приведение типов, и т.д.), а рантаймовый сборщик мусора нужен для расширяемости. Потому что только во время работы системы можно принять решение об освобождении памяти, но невозможно это сделать во время написания отдельно взятого модуля, когда точно не известно в какой системе он будет запущен на выполнение и кто его будет использовать, какие модули в этот момент будут загружены в систему и т.д.


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

Например, отсутствие в С++ сборки мусора на уровне языка заставило людей задуматься о таком природном явлении, как политики владения данными. Это больше, чем владение памятью (и не только памятью), на самом деле.

И соответственно, найдены разные способы управления разделяемыми данными:
— выстрелил-и-забыл: требует ответственности с принимающей стороны, зато минимальные накладные расходы и простота синтаксиса (голые указатели), совместимость с разными API.
— передача владения: выстрелил, если там подхватили то молодцы, а если нет, то освободили. Например, std::auto_ptr.
— совместное владение: подсчёт ссылок. Простота реализаций (разных!), небольшие накладные расходы, покрывает изрядную долю потребностей. Есть ряд подводных камней наподобие циклических зависимостей (решаемые, но уже на уровне проектирования!).
— безответственное владение: сборка мусора. Дёшево для программиста (если фича встроена в язык), дорого для системы.
Перекуём баги на фичи!
Re[17]: Грамотность
От: Кодт Россия  
Дата: 11.11.04 11:28
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

К>>На Обероне такую фигню спороть гораздо легче, чем на С++. Просто хотя бы потому, что программист С++ (и даже, отчасти, на VB6) изначально держит в голове вопросы использования памяти. А Оберон (и другие языки с GC) позволяют ему не париться.


СГ>Не парится над удалением объектов, а не над тем что оперативная память может быть исчерпана.


А это одно и то же, в шаловливых ручках.
Вот пример был:
HDC hdc = GetWindowDC(hwnd);
for(int i=0; i<100000; ++i)
  SelectObject(hdc, CreateSolidBrush(COLORREF(255,255,255)));

При том, что имеется встроенный в GDI сборщик неиспользуемых объектов — этот код выжрет все ресурсы со страшной силой.

И я уже говорил про совместное адресное пространство: в пользовательских системах любая корпоративность (будь то адресное пространство, планировка или что ещё) — серьёзная дыра в безопасности. Найдётся один придурок, который угробит деятельность не только своей программы, но и системы в целом.
Перекуём баги на фичи!
Re[16]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 11:31
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>ЗЫ Ты уже не первый раз пытаешься ставить под сомнение профпригодность собеседников.


1) Когда Vlad2 заявил что в обероне нет RETURN, хотя он есть, а также что он является мертвым языком, я это опроверг, а Владу сообщил что он не компетентен в этом вопросе. Обратите внимание на слова "в этом вопросе". Никакого сомнения в профпригодности я не выдвигал. (Кстати, совсем недавно Vlad2 стал заявлять что в оберонах, оказывается есть JIT компилятор, которого там на самом деле нет и не понятно с чего он это взял).

2) Малограмотность большинства программистов — это тоже факт. Посмотрите на вопросы задаваемые в технических форумах. Так что ничего особенного в таком заявлении нет.

3) Вы лично привели код якобы тестирующий сборщик мусора, а на самом деле не имеющий к нему никакого отношения. После того как я указал Вам на это, Вы вместо того чтобы признаться в том что совершили ошибку, приводите мне правила поведения на форуме. Как это понимать?
Re[18]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 11:38
Оценка:
Здравствуйте, Кодт, Вы писали:

К>А это одно и то же, в шаловливых ручках.

К>Вот пример был:
К>
К>HDC hdc = GetWindowDC(hwnd);
К>for(int i=0; i<100000; ++i)
К>  SelectObject(hdc, CreateSolidBrush(COLORREF(255,255,255)));
К>

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

А зачем же так сложно? Есть более простой способ:
VAR a: POINTER TO ARRAY OF BYTE;
BEGIN
  NEW(a, 1000000000); (* Зажираем 1 гигабайт одним махом *)



К>И я уже говорил про совместное адресное пространство: в пользовательских системах любая корпоративность (будь то адресное пространство, планировка или что ещё) — серьёзная дыра в безопасности. Найдётся один придурок, который угробит деятельность не только своей программы, но и системы в целом.


Совершенно серьезный вопрос: Как он это сделает? Ведь он не может обратиться к чужой памяти ни для чтения ни для записи, так как в языке программирования нет такого понятия как адресное пространство.
Re[19]: Грамотность
От: Кодт Россия  
Дата: 11.11.04 11:51
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

К>>И я уже говорил про совместное адресное пространство: в пользовательских системах любая корпоративность (будь то адресное пространство, планировка или что ещё) — серьёзная дыра в безопасности. Найдётся один придурок, который угробит деятельность не только своей программы, но и системы в целом.


СГ>Совершенно серьезный вопрос: Как он это сделает? Ведь он не может обратиться к чужой памяти ни для чтения ни для записи, так как в языке программирования нет такого понятия как адресное пространство.


А вот так: выжрет всю память и начнёт молотить бесконечный цикл. Всё, отдыхаем. В виндах я хотя бы Ctrl+Alt+Del нажму... прибью процесс, который много себе позволяет, и буду щаслив. А здесь?
Перекуём баги на фичи!
Re[19]: Грамотность
От: Kluev  
Дата: 11.11.04 11:57
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

К>>И я уже говорил про совместное адресное пространство: в пользовательских системах любая корпоративность (будь то адресное пространство, планировка или что ещё) — серьёзная дыра в безопасности. Найдётся один придурок, который угробит деятельность не только своей программы, но и системы в целом.


СГ>Совершенно серьезный вопрос: Как он это сделает? Ведь он не может обратиться к чужой памяти ни для чтения ни для записи, так как в языке программирования нет такого понятия как адресное пространство.


Если нет указателей-то действительно никак. Единственная возможность выход за границы массива. Правда насколько я понял это контроируется в рантайме. Однако идеальных систем не бывает, где выигрываем на системных вызовах серьезно проигрываем на массивах. С одной стороны такой подход (все в режиме ядра) должен дать большие преимущества в многопоточных серверных приложениях, а с другой стороны серверным приложениям нужен доступ к таким штукам как БД, а написать быструю БД на языке не позволяющем делать низкоуровневые оптимизации (прямая работа с памятью, отображение файлов в память и работа с ними как с массивами), имхо малореально. Т.е. получим быстрый многопоточный сервер, но преимущества могут сойти на нет из-за медленой БД. Т.е. как всегда палка о двух концах. Есть правда еще один скользкий вариант разрешить в такой системе низкоуровневое программирование, но даже при тщательном программировании надежность будет уже не та — все сможет рухнуть.
Re[20]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 12:02
Оценка:
Здравствуйте, Кодт, Вы писали:

К>А вот так: выжрет всю память и начнёт молотить бесконечный цикл. Всё, отдыхаем. В виндах я хотя бы Ctrl+Alt+Del нажму... прибью процесс, который много себе позволяет, и буду щаслив. А здесь?


Где здесь? BlackBox, например, под виндой работает — жмите Ctrl+Alt+Del.
Re[21]: Грамотность
От: Клапауций Ниоткуда  
Дата: 11.11.04 12:06
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>А вот так: выжрет всю память и начнёт молотить бесконечный цикл. Всё, отдыхаем. В виндах я хотя бы Ctrl+Alt+Del нажму... прибью процесс, который много себе позволяет, и буду щаслив. А здесь?


СГ>Где здесь? BlackBox, например, под виндой работает — жмите Ctrl+Alt+Del.


И что дальше то ? Убить процесс BlackBox ? Так это будет аналогично нажатию ресета в винде, а никак не убиению провинившегося процесса.
Re[22]: Грамотность
От: Кодт Россия  
Дата: 11.11.04 12:14
Оценка: +1
Здравствуйте, Клапауций, Вы писали:

К>>>А вот так: выжрет всю память и начнёт молотить бесконечный цикл. Всё, отдыхаем. В виндах я хотя бы Ctrl+Alt+Del нажму... прибью процесс, который много себе позволяет, и буду щаслив. А здесь?


СГ>>Где здесь? BlackBox, например, под виндой работает — жмите Ctrl+Alt+Del.


К>И что дальше то ? Убить процесс BlackBox ? Так это будет аналогично нажатию ресета в винде, а никак не убиению провинившегося процесса.


Не говоря уже о том, что нормальные ОС умеют выделять квоты на память и дисковое пространство. Тем самым выводят из-под удара всех остальных процессов.
Перекуём баги на фичи!
Re[18]: Миф
От: AndreyFedotov Россия  
Дата: 11.11.04 12:19
Оценка: :))
То то раздолье под такой операционкой вирусы писать. Уж там он как залезает — так мало никому не покажется...
Re[15]: Миф
От: AndreyFedotov Россия  
Дата: 11.11.04 12:21
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>К примеру, написал ты модуль для вычисления процентов по формуле

К>>
percentage(x,y) = x*100/y


СГ>Уже проходили. Пример недействительный (я бы так не написал). Точно также, к примеру, не написал бы я format c:/


Тогда кое-кто жульничает — пытаясь впарить язык который не дает писать format c:/
Re[17]: Грамотность
От: WolfHound  
Дата: 11.11.04 12:30
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>3) Вы лично привели код якобы тестирующий сборщик мусора, а на самом деле не имеющий к нему никакого отношения. После того как я указал Вам на это, Вы вместо того чтобы признаться в том что совершили ошибку, приводите мне правила поведения на форуме. Как это понимать?

Где я сказал что тестирую сборщик мусора? Это придумал ты. Это была лишь реакция на твой бред на счет того что в обероне все суперпупер и уронить его нельзя.
ЭТО НЕ ТАК! И именно это продемонстрировал мой пример. В реальных системах так ессно никто писать не будет. Но граф объектов может зацепится за чтонибудь случайно просто по недосмотру. Например в Янусе(он написан на .НЕТ)довольно долго была утечка памяти из-за того что просто не учли что если объект подписывается на событие санглитона то он не будет убран пока не отпишится от события.
Это была банальная ошибка программиста и никакой ГЦ от этого не застрахует.

С янусом то все просто надобыло его иногда переоткрывать(а если не держать его открытым неделями то эту утечку вобще небыло видно), а что делать в оберон-ос в которой один сборщик мусора на всех? А если подобная ошибка будет совершена в по для АЭС?
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Грамотность
От: AndreyFedotov Россия  
Дата: 11.11.04 12:41
Оценка:
Как пункт "Обязательные правила" про критическую массу и далее по тексту.
WolfHound привёл пример совершенно реальной ситуации — для того, что бы это проверить достаточно 5 минут. И хотя у меня нет оберона — я уверен что и под ним результат будет тем же самым.
Если он и сделал ошибку — так в том, что пытался сделать класс больше по размеру, а не меньше. Чем класс больше — тем меньше ссылок и устойчивее работает GC, а вот чем меньше — тем больше ссылок придётся разгребать и тем глубже GC задумается...
Re[22]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 12:50
Оценка:
Здравствуйте, Клапауций, Вы писали:

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


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


К>>>А вот так: выжрет всю память и начнёт молотить бесконечный цикл. Всё, отдыхаем. В виндах я хотя бы Ctrl+Alt+Del нажму... прибью процесс, который много себе позволяет, и буду щаслив. А здесь?


СГ>>Где здесь? BlackBox, например, под виндой работает — жмите Ctrl+Alt+Del.


К>И что дальше то ? Убить процесс BlackBox ? Так это будет аналогично нажатию ресета в винде, а никак не убиению провинившегося процесса.


С точки зрения самого Windows, система BlackBox — это обычное приложение Windows со всеми вытекающими последствиями... Так что нечему тут удивляться.
Re[18]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 12:54
Оценка:
Здравствуйте, AndreyFedotov, Вы писали:

AF>Как пункт "Обязательные правила" про критическую массу и далее по тексту.

AF>WolfHound привёл пример совершенно реальной ситуации — для того, что бы это проверить достаточно 5 минут. И хотя у меня нет оберона — я уверен что и под ним результат будет тем же самым.
AF> Если он и сделал ошибку — так в том, что пытался сделать класс больше по размеру, а не меньше. Чем класс больше — тем меньше ссылок и устойчивее работает GC, а вот чем меньше — тем больше ссылок придётся разгребать и тем глубже GC задумается...

Извините, а что именно Вы проверили? Вы, что, тоже GC проверяли с помощью кода:
        Class1 c = null;
        while(true)
        {
            Class1 n = new Class1();
            n.next = c;
            c = n;
        }

А поконкретнее, в каком именно месте тут должен был сработать GC?
Re[23]: Грамотность
От: WolfHound  
Дата: 11.11.04 12:55
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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

А если это оберон-ос стоящая на АЭС?
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 13:00
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Где я сказал что тестирую сборщик мусора?


Вот тут:

Этот код конечно не роняет .НЕТ но программа примерно на 9 миллионах итераций уходит в глубокий ГЦ... но из него всеравно не вернется...

<code>

Уверен что на обероне будет тотже результат.
Ты скажешь а какое отношение это имеет к реальным программам? Да очень простое. В реальных программах будет граф ссылок и если этот грав гденибудь недай бог случайно зацепится за стек то произойдет... см код выше.


Нет, ну если, конечно буквы ГЦ — это вовсе не GC — сборщик мусора. То, я не прав. Моя вина. Прости. Но не объяснишь ли что же это за буквы такие — ГЦ?
Re[15]: Миф
От: Кодт Россия  
Дата: 11.11.04 13:01
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

К>>
percentage(x,y) = x*100/y


СГ>Уже проходили. Пример недействительный (я бы так не написал).


Что значит недействительный? Оберон не позволяет так писать? Или всё же твоё мастерство не позволяет?
Ну хорошо. Не ты. Вася Пупкин написал свой модуль и не подумал, что кто-то может использовать его не по назначению.

В Эйфеле — там каждая функция оснащается контрактом. Попытка вызвать percentage(x,y) с нулевым y будет пресечена на шаг раньше.
Если, конечно, программист озаботился тем, чтобы этот контракт правильно написать — что тоже является допущением...

Или пример с янусом — подписка по требованию, а отписка — когда необходимость исчезнет. Как следствие, трупик.
Потому что на встроенный сборщик мусора верит, что эта деталька привинчена, и оставляет её в покое.
Сборка мусора — это не только сервис рантайма, но ещё и Принцип. И воплощать его нужно на всех уровнях, где появляются потребители ресурсов — в том числе на самых верхних. Но туда коротенькие лапки рантайма уже не дотянутся.
Перекуём баги на фичи!
Re[24]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 13:02
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

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


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

WH>А если это оберон-ос стоящая на АЭС?

Ответ на этот вопрос надо искать в мануалах той ОСи, у меня их нет. Так что, прости, я на этот вопрос ответить могу. Может кто другой сможет.
Re[24]: Грамотность
От: Kluev  
Дата: 11.11.04 13:05
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

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


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

WH>А если это оберон-ос стоящая на АЭС?

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

Сама идея оберон-системы на самом деле-то весьма любопытная. Все в одном кольце защиты и запрет на прямой доступ к памяти. В этом что-то есть. Другое дело, что язык сам имхо примитивный, начиная с синтаксиса. С-подобный синтаксис имхо гораздо более логичный и юзабельный чем паскалевский.
Re[23]: Грамотность
От: Кодт Россия  
Дата: 11.11.04 13:07
Оценка: +1 :)
Здравствуйте, Сергей Губанов, Вы писали:

К>>>>А вот так: выжрет всю память и начнёт молотить бесконечный цикл. Всё, отдыхаем. В виндах я хотя бы Ctrl+Alt+Del нажму... прибью процесс, который много себе позволяет, и буду щаслив. А здесь?


СГ>>>Где здесь? BlackBox, например, под виндой работает — жмите Ctrl+Alt+Del.


К>>И что дальше то ? Убить процесс BlackBox ? Так это будет аналогично нажатию ресета в винде, а никак не убиению провинившегося процесса.


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


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

Так и с БлекБоксом... повис контроллер реактора, и хрен с ним. Авось, АЗ сама как-нибудь опустится, там вообще никакой электроники нетути.
Перекуём баги на фичи!
Re[17]: Грамотность
От: bkat  
Дата: 11.11.04 13:10
Оценка: 29 (3) +6
Здравствуйте, Сергей Губанов, Вы писали:

К>>Или вы предполагаете писать программы "сразу без ошибок" ?


СГ>Да, предлагаю. Удивлены?


После таких заявлений самое время задавать вопросы
о реальном опыте автора таких заявлений
Сколько реальных систем, которыми пользуются люди, вами было написано.
Сколько человек принимало участие в разработках.
Что за системы были написаны и на чем. Я так понимаю на Обероне?

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

Кстати, а что такое ошибка и какие ошибки, на ваш взгляд сущетсвуют?
От каких ошибок может уберечь Оберон?
Если вы найдете ответы на эти вопросы, то будете удивлены,
что возможности Оберона не стоят и выеденного яйца, особенно
если сравнивать с тем, что реально используется.
Re[23]: Грамотность
От: Sergey J. A. Беларусь  
Дата: 11.11.04 13:16
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

К>>И что дальше то ? Убить процесс BlackBox ? Так это будет аналогично нажатию ресета в винде, а никак не убиению провинившегося процесса.


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


То есть я так понимаю, каждую апликацию нужно запихивать в отдельный BlackBox чтоб она не могла повесить намертво всё ? И где же тогда хвалёное единое адресное пространство ?
Или может вы считаете, что все процессы блэкбоксов в винде как-то объединяются в единое адресное пространство ?
Я — свихнувшееся сознание Джо.
Re[24]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 13:18
Оценка:
Здравствуйте, Sergey J. A., Вы писали:

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


К>>>И что дальше то ? Убить процесс BlackBox ? Так это будет аналогично нажатию ресета в винде, а никак не убиению провинившегося процесса.


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


SJA>То есть я так понимаю, каждую апликацию нужно запихивать в отдельный BlackBox чтоб она не могла повесить намертво всё ? И где же тогда хвалёное единое адресное пространство ?

SJA>Или может вы считаете, что все процессы блэкбоксов в винде как-то объединяются в единое адресное пространство ?

К сожалению, Вы путаете BlackBox и Aos BlueBottle. Это две разные системы написанные на двух разных языках (потомках Оберона).
Re[19]: Грамотность
От: AndreyFedotov Россия  
Дата: 11.11.04 13:22
Оценка: :)
Дайте определение сборщику мусора — и перечислите известные способы реализации и сразу станет очевидным — на каком месте и что должно было сработать. Впрочем очень сомневаюсь, что Вам это не известно.
Разве не очевидно, что ГЦ — это глубокий цикл — т.е. повиснет на долго — в частности достаточно — для того, что бы полностью убедить пользователя в своей неработоспособности?
Может стоит таки задуматься над тем — всегда ли Ваше мнение верно?
Re[19]: Грамотность
От: WolfHound  
Дата: 11.11.04 13:28
Оценка: 1 (1) +1
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Нет, ну если, конечно буквы ГЦ — это вовсе не GC — сборщик мусора. То, я не прав. Моя вина. Прости. Но не объяснишь ли что же это за буквы такие — ГЦ?

Еще раз ГДЕ НАПИСАНО ЧТО Я ТЕСТИРУЮ ГЦ? Я лишь продемонстрировал уязвимость в системе с ГЦ. И это была лишь реакция на твои заявления что модульную систему с ГЦ и контролем индексов массивов нельзя свалить. Еще раз повторю свалить можно ВСЕ.
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: Грамотность
От: Sergey J. A. Беларусь  
Дата: 11.11.04 13:32
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

SJA>>То есть я так понимаю, каждую апликацию нужно запихивать в отдельный BlackBox чтоб она не могла повесить намертво всё ? И где же тогда хвалёное единое адресное пространство ?

SJA>>Или может вы считаете, что все процессы блэкбоксов в винде как-то объединяются в единое адресное пространство ?

СГ>К сожалению, Вы путаете BlackBox и Aos BlueBottle. Это две разные системы написанные на двух разных языках (потомках Оберона).


Да. Вероятно я что-то путаю.
Что таком случае BlackBox ? Песочница для 1 апликации ? Так что ли ?
Я — свихнувшееся сознание Джо.
Re[25]: Грамотность
От: Кодт Россия  
Дата: 11.11.04 13:33
Оценка: +2 :)
Здравствуйте, Сергей Губанов, Вы писали:

СГ>К сожалению, Вы путаете BlackBox и Aos BlueBottle. Это две разные системы написанные на двух разных языках (потомках Оберона).


Это не мы, а ты нас путаешь. Итак. Как на BlueBottle пристрелить код, который глючит и подсаживает всю систему?
Перекуём баги на фичи!
Re[20]: Грамотность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 13:36
Оценка:
Здравствуйте, AndreyFedotov, Вы писали:

AF> Разве не очевидно, что ГЦ — это глубокий цикл


Сам автор подтвердил, что ГЦ — это сборщик мусора

http://www.rsdn.ru/Forum/Message.aspx?mid=894594&amp;only=1
Автор: WolfHound
Дата: 11.11.04
Re[17]: Миф
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.11.04 15:48
Оценка: +3 :)
Здравствуйте, Кодт, Вы писали:

К>Юзеру без разницы, каким именно способом рухнет его программа — получив исключение от несостоявшейся проверки или расстреляв стек возврата.


А вот тут ты не прав. При исключении грохнется только конкретная обработка, а вот при расстреле стека повалится все приложение. Что особенно приятно в серверах.
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[6]: Связанные с типом процедуры должны быть виртуальными
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.11.04 16:09
Оценка: +2
Здравствуйте, Silver_s, Вы писали:

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


Не совсем. Вот классы джавы, те да — один класс, один модуль.
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[5]: Связанные с типом процедуры должны быть виртуальными
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.11.04 16:09
Оценка:
Здравствуйте, Alxndr, Вы писали:

A>Прошу прощения, по-моему, package'ы в Java выполняют именно функцию модулей.

A>Разве нет?

Нет. Модуль джавы это единичный класс. А package это в джаве так неймспейс обзывают.
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[7]: Связанные с типом процедуры должны быть виртуальными
От: EvilChild Ниоткуда  
Дата: 11.11.04 17:13
Оценка:
Здравствуйте, Mr. None, Вы писали:

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

А можно развернуть мысль, для тех кто не в теме?
Не флейма ради, а самообразования для.
Re[18]: Миф
От: Кодт Россия  
Дата: 11.11.04 17:29
Оценка: +1 :)
Здравствуйте, AndrewVK, Вы писали:

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


К>>Юзеру без разницы, каким именно способом рухнет его программа — получив исключение от несостоявшейся проверки или расстреляв стек возврата.


AVK>А вот тут ты не прав. При исключении грохнется только конкретная обработка, а вот при расстреле стека повалится все приложение. Что особенно приятно в серверах.


Представляешь себе, каким изощрённым должен быть обработчик проверочного исключения, чтобы обеспечить стабильную работу сервера?
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 — это ради бога. Потрассируем, регистры ручками выставим... там, глядишь и исправим. А в релизе?
Перекуём баги на фичи!
Re[18]: Грамотность
От: Шахтер Интернет  
Дата: 11.11.04 17:59
Оценка:
Здравствуйте, Кодт, Вы писали:

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


К>>>На Обероне такую фигню спороть гораздо легче, чем на С++. Просто хотя бы потому, что программист С++ (и даже, отчасти, на VB6) изначально держит в голове вопросы использования памяти. А Оберон (и другие языки с GC) позволяют ему не париться.


СГ>>Не парится над удалением объектов, а не над тем что оперативная память может быть исчерпана.


К>А это одно и то же, в шаловливых ручках.

К>Вот пример был:
К>
К>HDC hdc = GetWindowDC(hwnd);
К>for(int i=0; i<100000; ++i)
К>  SelectObject(hdc, CreateSolidBrush(COLORREF(255,255,255)));
К>

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

К>И я уже говорил про совместное адресное пространство: в пользовательских системах любая корпоративность (будь то адресное пространство, планировка или что ещё) — серьёзная дыра в безопасности. Найдётся один придурок, который угробит деятельность не только своей программы, но и системы в целом.


Давно давно я работал на старой Unix станции. Я был очень удивлен когда мне рассказали, что система не контролирует размер стека приложения. Написав простенькую программу, я очень быстро убедился, что да -- не контролирует. Станцию пришлось перезагружать. Ну естественно, я всех сидящих пользователей честно предупредил -- мужики, сейчас буду ставить опасный эксперимент, сохраняйтесь.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[17]: Грамотность
От: Зверёк Харьковский  
Дата: 11.11.04 18:32
Оценка: +7 :)
Здравствуйте, Сергей Губанов, Вы писали:

MN>>Линейку в студию — будем мерить у кого длиннее. А вообще-то такие нападки запрещены правилами форумов RSDN...


СГ>Извините, но в чем проблема-то?

В том, что ты обозвал WolfHound'а малограмотным придурком.

СГ>Форум RSDN как раз и создан для того чтобы общаясь друг с другом, мы могли повышать уровень нашей грамотности.

Форум RSDN создан для обсуждения профессиональных вопросов, а не для выкриков о "всеобщей (кроме меня) безграмотности", " херовости всех (кроме Оберона) языков", "всеобщей (кроме меня) некомпетентности", "неправильности всех парадигм (кроме модульной)"

Это уже давно был бы бан, если бы Влад в этой дискуссии не заслуживал такого же бана, будучи РСДН-овцем.
сам слушаю и вам рекомендую: Muse — Track 2
FAQ — це мiй ай-кью!
МОДЕРАТОРЫ, блин!!!
От: Зверёк Харьковский  
Дата: 11.11.04 18:47
Оценка: +1
Извините, конечно, но!

В этом форуме еще есть модераторы?
сам слушаю и вам рекомендую: Muse — Track 5
FAQ — це мiй ай-кью!
Re[15]: Грамотность
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 20:44
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>То что Вы привели такой пример пытаясь в чем-то уличить сборщик мусора, лишь лишний раз поддтверждает тезис о малограмотности большинства современных программистов.


Большинства не знаю, но одного упертого оберонщика точно.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Грамотность
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 20:44
Оценка: +1 :)
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Это уже давно был бы бан, если бы Влад в этой дискуссии не заслуживал такого же бана, будучи РСДН-овцем.


Ну, нормально. Влад тут даже рядом не стоят, а не него уже хоят списать всех собок.

Просто здесь модераторы демократичные.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Грамотность
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 20:44
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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

СГ>

СГ> format c:/

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

Ну, если ОС на Обероне написана, то несомненно. А в NT тебе скорее всего скажут, что форматирование раздела на который установлена ОС невозможно. Это я к вопросу об обработке внештатных ситуаций...
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Грамотность
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 20:44
Оценка: -1
Здравствуйте, Сергей Губанов, Вы писали:

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

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


Ну, код чтения из файла мы уже видели. Там было строк 10 от силы. Не думаю, что в написанной тобой программе будет меньше строк. А стало быть ошибки неизбежны. И супер-надежная система Оберона дает крах приложения. А вот Шарповское, после выдачи окошка с сообщением об ошибке, продолжает работать как ни в чем не бывало. Вот ведь парадокс. Так кто тут безграмотный программист?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Грамотность
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 21:45
Оценка:
Здравствуйте, Кодт, Вы писали:

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


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

Другое дело, что если исчерпать всю память то лягут любые приложения.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Грамотность
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 21:45
Оценка: :))) :)
Здравствуйте, WolfHound, Вы писали:

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

WH>А если это оберон-ос стоящая на АЭС?

Дык главное успеть лечь нагами к АЭС.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Грамотность
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 21:45
Оценка:
Здравствуйте, Kluev, Вы писали:

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


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

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


А главное уникальа! VB, C#, Java, ...
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Связанные с типом процедуры должны быть виртуальными
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 12.11.04 04:46
Оценка: +1 -1
Здравствуйте, 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();
}



А ну ка, теперь на шарпе сварганьте что-нть подобное, с такиме же начальными условиями...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[22]: Грамотность
От: Трурль  
Дата: 12.11.04 06:46
Оценка: +1
Здравствуйте, VladD2, Вы писали:


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

То есть, мы чего-то там считали, поделили на 0, выдали сообщение об ошибке и продолжаем считать дальше как ни в чем не бывало? А смысл?
Re[7]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 06:55
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


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


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


Допустим, класс Java, равно как и класс C#, написанный в одном файле есть модуль. Компилируем его в исполнимый файл и загружаем этот исполнимый файл в память — исполняться. Вопрос на засыпку: Что именно будет исполнять данная единица исполнения?
Re[9]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 07:31
Оценка:
Здравствуйте, 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.
Re[10]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 07:38
Оценка:
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;

в торопях очепятался.
Re[10]: Связанные с типом процедуры должны быть виртуальными
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 12.11.04 07:51
Оценка: +3
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, 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?
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[8]: Связанные с типом процедуры должны быть виртуальными
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.04 08:27
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Допустим, класс Java, равно как и класс C#, написанный в одном файле есть модуль. Компилируем его в исполнимый файл и загружаем этот исполнимый файл в память — исполняться.
Это невозможно. Нельзя загрузить в память и исполнить класс C#. Загружается сборка, которая может содержать N классов.
В Java единицей загрузки является именно class, а пакет является всего лишь организационной абстракцией. Дефолтный класс лоадер умеет загружать классы из архивов, что делает архив еще и единицей деплоймента.
Но с точки зрения теории, все это — детали реализации класс лоадера, которая может изменяться и расширяться произвольным образом. При помощи такой техники не изменяя ни языка ни джава-машины можно получать генерацию кода не только на лету, но и по требованию.
В .Net другая идеология. Единицей деплоймента, загрузки, а также области видимости является именно сборка. Эти понятия не "размазаны" по разным сущностям и не отданы на откуп прикладным разработчикам.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: Миф
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.04 08:31
Оценка: 26 (2) +1
Здравствуйте, Кодт, Вы писали:

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


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

К>
К>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 — это ради бога. Потрассируем, регистры ручками выставим... там, глядишь и исправим. А в релизе?

Мы вроде бы об исключениях говорим, не так ли?
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[8]: Связанные с типом процедуры должны быть виртуальными
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 12.11.04 08:35
Оценка: 1 (1) :))) :))
Здравствуйте, Сергей Губанов, Вы писали:

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


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


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


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


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


Блин, прям анекдот получается. Помните?
Инженера-практика и математика-теоретика заперли в разных комнатах в каждой комнате сундук, задание — открыть сундук за 30 минут. Через 30 минут заглядывают к инженеру — то сделал из подручных средств ломик и за 5 минут вскрыл сундук. Заглядывают к математику — сундук закрыт, но все стены исписаны формулами, а математик бормочит под нос: Ладно, давайте доказывать от противного, допустим, что сундук открыт!
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re: МОДЕРАТОРЫ, блин!!!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.04 08:52
Оценка: +1 :)))
Здравствуйте, Зверёк Харьковский, Вы писали:

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


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


Есть, но лучше без крайней необходимости их не призывать
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[8]: Связанные с типом процедуры должны быть виртуальными
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.04 08:52
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

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


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


Не понял вопроса
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[9]: Связанные с типом процедуры должны быть виртуальными
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.04 08:59
Оценка:
Здравствуйте, 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();
        }
    }
}
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: МОДЕРАТОРЫ, блин!!!
От: Зверёк Харьковский  
Дата: 12.11.04 09:00
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

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


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


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


то есть она, типа, еще не крайняя? уй...
сам слушаю и вам рекомендую: Guns N' Roses — You Could Be Mine
FAQ — це мiй ай-кью!
Re[9]: Связанные с типом процедуры должны быть виртуальными
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.04 09:03
Оценка:
Здравствуйте, 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();
    }
}
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[10]: Связанные с типом процедуры должны быть виртуальными
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 12.11.04 09:21
Оценка:
Здравствуйте, 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
{
// как и раньше
};
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[10]: Связанные с типом процедуры должны быть виртуальными
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 12.11.04 09:27
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


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


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

AVK>
AVK>public class CompositeMessages
[skip]
AVK>


AVK>
AVK>public class CompositeMessages
[skip]
AVK>


вариант 1 не катит, любой класс находящийся в этой же сборке получит точно такой же доступ как и Node, более надёжный вариант предложеный Sinclair
Автор: Sinclair
Дата: 12.11.04
, но и у него есть недостатки, я описал их в ответе к тому посту.

нечто похожее на вариант 2 я и сам использовал как-то, но там тоже был какой-то минус относительно надёжности — можно было обойти все эти ухищрения, только сейчас не помню как... да и вообще, обращаясь к Node я не хочу писать CompositeMessages.Node... а если таких CompositeMessages будет несколько — для разных видов Composite?
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[9]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 09:30
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


По определению, модуль — это единица исполнения. И если кто-то говорит. что класс выполняет роль модуля, то в каком смысле он выполняет эту роль? Как класс может исполняться?
Re[10]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 12.11.04 09:33
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


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


СГ>По определению, модуль — это единица исполнения. И если кто-то говорит. что класс выполняет роль модуля, то в каком смысле он выполняет эту роль? Как класс может исполняться?


Т.е. любой модуль (единственно верный "обероновский", естественно) у нас есть EXE-шник, там чтоли?
Re[10]: Связанные с типом процедуры должны быть виртуальными
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.04 09:45
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


СГ>По определению, модуль — это единица исполнения. И если кто-то говорит. что класс выполняет роль модуля, то в каком смысле он выполняет эту роль? Как класс может исполняться?


Все равно не понял. Обыкновенно может исполняться — вызываем метод и исполняемся на здоровье. В чем проблема то?
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[11]: Связанные с типом процедуры должны быть виртуальными
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.04 09:45
Оценка:
Здравствуйте, Mr. None, Вы писали:

MN>вариант 1 не катит, любой класс находящийся в этой же сборке получит точно такой же доступ как и Node,


Это вобщем то не столь важно — сборку обычно ты можешь контролировать, все же исходный код у тебя есть в полном объеме.

MN> более надёжный вариант предложеный Sinclair
Автор: Sinclair
Дата: 12.11.04
,


Честно говоря никаких отличий между ними я не нашел.

MN>нечто похожее на вариант 2 я и сам использовал как-то, но там тоже был какой-то минус относительно надёжности — можно было обойти все эти ухищрения, только сейчас не помню как...


Через рефлекшен разве что. Других способов нет.

MN> да и вообще, обращаясь к Node я не хочу писать CompositeMessages.Node...


using Node = CompositeMessages.Node;

MN> а если таких CompositeMessages будет несколько — для разных видов Composite?


Тогда первый вариант самое оно.
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[3]: МОДЕРАТОРЫ, блин!!!
От: Mamut Швеция http://dmitriid.com
Дата: 12.11.04 09:54
Оценка: :)))
Здравствуйте, Зверёк Харьковский, Вы писали:

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


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


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


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


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


Не поминай имя модератора всуе
... << RSDN@Home 1.1.4 beta 3 rev. 185>> ... <<Winamp is playing "Silence">>


dmitriid.comGitHubLinkedIn
Re[12]: Связанные с типом процедуры должны быть виртуальными
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 12.11.04 10:07
Оценка:
Здравствуйте, AndrewVK, Вы писали:

MN>>вариант 1 не катит, любой класс находящийся в этой же сборке получит точно такой же доступ как и Node,


AVK>Это вобщем то не столь важно — сборку обычно ты можешь контролировать, все же исходный код у тебя есть в полном объеме.


Согласен, если полностью себе доверяешь ... Я обычно стараюсь ещё и от себя защититься — так сказать многоуровневая оборона, иногда помогает.

MN>> более надёжный вариант предложеный Sinclair
Автор: Sinclair
Дата: 12.11.04
,


AVK>Честно говоря никаких отличий между ними я не нашел.


У него Composite в одной сборке, Node и CompositeMessages — в другой.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[13]: Связанные с типом процедуры должны быть виртуальными
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.04 10:58
Оценка:
Здравствуйте, Mr. None, Вы писали:

AVK>>Честно говоря никаких отличий между ними я не нашел.


MN>У него Composite в одной сборке, Node и CompositeMessages — в другой.


Ну так я примерно то же предполагал.
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[11]: Связанные с типом процедуры должны быть виртуальными
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.04 11:06
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Все равно не понял. Обыкновенно может исполняться — вызываем метод и исполняемся на здоровье. В чем проблема то?
Да Сергей все еще пытается опровергнуть неверное утверждение Silver_s о том, что класс в C# является более крутым аналогом оберонового модуля
Автор: Silver_s
Дата: 10.11.04
. Правда, он почему-то написал свое опровержение в ответ на твое опровержение того же утверждения.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Связанные с типом процедуры должны быть виртуальными
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.04 11:06
Оценка: 24 (4) +3
Здравствуйте, Mr. None, Вы писали:

MN>Ну этот вариант сработает. Но мне не нравится следующее:

MN>1) CompositeMessages и Composite фактически разделены, что не логично (хотя этот пункт весьма спорный);
MN>2) для каждой такой пары (Composite — Node) придётся делать 2 отдельный сборки, этак мы придёи к идее господина Губанова о 500 независимых модулей...
MN>3) но самое главное — небольшое усложенени исходной задачи сводит на нет эту реализацию...
Вообще говоря ты прав. Но надо отдать себе отчет в том, зачем вообще нужны спецификаторы доступа. Как я уже писал
Автор: Sinclair
Дата: 09.07.04
, эти спецификаторы являются некоторыми предикатами, налагаемыми на вызывающий код. В с++ предусмотрен метод раздачи исключительных прав путем friend, как дополнение к предоставленному предикату "является моим потомком".
В .Net вместо этого есть CAS, который позволяет раздавать привилегии с произвольной гранулярностью. Вносить это в язык нужным не посчитали. Трюки с компайл-тайм отловом нарушений контрактов нужны крайне редко. Примеры, которые ты приводишь, на первый взгляд напоминают "возьмите себя правой рукой за левое ухо... Как получилось?! Тогда не отпуская, поднимите левую ногу на уровень глаз и отхлебните кипяток из стакана". При проектировании возникают макрозадачи, непосредственно вытекающие из юс-кейзов, и микрозадачи — эдакие строительные кирпичи. При переходе от технологии к технологии макрозадачи остаются на месте, а вот кирпичи меняются. Удивляться этому не стоит, как не стоит и искать аналогов каждому кирпичу. Гораздо полезнее подняться на макроскопический уровень, и выполнить разложение на микрозадачи по-новому. Как правило, привычка решать задачи в рамках одной технологии диктует мгновенный и неосознанный выбор решения, которое может подойти, а может и не подойти к другой технологии. Особенно часты такие грабли в "визуально близких" технологиях — если тебе дать ту же задачу с ограничением "решить на SQL", то ты вряд ли начнешь страдать от отсутствия в нем protected и friend. А вот C# слишком синтаксически близок к С++, что провоцирует поиск в нем прямых аналогов привычным решениям.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 11:16
Оценка:
Здравствуйте, Курилка, Вы писали:


К>Т.е. любой модуль <....> у нас есть EXE-шник, там чтоли?


Да, что-то в этом роде. Только в Windows есть небольшая разница между EXE, DLL, и прочими сортами бинарников, а в оберонистых модулях нет деления на несколько сортов, там все модули по форме одинаковы. Если все модули по форме идентичны, то загрузчик легче сделать, ведь он будет загружать всего 1 сорт модулей.
Re[12]: Связанные с типом процедуры должны быть виртуальными
От: Sergey J. A. Беларусь  
Дата: 12.11.04 11:24
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Да, что-то в этом роде. Только в Windows есть небольшая разница между EXE, DLL, и прочими сортами бинарников, а в оберонистых модулях нет деления на несколько сортов, там все модули по форме одинаковы. Если все модули по форме идентичны, то загрузчик легче сделать, ведь он будет загружать всего 1 сорт модулей.


Ну расскажи, чем же DLL так разительно отличается от EXE ?
Я — свихнувшееся сознание Джо.
Re[12]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 12.11.04 11:26
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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



К>>Т.е. любой модуль <....> у нас есть EXE-шник, там чтоли?


СГ>Да, что-то в этом роде. Только в Windows есть небольшая разница между EXE, DLL, и прочими сортами бинарников, а в оберонистых модулях нет деления на несколько сортов, там все модули по форме одинаковы. Если все модули по форме идентичны, то загрузчик легче сделать, ведь он будет загружать всего 1 сорт модулей.


А як оно запущаеца-то?
В каждом модуле есть ф-ция Main чтоли?
Всё-равно должна быть точка входа
Re[12]: Связанные с типом процедуры должны быть виртуальными
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 12.11.04 11:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


S>Трюки с компайл-тайм отловом нарушений контрактов нужны крайне редко. Примеры, которые ты приводишь, на первый взгляд напоминают "возьмите себя правой рукой за левое ухо... Как получилось?! Тогда не отпуская, поднимите левую ногу на уровень глаз и отхлебните кипяток из стакана". При проектировании возникают макрозадачи, непосредственно вытекающие из юс-кейзов, и микрозадачи — эдакие строительные кирпичи.


Согласен с тем, что это микрозадача. Но с тем, что это искусственный пример — не согласен.
Я не случайно в качестве примера привёл классы с именами Composite и Node. В моей практике при более-менее сложной реализации паттерна COMPOSITE нередко возникала задача внутреннего общения между элементами иерархии. Причём общение это должно было быть с одной стороны защищённое от внешнего доступа — не гоже, если кто-нибудь другой уведомит контейнер об изменении состояния его элемента, особенно когда состояние элемента не менялось. С другой стороны внутренняя реализация контейнеров и элементов должна быть защищена и скрыта друг от друга. Если эту иерархию реализует и использует один программист, то всё что я сказал излишне, но когда их больше одного могут начаться проблемы:
1) есть доступ к методу посылающему уведомление контейнеру, почему бы не послать от имени некоего элемента — не важно какого, не важно что нельзя, сейчас это решит мою проблему... правда потом всё может упасть, потому что обработку посылки сообщения контролирую не я, но ведь метод-то доступен;
2) есть возможность пронаследоваться от CompositeMessages и подпихнуть свой левый обработчик ноду, не важно что по спецификации нельзя — компилятор ведь позволяет и это решит мою проблему в данный момент времени...
3) ... и так далее
Поэтому ИМХО, всё что декларируется в спецификации как "нельзя" необходимо подтверждать таким же "нельзя" в коде. И желательно, чтобы отлов нарушения контрактов происходил в компайл-тайме, потому что и плюсы и шарп — это всё таки языки со статической типизацией, и надо её использовать по максимуму, потому как для динамической проверки контрактов в них не построена нужная инфраструктура. Если не нравится, пожалуйста есть прекрасные динамические языки, где предоставлены все удобства для динамической проверки условий контракта: Smalltalk, Self...

Вобщем вот, но это отступление от темы форума.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[13]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 11:34
Оценка:
Здравствуйте, Курилка, Вы писали:

К>А як оно запущаеца-то?

К>В каждом модуле есть ф-ция Main чтоли?
К>Всё-равно должна быть точка входа

Ну, почти.

Можно написать так:
MODULE M1;

END M1.


А можно так:
MODULE M1;

BEGIN
 (* код, который будет выполнен при загрузке модуля в память *)
END M1.


Минимальная программа:
MODULE M1;
IMPORT StdLog;
BEGIN
 StdLog.String("Здравствуй Мир!");
END M1.
Re[13]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 11:34
Оценка:
Здравствуйте, Sergey J. A., Вы писали:

SJA>Ну расскажи, чем же DLL так разительно отличается от EXE ?


Не расскажу. Военная тайна.
Re[14]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 12.11.04 11:40
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

[skipped]

Т.е. получаем одну и ту же фигню, что и в случае длл и экзе — разница минимальна, так что же ты хотел этим сказать?
Re[14]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 12.11.04 11:40
Оценка: 1 (1) :))) :))
Здравствуйте, Сергей Губанов, Вы писали:

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


SJA>>Ну расскажи, чем же DLL так разительно отличается от EXE ?


СГ>Не расскажу. Военная тайна.


Ага, тайна святых воителей во имя небесночистого Оберона
Re[12]: Связанные с типом процедуры должны быть виртуальными
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.04 11:47
Оценка: 1 (1) +2
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Да, что-то в этом роде. Только в Windows есть небольшая разница между EXE, DLL, и прочими сортами бинарников,

Это миф. В Windows используется ровно один тип загружаемых модулей — так назывемый PE-формат. "Прочие сорта бинарников", навроде com и старых exe, оставленных для обратной совместимости, можно не рассматривать, т.к. они вообще выполняются в рамках legacy 16-разрядной подсистемы.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Связанные с типом процедуры должны быть виртуальными
От: Sergey J. A. Беларусь  
Дата: 12.11.04 12:00
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Минимальная программа:

СГ>
СГ>MODULE M1;
СГ>IMPORT StdLog;
СГ>BEGIN
СГ> StdLog.String("Здравствуй Мир!");
СГ>END M1.
СГ>


А как её запустить в Чёрном Коробке ? Если выделить M1 и выбрать в меню Execute ничего не выполняется?
Я — свихнувшееся сознание Джо.
Re[12]: Связанные с типом процедуры должны быть виртуальными
От: Silver_s Ниоткуда  
Дата: 12.11.04 12:29
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Да Сергей все еще пытается опровергнуть неверное утверждение Silver_s о том, что класс в C# является более крутым аналогом оберонового модуля
Автор: Silver_s
Дата: 10.11.04
.


Ну да ... если бы я написал что мотоцикл это более продвинутый аналог велосипеда, то сразу бы все кинулись опровергать это и были бы конечно правы, ....потому что у мотоцикла колеса гораздо толще...

... Я вобще то про форматы Portable Executable не говорил...

Вопрос на засыпку: А что можно инкапсулировать в модуле Оберона что нельзя было бы инкапсулировать в C# классе? ... Аналог кода на начальную загрузку модуля тоже имеется — статический конструктор.
Re[13]: Связанные с типом процедуры должны быть виртуальными
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.04 12:34
Оценка:
Здравствуйте, Silver_s, Вы писали:

S_>Вопрос на засыпку: А что можно инкапсулировать в модуле Оберона что нельзя было бы инкапсулировать в C# классе? ... Аналог кода на начальную загрузку модуля тоже имеется — статический конструктор.

Гм. Ты слишком узко понимаешь модуль в Обероне.
В качестве единицы инкапсуляции он несомненно проигрывает классу C#.
Но, в отличие от класса C#, модуль заодно выполняет функции единицы деплоймента и единицы исполнения. А класс C#, увы, ни одну из них не выполняет. Вот Java class, как тебе уже объяснили, является и тем и другим и третьим.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Связанные с типом процедуры должны быть виртуальными
От: hrg Россия  
Дата: 12.11.04 12:41
Оценка:
Sinclair -> "Re[13]: Связанные с типом процедуры должны быть виртуальными"

S> Гм. Ты слишком узко понимаешь модуль в Обероне.

S> В качестве единицы инкапсуляции он несомненно проигрывает классу C#.
S> Но, в отличие от класса C#, модуль заодно выполняет функции единицы
S> деплоймента и единицы исполнения. А класс C#, увы, ни одну из них не
S> выполняет. Вот Java class, как тебе уже объяснили, является и тем и
S> другим и третьим.

И чем же C# от такой засады плохо? Не будет же внедряться 1 класс?

Yury Kopyl aka hrg | Гордость мешает доходам!
Posted via RSDN NNTP Server 1.9 gamma
Re[8]: Связанные с типом процедуры должны быть виртуальными
От: Silver_s Ниоткуда  
Дата: 12.11.04 12:46
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


Все то же самое что и модули в Обероне. Единственное отличие это в формате хранения на диске. То что в С# несколько классов можно в один откомпилированый файл объединить это несущественное отличие.
Если интересует аналог точки входа у Оберона при загрузке модуля, то в С# тоже есть статический конструктор.
Re[15]: Связанные с типом процедуры должны быть виртуальными
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.04 12:57
Оценка:
Здравствуйте, hrg, Вы писали:
hrg>И чем же C# от такой засады плохо? Не будет же внедряться 1 класс?
Ничем не плохо. Просто утверждение, что у класса в C# больше возможностей, чем у модуля в Обероне, неверно. И обратное тоже неверно.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 13:01
Оценка: :))
Здравствуйте, Sergey J. A., Вы писали:

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


СГ>>Минимальная программа:

СГ>>
СГ>>MODULE M1;
СГ>>IMPORT StdLog;
СГ>>BEGIN
СГ>> StdLog.String("Здравствуй Мир!");
СГ>>END M1.
СГ>>


SJA>А как её запустить в Чёрном Коробке ? Если выделить M1 и выбрать в меню Execute ничего не выполняется?


Гы-гы-гы...Вы первый задали этот вопрос, хотя этот вариант наименьшей проги я тут давно толкал. Поздравляю Вас. Ответ на этот вопрос лично мне не известен. Наверное, как-то можно.
Re[16]: Связанные с типом процедуры должны быть виртуальными
От: Курилка Россия http://kirya.narod.ru/
Дата: 12.11.04 13:06
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


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


СГ>>>Минимальная программа:

СГ>>>
СГ>>>MODULE M1;
СГ>>>IMPORT StdLog;
СГ>>>BEGIN
СГ>>> StdLog.String("Здравствуй Мир!");
СГ>>>END M1.
СГ>>>


SJA>>А как её запустить в Чёрном Коробке ? Если выделить M1 и выбрать в меню Execute ничего не выполняется?


СГ>Гы-гы-гы...Вы первый задали этот вопрос, хотя этот вариант наименьшей проги я тут давно толкал. Поздравляю Вас. Ответ на этот вопрос лично мне не известен. Наверное, как-то можно.


Да великий язык — Оберон, на нём можно писать великие программы,
но вот запустить эти программы смогут только великие типа Вирта
Re[16]: Связанные с типом процедуры должны быть виртуальными
От: Sergey J. A. Беларусь  
Дата: 12.11.04 13:19
Оценка: :)
Здравствуйте, Сергей Губанов, Вы писали:

SJA>>А как её запустить в Чёрном Коробке ? Если выделить M1 и выбрать в меню Execute ничего не выполняется?


СГ>Гы-гы-гы...Вы первый задали этот вопрос, хотя этот вариант наименьшей проги я тут давно толкал. Поздравляю Вас. Ответ на этот вопрос лично мне не известен. Наверное, как-то можно.


Вероятно какой-то вид стартап кода:
MODULE Hello;

    IMPORT StdLog;

    PROCEDURE Do*;
    BEGIN
        StdLog.String("Hello World"); StdLog.Ln
    END Do;

BEGIN
    StdLog.String("Startup"); StdLog.Ln;
END Hello.


Выводит

Startup
Hello World

Я — свихнувшееся сознание Джо.
Re[17]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 16:00
Оценка:
Здравствуйте, Sergey J. A., Вы писали:

SJA>Вероятно какой-то вид стартап кода:


Я еще пытался слинковать этот модуль в отдельный экзешник, так чтобы при запуске экзешника выполнился этот код. Но импорт StdLog требует линковки большей части самого BalckBox, включая его Kernel. А если линкуется Kernel, то он и должен назначатся первым загружаемым модулем. Короче, ничего у меня не получилось.
Re[17]: Связанные с типом процедуры должны быть виртуальными
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 16:04
Оценка: :)
Здравствуйте, Курилка, Вы писали:

К>Да великий язык — Оберон, на нём можно писать великие программы,

К>но вот запустить эти программы смогут только великие типа Вирта

Я бы свалил это на происки Oberon Microsystems: DevDebug.Unload(); они написали, а обратную функцию "DevDebug.Load()" они написать "забыли"...
Re[16]: Миф
От: mister-AK Россия  
Дата: 12.11.04 16:55
Оценка: +1
Здравствуйте, Кодт, Вы писали:

К>В Эйфеле — там каждая функция оснащается контрактом. Попытка вызвать percentage(x,y) с нулевым y будет пресечена на шаг раньше.

К>Если, конечно, программист озаботился тем, чтобы этот контракт правильно написать — что тоже является допущением...

да, к вопросу об галочках

НЕ ПРИГЛАСИТЬ ЛИ НАМ ПОКЛОННИКОВ ЭЙФЕЛЯ????????????????????
очень хочестя узнать суть языка, но читать мануал влом
Re[23]: Грамотность
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.04 17:43
Оценка:
Здравствуйте, Трурль, Вы писали:

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


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

В качестве примера могу привести RSDN@Home с помощью которого пишу это сообщение. Мелкая ошибка в нем не приводит к схлопыванию всего приложения с потерей несохраненных данных. Вместо этого просто выдается сообщение и после нажатия "продолжить" приложение продолжает работать.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Миф
От: Зверёк Харьковский  
Дата: 12.11.04 20:10
Оценка:
Здравствуйте, mister-AK, Вы писали:

MA>да, к вопросу об галочках


MA>НЕ ПРИГЛАСИТЬ ЛИ НАМ ПОКЛОННИКОВ ЭЙФЕЛЯ????????????????????

MA>очень хочестя узнать суть языка, но читать мануал влом
MA>
Будет, будет.
Скоро уже будет "Idit's Guide to 10 uncommon programming languages" by Ваш покорный слуга.
сам слушаю и вам рекомендую: 06 — We Use The Pain
FAQ — це мiй ай-кью!
Re[14]: Связанные с типом процедуры должны быть виртуальными
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.04 21:26
Оценка:
Здравствуйте, Sinclair, Вы писали:
S>В качестве единицы инкапсуляции он несомненно проигрывает классу C#.
S>Но, в отличие от класса C#, модуль заодно выполняет функции единицы деплоймента и единицы исполнения. А класс C#, увы, ни одну из них не выполняет. Вот Java class, как тебе уже объяснили, является и тем и другим и третьим.

А почему "увы"?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Грамотность
От: Трурль  
Дата: 13.11.04 13:02
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Современный софт в основном не работает в пакетном режиме. Он обрабатывает различные транзакции. Если одна обламается — то ничего страшного. Ее можно перезапустить. Ну, и другие продолжат работать без проблем. Вылет же всего процесса (а для ублюдочных кооперативных ОС и всей системы) — это неприемлемый вариант.


В BlackBox тоже вылетит только одна комманда.
Re[25]: Грамотность
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.04 23:45
Оценка:
Здравствуйте, Трурль, Вы писали:


VD>>Современный софт в основном не работает в пакетном режиме. Он обрабатывает различные транзакции. Если одна обламается — то ничего страшного. Ее можно перезапустить. Ну, и другие продолжат работать без проблем. Вылет же всего процесса (а для ублюдочных кооперативных ОС и всей системы) — это неприемлемый вариант.


Т>В BlackBox тоже вылетит только одна комманда.


Какая еще команда? И вообще, напомню... незакрытый файл — это привет не только текущему приложению, но и всем пытающимся к нему обратиться.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Грамотность
От: prVovik Россия  
Дата: 15.11.04 07:46
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

WH>А если это оберон-ос стоящая на АЭС?

А от АЭС не только оберон, но и всякие там джавы, шарпы и прочая бизнес-ориентированная байда с гц идет лесом.
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Извини, конечно, что поздно....
От: SilverCloud Россия http://rodonist.wordpress.com
Дата: 06.12.04 19:34
Оценка: :))
Здравствуйте, Сергей Губанов, Вы писали:

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

СГ>

СГ> format c:/

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

Ну, вот только что попробовал

Microsoft Windows XP [Версия 5.1.2600]
(С) Корпорация Майкрософт, 1985-2001.

C:\Documents and Settings\Phil>format c:
Отказано в доступе.

C:\Documents and Settings\Phil>

Не падает, зараза
Who needs information?
Re[15]: Миф
От: jazzer Россия Skype: enerjazzer
Дата: 07.12.04 10:30
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


AF>> Кроме того, я просто не верю, что Оберон распознает нарушение границ массива на этапе компиляции.


СГ>В общем случае, естественно, на этапе компиляции — нет. Это runtime проверка.


и что, она будет работать быстрее, чем ее отсутствие? :)

AF>> Приведённый пример — ярчайшее доказательство несостоятельности оберона как практически используемого языка. :)


СГ>Значит если язык ОФИЦИАЛЬНО РАЗРЕШАЕТ buffer overflow, утечку памяти, повисшие указатели, неправильное приведение типов то он практически состоятельный, а если языке В ПРИНЦИПЕ НЕВОЗМОЖНЫ такие явления то этот язык практически не состоятельный, так да?


Во-первых, начнем с того, что стандарты языков не "разрешают официально" все то, что ты сказал.
Для всего этого в стандартах предусмотрены термины "неопределенное поведение", "неспецифицированное поведение" и т.п. Так что не надо приписывать языкам несуществующие свойства. Либо приведи цитату из Стандарта с явным позволением (т.е. с гарантиями правильной работы программы) писать в левую память, некорректно приводить типы и т.п.

Во-вторых, эти вещи вообще не связаны. Состоятельность языка — это то, насколько широко он используется, а на это оказывает влияние множество факторов, а не только наличие рантайм-проверок выхода за границы массива и прочие "ПРИНЦИПИАЛЬНОСТИ".

AF>> Если — соблюдая внешнюю форму интерфейсов, я тем не менее наделаю в них смысловых ошибок — то ни одна модульная система — хоть на обероне 99th edition — этого не заметит и правильно работать не станет. :) Или ты и это станешь оспаривать? :)


СГ>Если Вы испортите свой модуль, то изломается только то что от него зависит (а как же иначе?), но остальная система от этого не изломается. А вот если будет buffer overflow, то изломаться может все что угодно.


Это только в Обероне так, потому что в нем все моголитно. В такой архитектуре (типа DOS) действительно buffer overflow приведет к падению всей системы.

Да только в реальном мире (UNIX, WinNT) каждый процесс изолирован от других, так что buffer overflow, который он сделал — это только его личные проблемы и проблемы тех, кто с ним связан.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.