Здравствуйте, Пацак, Вы писали:
П>Ма-а-аленькая тонкость. Если в моем коде maxLevel изначально = 0 (звук выключен), то цикл не выполнится ни разу. В вашем — выполнится один раз.
А если повнимательнее посмотреть на мой код
step := GetStep();
IF (step > 0) & (maxLevel > i0)THEN
i := i0;
REPEAT SoundLevel(i); INC(i, step) UNTIL (i >= maxLevel) OR ManualInterrupt()
END
и увидеть сделанную в начале проверку "maxLevel > i0", то цикл тоже не выполнится ни разу.
Здравствуйте, Сергей Губанов, Вы писали:
П>>после окончания (не суть важно — "завершения" или "прерывания") СГ>В своем сообщении я показал как раз обратное — важно!
Примеры (в частности последний, с вызовом функции в условии цикла) так и будут игнорироваться?
Минус вам за это.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>и увидеть сделанную в начале проверку "maxLevel > i0", то цикл тоже не выполнится ни разу.
Да, виноват, не заметил. Кстати прекрасная иллюстрация к читабельности обероновского кода: в C++овском for это синтактически подразумевалось алгоритмом работы самого цикла и лишний огород из IFов городить не пришлось бы. Здесь — увы, и не пахнет ни лаконизмом, ни удобством.
Здравствуйте, Сергей Губанов, Вы писали:
SJA>>Да не. break прерывает, а не завершает. Он так и переводится — прервать.
СГ>Термины "завершение цикла" и "прерывание цикла" я полностью объяснил в своем сообщении
Я тоже уже объяснял, что while это синтаксический сахар над
LOOP
WHILE x DO
END(* A *)END
Более того, С-ниый while не даёт программисту вписывать код в точку A. Это предотвращает ошибки. Почему в обероне так не сделано — мне не понятно. Зачем писать лишие LOOP-ы, причём с позможностью ошибится и вставить код в точку A. при этом, если цикл прервётся, то этот код не будет выполнен ! C-шный while такого не позволит ! C-шный while защищает программиста от ошибок, в отличии от Обероновского !
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Mr. None, Вы писали:
MN>>>>Вы русский язык понимаете вообще? Вам были заданы простейшие вопросы, вы можете на них ответить предельно просто: да или нет.
СГ>>>Да.
СГ>>>(В смысле русский язык понимаю)
MN>>Вы как всегда в своём амплуа. Если ответы на вопросы угрожают вашей теории, вы на них не отвечаете... Вобщем продолжать дискуссию считаю абсолютно бесполезно. Потому что вы не умеете слушать и отвечать на вопросы аппонента. А всё остальное смысла не имеет.
СГ>Я просто не отвечаю на вопросы ответы на которые и так очевидны
Т.е. вы решили, что только ответ на вопрос
Здравствуйте, Sergey J. A., Вы писали:
SJA>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Здравствуйте, Mr. None, Вы писали:
MN>>>>>Вы русский язык понимаете вообще? Вам были заданы простейшие вопросы, вы можете на них ответить предельно просто: да или нет.
СГ>>>>Да.
СГ>>>>(В смысле русский язык понимаю)
MN>>>Вы как всегда в своём амплуа. Если ответы на вопросы угрожают вашей теории, вы на них не отвечаете... Вобщем продолжать дискуссию считаю абсолютно бесполезно. Потому что вы не умеете слушать и отвечать на вопросы аппонента. А всё остальное смысла не имеет.
СГ>>Я просто не отвечаю на вопросы ответы на которые и так очевидны SJA>Т.е. вы решили, что только ответ на вопрос SJA>
Вы русский язык понимаете вообще?
не очевиден ?
Ну формально он прав... из остальных постов сделать правильный вывод насчёт ответа на этот вопрос весьма сложно...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Сергей Губанов, Вы писали:
MN>>Вы как всегда в своём амплуа. Если ответы на вопросы угрожают вашей теории, вы на них не отвечаете... Вобщем продолжать дискуссию считаю абсолютно бесполезно. Потому что вы не умеете слушать и отвечать на вопросы аппонента. А всё остальное смысла не имеет.
СГ>Я просто не отвечаю на вопросы ответы на которые и так очевидны, за исключением некоторых случаев (например сейчас).
Вот вы не поверите, но в отношении вас ответы на обозначеные вопросы для меня не очевидны. Если бы они были очевидны и совпадали бы с моими, то этого флейма просто не было бы. Поэтому я и хочу услышать их, чтобы понять ваш ход мыслей и высказать своё мнение, либо пракратить спор, как бессмысленный (с фанатиками спорить бесполезно).
Сударь, пусть вам не кажется, что эти вопросы — попытка загнать вас в дискуссионную ловушку, дабы поставить МАТ. Это именно так и есть. А то, что вы не хотите на них отвечать — так это как раз признак того, что вы начали это осознавать и выкинули белый флаг раньше времени, точнее сбежали с поля боя. Поэтому всё равно — это моя победа. Если хотите продолжить дискуссию, то можем откатить один ход и вернуться к вопросам (см. парой постов выше). Я жду вашего ответа до завтрашнего утра, если вы так и не ответите на те 3 вопроса буду считать вас окончательно поверженным.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Статья — редкостный бред. Автор либо не понимает, чем стиль записи отличается от синтаксиса, либо занимается сознательной подтасовкой.
СГ>Программа записанная в Си-образном синтаксисе содержит в разы, а не на проценты больше лексем и строчек кода чем это реально необходимо. Спрашивается, и как долго этот синтаксис еще будет существовать?
Здравствуйте, eandr, Вы писали:
E>Статья — редкостный бред. Автор либо не понимает, чем стиль записи отличается от синтаксиса, либо занимается сознательной подтасовкой.
А теперь внимательно смотрим на название форума...
и заодно, на количество ответов. В общем, опоздали, батенька!
Здравствуйте, Sinclair, Вы писали:
S>Потому, что антонимом к DestroyInstance является ConstructInstance.
Антоним для практически любого слова, если он существует, не единственный. Так что то, что вы написали — правда, но не вся правда. Также антонимами могут быть CreateInstance, MakeInstance, BuildInstance и еще куча других.
F>>И "паттерн" использования COM-объекта чаще всего именно такой: создать по CreateInstance(), поработать с ним и освободить по Release(). S>А какое отношение имеет паттерн использования COM объекта?
Потому что программист пишет именно в терминах этого паттерна (не всегда, конечно).
S>В него обычно входит еще много других вызовов. У CreateInstance пары нет. S>Теоретически, можно считать, что есть приватная DeleteInstance, которая вызывается из Release при достижении нулевого количества ссылок.
Ну вот видите, сами нашли ответ.
Вообще, все эти рассуждения никак не опровергают тех тезисов, которые я здесь продвигаю, и которые повторю еще раз:
1. Действие должно обозначаться глаголом.
2. Противоположные по смыслу действия должны обозначаться противоположными по смыслу словами (одной и той же грамматической категории).
Найдется ли смелый человек, который прямо выступит против этих тезисов, без увода разговора в сторону? Например, прямо скажет: тезис 1 неправильный, действие может обозначаться как угодно, например, существительным, наречием, предлогом и т.п. (Естественно, весь разговор ведется в рамках языков программирования). Или скажет про тезис 2: он неверный, противоположные действия могут обозначаться синонимами (создать объект с помощью ключевого слова yes, а удалить — ключевым словом of_course).
Здравствуйте, Amidlokos, Вы писали:
F>>Что парной к Release() является AddRef() я, естественно, знаю. Но ведь CreateInstance() вызывает AddRef(), разве нет? И "паттерн" использования COM-объекта чаще всего именно такой: создать по CreateInstance(), поработать с ним и освободить по Release().
A>Спасибо хоть "чаще всего", а не "всегда"...
Только ситхи возводят все в абсолют...
A>Не знаю как у кого, но лично мне практически при каждом серьёзном использовании COM приходится несколько раз ручками вызывать AddRef() при передаче указателей на COM-объекты. Конечно, это не слишком актуально для "одноразовых" объектов, но когда объект глобальный и длительного использования — приходится для надёжности. Только так есть гарантия, что все экземпляры классов и все потоки не получат "мусор", уже удалённый кем-то.
Как-то звучит подозрительно, видимо, я не очень хорошо понимаю? Что значит "для надежности"? А присваивание по два раза для надежности вы не пишете?
A>А в конце работы, кстати, в отладочной версии всегда ставлю проверку и вывод значения, возвращаемого Release(). Вот такое оно бесполезное.
Здравствуйте, Сергей Губанов, Вы писали:
E>>Абсолютная глупость.
СГ>Однако же Вы зарегистрировались на этом форуме и первое Ваше сообщение посвятили именно этой абсолютной глупости. Задело за живое, я полагаю...
Скорее всего, твоё эссе уже стало достоянием интернета. Кто-то где-то на полном серьёзе ссылочку тиснул, вот реакция и случилась
СГ>>Однако же Вы зарегистрировались на этом форуме и первое Ваше сообщение посвятили именно этой абсолютной глупости. Задело за живое, я полагаю...
К>Скорее всего, твоё эссе уже стало достоянием интернета. Кто-то где-то на полном серьёзе ссылочку тиснул, вот реакция и случилась
Это, наверное, как и с приснопамятным распараллеливанием кода на геймдеве (или где он там был). Кстати, а Оберон поддерживает распараллеливание кода?
Здравствуйте, Mr. None, Вы писали:
J>>Потому что этот класс — не POD-тип, так как имеет определенный пользователем конструктор. MN>Не конструктор, а деструктор ;) . Наличие конструктора не превращает класс в POD-тип:
Ты хотел сказать, в не-POD-тип? :)
MN>Стандарт, 9.4
MN>...A POD-struct is an aggregate class that has no nonstatic data members of type pointer to member, non-POD-struct,
MN>non-POD-union (or array of such types) or reference, and has no userdefined copy assignment operator and no userdefined destructor...
Превращает.
Стандарт, 8.5.1/1
An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected
non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3).
Наткнулся на следующее выражение в книге "Прорри Гаттер. Двенадцать повигов Сена Аесли. Подвиги 9-12":
Я люблю вовсе не расчеты, а рассуждения. Настоящей, чистой теории не нужны ни расчеты, ни наблюдения, ни подтверждения опытными фактами. А самое главное – у теории не должно быть практических применений, иначе она не будет теорией
Эту фразу можно применить к доброй половине высказываний в этой ветке
Здравствуйте, Mamut, Вы писали:
M>Кстати, а Оберон поддерживает распараллеливание кода?
Несчастный, да как ты посмел поставить такую скверну рядом со священным именем Оберона?!! Конечно же нет, ведь при параллелизме невозможно обеспечить формального выполнения ложности условия продолжения цикла по его завершении! Как же тогда проводить формальную верификацию программ?
Ну формально он прав... из остальных постов сделать правильный вывод насчёт ответа на этот вопрос весьма сложно... 
.
Перекуём баги на фичи!
