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

H>>В какие разы??? Не смеши. Будет ровно таже -- строчка две и всех делов. Но мы от DCOM отказались именно по причине его настроек безопасности. Сеть работала не с MS-инфраструктурой, посему это был большой геморой.
G>А прозрачно для прилодения сделать объект не удаленным, а локальным?

Вообще ни каких проблем

G>Про поменять протокол и формат сериализации вообще молчу.

Я перечислял уже протоколы по которым может работать MIDAS.

G>>>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие)
H>>В чем та возня? Объекты маршалить можно не напрягаясь, если знать как
G>В .NET вообще маршалить не надо, а знать тем более. Главное чтобы передаваемые объекты были сериализуемыми.

Маршалить = передавать (в обобщенной форме). Про знание о сериализации я и говорю

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

kuj>>>>>Не знаю как оно в Делфи, но в .NET и Java конфиги не имеют такой привычки — куда-то там слетать...

H>>>>И юзеры с админами ну прям небожители. Охотно верю.

___>>>Ну так какое отношение .Net имеет к админам? Если уж ты такой любитель народных поговорок (впрочем как и я): с дуру можно и х.. сломать"

H>>Ситуация, вполне себе, жизненная

___>Не спорю. Но тем не менее никакого отношения к "пердмету" разговора не имеющая. Или скажем по другому: юзеры/админы относятся к Дельфи/C#-ДотНет также как считать, что пользователи могут залить клавиатуру кофе недостатком клавиатуры.

Delphi не обязывает программиста иметь конфигурационные файлы, от которых будет зависеть работоспособность приложения. Вот и вся разница.

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

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

H>>>Я уже писал. Чилды должны умереть раньше, чем родитель.
G>>Зачем, сферический конь в вакууме? Можешь считать что они умрут одновременно.
G>>Ты же писал что-то такое. Приведи условия реальной задачи, тогда посмотрим как она решается в .NET

H>Я и так привел условия реальной задачи. Чилды должны умирать раньше парента. Я уже говорил, про попытку кроить задачу под решение. Просто согласиь, что такие моменты ты не контролируешь, и разойдемся спокойно.
Всегда нужно решение конкретной задачи, а не абстрактной. Приведи КОНКРЕТНУЮ зададу и я показу как она решается на .NET.
В твоих условиях это только ЖЕЛАНИЕ чтобы чилды умирали раньше парента. Если ничего им не мешет упирать позже парента, то почему все должно быть как ты хочешь?

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

___>>>Мужики, он против Линукса — налетай

H>>Я не против Он мне... В общем, фиолетов.

___>Это была шутка йумара. Здесь есть ярые поборники оного, впрочем, как и ты Дельфи.

Я не поборник Delphi Я осведомлен о ее проблемах сильно больше, нежели нападающие тут. Я просто скромно, честь девушки отстаиваю

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

G>>>>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие)
H>>>В чем та возня? Объекты маршалить можно не напрягаясь, если знать как
G>>В .NET вообще маршалить не надо, а знать тем более. Главное чтобы передаваемые объекты были сериализуемыми.

H>Маршалить = передавать (в обобщенной форме). Про знание о сериализации я и говорю
А зачем знать? достаточно чтобы объект был сериализуемым (имел соответсвующий атрибут). В COM нельзя любой класс передать в метод.

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

H>>А на своем test.GetAppName() ты думаешь не можешь получить эксепшен? Я думаю ты хотел сказать, что при написании можно ошибиться в имени метода. Если так, это не проблема, ибо Delphi умеет генерить заглушки.
G>В делфи можно включить режим, когда для каждого объекта, реализующего IDispatch вызовы методов через точку будут оборачиаваться в вызовы Invoke. При синтаксической ошибке в имени метода будет получатся Runtime exception. То что делфи умеет генерить заглушки я знаю.

В Delphi такого режима нет В Delphi можно от варианта хранящего IDispatch звать методы. Это, кстати, я тебе в примере на XML-RPC показывал.

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

___>Насчет минусов — ты вообще заметил смайлик? Шутка же. Сам к оценкам отношусь двояко — ставлю когда ну уж совсем нравится или нет. Отрицательные оценки ставлю очень редко. Оценки своих сообщений не смотрю, т.к. во первых, в Outlook Express-е их не видно, во вторых: ибланов много, минусов наставят будь здоров — ну что мне из-за этого настроение портить — не дождутся. Вобщем, живу по совести — остальное все х..ня.

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

___>>>Про Дельфи не скажу, но от поделий Богланд меня что-то воротит. Может вспомним еще угробище под названием Interbase?

H>>Есть такая штука: индивидуальная препаратная непереносимость Про интербейс спорить не буду, мне его клон (FB) вполне нравится (но я и с MSSQL (6.5-2000) работал).

___>FB это уже другая пестня, которая к Богланд уже не имеет никакого отношения.

С Interbase'ом вообще мало работал, так, чисто для тестов. Но на Абрамсах он, тем не менее, стоял

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

H>>Я и так привел условия реальной задачи. Чилды должны умирать раньше парента. Я уже говорил, про попытку кроить задачу под решение. Просто согласиь, что такие моменты ты не контролируешь, и разойдемся спокойно.
G>Всегда нужно решение конкретной задачи, а не абстрактной. Приведи КОНКРЕТНУЮ зададу и я показу как она решается на .NET.
G>В твоих условиях это только ЖЕЛАНИЕ чтобы чилды умирали раньше парента. Если ничего им не мешет упирать позже парента, то почему все должно быть как ты хочешь?

Чилды могут желать дернуть парента в момент своей смерти. На этапе проектирования я этот момент контролировать не могу т.к. чилды могут быть реализованы позднее и другим программистом, и ему может понадобиться дернуть парент перед смертью чилда. Я всячески пытаюсь избежать связанности реализаций, отсюда такое требование.

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

G>>>>>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие)
H>>>>В чем та возня? Объекты маршалить можно не напрягаясь, если знать как
G>>>В .NET вообще маршалить не надо, а знать тем более. Главное чтобы передаваемые объекты были сериализуемыми.

H>>Маршалить = передавать (в обобщенной форме). Про знание о сериализации я и говорю
G>А зачем знать? достаточно чтобы объект был сериализуемым (имел соответсвующий атрибут). В COM нельзя любой класс передать в метод.

В COM вообще нельзя ничего сложнее интерфейса да варианта передавать в метод . Я говорю о том, что если человек знает, как сериализовать объект, у него проблем с маршалингом оного не представится.

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

H>Чилды могут желать дернуть парента в момент своей смерти. На этапе проектирования я этот момент контролировать не могу т.к. чилды могут быть реализованы позднее и другим программистом, и ему может понадобиться дернуть парент перед смертью чилда. Я всячески пытаюсь избежать связанности реализаций, отсюда такое требование.

Ну приведи реальный пример задачи. Я больше чем уверен, что GC нормально ситуацию разрулит.
Сферический конь в вакууме не интересует

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

H>Delphi не обязывает программиста иметь конфигурационные файлы, от которых будет зависеть работоспособность приложения. Вот и вся разница.

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

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

___>>Это была шутка йумара. Здесь есть ярые поборники оного, впрочем, как и ты Дельфи.

H>Я не поборник Delphi Я осведомлен о ее проблемах сильно больше, нежели нападающие тут. Я просто скромно, честь девушки отстаиваю

Она не девушка, так что смысл отстаивать? Да и по поводу чести девушки я тоже другого мнения что с ней делать (и девушки тоже, хотя обычно молчат). Отстаивать надо пену на пиве в кружках

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

H>В COM вообще нельзя ничего сложнее интерфейса да варианта передавать в метод . Я говорю о том, что если человек знает, как сериализовать объект, у него проблем с маршалингом оного не представится.
Пример, я не знаю как сериализуется объект. Я могу написать класс и пометить его атрибутом Serializable. И потом передавать по сети совершенно нормально.
В DCOM так не получится.

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

___>>FB это уже другая пестня, которая к Богланд уже не имеет никакого отношения.

H>С Interbase'ом вообще мало работал, так, чисто для тестов. Но на Абрамсах он, тем не менее, стоял

Ну это не плюс Абрамсов, хотя пендосы так им гордятся. Один из лучших танков в мире, однако не лучший, но когда появится на них:
— автомат заряжания (у нас еще в на Т-64);
— стрельба как снарядами, так и ракетами на 5км по лазерному лучу из орудия причем зарядка ведется штатным автоматом заряжания (Т-64);
— аналог системы "Арена" (СССР 80 годы);
— приемлимый силуэт (Т-90 он явно сливает);
— приемлимый вес для езды по слабым грунтам и по большинству автомобильных мостов (Т-90 он сливает вчистую).

Вот тогда можно будет приводить в пример Абрамс. А так Абрамс для меня не авторитет.

PS: Смотрел передачу по National Geographic про Абрамс. Так вот там он позиционируется как единственный танк с ГТД. А про Т-80/Т-80У они типа не знали. Офтоп конечно, но по теме военной техники со мной лучше не спорить.

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

S>Здравствуйте, hattab, Вы писали:
H>>Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом.
S>Ну если захотелось помериться хамилками, то объясни мне, как Дельфи разработчик, отчего в дельфи программах утечки памяти наступают на ровном месте. Ась?
S>Я вот учил ПДД по вот такой дельфийской программе — приходилось перезапускать раз в десять минут из-за чудовищных ликов. А казалось бы — место ровнее некуда.

Синклар, от тебя не ожидал — это не аргумент. Угробищную программу можно написать на любом языке, хотя как тут уже говорили, таких дельфописателей больше всего будет. Я вот пару лет назад наблюдал прогу для учета и печати акцизных марок на Дельфи от фирмы "Атлас" — это ваще полный звездец. Так ее еще в свое время обязали пользоваться — и не ипет. Обычная десктопная прога жрала 300-500 Мб ОЗУ да еще глюков воз и маленькая тележка.

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

DOO>У нас один преподаватель в университете про языки с очень большим числом степеней свободы говорил, что это миры: мир ассемблера, мир перла и т.п. Изучать эти миры можно хоть всю жизнь, но суровая действительность требует практических скучных решений

Эти миры можно изучать очень долго только если будешь изучать один конкретный мир.
Если начать изучать все сразу то это волшебным образом займет намного меньше времени чем изучение одного мира.
Скажем метапрограммирование на шаблонах становится тривиальным после изучения функциональщины.

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

WH>>А зачем нам COM-интерфейсы?
H>По условию задачи.
Что это за условия такие?
Кого вобще волнует какие там интерфейсы?
Заказчика волнует только чтобы программа делала то что ему надо.

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

>> Также C++ даёт возможность размещать классы не только в куче, но и в
>> стеке и в глобальной памяти.
OCT>В C++ нельзя возвращать из функции объекты размера, не известного на
OCT>этапе компиляции.
OCT>а) строки
OCT>б) экземпляры потомка класса

Я стараюсь вообще не возвращать из функции объектов, а только передовать их в функции.
Строки тоже можно не возвращать. Достаточно возвращать указатель на строку и длину. А текст, внутри которого находится эта строка, может жить где-то на другом уровне стека. Также, как и выходной буфер, если речь идёт о выводе текста. А то месят, месят байты, складывая и разрезая один и тот же текст бог знает сколько раз.

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

H>По условию задачи: родитель живет, пока жив хоть один дочерний интерфейс.
Перестань описывать решение.
Опиши задачу.