Здравствуйте, Kluev, Вы писали:
K>Да нет просто перевод акада на дот-нет судя повсему оказался пустым трепом. Можешь глянуть к нему девелоперскую докцументацию. Мелкие макросы в нем можно и на ВБ писать, а для серьезных вещей: ObjectARX — набор плюсовых библиотек.
А что мне смотреть? Они его и обернули на МС++, о чем открыто и написали.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AVK>>>Вот поэтому мудрые мужи пользуют технологии, позволяющие гарантированно избежать подобных ситуаций K>>Мудрые мужи не вводятся в заблуждение гарантированными технологиями. Если плагины вызвает фунекции в последовательности которая не предусмотрена ядром, то оно может упасть очень легко.
AVK>Это уже ошибка другого рода, причем ошибка ядра. Опять же в грамотном ядре грохнется максимум обслуживающий клиента поток. Впрочем это я уже о серверах, а у тебя задачи другие.
K>> Хотя плагин будет живее всех живых. Оно не упадет только если все вызовы ядра атомарные.
AVK>Оно не упадет если любое внещнее воздействие не приведет ядро в неожиданное состояние. Это не так сложно обеспечить. Впрочем неважно — эта ошибка общая для любой технологии.
Реально в том же SolidWorks ядро вылетает просто на-ура из-за неправильной последовательности вызовов. Которая, кстати, не всегда документирована.
Думай, прежде чем родиться в этой сказочной стране!
(с) Антон Духовской
Здравствуйте, AndrewVK, Вы писали:
V>>Не наследующий IComponent не может визуально обрабатываться студией,
AVK>Блин, ну что за повальное маньячество — IComponent классом реализуется. AVK>Не студией, а конкретной реализацией дизайнера, я тебе даже больше скажу, если ты даже реализуешь его, дизайнер все равно с ним работать не будет. А вот к примеру PropertyGrid с успехом может отображать любой класс.
речь об экземпляре класса, вроде?
Если я наследую Component (реализующий IComponent), то могу кидать экземпляры этого класса на формы и компоненты, и только после этого выставлять значения с помощью PropertyGrid.
AVK>Ровно как я могу написать дизайнер, так же успешно без IComponent обходящийся.
Осталось узнать, как применить подобный дизайнер к независимой переменной на форме.
Здравствуйте, vdimas, Вы писали:
AVK>>Блин, ну что за повальное маньячество — IComponent классом реализуется. AVK>>Не студией, а конкретной реализацией дизайнера, я тебе даже больше скажу, если ты даже реализуешь его, дизайнер все равно с ним работать не будет. А вот к примеру PropertyGrid с успехом может отображать любой класс.
V>речь об экземпляре класса, вроде?
Есть разница?
V>Если я наследую Component (реализующий IComponent), то могу кидать экземпляры этого класса на формы и компоненты, и только после этого выставлять значения с помощью PropertyGrid.
Еще раз — это вполне конкретная реализация дизайнера. Никаких проблем написать свой вариант IComponent или вобще обойтись без каких либо интерфейсов нет.
AVK>>Ровно как я могу написать дизайнер, так же успешно без IComponent обходящийся. V>Осталось узнать, как применить подобный дизайнер к независимой переменной на форме.
Написать свой дизайнер форм и можно хоть обприменяться.
Здравствуйте, WFrag, Вы писали:
WF>Я не пытаюсь тебя убедить. Я пытаюсь тебе сказать, что ты не совсем прав. Конкретно я не согласен с вот этим вот сообщением:
WF>
Ядро собирается в одну большую махину без намеков на компоненты. Например, драйвер можно выдрать из ядра только если поставить дефан в исходниках и перекомпилировать ядро.
WF>Без всяких перекомпиляций я выгрузил из ядра практически все — видео, звук, модем, сеть, USB-устройства, BlueTooth stack, NTFS, FAT32, и.т.д. Вполне модульно
Можно подробности? Даже в отдельной ветке?
Здравствуйте, WFrag, Вы писали:
G>> Можно подробности? Даже в отдельной ветке? WF>А что именно интересует?
Интересует способ выгрузки "лишних" модулей из монолитного ядра без перекомпиляции. Или имеется ввиду
указать на выгружаемость этих модулей при компиляции ядра
Здравствуйте, Аноним, Вы писали:
А> Приятель работает в проекте, где все коспоненты сложной распределённой системы сделаны как COM'ы на С++ и все это хозяйство объединяется через VBScript. Спорили с ним о такой архитектуре ... Многоуважаемый ALL, просьба высказывать что вы думаете о таком способе конструирования сложных систем, не слишком ли сложная получается инфраструктура, не устарел ли сейчас такой подход ?
Если система справляется со своими задачами, а затраты на разработку / поддержку не высоки, значит подход оправдан. А в отрыве от задач / затратности — подход производит скорее негативное впечатление. Плюс подхода — слабая зависимость между частями системы (компонентами); простота модернизации бизнес логики (редактируя скрипты). Минусы — сложность разработки СОМ-компонентов; ограниченность языка VBScript; медленность его же (если это критично); если скрипты не хранятся в одном экземпляре, то необходимость менять скрипты при изменениях.
Здравствуйте, glyph, Вы писали:
G>>> Можно подробности? Даже в отдельной ветке? WF>>А что именно интересует? G> Интересует способ выгрузки "лишних" модулей из монолитного ядра без перекомпиляции. Или имеется ввиду G>
указать на выгружаемость этих модулей при компиляции ядра
?
Да просто при сборке ядра все, что можно, в виде модулей собирается (например, в Debian стандартное ядро примерно так и собрано). Естественно, если собрать ядро одним монолитом, то выгрузить из него ничего не удастся — но, в таком случае, как говорится, что хотели, то и получили.
