По мотивам этой ветки: http://www.1cpp.ru/forum/YaBB.pl?num=1171365194
решил создать отдельную тему для обсуждения возможности/невозможности, нужности/ненужности модульности для 1С++.

В настоящий момент мне удалось относительно удачно выделить модуль ActiveX в отдельную DLL с сохранением функционала (т.е. не пострадало ни взаимодействие с 1С, ни взаимодействие с 1С++). Тесты в тестовой конфигурации выполняются нормально.

Результаты и исходники находятся здесь:
http://uzhast.fatal.ru/1cpp.modules/

Да, красиво получилось

Просто по АктивИкс все тесты мои и пару месяцев уже не изменялись, т.е. пока все стабильно

sedmin писал(а) 21. Февраля 2007 :: 15:19:

А чем здесь плохо?

sedmin писал(а) 21. Февраля 2007 :: 15:19:

Не знаю, пока сам смотрю, что происходит По всем прогнозам семерка должна была умереть еще лет пять назад, а она вроде живее всех живых Значит, что-то в ней есть такое, чего не дает восьмерка. Наверное, это легкость движка и простота конфигураций. Возможно, семерка не умрет еще долго. Ведь это не столько какое-то одно решение, сколько платформа. А платформы просто так не умирают Скорее всего, просто семерка и восьмерка просто будут занимать разные ниши (где помельче - семерка, где покрупнее восьмерка).

sedmin писал(а) 21. Февраля 2007 :: 15:19:

Будут или не будут писать компоненты под 1С++, будет определяться возможностью "1С++ SDK". Если там будут реально удобные и полезные вещи для разработчика, то просто не будет смысла "не писать компоненты для 1С++". Например, возьмем CMyContextBase. Если его не использовать, то написание новых объектов для 1С будет связано с огромным геморроем и тормозами (все эти switch/case, прямой перебор списка имен методов и т.д.). Чтобы избавиться от геморроя, надо либо изобретать свой велосипед, либо вытягивать CMyContextBase из 1С++. Вытягивать из 1С++ на уровне исходников - то еще веселье. Когда я этим занимался, то опомнился, когда обнаружил, что перетянул в свой проект чуть ли не половину 1С++ Пришлось ковырять исходники и отрубать зависимость от CComponentClass - тогда получилось более-менее компактно. А вот если будут готовые хедеры и библиотеки, которые подключаются легким движением руки и сразу позволяют задействовать CMyContextBase, то тут уже и мыслей не возникнет, чтобы не использовать 1С++ Заодно получится дополнительное продвижение 1С++

Ну и написание плагинов для 1С++ даст разработчикам помимо удобства еще и новые возможности, например, взаимодействие с классами 1С++ (теми, что в 1С). Это вообще реально сделать без интеграции с 1С++ (а то, может, зря я это все )?

Если уж делать "1С++ SDK", то надо сразу позаботиться о документации Лучше сразу сделать специальный подраздел в Wiki (она как раз очень для этого подходит). Там можно будет описывать все экспортируемые из 1С++ возможности. Создать плагин для 1С++ будет не сложнее, чем простую ВК по технологии Rainbow - сначала создаем просто ВК по типу Rainbow (как описано в Wiki), а потом просто подключаем заголовки 1С++.

artbear писал(а) 22. Февраля 2007 :: 03:43:

Из репозитория:
CVSROOT: :pserver:anonymous@cvs.alterplast.ru:/usr/cvsroot
Module name: 1cpp

Да, все ок.
Проходят все тесты, кроме тестов на новый функционал для динамически добавляемых классов.

spock писал(а) 22. Февраля 2007 :: 05:06:

Линковкой с 1С++ и отсутствием необходимости корректировать конфу при его установке. Отсутствие необходимости менять конфу это не просто каприз. Ведь если модуль фактически становится частью 1С++, то пусть 1С++ и занимается его загрузкой. Ведь когда мы загружаем Excel, мы не занимаемся ручной загрузкой всех необходимых модулей? Более логично, ИМХО, получается.

spock писал(а) 22. Февраля 2007 :: 05:20:

ВК может быть какой-нибудь специализированной (какой-нибудь патчер/хукер) - т.е. не взаимодействующей с языком 1С. Тогда конфу можно вообще для этой ВК не править.

Во-вторых, автозагрузка ВК избавляет от разработчика от необходимости помнить порядок загрузки ВК: сначала 1С++, а потом уже зависимую ВК. Допустим, сейчас все просто, а если зависимости станут более сложными? ИМХО, чем меньше нужно программисту помнить, тем меньше возможности сделать ошибку.

Ну и, если автозагрузка плагинов не нужна, можно сделать эту возможность опциональной (и овцы сыты, и волки целы)