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 для Чернобыльской АЭС....

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


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


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

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

Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.