OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 22 Июнь, 2025 17:50

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




Начать новую тему Ответить на тему  [ Сообщений: 321 ]  На страницу Пред.  1 ... 8, 9, 10, 11, 12, 13, 14 ... 17  След.
Автор Сообщение
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Вторник, 05 Август, 2008 22:15 

Зарегистрирован: Вторник, 18 Сентябрь, 2007 08:48
Сообщения: 108
Пётр Кушнир писал(а):
Вы не поняли сути. Если все ассерты пройдены, то значит ваш код корректно работает в любой проверенннной вами ситуации. Если вы не проверили файл на read-only то это вы виноваты(кстати конкретно эта ситуация корректно обрабатывается в ББ ещё на уровне слоя работы с файлами).


Все равно найдутся исключения из правил. Мы не можем предусмотреть все случаи.
Классический пример: пишем вывод в файл на дисковод А. Или на флешку. Юзер или выдергивает дискету раньше окончания времени записи, или забывает вставить (или попали на битые секторы). Помимо этого, могут быть аппаратные сбои. В ББ, скорее всего, получим дамп исключений, который юзеру не нужен (неинформативно для него + форма будет "грязной").
В Delphi (и в других языках) можно (и нужно) цивилизованно перехватить исключения и культурно доложить юзеру о внештатной ситуации. Почему этого нет в ББ - непонятно.
Интересно, если я открыл файл в ББ на запись и получил дамп исключений (по крайней мере, ББ память хотя бы должен отдать) - ББ его закроет? В Delphi это гарантируется.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Вторник, 05 Август, 2008 22:37 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Edward Ivanov писал(а):
Все равно найдутся исключения из правил. Мы не можем предусмотреть все случаи.
Классический пример: пишем вывод в файл на дисковод А. Или на флешку. Юзер или выдергивает дискету раньше окончания времени записи, или забывает вставить (или попали на битые секторы). Помимо этого, могут быть аппаратные сбои. В ББ, скорее всего, получим дамп исключений, который юзеру не нужен (неинформативно для него + форма будет "грязной").
В Delphi (и в других языках) можно (и нужно) цивилизованно перехватить исключения и культурно доложить юзеру о внештатной ситуации. Почему этого нет в ББ - непонятно.
Интересно, если я открыл файл в ББ на запись и получил дамп исключений (по крайней мере, ББ память хотя бы должен отдать) - ББ его закроет? В Delphi это гарантируется.

Ой, ну тут каждый случай надо рассмотреть отдельно. Как с этим справится слой работы с файлами - лично я пока не знаю. А кстати, ведь ассерт ведь как-то вызывается. Это ведь не волшебство, поэтому до конца не известно, что его НЕЛЬЗЯ перехватить. Может, достаточно всего лишь написать свою реализацию "отлова ассерта" и подменить ею "стандартное вылетание окна trap". Я не интересовался пока. И кстати, любой пример который вы придумаете для того, чтобы "завалить" ББ вы сможете придумать и для теста вашего механизма. Надо только подумать. А "удар АССЕРТОМ по голове" - лучший стимулятор мозговой активности. :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 00:07 

Зарегистрирован: Вторник, 18 Сентябрь, 2007 08:48
Сообщения: 108
Assert - он и в Африке Assert. В Delphi тоже есть. :wink:
Из экстремального программирования пришло такое понятие, как test case. Тоже встроен в Delphi с недавних времен.
Только я бы не рискнул назвать Delphi сверхнадежным инструментом. 8)

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 00:22 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Иван Кузьмицкий писал(а):
Вот, типичный подход стандартного мышления. Задача формулируется и решается так, чтобы её на С++ было удобнее записать. Оберонщик даже не будет проверять координаты цели, если она принадлежит союзнику, и функция, возвращающая ошибку (кстати, с чего вдруг ошибка в штатной ситуации?) просто не нужна :)


Ну блин - что за гнилые придирки к примеру? :( Так дискуссии не получится. Я просто хотел показать, что возвращать в случае ошибки "абы что" в принципе неправильно. Будь то структура или даже просто int. Неужели это не очевидно? Причем здесь C++? Жаба/C# тоже позволяют писать в таком стиле. А вот C и Оберон не позволяют.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 00:39 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Edward Ivanov писал(а):
Из экстремального программирования пришло такое понятие, как test case.
И понятие, и направления не заслуживают того, чтобы на них обращали внимание.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 01:20 
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Edward Ivanov писал(а):
Все равно найдутся исключения из правил. Мы не можем предусмотреть все случаи.
Классический пример: пишем вывод в файл на дисковод А. Или на флешку. Юзер или выдергивает дискету раньше окончания времени записи, или забывает вставить (или попали на битые секторы). Помимо этого, могут быть аппаратные сбои. В ББ, скорее всего, получим дамп исключений, который юзеру не нужен (неинформативно для него + форма будет "грязной").
В Delphi (и в других языках) можно (и нужно) цивилизованно перехватить исключения и культурно доложить юзеру о внештатной ситуации. Почему этого нет в ББ - непонятно.

Если речь об общем перехвате совершенно неопознанных ситуаций, то это же делает сам ББ. А ББ написан сам на себе - значит, никто не мешает реагировать на это по-другому. На самом деле, даже стандартно есть две реализации дампа - DevDebug для разработчика и StdDebug для поставки с конечным приложением. Можно переиначить дамп под красивое окно с кнопкой "Отмылить разработчику". Я когда-то делал вариант с его сохранением в лог на диск.

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

Финализация при сборке мусора.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 01:24 
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Valery Solovey писал(а):
Edward Ivanov писал(а):
Из экстремального программирования пришло такое понятие, как test case.
И понятие, и направления не заслуживают того, чтобы на них обращали внимание.


Вы так считаете?
По-моему, идея постоянных итераций с уточнением требований хорошо коррелирует с Виртовским step-by-step refinement. + парное программирование иногда очень хорошо работает, проверено неоднократно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 02:35 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Пётр Кушнир писал(а):
Vlad писал(а):
Покажите в коде. Потому что я не вижу никакой разницы между i.ToString() и ToString(i).
Вы преимущественно кодите, или думаете?


А разве возможно делать первое без второго (индусов в расчет не берем)?

Пётр Кушнир писал(а):
Vlad писал(а):
Как это связано с невозможностью писать i.ToString()?
Математическая модель ничего не может писать. Даже теоретически.


И что? Такая запись обязывает математическую модель чего-то писать? А если вот так:
Код:
(new Integer(i)).ToString()

Полегчало? Весь этот сыр-бор только из-за более сокращнной (удобной) записи? Или еще что-то есть, чего от меня по-прежнему ускользает?

Пётр Кушнир писал(а):
Vlad писал(а):
- Смотри, не в обероне я могу понять код не прыгая в интерфейс, так гораздо быстрее- А я хочу прыгать в интерфейс
Вы это к чему? Я то в обероне. А вы нет. Я знаю наверняка. А вы гадаете(пусть и с большой вероятностью).


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

Пётр Кушнир писал(а):
Vlad писал(а):
- Смотри, не в обероне я могу понять смысл интерфейса не заглядывая в доку (которые если и бывают, то только у устоявшихся библиотек) или код- А я хочу смотреть доку и код
Получается, что Вы - БОГ. Или вам повезло.


Мне повезло, что я работаю с людьми, которые умеют использовать C++. Иначе я, возможно, уверовал бы в оберон и в сказки про то, что на нем нельзя писать неправильные программы :)

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


Ага. По вашей логике GC - это тоже сахар, потому что есть решение - вовремя удаляйте объекты и не используйте указатели на удаленные ;) Разница только в трудоемкости. Но и то и другое это ручной человеческий труд, по определению подверженный ошибкам.

Пётр Кушнир писал(а):
Vlad писал(а):
Мне все равно как писать i.ToString() или ToString(i), потому что и та и та запись читаются одинаково- Запись i.ToString() не может быть правильной потому что (далее куча абстрактных рассуждений про базовые типы, ООП и т.д.)
Всё таки вы наверное больше кодите чем думаете. Без обид.


Просто я не думаю закостенелыми обероновскими шаблонами (ах, у целого вызвали метод, тушите свет).

Vlad писал(а):
Если вы не проверили файл на read-only то это вы виноваты(кстати конкретно эта ситуация корректно обрабатывается в ББ ещё на уровне слоя работы с файлами).


Пойдем по кругу? Ладно. Я проверил файл на read-only и хочу вернуть код ошибки (потому что ASSERT, как мы только что выяснили уже не катит). Посмотрите еще раз свое сообщение:
viewtopic.php?p=17814#p17814
Итак, как же все-таки будем возвращать ошибку? Out параметром? А результатом функции будет мусор? Просто скажите "да" и покончим с этим :)

Пётр Кушнир писал(а):
Vlad писал(а):
Понаставьте ассертов. Протестируйте всесторонне.



Это вместо того, чтобы просто правильно написать и отдать все проверки компилятору? Спасибо, но похоже овчинка (даже в лице C++) стоит выделки.

Пётр Кушнир писал(а):
Ваши слова про студентов я могу принять на свой счёт, принять за неуважение, и страшно расстроиться. Я кажется ни разу не усомнился в вашем профессионализме.


Нет, про студентов это было не лично про вас. Это про наивных людей, верящих что 16 страниц документации за счет простоты дадут им больший контроль над ситуацией, чем более сложные инструменты. За простоту надо платить. В каком-то случае больше, в каком-то меньше. Непопулярность оберонов в мэйнстриме наглядное тому подтверждение.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 02:54 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Пётр Кушнир писал(а):
А кстати, ведь ассерт ведь как-то вызывается. Это ведь не волшебство, поэтому до конца не известно, что его НЕЛЬЗЯ перехватить. Может, достаточно всего лишь написать свою реализацию "отлова ассерта" и подменить ею "стандартное вылетание окна trap".


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 03:55 

Зарегистрирован: Среда, 17 Январь, 2007 03:59
Сообщения: 225
Vlad писал(а):
Непопулярность оберонов в мэйнстриме наглядное тому подтверждение.


Непопулярен потому, что 90% людей "программирующих" на мэйнстриме кидают кнопки на форму и это считается программированием.

Vlad писал(а):
Просто я не думаю закостенелыми обероновскими шаблонами


Вы думаете другими закостенелыми шаблонами.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 04:12 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Штирлиц писал(а):
Непопулярен потому, что 90% людей "программирующих" на мэйнстриме кидают кнопки на форму и это считается программированием.


Ну допустим. А 10% осташихся? :)

Штирлиц писал(а):
Vlad писал(а):
Просто я не думаю закостенелыми обероновскими шаблонами

Вы думаете другими закостенелыми шаблонами.


Можете меня уличить?

Штирлиц писал(а):
Альберт Эйнштейн: писал(а):
Все знают, что это невозможно. Но вот приходит невежда, которому это неизвестно - он-то и делает открытие.


И вот, в 2007 году в обероне появляются константные параметры, существующие в C++ уже 20 лет :) Глядишь, в 2010 появится объявление/инициализация, а в 2020 оберонщики откроют шаблоны :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 07:22 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1053
Откуда: Россия, Чебоксары
Пётр Кушнир писал(а):
Vlad писал(а):
Покажите в коде. Потому что я не вижу никакой разницы между i.ToString() и ToString(i).
Вы преимущественно кодите, или думаете?
Повторяю, что таки нет никакой разницы. Это всего лишь СИНТАКСИС.
А синтаксис ДОЛЖЕН вытекать из СЕМАНТИКИ.
А семантика ДОЛЖНА отражать ПРЕДСТАВЛЕНИЕ, УДОБНОЕ В ТЕКУЩЕМ КОНТЕКСТЕ.
Поэтому ДЛЯ РАЗРАБОТЧИКА (который ДУМАЕТ) разница таки есть! И она в том, что первый вариант АДЕКВАТЕН текущему контексту (выше я писал, почему я так считаю); а второй вариант - выбивается из этого контекста, что существенно ВЛИЯЕТ НА ЭРГОНОМИКУ.

Разницу в подходах чувствуете?

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 07:34 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Vlad писал(а):
И вот, в 2007 году в обероне появляются константные параметры, существующие в C++ уже 20 лет :) Глядишь, в 2010 появится объявление/инициализация, а в 2020 оберонщики откроют шаблоны :)

Ну вапще-то шаблоны в оберонах уже были, но так как их автор ушёл в Майкрософт, то это направление в оберонах как-то тихо-незаметно заглохло...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 08:11 

Зарегистрирован: Среда, 17 Январь, 2007 03:59
Сообщения: 225
Vlad писал(а):
Ну допустим. А 10% оставшихся? :)


10% оставшихся - выбирают тот инструмент, который как ОНИ СЧИТАЮТ позволит им решить
поставленную задачу. Выбор делается исходя из своих вкусов, привычек работы, стереотипа мышления и т.д.
В общем список может быть длинным.
Главное, чтобы ЗАДАЧА ДОЛЖНА БЫТЬ ВЫПОЛНЕНА, соблюдены сроки, качество и надежность.
Все зависит от того как программист проектирует, а не от того как лучше записать
так i.ToString() или так ToString(i) (мне лично тоже все равно, в обоих случаях понятно, что имелось ввиду).

Короче, все задачи которые решаются на С-подобных языках, можно решить и на Pascal-подобных.
И наоборот. На этом разгоравшуюся здесь дисскусию можно завершить, потому как все
упирается в личные предпочтения участников. А об этом можно рассуждать долго и упорно, переливать
воду из пустого в порожнее.


Последний раз редактировалось Штирлиц Среда, 06 Август, 2008 08:47, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 08:38 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Vlad писал(а):
И вот, в 2007 году в обероне появляются константные параметры, существующие в C++ уже 20 лет :) Глядишь, в 2010 появится объявление/инициализация, а в 2020 оберонщики откроют шаблоны :)

Константные параметры появились в КП.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 08:56 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Евгений Темиргалеев писал(а):
Константные параметры появились в КП.


Ой, погорячился, действительно в BB есть IN.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 09:01 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Vlad писал(а):
Иван Кузьмицкий писал(а):
Вот, типичный подход стандартного мышления. Задача формулируется и решается так, чтобы её на С++ было удобнее записать. Оберонщик даже не будет проверять координаты цели, если она принадлежит союзнику, и функция, возвращающая ошибку (кстати, с чего вдруг ошибка в штатной ситуации?) просто не нужна :)


Ну блин - что за гнилые придирки к примеру? :( Так дискуссии не получится. Я просто хотел показать, что возвращать в случае ошибки "абы что" в принципе неправильно. Будь то структура или даже просто int. Неужели это не очевидно? Причем здесь C++? Жаба/C# тоже позволяют писать в таком стиле. А вот C и Оберон не позволяют.


Конечно, не получается дискуссии. Потому что постоянно приводятся примеры, которые, в сути своей, порождаются семантикой одного ЯП, и эта семантика отличается от другого ЯП. Это сравнение красного с горячим. Вам удобнее красное, оно привычно, и мыслите Вы красными категориями. Ах, в Обероне нет шаблонов, нет того-сего. На то он и Оберон.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 09:40 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Штирлиц писал(а):
Короче, все задачи которые решаются на С-подобных языках, можно решить и на Pascal-подобных. И наоборот.

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

Если рассматривать программу как текст, то речь идёт о способе шифрации (кодирование!). Чтобы "нормально" закодировать решение задачи на не-обероне, нужна очень высокая квалификация как автора, так и читателя, дабы обмен информацией автор-текст-читатель всё-таки случился. "Кодирование" и декодирование задачи на обероне проще, т.к. сам язык кодирования, или нотация, проще.

Соответственно, усложнение нотации сокращает площадь записи решения (помогают "слова-кошельки", по Кэрроллу). Что местами может служить утешением баголовам.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 09:55 

Зарегистрирован: Вторник, 18 Сентябрь, 2007 08:48
Сообщения: 108
Еще один момент.
Что будет с Оберонами под Windows (инструменты фактически не развиваются) через 5..10 лет? В Windows сменится разрядность, выйдет пара версий - по крайней мере существующие приложения могут быть несовместимы.
Как правило, фирмы-разработчики инструментальных средств вывешивают роадмапы на будущее, дают комментарии, статьи, публикации, предоставляют бета и альфы-версии.
Программист при выборе инструмента сродни банкиру, думающему, куда вложить инвестиции. И тот, и другой хотят иметь уверенность в завтрашнем дне. Кому охота переносить наработки на другой язык?
Я здесь к тому, что раз Оберон как язык чрезвычано прос - таких Оберонов были бы легионы. Нет, никто не берется. Форт в разработке тоже очень прост - и их можно найти везде.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Среда, 06 Август, 2008 10:02 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Edward Ivanov писал(а):
Пётр Кушнир писал(а):
Вы не поняли сути. Если все ассерты пройдены, то значит ваш код корректно работает в любой проверенннной вами ситуации. Если вы не проверили файл на read-only то это вы виноваты(кстати конкретно эта ситуация корректно обрабатывается в ББ ещё на уровне слоя работы с файлами).


Все равно найдутся исключения из правил. Мы не можем предусмотреть все случаи.
Классический пример: пишем вывод в файл на дисковод А. Или на флешку. Юзер или выдергивает дискету раньше окончания времени записи, или забывает вставить (или попали на битые секторы). Помимо этого, могут быть аппаратные сбои. В ББ, скорее всего, получим дамп исключений, который юзеру не нужен (неинформативно для него + форма будет "грязной").
В Delphi (и в других языках) можно (и нужно) цивилизованно перехватить исключения и культурно доложить юзеру о внештатной ситуации. Почему этого нет в ББ - непонятно.


Как ни крути, а обработка исключений не помогает. Программы тупо зависают, тормозят, падают. Несмотря на. Даже самые именитые, типа Crystal Reports. Скажете, квалификация программистов не та? В чём же дело, блин. Язык позволяет красиво записывать решение, имеется обработка исключений - ан нет, где-то собака порылась.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 321 ]  На страницу Пред.  1 ... 8, 9, 10, 11, 12, 13, 14 ... 17  След.

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


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

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


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

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