2 AISOFT

хм... взаимные упреки в "пустой" болтовне. (я первый начал :), и было от чего)

Постановку в студию!
Всего лишь парочка из множества задач в последнем проекте.

----------
1. Необходимо на С++ (дано свыше, что именно С++) реализовать систему учета времени жизни объектов (наподобие Java, С#, VB).
Цель - повышение надежности программы, упрощение подхода к написанию программ в рамках языка C++, сокращение времени на отладку, сокращение размера исходного кода, повышение читабельности и обслуживаемости.

COM не предлагать. (тысячи причин, кому интересно - в отдельный топ).
Хотя, в решении предусмотрена некая совместимость с COM. (Полно готовых COM-компонентов используется в проекте).

При этом необходимо обеспечить "прозрачность" этого механизма для программистов, использующих технологию, а так же сохранить возможность для множественного наследования реализации объектов, использующих данную технологию (в противовес технологиям Java, С#, VB, где множественно наследовать можно только интерфейсы).

Решение?

Потом выложу свое с исходниками и докой (просто охота перед этим хотя бы пару ответов услышать).
2 funikovyuri
Именно виртуальное именно наследование (а не только виртуальные функции-члены) использовано зело широко как основа технологии.

----------------
2. Необходимо разработать удобную потоковую библиотеку в целях упрощения работы с потоками разной природы (файлы, память, строки) и инвариантной сериализации объектов в разных форматах (текстовом, бинарном). Предусмотреть возможность использовать библиотеки в семействе алгоритмов STL.

Решение? (и во сколько строк?)
Применение виртуального наследования сэкономило размер исходного кода примерно вдвое. (В доках есть диаграммы наследования)

--------------
3. Необходимо разработать гибкую событийную модель, не уступающую возможностям C#.
Разработана - превосходящая по возможностям.

(Событийная модель Java, к примеру, причина моего прохладного к ней отношения... топОрно...)

2 AISOFT again
А обломать мне рога очень легко - дай мне реальную задачку из области программирования, заведомо имеющую решение (в рамках языка С++ для чистоты эксперимента), но которую я не смог бы решить.
Да и для чего людям "рога ломать"? - превращать их в серости всякие? Мне рога обломать трудно хотя бы из-за некоторых черт характера, 12-ти летнего успешного опыта и высокой трудоспособности. ЛЮБЫЕ задачи, принципиально имеющие решение можно решить , big deal. К тому же их можно еще и НЕПЛОХО решить.

Удивительно желание отдельных индивидумов безосновательно "попускать" коллег - взгляни на свой первый пост в этом топе. С ЧЕГО ЭТО ТЫ ВСЕ ЭТО ВЗЯЛ, умник ? (вполне вежливое обращение, по сравнению с другими топами). На свой жизненный "опыт" опираемся? Да на "сломанные рога"? Или у нас только идиоты программы пишут, а все гении - там?

А насчет русского языка - ты прав, тщательнее надо! Только вот времени на проверку своих постов маловато и пишу их зело быстро, порой мимо клавиш. Да и пользуюсь русским языком в последнее время нечасто, так что практики не хватает.

ЗЫ
Дайте кто-нить FTP, куда бросить, - если на FTP фирмы выложу и народ туда ломанется - мне мало не покажется.

А теперь вопросы:
1) Как пункт 1, связан с пунктом 3 и, причем здесь пункт 2?
Чьи пункты, мои или ваши? После уточнения обязательно отвечу.

2) А не проще, было бы, C# использовать?
Как интерфейс к Java-сереверу приложений используется CORBA . CORBA генерирует гораздо меньший траффик чем .NET Remoting . Клиенты работают с системой через интернет. Клиентское приложение, целиком написанное на C++, одинаково хорошо чуствует себя как на P133 32M, так и на P4 512М. Клиентская часть предназначена для повсеместной установки в госпиталях, техника там разная. .NET будет там порой еле "пыхать".

3) Какой SQL SERVER использовался в проекте?
В данном - ORACLE.

4) Какие проблемы решает, в данном проекте, использование трехуровневого приложения?
Довольно сложная (рутинная) бизнесс-логика, и, к тому же, заведомо будет дополняться (количество инструкций на обслуживание медицинского оборудования разных классов просто поражает воображение, каждый год выходит очередной дополнительный "талмуд", это все в штатах). Сердце приложения - на Java, это middle-tier. Клиент получает довольно "тонкое" приложение, которое работает весьма шустро через обычный Dial-UP, система оптимизирована для работы даже на медленных соединениях.
Первоначальный вариант проекта был на JSP (функциональный аналог нынешнего ASP.NET), но быстродействие загрузки JSP страниц совершенно не устраивало при Dial-UP соединении. Сейчас клиент работает "мгновенно", т.к. передаются только "голые" данные, да еще и в бинарном представлении. (камешек в сторону Web-Services)

2 AISOFT

Вдогонку - 12 лет стажа, это не стаж - это детство, которое и объясняет твое хамство и самоуверенность.

А нечего заочно (не глядя) оценки выставлять да попускать - плохая привычка. Всегда рискуешь нарваться на хамство.
Тщательнее, доказательнее... :)
С этих вопросов (см. предыдущий пост) и стоило начинать, и только потом ставить оценки.

2 funikovyuri

google:Виртуальное наследование

Это оно и есть. Мне кажется, что это, все-таки, термин...

2 aag

Да, я системщик, потому что имею опыт проектирования систем, и потому что в основном применяю системный подход. :) (и недолюбливаю XP-стиль).

А попробуй разработать сетевой протокол или компилятор, или распределенную информационную систему без системного подхода (это то, чем я занимался в "прошлой" жизни). Да, бизнес-приложения - скучноватая область. Это опускает меня в чьих-то глазах? Или позволяет называть меня "кодером"? В проекте, о котором идет речь, мне на "откуп" дано проектированиие с 0-ля клиентской части системы. Люди, которые так решили, знали, что архитектуру приложения я спроектирую как никто другой. И "закодю" соответственно. :)

Или что, хорошо "кодить" – уже стало стыдно? А покажите мне живого человека, который на С++ хорошо кодит (я таких только изредка разве что в и-нете встречаю). Такие люди попадаются гораздо реже архитекторов (которых развелось как собак нерезанных, дармоедов). Или качество программного продукта уже никого не интересует? А внешний вид? А функциональность и дружественность интерфейса?
Может ли заказчик, в большинстве не специалист, предъявить достаточно подробное ТЗ? Дай бог, что бы он внятно смог сформулировать общие цели, и ему в этом еще помогать и помогать. Про удобство ввода и представлении информации заказчик вообще никогда ничего внятного сказать не может, т.е. это на совети разработчиков. (а совести обычно немного). И дальше начинается самое интересное кино. Того, что в ТЗ нет, МЫ НЕ ДЕЛАЕМ! Ха-ха-ха. И плодятся серые, безликие, неудобные в обращении программы, которые, прочем, соответствуют своей спецификации.

А спор начался на самом деле из-за декларируемых цифр по производительности труда программиста С++. AISOFT утверждает, что задекларированные 200 строк в день в среднем возможны только методом copy&paste. И я ведь его понимаю. На фирме, в которой он занимет некоторую должность ( может даже самую высокую) все происходит "стандартным" для последних нескольких лет способом: кто-то проектирует проект (обычно это 1-2 единственных грамотных человека на фирме, но большую часть своей жизни они теперь проводят за бумагами или их электронным аналогом, так что реальной пользы от них немного). Затем всякие team-lider-ы задают работу "кодерам" самого низкого звена, планируют и координируют их труд. На каждого такого кодера приходится 0.5-1.5 тестера - именно таким образом может достигаться некая надежность программ. Дай бог, чтобы в его фирме приходилось 30-40 строк в день на человека при такой организации труда. Это уродство происходит от наивной веры в то, что количество (кодеров + тестеров) может перерасти в качество. НИКОГДА! Программный продукт или качественный изначально, или характеризуется лишь отношением отловленных ошибок к их общему числу.

Никто не пишет без ошибок, речь может идти лишь о вероятности их возникновения. Но эта вероятность может отличаться на порядки.

Я как-то работал в подобной фирме. Для выполнения своей работы мне достаточно было “поковыряться” 1 час в день. Качество проекта, над которым работали было УЖАСАЮЩЕЕ (для авторов, разумеется, это было само совершенство). (Кстати – очень известная фирма, делающая очень серьезные вещи). На многие участки кода без слез смотреть было невозможно. Быстродействие – на уровне VB (а это C++). С первого дня я стал засыпать team-lider-ов тонной предложений по реальному упрощению и переделке многих моментов в программе, настаивал на рефакторинге. ВСЕ НАПРАСНО! На этот «отлаженный» код боялись «дунуть». (Это же сколько получится зарплаты напрасно выдали тестерам, если взять, да переделать) Обещали, что вот когда начнем разрабатывать следующую версию, тогда, мол, подключим тебя к проектированию, заодно сразу, по-типу, за качеством кода будешь следить... Я не «дожил» до следующей версии, потому как уже на второй месяц почуствовал, что деградирую... Да и Unreal с Tactical Operation поднадоел. И ушел. В маленькую, но очень динамичную команду. Времени в обрез. Но я крайне доволен. (AISOFT опять скажет, что я мальшишка, вместо того, чтобы заняться карьерой, раз фирма известная, занимаюсь, видите ли "интересными" вещами. Ответ: когда надоест работать - займусь карьерой, пока предложений о работе в серьезных фирмах хватает. Денег, кстати, тоже.)

Дальше, насчет copy&paste.

Если кто имеет опыт написания клиентских прог на С++, скажите, во сколько строк примерно обходится форма, на которой около 50-ти дата-контролов? Форма выполняет поиск, редактирование, ввод и первичную валидацию данных, корректное реагирование на ошибочные ситуации с выводом всяких сообщений. Так сколько в среднем?

Форма для таких операций у меня занимает в среднем - 100 строк! Все! Куда меньше? Из них 50 – объявление переменных, и еще 50 – спецификация data-bindings. Остальное работает посредством механизма, реализованного в базовых классах, оперируещего мета-информацией. Для приведенных операций этого достаточно.

Я свой код практически не отлаживаю (слово "практически" - ключевое). Я предпочитаю его пр о думывать. И на момент механической “выкладки” кода в исходник, он уже прилично отлажен в голове или схемах на бумаге. Это – кодирование? Ну конечно кодирование. Любой алгоритм перед исполнением на ЦП должен быть закодирован. (В студенческие годы я увлекался поиском оптимальных способов кодирования состояний конечных автоматов).

И если сейчас, имея шикарные вижуал студии со всякими вижуал ассистами, с удобной навигацией, с утилитами для авто-документирования кода и реверс-енженирингом UML диаграмм (…вписать еще 50 фишек ...), если используя все это, кто-то умудряется писать так, что на одного программиста требуется один тестер – нафиг из отрасли! НА-ФИГ! Хватит дискредитировать интересную и почетную профессию. А то жалуемся – к программистам отношение в последнее время, как к слесарям... Сами дураки! Нефиг «слесарно» работать. (ни к кому лично, но все же ...)

Сейчас идет бета-тестирование, через пару недель дам ссылку на свою последнюю программку. Тонкий такой клиент, форм на 300...

Всем сорри за дурацкое настроение.
Да, чуть не забыл:
Если программист не знает предметной области и методов проектирования
Предметной области чего? Клиент достаточно «тупой», т.е. я на клиенте не учитываю деньги ресурсы и пр. Я отображаю и позволяю вводить ДАННЫЕ, в самом широком смысле этого слова.
Боюсь, что именно в плане понимания всех тонкостей работы с данными, и методов проектирования систем обработки данных (причем, на всех уровнях, а не только на уровне кружочков и стрелочек) уважаемый AISOFT далеко в форватере. Я имел ввиду, что не очень лезу именно в тонкости и правила учета медицинского оборудования, потому как существуют четкие спецификации, не оставляющии простора для двоякого толкования. Предпочитаю спроектировать систему так, чтобы эти тонкости легко можно было настраивать, а не вбивать их в код (тогда уж точно пришлось бы досконально изучить прикладную область, но я предпочитаю оставлять это право специалистам, и в руки им давать инструмент )

1) Как пункт 1, связан с пунктом 3 и, причем здесь пункт 2?
П.1. – это декларация того, что нет ничего необычного в бизнес-приложении. П.3. это ответ на предложения применить С#, и + реальный способ уменьшить число строк в программе (из-за этого собственно сыр-бор). Если бы не п.3. программа была бы примерно на 25% больше, примерно вдвое больше времени потребовала бы на отладку.

П.2. – собственно ответ автору топика (а не AISOFT-у).

И какого лешего эти пункты из совершенно разных моих постов понадерганы и в кучу свалены??? В топах я отвечал на совершенно различные вопросы, а не выписывал единый художественный рассказ.

Вообще спор у нас о чем? Что 200 строк в день не бывает при качественном подходе?
Бывают разные качественные подходы ! Вопрос закрыт.

2 aag again
У меня в качестве шаблонов диалогов HTML страницы используются - порой там тоже немало строк. При подсчете я это не учитывал.

2 AISOFT\r
\r
на клиентской части работало 2 человека. \r
174520/12/26/2=280\r
\r
130-150 ваших - неплохо, лучше, чем в той конторе, которую я упоминал.\r
\r
2 aag\r
Он скажет "Мы разрабатывали такую-то (бизнес) систему, для реализации таких-то ф-ций по таким-то причинам нам пришлось написать свою потоковую библиотеку. \r
Разумеется именно так все и было, в условиях маленькой команды необходимость каждого "ответвления" в процессе разработки тщательно обосновывается.\r
А разговоры про круче относились к вопросу "почему именно на с++?". Т.к. только такой язык позволил решить эту задачу весьма элегантно и смешным количеством строк (для потоковой библиотеки).\r
\r
см мой пост

2 c127

А какие еще языки тестировались и как?

шутник, однако... тестирование языков... :)

в течении последних 12 лет "тестировались" следующие языки:
Asm: z80, x48, x51, x80, x86, PIC,
Fortran, Forth, Lisp, Prolog, M(Matlab),
C, C++, Pascal, Delphi,
VB, VBA, VBScript, JavaScript, Perl,
Java, C#, VB.NET, MC++

Тестировались по-всякому.
Например в 1994-м на Forth-е был написан полноценный assembler x51 за 3 дня и занял он 600 строк. Я уверен, что на С++ это заняло бы минимум 2 месяца и минимум 10000 строк.

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

Вопрос был по-приколу?

2 aag

Я думаю, проблема в том, что разработка крупных проектов, на мой взгляд, по-прежнему остается Искусством (а не наукой). И применение того или иного подхода, не гарантирует успеха.

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

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

В основе проектов должны, в первую очередь, лежать ИДЕИ (я не беру достаточно стандартные проекты, колторые легко решаются на той же 1С, превращая спор о достоинствах С++ и Дельфи в пустопорожнюю болтовню), а алгоритм может разве что "подсказать" нам как не просрать хорошую идею.
Я думаю, что два этих понятия (идея - реализация) паритетны.