Здравствуйте, Cyberax, Вы писали:
>> В Блэкбоксе нет потоков и активных объектов. C>Ээээ? А что там есть?
В самом Блэкбоксе, как я уже тут писал, многозадачность кооперативная. Делаете свою службу, регистрируете её в Блэкбоксе и он её периодически дёргает из своего главного цикла в окружении системной ловушки.
А вообще, есть свободный доступ к WinAPI, но это уже из разряда: "Сделай сам!". Сами делаете свои потоки, сами в них и исключения ловите с помощью соответствующих WinAPI-шных функций.
Сейчас Oberon Microsystems делает следующую версию BlackBox. Когда выйдет, посмотрим что они там наворотили. Может и потоки прикрутят.
Сергей Губанов wrote: > В самом Блэкбоксе, как я уже тут писал, многозадачность кооперативная. > Делаете свою службу, регистрируете её в Блэкбоксе и он её периодически > дёргает из своего главного цикла в окружении системной ловушки.
Уууууу...... Это "ОС нового поколения"????
> А вообще, есть свободный доступ к WinAPI, но это уже из разряда: "Сделай > сам!". Сами делаете свои потоки, сами в них и исключения ловите с > помощью соответствующих WinAPI-шных функций.
Ага, еще надо самому написать компилятор и спаять компьютер.
Здравствуйте, Cyberax, Вы писали:
C>Уууууу...... Это "ОС нового поколения"????
BlackBox — это не ОС. ОС нового поколения — это BlueBottle. Кстати, на счет Блюботлины — ходят слухи, что скоро выйдет новая Рождественская версия (как в прошлом году).
Здравствуйте, Mamut, Вы писали:
M>Так мало, что 8 световых минут, так еще и на оборудовании стоимостью в н мегабаксов
В общем, хай-тэк-экстёмъ!
Внеполовой сэкс с латентностью в ощущениях 8 минут и постоянным адриналиновым ознобом от осозднания, что любое неверное движение может обойтись начальству в Н мегабаксов и уж тогда грубого анального сексе не избежать.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Почему нельзя отключать ASSERT-ы в релизе
СГ>В модульных (компонентных) расширяемых системах отключать ASSERT-ы в «релизе» нельзя. Это связано с тем, что для Вас-то, быть может эта система «релизная», а вот для клиента, который пишет для неё (и отлаживает) свои компоненты, она никакая не «релизная».
Ок, решил перечитать исходный текст, потому что возникла мысль. Если авторы блакбокса не рекомендуют отключать асерты в релизе , почему вообще они предусмотрели такое отключение ? Выделенный текст — мои коментарии.
СГ>Фрагмент из хелпа к BlackBox:
СГ>
СГ>Хорошо известно, что определение ошибки тем более затруднено и дороже обходится, чем позже она обнаруживается, т.е. чем дальше разнесены источник и его эффекты. Это позволяет сформулировать правило:
СГ>Позволяйте ошибкам заявлять о себе как можно раньше. Совершенно согласен.
СГ>В компонентно-ориентированных системах дефекты всегда должны содержаться в их компонентах
СГ>и не распространяться на другие компоненты. Другие компоненты даже могут быть черными ящиками и не иметь исходных текстов, что делает отладку на уровне исходных текстов невозможной. Более того, поток передачи управления в больших объектно-ориентированных программных системах настолько запутанный, что нереально, и это пустая трата времени, проследить его за пределами границ компонентов для целей отладки.
СГ>Единственный жизнеспособный отладочный подход есть проектирование всего, от языка программирования до библиотек, до компонентов и приложений, используя оборонительный стиль программирования. В частности, входные точки в компоненты (вызовы процедур/методов) должны останавливать исполнение, если их предусловия не обеспечены:
СГ>Никогда не позволяйте ошибкам проникать сквозь границы компонентов. Совершенно верно, оборонительный стиль , это предполагать что на вход могут дать ЛЮБЫЕ данные и мы обязанны их обработать и немедленно сообщить если данные были некоректны (ексепшеном или кодом возврата в релизе и дополнительно асертом в дебаге).
СГ>К счастью, большинство проверок предусловий недорого и поэтому их отключение при исполнении не имеет смысла. Это важно, поскольку в компонентно-ориентированной системе проверки периода исполнения не могут быть выключены в конечной (готовой) системе, поэтому разрабатываемая и готовая системы не различаются. На практике большинство компонентов уже отлажено в режиме черного ящика ("продукция"), а другие отлаживаются в режиме белого ящика. Готовые компоненты должны взаимодействовать, чтобы доказать приверженность сформулированному выше правилу, которое означает «никогда не отключать проверки периода исполнения».
А теперь позвольте спросить , где тут сказанно что проверки во время выполнения рекомендованно осуществлять асертами ? Может документация неправильно понята ? Можно кусок текста из которого видно что речь идет об асертах ?
Тут высказывалась мысль что асерты это ШТАТНОЕ средство обработки ошибок в рантайме в блак боксе , по косвеннм признакам я начинаю в этом сомневаться ....
Здравствуйте, minorlogic, Вы писали:
M>Ок, решил перечитать исходный текст, потому что возникла мысль. Если авторы блакбокса не рекомендуют отключать асерты в релизе , почему вообще они предусмотрели такое отключение?
Дык, они и не предусмотрели возможность его отключения. Отключать нельзя, а раз нельзя, то и возможности отключить — нету.
M>А теперь позвольте спросить , где тут сказанно что проверки во время выполнения рекомендованно осуществлять асертами ? Может документация неправильно понята ? Можно кусок текста из которого видно что речь идет об асертах ?
Э-э-э, это моя вина. Я здесь разместил только фрагмент текста хелпа.
M>Тут высказывалась мысль что асерты это ШТАТНОЕ средство обработки ошибок в рантайме в блак боксе , по косвеннм признакам я начинаю в этом сомневаться ....
Не обработки ошибок, а сообщения о них. Обрабатывать ошибки будет потом программист.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, minorlogic, Вы писали:
M>>Ок, решил перечитать исходный текст, потому что возникла мысль. Если авторы блакбокса не рекомендуют отключать асерты в релизе , почему вообще они предусмотрели такое отключение?
СГ>Дык, они и не предусмотрели возможность его отключения. Отключать нельзя, а раз нельзя, то и возможности отключить — нету.
Э..... ну тогда название темы надо переписать
Почему нельзя отключать ASSERT-ы в релизе — потому что НЕЛЬЗЯ (нету возможности)
Здравствуйте, minorlogic, Вы писали:
M>Э..... ну тогда название темы надо переписать M>Почему нельзя отключать ASSERT-ы в релизе — потому что НЕЛЬЗЯ (нету возможности)
Ещё вариант: "Сделали НЕЛЬЗЯ потому что — нельзя!"
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, minorlogic, Вы писали:
M>>Э..... ну тогда название темы надо переписать M>>Почему нельзя отключать ASSERT-ы в релизе — потому что НЕЛЬЗЯ (нету возможности)
СГ>Ещё вариант: "Сделали НЕЛЬЗЯ потому что — нельзя!"
Здравствуйте, Сергей Губанов, Вы писали:
M>>Э..... ну тогда название темы надо переписать M>>Почему нельзя отключать ASSERT-ы в релизе — потому что НЕЛЬЗЯ (нету возможности) СГ>Ещё вариант: "Сделали НЕЛЬЗЯ потому что — нельзя!"
Это ж сколько можно научных статей по этому принципу написать?
"Почему на С++ нельзя делать вставки на Паскале"
"Почему нельзя переопределять встроенные типы"
"Почему пивную кружку надо держать донышком вниз"
...
