Tonal писал(а) 29. Февраля 2008 :: 14:56:

Да уж есть. Например биндинг OLE-обектов на бесплатной версии QT.
Даже и не представляю как делать.
Отладка: обмен информацией между 2-мя запущенными приложениями причем и в Windows и в Linux. Тоже не представляю как сделать...
Ну и всякие заморочки типа момента очистки мусора, обеспечения цепочек прохождения событий, способ подвязки к событиям обектов и т.п.
Очень помогает сквирел, хотя его возможностей явно не хватает.
А думать надо...

Tonal писал(а) 29. Февраля 2008 :: 14:34:

Которые в принцыпе ломают всю схему интерпретатора  ...

Tonal  Все твои вопросы я уже задавал, результат тот же. В общем какая то странная политика у trdm

Tonal писал(а) 13. Марта 2008 :: 06:10:

Я вот сейчас чесно признаюсь, что есть очень большая проблема конструирования фраймверка в целом в итерминах С++. Так сказать, осознал свою полную профнепригодность в этом вопросе.
По этому ТЗ захлебнулось, т.к. не смог переложить свое "видение" и части прототипа на бумагу, на схемы, на документацию..
Осознал я это вот в какой момент и с какой проблемы: MDI/QWorkspace+разные типы документов.
На данный момен попросил разработчиков заниматься только локальными компонентами. Ибо общая схема взаимодействия внутренностей мне пока не ясна.
В свое оправдание могу сказать что стараюсь начитывать больше информации по проектированию.. ищу буквари, штудирую.. многое становится понятным, к сожалению не все...

Salimbek писал(а) 13. Марта 2008 :: 10:11:

А каким, если не секрет?
Ждать в засаде с гранатометом?

Я сильно извиняюсь, но почему было решено делать систему полностью с 0, начиная с интерпретатора с собственным языком (если не ошибаюсь, аналогом 1С) и иде?
Ведь кроме реализации системных вещей, что в принципе само по себе особо никому не надо, на этой системе обязательно должно быть реализовано 2-3 типовых решения, демонстрирующих работоспособность системы и отсутствие багов, и которые можно было бы взять за основу для собственной разработки.

Разработка начиная с интерпретатора:
1) увеличивает количество багов.
2) в конечном итоге делит программистов работающих на этом проекте на системщиков, и прикладников пишущих аналоги бухгалтерии, ТиС и т.д. Как Вы думаете, какая доля разработчиков прикладной части решения сможет найти и исправить какой либо баг в системной?
3) уход системного архитектора повлечет или остановку или смерть проекта.
4) без обкатанного типового решения ставить эту систему в моло мальски серьезной фирме - самоубийство, т.к. см. пункт 3), а держать в одной конторе 2 программистов, один 1С другой С++ никто не будет.

Почему бы просто не сделать предметный фреймворк+набор компонентов+орм на чем-нибудь распространенном, например том же .Net или Питоне?
В этом случае все будет написано на одном языке, да и расширение функциональности возможно за счет базовой платформы. И каждый разработчик прикладного решения при желании может внести вклад в расширение фреймворка.
А самое главное, рабочий вариант выйдет не в пример быстрее.

Ведь конечная цель проекта не набраться опыта в системном программировании а дать средство быстрой разработки решений, да?

sn175 писал(а) 13. Марта 2008 :: 12:04:

50/50...

trdm писал(а) 13. Марта 2008 :: 12:26:

+1
я бы с удовольствием почитал то как кто-либо реализовал работу с блокировками. есть свои идеи, но всегда интересно знать кто как бы это сделал.
т.е. мы открыты для КОНСТРУКТИВНОГО обсуждения, а не флейма.
т.к. сейчас только флейм даже на форум залезать не хочется.