OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 23 Сентябрь, 2018 21:40

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 96 ]  На страницу 1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Среда, 08 Апрель, 2009 07:22 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1014
Откуда: Россия, Чебоксары
"Но позвольте же!" - вскричал Ондатр. - "Моя книга называлась "О тщете всего сущего", а не о пользе!"

Значит, так. В обилии флейма и флуда в теме История с несколькими моралями (в том числе анти-FOR) естественным образом снова всплыла тема исключений.

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

Исходные тезисы противоречивы:

1) исключения - неструктурны и поэтому ухудшают качество программы (в том числе когнитивные качества и потенциальную вероятность ошибок);

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

В процессе изучения механизма исключений также придётся решить подзадачу:
а) анализ практической потребности прерывать алгоритм до завершения;
б) как правильно и оптимально это сделать? :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 07:46 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 567
Откуда: Россия, Санкт-Петербург
Сначала следует определиться. Существуют ли безошибочные программы ;), а уже потом говорить о КАЧЕСТВЕ и НАДЁЖНОСТИ и как на это влияет обработка исключений.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 07:53 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1014
Откуда: Россия, Чебоксары
Существуют программные комплексы, которые должны работать в режиме 24х7 (то есть постоянно, без перерыва, годами). Какими путями достигается обеспечение такого режима, пользователя волновать не должно.
А наша задача - предложить оптимальный путь для этого.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 09:03 

Зарегистрирован: Четверг, 25 Май, 2006 09:20
Сообщения: 42
Откуда: Королёв М. О.
ПРИМЕР ВОПИЮЩИЙ!!!
"Правильные" слова:
Madzi писал(а):
Появились исключения не от хорошей жизни, а от упавшего уровня программистов разработчиков, которые вместо грамотного построения программы "ловят" ошибки на выходе.

И ярчайшее подтверждение:
Madzi писал(а):
Пример 1:
try {
a = x / y;
} catch (Exception e) {
System.out.writeln("Деление на нуль.");
}
Пример 2:
IF x = 0
THEN Out.String("Делитель(??????)равен нулю"); Out.Ln;
ELSE a = x / y;
END;

АПЛОДИРУЮ СТОЯ!!!
Vlad может расслабиться. Практика-критерий пользы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 09:27 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1014
Откуда: Россия, Чебоксары
В системах 24х7 оба примера никуда не годятся :)
Давайте уж сравнивать сравнимые вещи. Например:

Вариант 1: try a:=x/y except a:=inf end;
Вариант 2: if abs(y)>=eps then a:=x/y else a:=inf;

Или же:
Вариант 1: try a:=x/y except {значение а не изменяется} end;
Вариант 2: if abs(y)>=eps then a:=x/y;

По-моему, так эти варианты ничего по существу не доказывают. Их использование зависит от задачи. Удобство не сильно отличается. Затраты, в общем, тоже не сильно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 09:27 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4485
Откуда: Россия, Орёл
Alexey_Donskoy писал(а):
...Значит, так. В обилии флейма и флуда в теме История с несколькими моралями (в том числе анти-FOR) естественным образом снова всплыла тема исключений.
Обилие флуда и флейма не имеет никакого отношения к образованию. Так же как и тема исключений к "Начальному обучению программированию". Надо сразу попросить модераторов перенести эту тему в более подходящий форум...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 09:41 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1014
Откуда: Россия, Чебоксары
Согласен, флуд не имеет. Но надо же получить ясность в теории, чему учить-то?
Другое дело, что процесс получения этой теории... гм... выглядит непедагогично :)
Хотя, впрочем, и познавательно тоже :)

P.S. Да, в "Высшем образовании" смотрелось бы более уместно, тут я промахнулся чуток...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 09:43 

Зарегистрирован: Четверг, 25 Май, 2006 09:20
Сообщения: 42
Откуда: Королёв М. О.
Алексей, не увиливайте!

А если Ваши примеры напишут вот так:

Вариант 1: try a:=x/y except a:=inf end;
Вариант 2: if abs(x)>=eps then a:=x/y else a:=inf;

Или же:
Вариант 1: try a:=x/y except {значение а не изменяется} end;
Вариант 2: if abs(x)>=eps then a:=x/y;

Какой вариант будет безопаснее в эксплуатации, а?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 10:39 

Зарегистрирован: Воскресенье, 08 Март, 2009 17:54
Сообщения: 372
Приведённые примеры неуместны. Конечно, в таком случае проще обойтись без исключений.
Вот если этих проверок будет 20 штук или ошибка в "глубине" программы. Как поступать тогда?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 10:55 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1014
Откуда: Россия, Чебоксары
GeoVit писал(а):
Вариант 1: try a:=x/y except {значение а не изменяется} end;
Вариант 2: if abs(x)>=eps then a:=x/y;
Какой вариант будет безопаснее в эксплуатации, а?
То, о чём Вы говорите, называется скрытой ошибкой, которая закрывается "мягкой подушкой" исключения, но в ран-тайме. Такая практика, к сожалению, имеет место, но я бы назвал её категорически недопустимой! Потому что никто заранее не скажет, какие побочные эффекты может иметь сокрытие такой опечатки.
Поэтому второй вариант предпочтительней. Он навернётся сразу.

Algo писал(а):
Вот если этих проверок будет 20 штук или ошибка в "глубине" программы. Как поступать тогда?
Давайте договоримся так, что ошибки в программе быть не должно!
Вариант - аварийная ситуация во внешней среде - но это совершенно другое дело, и методы другие.
Как я написал в первом посте, исключения можно рассматривать как способ оптимизации (свёртки сложного графа алгоритма обработки всех вариантов, в т.ч. ошибочных ситуаций). Однако этот тезис требует доказательства. Я бы хотел увидеть такое доказательство (больше пользы или вреда от такой свёртки). Для этого и открыл тему.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 13:12 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Со случаем алгоритмических ошибок, видимо, всё ясно... Либо программа работает, либо нет. Должны быть барьеры ошибок на неких уровнях рантайма, которые отвечают за обработку таких отказов и восстановление. Но это вообще внеязыковой вопрос.

Со случаем обработки особых веток событий в системах класса 24*356 ситуация интереснее... Даже если принять полезность try-except, то вот ведь какая штука. Эти средства расчитаны на текущие архитектуры ПО. Так скажем, "промежуточное", застрявшее на середине ООП - это касается всех вариаций, в том числе и КП (я бы даже сказал "шизофреническое" ООП, это ощущается из преподавания - эти механизмы противоестественны, они не идут "от задач"). Суть в том, что мы имеем множество (взаимо)действующих объектов, но при этом они приводятся в движение только одним (или небольшим количеством) потоков выполнения. И эти потоки "шуруют" насквозь через граф из огромного числа обьектов.

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

Так вот, если уж обсуждать проблему обработки особых ситуаций - то имеет смысл уже держать в уме такую перспективу. Как будем делать там, а? :) В Эрланге вот принцип простой - ошибка в процессе = "моментом в море" :) HALT, но, естественно, без раскрутки стека, на котором просто раскручивать нечего и не к кому...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 08 Апрель, 2009 13:17 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 22:34
Сообщения: 431
Откуда: Москва
Alexey_Donskoy писал(а):
Предлагаю здесь без лишних слов привести пару учебных примеров, на которых показать пользу или вред исключений.


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

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

Исключения предназначены отнюдь не только для обработки ошибок. Они образуют своего рода сигнальную шину, по которой передаются сигналы о важных событиях, связанных с выполнением программного кода. Как правило, нестандартные/нештатные события, которые требуют соответствующего арбитража. Обрабатывающий блок не всегда способен принять решение на месте, нужно делегирование в вышестоящие инстанции. Делегирование обеспечивать по готовности (на уровне традиционных кодов ошибок) бывает крайне неудобно и неэффективно.

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

Но надо понимать, что исключения еще более опасны, чем goto. Они могут приводить к таким наведенным эффектам, которые локализовать и нейтрализовать бывает крайне трудно. ASSERT в Обероне -- это компромисс. Это упрощенные исключения, позволяющие не потерять контроль над "сигнальной шиной". При желании можно, оставаясь в терминах ASSERT, обеспечить в языке полноценную обработку исключений. Но цена за это -- опасность возникновения ошибок иного рода и наведенных эффектов, вызванных самими исключениями.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 13:38 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 567
Откуда: Россия, Санкт-Петербург
Alexey_Donskoy писал(а):
В системах 24х7 оба примера никуда не годятся :)
Давайте уж сравнивать сравнимые вещи. Например:

Вариант 1: try a:=x/y except a:=inf end;
Вариант 2: if abs(y)>=eps then a:=x/y else a:=inf;

Или же:
Вариант 1: try a:=x/y except {значение а не изменяется} end;
Вариант 2: if abs(y)>=eps then a:=x/y;

По-моему, так эти варианты ничего по существу не доказывают. Их использование зависит от задачи. Удобство не сильно отличается. Затраты, в общем, тоже не сильно.

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

Я понимаю, что пример НАДУМАН, и логичнее было бы рассматривать файловую или дисковую операцию, просто кода в этом случае больше получиться.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 14:04 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 567
Откуда: Россия, Санкт-Петербург
Илья Ермаков писал(а):
Со случаем алгоритмических ошибок, видимо, всё ясно... Либо программа работает, либо нет. Должны быть барьеры ошибок на неких уровнях рантайма, которые отвечают за обработку таких отказов и восстановление. Но это вообще внеязыковой вопрос.

...

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

Так вот, если уж обсуждать проблему обработки особых ситуаций - то имеет смысл уже держать в уме такую перспективу. Как будем делать там, а? :) В Эрланге вот принцип простой - ошибка в процессе = "моментом в море" :) HALT, но, естественно, без раскрутки стека, на котором просто раскручивать нечего и не к кому...

Мне кажется, вы незаслуженно забываете A2/AOS/Bluebottle, на базе которого разрабатывалась COMPOSITA. До миллионов активных объектов, крутящихся на железе в едином адресном пространстве. В случае ошибки там предусмотрено 2 варианта:

1. обычное объявление тела
Код:
ObjectName = OBJECT
...
BEGIN {ACTIVE}
...
END ObjectName;

при возникновении исключительной ситуации объект будет прибит средой.

2. "безопасное" объявление типа
Код:
ObjectName = OBJECT
...
BEGIN {ACTIVE, SAFE}
...
END ObjectName;

при возникновении исключительной ситуации объект будет ПЕРЕЗАПУЩЕН с начала, при этом по состоянию локальных переменных объекта, он сможет узнать что с ним случилось.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 14:12 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1014
Откуда: Россия, Чебоксары
Илья Ермаков писал(а):
"каждый объект сможет поиграть собственным мячом"
За увеличение возможностей придётся платить увеличением сложности...

Madzi писал(а):
Практика показывает, что первый вариант возникает когда автору некогда/лень разбираться с алгоритмом, который иногда сбоит...
Вот именно, всё из-за лени!

Руслан Богатырев писал(а):
Исключение можно рассматривать как программное прерывание.
НЕЛЬЗЯ!
Программное прерывание - это всего лишь способ синхронного вызова обработчика прерывания на манер процедуры.

Руслан Богатырев писал(а):
Исключения предназначены отнюдь не только для обработки ошибок. Они образуют своего рода сигнальную шину, по которой передаются сигналы о важных событиях, связанных с выполнением программного кода. Как правило, нестандартные/нештатные события, которые требуют соответствующего арбитража.
А вот это абсолютно справедливо!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 14:21 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 567
Откуда: Россия, Санкт-Петербург
Alexey_Donskoy писал(а):
Руслан Богатырев писал(а):
Исключения предназначены отнюдь не только для обработки ошибок. Они образуют своего рода сигнальную шину, по которой передаются сигналы о важных событиях, связанных с выполнением программного кода. Как правило, нестандартные/нештатные события, которые требуют соответствующего арбитража.
А вот это абсолютно справедливо!

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 14:25 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1014
Откуда: Россия, Чебоксары
Да я затем ветку и выделил, чтобы хоть кто-нибудь привёл "правильный" пример без механизма исключений :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 14:58 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 22:34
Сообщения: 431
Откуда: Москва
Madzi писал(а):
Позвольте спросить вас с Русланом, а что мешает реализовать такую сигнальную шину без механизма исключений? На уровне операционной системы или надстройки над ней. Да хотя бы на уровне приложения.


Поясню. Если Вы обратили внимание, в отношении исключений я разграничил области прикладного ПО и системного ПО. В прикладном ПО использование исключений, на мой взгляд, требуется только в очень специфических областях, как правило, активно работающих с (нестандартным) железом (например, встроенные системы). А также при особых требованиях проекта. Что касается сферы системного ПО, то это и есть, прежде всего, ОС. :wink:

Я сторонник жесткого подхода -- не размазывать системные вызовы по всему исходнику, а локализовывать и закреплять в соотв. "саркофагах". Правило простое: нельзя в проекте использовать системные вызовы, только свою четко регламентированную прослойку, у которой есть исполняющий (конкретизирующий) тонкий слой (своя run-time system). В нем и производится статическая либо динамическая коммутация с операционной средой. Подобное подмножество легче контролировать и тестировать на предмет изменений характеристик, внесенных при очередном апдейте разработчиками ОС (или соотв. сторонних библиотек).

И как сторонник жесткого подхода я против какой-то имитации программистом механизма обработки исключений напрямую средствами ОС. Этот механизм либо должен быть штатно в языке, либо должен быть решен библиотекой, служащей специфической прослойкой над ОС и/или RTS языка. Впрочем, именно библиотечным решением в свое время, лет 15 назад, занимался для Модулы-2, когда только обсуждался ISO-стандарт языка.
Найти детали можно в статье "Еще один подход к реализации механизма обработки исключений" (1993) . См. http://www.europrog.ru/oberon.html


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 15:03 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 567
Откуда: Россия, Санкт-Петербург
Рассмотрим Википедию http://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D0%B8%D1%81%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B9
Цитата:
Достоинства использования исключений особенно заметно проявляется при разработке библиотек процедур и программных компонентов, ориентированных на массовое использование. В таких случаях разработчик часто не знает, как именно должна обрабатываться исключительная ситуация (при написании универсальной процедуры чтения из файла невозможно заранее предусмотреть реакцию на ошибку, так как эта реакция зависит от использующей процедуру программы), но ему это и не нужно — достаточно сгенерировать исключение, обработчик которого предоставляется реализовать пользователю компонента или процедуры. Единственная альтернатива исключениям в таких случаях — возврат кодов ошибок, которые вынужденно передаются по цепочке между несколькими уровнями программы, пока не доберутся до места обработки, загромождая код и снижая его понятность.

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

Итак, достоинство:
1. В том, что вместо того, чтобы обработать ошибку на месте программист (ссылаясь на незнание мотивов другого программиста) перекладывает обработку на плечи "потомка" (отмазка). (При этом ссылаются на процедуру чтения из файла. Всё что нужно знать при чтении из файла, так это прочитаны данные - всё хорошо, или не прочитаны - есть ошибка. Можно, конечно, используя код ошибки передавать причину неудачи: отсутствует файл, занят другим ресурсом и т.п., но как правило для родительской программы это не важно).
2. Безусловно, читаемость кода возрастает, поскольку сразу виден опасный участок и его обработка, но это преимущество сомнительное, так как если есть проверка критических значений, то и обработка просматривается лучше. (См. мой пример со скрытой опечаткой, которую нашли исключительно благодаря безисключительному :) методу).
3. Облегчает программирование - опять отмазка.
"Что бы мне такое делать, чтобы ничего не делать" (с)

Цитата:
...
Недостаток исключений — в том, что их поддержка снижает скорость работы программы. Поэтому в местах программы, критичных по скорости, не рекомендуют возбуждать и обрабатывать исключения, хотя следует отметить, что в реальности такие случаи крайне редки, во всяком случае, в прикладном программировании.

Также в сложных программах возникают большие «нагромождения» операторов try ... finally и try ... catch (try ... except).

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 15:09 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 22:34
Сообщения: 431
Откуда: Москва
Alexey_Donskoy писал(а):
Руслан Богатырев писал(а):
Исключение можно рассматривать как программное прерывание.
НЕЛЬЗЯ!
Программное прерывание - это всего лишь способ синхронного вызова обработчика прерывания на манер процедуры.


Почему же сразу так категорично? :wink: Любое сравнение, любая ассоциация грешит неточностью. Но при этом может помочь понять суть. По аналогии. Есть синхронная и асинхронная работа. Исключение -- инструмент для организации асинхронной работы внутри чисто синхронной (последовательной) среды императивного языка. Этой асинхронной работы добиваются за счет жесткой синхронизации с обработчиком (исключения). За счет по сути программного прерывания. Блоки контроля исключений (штатный код) всегда привязаны к соответствующим блокам обработки (обработчикам "прерываний"). В разных языках и системах программирования это делается по-разному. Потому Вашу точку зрения, увы, разделить не могу.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 96 ]  На страницу 1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB