Здравствуйте, Kluev, Вы писали:

AVK>>Но весьма часто. Design-time вобще без этого невозможен.
K>design time как правило нужен только для UI,

Отнюдь. Просто для UI без него вобще жить очень сложно.

K> а возьми к примеру АПИ какой нить системы типа PRO/E, acad или solidworks.

Не имею честь быть знакомым.

AVK>>Грабли в том что несоответствие форматов VMT порушит твое приложение. Причем причину ты будешь искать долго.

K>Не порушит т.к. компилер-то один юзается, о чем и сказано в доках.

Ты можешь в доках что угодно указывать — это тебя не спасет.

K> А кто не понял, я не виноват.

Вот вот.

AVK>>А если удалить?
K>А зачем?

А вот идиот какой код попортил.

K> Даже если и удалишь то обнаружишь очень быстро.

Вот это вряд ли.

K> Системы выплюнет сообщение что функция в DLL не найдена.

Или из-за несовпадения размеров VMT будет проход по памяти.

K>>> А в классах где есть наследование можно про запас обьявить штук пять-десять виртуальных функций про запас, на редкий случай расширения.
AVK>>Самому не смешно?

K>А чего смеятся, все так и делают.



K> Посмотри например GTK, там честенько резервируют.

Их проблемы.

K> Мудрые мужи знают что живут в мире где не может быть идеальных решений.

Мудрые мужи при наличии более надежных и удобных решений используют их, а не продолжают жрать кактус.

Здравствуйте, Aviator, Вы писали:

K>>Это типичные заблуждения начинающего, об исходниках, удобстве и "сделал и забыл".
A> Даааааааа ?? Да что вы говорите ... Лично знаю контору где сделал компоненту, сгенерил длл-ку, свалил в общее хранилище и всё, с чужим кодом вообще никто не работает почти, то что сделано то рабоает, что работает плохо переписывается полностью, вся система состоит из кучи небольших длл-лек.
Ты лично сколько таких длл-лек написал? Что они делали? И как вообще удобно писалось?

K>>Полный отстой. Это даже хуже чем СОМ
A> Ну если руки кривые то всё полный отстой . Вот экспорт классов — это уж точняк редкостный изврат и в принципе не может быть хорошим решением, хотя бы потому что жёстко привязано к конкретному компилятору.

А то что ты написал тоже привязано к конкретному компилятору т.к. нет гарантии что формат VFT совпадет. Более того даже если он случайно совпадет, то dynamic_cast, typeid и exceptions точно не совпадут, так что толку от такого подхода ноль. Никаких преимуществ по стравнению с экспортом классов, только лишний слой гемора добавлен.

A>... Кстати, чем же полный отстой фабрика классов, можно узнать ?
Я уже писал.

A>ЗЫ Разумные люди пытаются использовать то хорошее что есть в каждом подходе и находить компоромиссные решения, а не придумывать принципы на пустом месте.

Вот и я о том же. Надо писать просто и грамотно, а не придумывать лишний слой гемороя на пустом месте. Прочитай еще раз мои посты, авось поймешь. А то что ты предлагаешь, это действительно полный гемор, с которым народ сначала связывается, а потом плюется.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Kluev, Вы писали:

AVK>>>Но весьма часто. Design-time вобще без этого невозможен.
K>>design time как правило нужен только для UI,

AVK>Отнюдь. Просто для UI без него вобще жить очень сложно.

K>> а возьми к примеру АПИ какой нить системы типа PRO/E, acad или solidworks.

AVK>Не имею честь быть знакомым.

AVK>>>Грабли в том что несоответствие форматов VMT порушит твое приложение. Причем причину ты будешь искать долго.

K>>Не порушит т.к. компилер-то один юзается, о чем и сказано в доках.

AVK>Ты можешь в доках что угодно указывать — это тебя не спасет.

K>> А кто не понял, я не виноват.
AVK>Вот вот.

Почему же вот-вот? Насколько я знаю Борланд к примеру в микросовтовских либах только extern "С" понимает. Так что даже скомпилить не получится. А у кого получилось, тот наверное знает что делает.

AVK>>>А если удалить?
K>>А зачем?

AVK>А вот идиот какой код попортил.
Когда идиот портит код тогда уже мало что поможет. Идиотов только на разработку плагинов надо бросать, core — это для мудрых мужей.

K>> Даже если и удалишь то обнаружишь очень быстро.
AVK>Вот это вряд ли.

Намек понят?

AVK>Или из-за несовпадения размеров VMT будет проход по памяти.
Не будет. Размер VMT не меняется. Т.к. виртуальными при использовании P-Impl нужно делать только колбеки типа onMessage которые в дочерних классах переопределяются и как правило число таких функций не увеличивается, есть и заглушки для расширения, и одна универсальная на случай ядерной войны. А входящие можно обьявлять не виртуальными, а виртуальность обеспечивается уже в реализации P-Impl

K>> Посмотри например GTK, там честенько резервируют.
AVK>Их проблемы.
Проблемы там есть толко в другом. С этом как раз проблем нет.

AVK>Мудрые мужи при наличии более надежных и удобных решений используют их, а не продолжают жрать кактус.

Ага, только эти надежные и удобные решения не применимы в проектах где 800 мегов памяти требуется для расчета. Только законченный дурак будет писать тяжелые CAD/CAM/САЕ системы на яве или шарпе.

Здравствуйте, Kluev, Вы писали:

K>>>А зачем?
AVK>>А вот идиот какой код попортил.
K>Когда идиот портит код тогда уже мало что поможет. Идиотов только на разработку плагинов надо бросать, core — это для мудрых мужей.

Вот в плагине и попортит . Точнее сервер твой попортит, когда в плагине будет совсем не тот VMT что ожидается.

K>>> Даже если и удалишь то обнаружишь очень быстро.
AVK>>Вот это вряд ли.
K>
K>Намек понят?

Нет. Несоответствия разные могут быть.

AVK>>Или из-за несовпадения размеров VMT будет проход по памяти.
K>Не будет. Размер VMT не меняется. Т.к. виртуальными при использовании P-Impl нужно делать только колбеки типа onMessage которые в дочерних классах переопределяются и как правило число таких функций не увеличивается, есть и заглушки для расширения, и одна универсальная на случай ядерной войны.

Все это здорово до тех пор пока чудик из плагина не передаст тебе на вход какой нибудь совершенно левый класс.

AVK>>Их проблемы.
K>Проблемы там есть толко в другом. С этом как раз проблем нет.

Наличие мусора это признак несовершеннности технологии.

AVK>>Мудрые мужи при наличии более надежных и удобных решений используют их, а не продолжают жрать кактус.

K>Ага, только эти надежные и удобные решения не применимы в проектах где 800 мегов памяти требуется для расчета. Только законченный дурак будет писать тяжелые CAD/CAM/САЕ системы на яве или шарпе.

Тут вот уже про Autocad 2005 кто то писал .

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Kluev, Вы писали:

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

K>>>> Даже если и удалишь то обнаружишь очень быстро.
AVK>>>Вот это вряд ли.
K>>
K>>Намек понят?

AVK>Нет. Несоответствия разные могут быть.
Тем не менее сразу видно имя функции и класса. Остально можно depends-ом посмотреть. Он еще и имена функций раздекорирует. Тоже самое с плагином. Если сбойнул LoadLibrary идем в депендс и смотрим. Вообщем не та ошибка котороую ищут неделями. Пара минут не больше.

AVK>>>Или из-за несовпадения размеров VMT будет проход по памяти.
K>>Не будет. Размер VMT не меняется. Т.к. виртуальными при использовании P-Impl нужно делать только колбеки типа onMessage которые в дочерних классах переопределяются и как правило число таких функций не увеличивается, есть и заглушки для расширения, и одна универсальная на случай ядерной войны.

AVK>Все это здорово до тех пор пока чудик из плагина не передаст тебе на вход какой нибудь совершенно левый класс.
От этого никто не застрахован. Если сидишь в одном адресном пространстве то испортить можно все что угодно.

AVK>Наличие мусора это признак несовершеннности технологии.
Да нет здесь совершенных технологий. Все несовершенны. Болое того сейчас мы пытаемся искать какую-то красоту среди нулей и едениц. Ну не тщетно ли?

K>>Ага, только эти надежные и удобные решения не применимы в проектах где 800 мегов памяти требуется для расчета. Только законченный дурак будет писать тяжелые CAD/CAM/САЕ системы на яве или шарпе.

AVK>Тут вот уже про Autocad 2005 кто то писал .
И что же он писал? Акад сидит на ядре ACIS, а это С++ библиотека. Альтернатива ему только parasolid — C библиотека. А писать свое собственное — это примерно 600 человеко-лет работы (цифра взята из рекламы parasolida). Скорее всего на шарпе будет только UI. Да и то я не вижу особых преимуществ юзать дотнет в такой системе.

Здравствуйте, Kluev, Вы писали:

AVK>>Нет. Несоответствия разные могут быть.
K>Тем не менее сразу видно имя функции и класса. Остально можно depends-ом посмотреть. Он еще и имена функций раздекорирует. Тоже самое с плагином. Если сбойнул LoadLibrary идем в депендс и смотрим. Вообщем не та ошибка котороую ищут неделями. Пара минут не больше.

Я тебе уже сказал — самое страшное если из-за каких либо несовместимостей компиляторов, версий хидеров и прочая у тенбя будет проход по памяти. Это тот же самый dll hell, только намного хуже.

AVK>>Все это здорово до тех пор пока чудик из плагина не передаст тебе на вход какой нибудь совершенно левый класс.
K>От этого никто не застрахован. Если сидишь в одном адресном пространстве то испортить можно все что угодно.

Вот только в дотнете я получу внятную ошибку и нетронутое ядро, а в твоем случае проход по памяти и ядро рухнет.

AVK>>Наличие мусора это признак несовершеннности технологии.
K>Да нет здесь совершенных технологий. Все несовершенны.

Только одна больше другой.

K> Болое того сейчас мы пытаемся искать какую-то красоту среди нулей и едениц. Ну не тщетно ли?

Да и вобще жить не стоит, одни напряги

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Нет. Несоответствия разные могут быть.
K>>Тем не менее сразу видно имя функции и класса. Остально можно depends-ом посмотреть. Он еще и имена функций раздекорирует. Тоже самое с плагином. Если сбойнул LoadLibrary идем в депендс и смотрим. Вообщем не та ошибка котороую ищут неделями. Пара минут не больше.

AVK>Я тебе уже сказал — самое страшное если из-за каких либо несовместимостей компиляторов, версий хидеров и прочая у тенбя будет проход по памяти. Это тот же самый dll hell, только намного хуже.
Я не понимаю откуда ему взятся проходу по памяти? и кстаи что ты имеешь ввиду под этим словом?

AVK>>>Все это здорово до тех пор пока чудик из плагина не передаст тебе на вход какой нибудь совершенно левый класс.
K>>От этого никто не застрахован. Если сидишь в одном адресном пространстве то испортить можно все что угодно.

AVK>Вот только в дотнете я получу внятную ошибку и нетронутое ядро, а в твоем случае проход по памяти и ядро рухнет.
Опять же что-такое проход по памяти? И потом плагин может испортить данные ядра просто неумелым вызовом функций ядра. Не хочешь же ты сказать, что ты все ходы предусмотрел? В этом случае либо ядро упадет из-за внутренней ошибки, либо данные будут испорчены.

Здравствуйте, Kluev, Вы писали:

AVK>>Я тебе уже сказал — самое страшное если из-за каких либо несовместимостей компиляторов, версий хидеров и прочая у тенбя будет проход по памяти. Это тот же самый dll hell, только намного хуже.
K>Я не понимаю откуда ему взятся проходу по памяти?

Из-за несовпадения размеров и форматов dll.

K> и кстаи что ты имеешь ввиду под этим словом?

А что, это выражение допускает разные трактовки?

AVK>>Вот только в дотнете я получу внятную ошибку и нетронутое ядро, а в твоем случае проход по памяти и ядро рухнет.
K>Опять же что-такое проход по памяти? И потом плагин может испортить данные ядра просто неумелым вызовом функций ядра. Не хочешь же ты сказать, что ты все ходы предусмотрел? В этом случае либо ядро упадет из-за внутренней ошибки, либо данные будут испорчены.

Вот поэтому мудрые мужи пользуют технологии, позволяющие гарантированно избежать подобных ситуаций

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Kluev, Вы писали:

AVK>>>Я тебе уже сказал — самое страшное если из-за каких либо несовместимостей компиляторов, версий хидеров и прочая у тенбя будет проход по памяти. Это тот же самый dll hell, только намного хуже.
K>>Я не понимаю откуда ему взятся проходу по памяти?

AVK>Из-за несовпадения размеров и форматов dll.
Это наверное шутка была? Формат один PE32.

K>> и кстаи что ты имеешь ввиду под этим словом?
AVK>А что, это выражение допускает разные трактовки?
А я так и не понял. Что за проход? куда проход?

AVK>>>Вот только в дотнете я получу внятную ошибку и нетронутое ядро, а в твоем случае проход по памяти и ядро рухнет.
K>>Опять же что-такое проход по памяти? И потом плагин может испортить данные ядра просто неумелым вызовом функций ядра. Не хочешь же ты сказать, что ты все ходы предусмотрел? В этом случае либо ядро упадет из-за внутренней ошибки, либо данные будут испорчены.

AVK>Вот поэтому мудрые мужи пользуют технологии, позволяющие гарантированно избежать подобных ситуаций
Мудрые мужи не вводятся в заблуждение гарантированными технологиями. Если плагины вызвает фунекции в последовательности которая не предусмотрена ядром, то оно может упасть очень легко. Хотя плагин будет живее всех живых. Оно не упадет только если все вызовы ядра атомарные. А это отнюдь не всегда возможно, и не всегда удобно. Все равно всего не предусмотришь. Либо будешь пахать 100 лет ради обесчпечения надежности которая может и не понадобится никому.

Здравствуйте, Kluev, Вы писали:


A>>Да потому что нету например желания возится со старыми отлаженными исходниками, писавшимися людьми которых давно уже нет в обозримом пространстве и о принципах работы которых можно только догадываться . В том же COM'е сделал кмпонент, прицепил к основной программе и забыл о нём...

K>Это типичные заблуждения начинающего, об исходниках, удобстве и "сделал и забыл".

Ну эт ты зря... Я вот щас с прожектом работаю — так в нем порядка 70 СОМ-компонентов. И половина пасаны 3-5 лет назад. Реально все что требуется для работы с ними — это idl ну и документация, че компонент делает. Никакого гемора нету. Конечно да, тормоза с виртуальностью никуда не деваются, но это уже другая песня.

Здравствуйте, Kluev, Вы писали:

K>Об этом и речь. Именно такой стиль я и использую. Некомпонентное ядро (со статическим апи) + плагины (сделаные как компоненты).

По-моему, огромное монолитное ядро — это признак плохого дизайна. Если продукт пишется одним человеком или группой из 3-5 человек, то может это и нормально. А Линукс — это просто флаг кривого дизайна.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Kluev, Вы писали:

K>>Об этом и речь. Именно такой стиль я и использую. Некомпонентное ядро (со статическим апи) + плагины (сделаные как компоненты).

VD>По-моему, огромное монолитное ядро — это признак плохого дизайна. Если продукт пишется одним человеком или группой из 3-5 человек, то может это и нормально. А Линукс — это просто флаг кривого дизайна.

Вот тут поподробнее. Можно даже в отдельной ветке.
ЗЫ: я (пока) не собираюсь оспаривать это утверждение. Мне просто интересно, чем оно обосновано.

VladD2:

> По-моему, огромное монолитное ядро — это признак плохого дизайна. Если продукт пишется одним человеком или группой из 3-5 человек, то может это и нормально. А Линукс — это просто флаг кривого дизайна.

А по-моему подобные огульные высказывания — признак недостаточно глубокого знакомства с проблемой. В частности, выбор между микроядерной архитектурой и монолитным ядром вовсе не очевиден. И у того, и у другого решения есть как достоинства, так и недостатки. И хотя при написании "больших" операционок чаще выбирают как раз архитектуру с монолитным ядром, оба подхода имеют право на жизнь.

http://www.webster-dictionary.org/definition/Kernel%20(computer%20science)

Monolithic kernels vs. microkernels

Monolithic kernels are often preferred over microkernels due to the lower level of complexity of dealing with all system control code in one address space. For example, XNU, the Mac OS X kernel, is based on Mach 3.0 + BSD in the same address space in order to cut down on the latency incurred by the traditional microkernel design.

In the early 1990s, monolithic kernels were considered obsolete. The design of Linux as a monolithic kernel rather than a microkernel was the topic of a famous flame war (or what then passed for flaming) between Linus Torvalds and Andrew Tanenbaum; a summary is available online.

There is merit in both sides of the arguments presented in the Tanenbaum/Torvalds debate.

Monolithic kernels tend to be easier to design correctly, and therefore may grow more quickly than a microkernel-based system. There are success stories in both camps. Microkernels are often used in embedded robotic or medical computers because most of the OS components reside in their own private, protected memory space. This is not possible with monolithic kernels, even with modern module-loading ones.

Although Mach is the best known general-purpose microkernel, several other microkernels have been developed with more specific aims. L3 was created to demonstrate that microkernels are not necessarily slow. L4 is a successor to L3 and a popular implementation called Fiasco is able to run Linux next to other L4 processes in separate address spaces. There are screenshots available on freshmeat.net showing this feat. A newer version called Pistachio also has this capability.

QNX is an operating system that has been around since the early 1980s and has a very minimalistic microkernel design. This system has been far more successful than Mach in achieving the goals of the microkernel paradigm. It is used in situations where software is not allowed to fail. This includes the robotic arms on the space shuttle to machines that grind glass where a tiny mistake may cost hundreds of thousands of dollars.

Many believe that since Mach basically failed to address the sum of the issues that microkernels were meant to solve, that all microkernel technology is useless. Mach enthusiasts state that this is a closed-minded attitude which has become popular enough that people just accept it as truth.

Здравствуйте, Kluev, Вы писали:

AVK>>Из-за несовпадения размеров и форматов dll.
K>Это наверное шутка была? Формат один PE32.

Описка, отвелкали. Имелась ввиду конечно VMT.

AVK>>А что, это выражение допускает разные трактовки?
K>А я так и не понял. Что за проход? куда проход?

Порча памяти программы из-за неверного определения адресов.

AVK>>Вот поэтому мудрые мужи пользуют технологии, позволяющие гарантированно избежать подобных ситуаций
K>Мудрые мужи не вводятся в заблуждение гарантированными технологиями. Если плагины вызвает фунекции в последовательности которая не предусмотрена ядром, то оно может упасть очень легко.

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

K> Хотя плагин будет живее всех живых. Оно не упадет только если все вызовы ядра атомарные.

Оно не упадет если любое внещнее воздействие не приведет ядро в неожиданное состояние. Это не так сложно обеспечить. Впрочем неважно — эта ошибка общая для любой технологии.

K> А это отнюдь не всегда возможно, и не всегда удобно. Все равно всего не предусмотришь. Либо будешь пахать 100 лет ради обесчпечения надежности которая может и не понадобится никому.

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>А по-моему подобные огульные высказывания — признак недостаточно глубокого знакомства с проблемой. В частности, выбор между микроядерной архитектурой и монолитным ядром вовсе не очевиден. И у того, и у другого решения есть как достоинства, так и недостатки. И хотя при написании "больших" операционок чаще выбирают как раз архитектуру с монолитным ядром, оба подхода имеют право на жизнь.

Уж не знаю. специально ты или просто не сообразил, но архитектура микроядра подразумевает изоляцию аппаратными средствами критичного кода. К динамической подгрузке частей ядра это имеет отдаленное отношение. К примеру в теперешней NT внутри ядра выполняется довольно много кода, при этом ядро весьма модульное. В Линуксе же, особенно в старых версиях, ядро линковалось в один большой модуль, даже вместе с драйверами. Об этом Влад собственно и говорил.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Kluev, Вы писали:

K>>Об этом и речь. Именно такой стиль я и использую. Некомпонентное ядро (со статическим апи) + плагины (сделаные как компоненты).

VD>По-моему, огромное монолитное ядро — это признак плохого дизайна. Если продукт пишется одним человеком или группой из 3-5 человек, то может это и нормально. А Линукс — это просто флаг кривого дизайна.

Вот тут поподробнее. Можно даже в отдельной ветке.
ЗЫ: я (пока) не собираюсь оспаривать это утверждение. Мне просто интересно, чем оно обосновано.

Здравствуйте, Kluev, Вы писали:

K>Имеется ввиду связывание с реализацией.
K>Ты же пишешь:
K>Foo f = new new Foo(); — конкретный класс реализация
А не че что я в VB тоже так пишу, хотя класс на самом деле в COM-сервере сидит?
Set oFoo = new Foo

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ> Вот тут поподробнее. Можно даже в отдельной ветке.
ЗХ> ЗЫ: я (пока) не собираюсь оспаривать это утверждение. Мне просто интересно, чем оно обосновано.

Ой, это старый и довольно безнадежный флэйм. Мач вс. монолит. Тут его уже не раз поднимали. А я что-то подустал в этих баталиях.

Здравствуйте, Павел Кузнецов, Вы писали:

>> По-моему, огромное монолитное ядро — это признак плохого дизайна. Если продукт пишется одним человеком или группой из 3-5 человек, то может это и нормально. А Линукс — это просто флаг кривого дизайна.

ПК>А по-моему подобные огульные высказывания — признак недостаточно глубокого знакомства с проблемой.

А, по-моему, применение ярлыков вроде "огульные высказывания" является некрасивым приемом в дисскусии. Я высказал свое мнение. Никаким огульным оно не может являеться по определению. Я не обязан подтверждать свое мнение.

ПК> В частности, выбор между микроядерной архитектурой

Ну, так и думал, что все это свалится на мач. вс. линукс.

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

ПК> и монолитным ядром вовсе не очевиден. И у того, и у другого решения есть как достоинства, так и недостатки.

Мля, очевиден, не очевиден. Мне совершенно фиолетово, что там тебе не очевидно. Мне все очевидно. Я всказал, свое мнение. Имею право? Ну, и все. Точка. Закрыли тему.

Здравствуйте, VladD2, Вы писали:

ЗХ>> Вот тут поподробнее. Можно даже в отдельной ветке.
ЗХ>> ЗЫ: я (пока) не собираюсь оспаривать это утверждение. Мне просто интересно, чем оно обосновано.

VD>Ой, это старый и довольно безнадежный флэйм. Мач вс. монолит. Тут его уже не раз поднимали. А я что-то подустал в этих баталиях.

Не, это все мне более-менее понятно (по ночам занимаюсь созданием своей платформы. на С++ )
Мне стало интересно вот это:

VD>А Линукс — это просто флаг кривого дизайна.

Кой-чего конечно и в JustForFun'е можно вычитать. Но все же? Поделись, а? (без ыронии)