Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, VladD2, Вы писали:
VD>>Господи, какой бред? Ты файлы когда нибудь открывал? А на 0 делить у тебя никогда не приходилось?
СГ>Естественно, файлы открывал, а что?
СГ>Естественно, на 0 не делил, я так делал: IF f > EPSILON THEN a := b/f; ...
При работе с плавающей арифметикой избежать возможности возникновения исключений по переполнению невозможно в принципе в любых мало-мальски серьёзных задачах. Так что изображённый выше подход не катит совершенно -- мало того, что он черезвычайно громоздкий, так он ещё и не решает проблемы. Без исключений тут не обойдешься.
Здравствуйте, Клапауций, Вы писали:
К>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>О как! Типа как в детском саду, да?
СГ>>BlackBox (Component Pascal): СГ>>
СГ>>MODULE TestTest;
СГ>> IMPORT StdLog, Files;
СГ>> PROCEDURE Test* ();
СГ>> VAR L: Files.Locator; f: Files.File; r: Files.Reader; b: BYTE;
СГ>> BEGIN
СГ>> L := Files.dir.This("C:\");
СГ>> IF L # NIL THEN
СГ>> f := Files.dir.Old(L, "New Text Document.txt", FALSE);
СГ>> IF f # NIL THEN
СГ>> r := f.NewReader(NIL);
СГ>> IF r # NIL THEN
СГ>> WHILE ~r.eof DO r.ReadByte(b); StdLog.Char(CHR(b)) END
СГ>> END;
СГ>> f.Close();
СГ>> END
СГ>> END
СГ>> END Test;
СГ>>END TestTest.
СГ>>
К>И типа этот человек будет говорить о программировании без ошибок ??? К>Привёл пример и на тебе. На eof нужно было проверять после чтения, иначе появляется дополнительный байт в конце, что и можно наблюдать.
Мало того. Все проблемы с чтением и открытием файла лихо игнорируются и в итоге если что случится, то ни единого писка от этого кода не услышишь. В общем, ламерство навязываемое "самым надежным языком"
Для примера тот же код на C#:
using System;
using System.IO;
using System.Text;
class Program
{
static void Main(string[] args)
{
try
{
string path = args[0];
using (StreamReader reader = new StreamReader(path, Encoding.Default))
{
Console.WriteLine(reader.ReadToEnd());
} // вот здесь файл будет закрыт даже если было исключение.
}
catch (IndexOutOfRangeException)
{ // Суда прийдем если args не содержит аргументов
Console.WriteLine("Enter path to file, lease.");
}
catch (Exception ex)
{ // А сюда в случае любой ошибки. Так что если файла нет или еще что,
// то незабудем сказать об этом пользователю.
Console.WriteLine(ex.Message);
}
}
}
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Здравствуйте, Клапауций, Вы писали:
К>>>Привёл пример и на тебе. На eof нужно было проверять после чтения, иначе появляется дополнительный байт в конце, что и можно наблюдать.
СГ>>Прости, ошибся. Действительно, на 1 байт больше читается.
СГ>Переделал:
...
А теперь сравни с Шарпом ради хохмы :
using (StreamReader reader = new StreamReader(path, Encoding.Default))
{
Console.WriteLine(reader.ReadToEnd());
} // вот здесь файл будет закрыт даже если было исключение.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
СГ>>Прости, ошибся. Действительно, на 1 байт больше читается. WH>О чем тебе уже все много раз говорили... Людям свойственно ошибаться... И как следствие нужен отладчик и тд и тп...
Да ладно уж отладчик. Хотя бы исключения и средства их обработки. А то ж смешно смотреть на супер надежный язык выподающий в осадок от первого отсуствующего файла или деления на 0 в совершенно несущесвтенном месте.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Говоря по-русски: чтобы предотвратить разбухание кода вводится частичная специализация для того случая, когда std::vector специализируется указателем. Оптимизация, так сказать.
СтлПорт рассчитан на компиляцию на самых разных компиляторах. Для VC 7+ и Intel C++ подобная фигня не нужна.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали: СГ>В том случае если динамический тип p не CorrectPtr, выполнение будет автоматически остановлено точно также как и при использовании ASSERT().
Ух как зашибись. То есть опять — устойчивость системы гарантируется через test coverage и прочие пироги; т.е. путем геморроя. Намекну, что в С++, С# 2.0 и Java 1.5 в случае, если статический тип не CorrectPtr, то компиляция будет автоматически остановлена и сообщение об ошибке попадет сразу тому, кто ее сделал и может быстро исправить. А не в QA отдел и уж тем более не в Support.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Лучше по делу чего уного сказал бы.
Так все что по делу игнорируется.
Замечу, однако, что закрывать файлы в Обероне нет необходимости.
Здравствуйте, Трурль, Вы писали:
VD>>Лучше по делу чего уного сказал бы. Т>Так все что по делу игнорируется. Т>Замечу, однако, что закрывать файлы в Обероне нет необходимости.
Нутко, подробнее пжалста. Почему не нужно ?
А я попробую заглючить это дело....
VD> catch (IndexOutOfRangeException)
VD> { // Суда прийдем если args не содержит аргументов
VD> Console.WriteLine("Enter path to file, lease.");
VD> }
VD>
Обратите внимание на отсутствие логической связи между IndexOutOfRangeException и
"если args не содержит аргументов". VD>
VD> catch (Exception ex)
VD> { // А сюда в случае любой ошибки. Так что если файла нет или еще что,
VD> // то незабудем сказать об этом пользователю.
VD> Console.WriteLine(ex.Message);
VD> }
VD>
Если файла нет или еще что, то система сама скажет об этом пользователю.
Здравствуйте, Клапауций, Вы писали:
Т>>Замечу, однако, что закрывать файлы в Обероне нет необходимости.
К>Нутко, подробнее пжалста. Почему не нужно ? К>А я попробую заглючить это дело....
Потому что они закрываются автоматически.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Клапауций, Вы писали:
Т>>>Замечу, однако, что закрывать файлы в Обероне нет необходимости.
К>>Нутко, подробнее пжалста. Почему не нужно ? К>>А я попробую заглючить это дело.... Т>Потому что они закрываются автоматически.
Здравствуйте, Трурль, Вы писали:
VD>>Лучше по делу чего уного сказал бы. Т>Так все что по делу игнорируется. Т>Замечу, однако, что закрывать файлы в Обероне нет необходимости.
Ужасть какая. Вот вам простейшая программа:
MODULE A11;
IMPORT StdLog, Files;
PROCEDURE AddSymbol();
VAR locator: Files.Locator; file: Files.File; writter: Files.Writer;
BEGIN
locator := Files.dir.This("C:\");
file := Files.dir.Old(locator, "New.txt", FALSE);
writter := file.NewWriter(NIL);
writter.WriteByte(33);
END AddSymbol;
PROCEDURE T*();
BEGIN
StdLog.String("Cool Program started !");
StdLog.Ln();
AddSymbol();
END T;
END A11.
Я не закрыл файл.
Результаты:
После первого запуска файл остался залоченным и в винде его открыть не удаётся.
Второй запуск выбрасывает исключение.
З.Ы. А исключения в BlackBox что нельзя обработать ??? Я сколько не искал — ничего такого не нашёл....
Здравствуйте, FR, Вы писали:
FR>То есть на отрицательные числа делить нельзя? FR>Что то не верится мне что ты, как недавно утверждал можешь писать безошибочный код
Ну, в теории — можно. В общем, это по-прежнему доказывает, что Оберон представляет собой типичный случай решения для сферического коня в вакууме. И собственно, все его сравнения с реальными методиками суть попытки доказать что его конь круглее, а вакуум — чище.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Ужасть какая. Вот вам простейшая программа:
[] SJA>Я не закрыл файл.
SJA>Результаты: SJA>После первого запуска файл остался залоченным и в винде его открыть не удаётся. SJA>Второй запуск выбрасывает исключение.
Я имел ввиду обычный Оберон, там файлы не блокируются. Как-то не учел, что здесь битва вокруг ящика идет. В блекбоксе по сути то же самое, при использовании разделяемого доступа. А если открыть файл для монопольного доступа, то надо, конечно закрывать или, по крайней мере, не отрывать его же второй раз.
SJA>З.Ы. А исключения в BlackBox что нельзя обработать ??? Я сколько не искал — ничего такого не нашёл....
Здравствуйте, Трурль, Вы писали:
Т>Я имел ввиду обычный Оберон, там файлы не блокируются.
Да... Наверное удобно писать операционные системы на языке, который на может открыть файл эксклюзивно.....
Или есть там какие-то подпорки и костыли ?
Здравствуйте, Sinclair, Вы писали:
S>Ух как зашибись. То есть опять — устойчивость системы гарантируется через test coverage и прочие пироги; т.е. путем геморроя. Намекну, что в С++, С# 2.0 и Java 1.5 в случае, если статический тип не CorrectPtr, то компиляция будет автоматически остановлена и сообщение об ошибке попадет сразу тому, кто ее сделал и может быстро исправить. А не в QA отдел и уж тем более не в Support.
Естественно, если процедура написана так: PROCEDURE f(p: CorrectPtr); то скопилировать модуль можно будет только если статический тип аргумента будет CorrectPtr.
Однако, мы тут обсуждали обобщенные контейнеры работающие с типом ANYPTR, то есть когда процедура написана так: PROCEDURE f(p: ANYPTR);