Дык, кто-то качественно 30 строк в день напишет. А кто-то еще качественнее 500 строк в день напишет.

Для среднего рядового программиста считаю 200 строк в день качественного кода нормально. Это значит, что пишешь со скоростью около 300-500 и на отладку и тесты уходит потом немного времени, давая в среднем 200.

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

Да, если пытаюсь тратить свое время на что-нить иное, чем проектировать и кодить программу, то вежливо одергивают. И правы. Т.к. мое время довольно дорого обходится. Больше программистов только менеджеры высокого звена получают. А про кодеров - "машинисток" забудьте, не те времена. Такие уже давным давно без работы, - кризис, понимаете ли. Быстрота писания - она от опыта и мозгов и ни от чего более. Примерно 90% кода - вполне обычный код, наилучшие варианты и методы известны давно (если спец в своем деле), можно писать на автомате, а тем временем обдумывать следующий класс/иерархию/алгоритмы. Как в той сказке - одну беру, на другую смотрю, третью подмечаю, а четвертая мерещиться - вполне нормальное рабочее состояние (если только не после удачно проведенных выходных, конечно :) ).

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

У меня после 15-го бета выходит, надыть ссылку кинуть. Будет для n источник информации. Наш проект - 3-х звенка. Писали 6 чел. 1 год. На клиентской части работало 2 чел.
Клиентская прога, LineCounter показывает: lines=257473, code=174520, comments=45857, ...

елы-палы! Ну упорный товарисч!
Поспорить хотса?

Предметная область - бизнесс-приложение. Т.е. учет документов, денег, материальных ценностей, людских ресурсов, и т.д. и т.п.
Ядро бизнес систем написанных под разные отрасли деятельности внутри может быть практически одинаковое, будет различаться "надстройка", т.е. сами бизнесс-операции. Вот именно подробности той самой настройки меня и не очень волнуют, т.к. это не самая сложная часть системы, хотя и самая объемная.

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

Был бы мембер - выслал бы на мыло пару не маленьких файлов из проекта, а ты бы попробовал съэкономить хотя бы строчку, или же попробовал бы предложить лучшую иерархию классов. Хотел бы я посмотреть на твои потуги, умник.
А то зря воздух гонять особого умения не надо.

А ребята у нас в команде - высший пилотаж. Каждый из них такого уровня, что в радиусе 200 миль однозначно лучшего нет. И методы используем свои, малость отличные от тех что я видел в обычных конторах где работают обычные программисты.
На аналогичном по сложности проекте в одной из фирм я видел задействовано около 20-чел, у них код более чем в два раза больше нашего, при той же сложности приложения.
Есть басня Крылова - как вы друзья не садитесь ... Успех разработки определяется не столько "правильным" подходом, сколько квалификацией действующих лиц. При достаточной квалификации разработчиков применить неправильный подход не получиться даже случайно - тебе никто не даст это сделать, программист может послать менеджера сходить проветриться, если этот менеджер явно не прав, и никогда ты не заставишь спеца делать что-либо неоптимально, потому как они люди зело ленивые.

2 Дмитрий Мыльников

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

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

Я С++ сравниваю с очень "тонким" инструментов, работая на котором легко поломать и "заготовку" и "инструмент". Спасает только некая система правил и стилей, выработанная годами, под разные по характеру участки кода.

2 Циничный Кот
да о каком code review может идти речь,

некто AISOFT умудряется обсуждать во сколько строк могла обойтись разработка не видя ни кода, ни задачи, да еще попутно советы давать, чтобы мы "copy&paste" пореже использовали. Замечание, конечно, весьма ценное, а то так бы всю жизнь методом "copy&paste" и пользовался.

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

Ну а раз товарищь AISOFT позволяет себе столь глубокое обсуждение не видя ни проекта ни кода, представляю, сколько полезного он мог сказать, взглянув хотя бы мельком. Будем считать, что я пытался схитрить, взять человека на "слабо", для того, чтобы "нахаляву" воспользоваться прозорливостью AISOFT в целях "ревью" собственного кода. Что ж, не вышло... ЦК меня раскрыл... Теперь я смогу посылать свой код только лишь любобытствующим и, причем, на совершенно гумманных условиях - делать "ревью" кода совсем не обязательно! Однако можно будет пользоваться.
В своих коммерческих проектах я зачастую использую код и библиотеки, которые разрабатываю в исследовательских целях в свое личное время. Когда такая библиотека "дозревает", я начинаю использовать ее в коммерчесских проектах, но т.к. такой код разрабатывался вне рамок проекта, я волен распоряжаться им по своему усмотрению, т.е. действительно могу показывать направо и на лево.

2 funikovyuri
А чем STL не устроила???
А попробуй сделать гибкую сериализацию объектов на STL-ных стримах. Да еще и в настраиваемых форматах. Любого не устроит.

И что такое виртуально наследование, а то я видно от жизни отстал....
Это шутка?
Если действительно есть нормальный интерес к C++ (а не ради стеба), с удовольствием пообщаюсь. Мыло мое открыто.

2 Циничный Кот again
Мыло-то, конечно, твое открыто, только после "финансовой" постановки вопроса как-то не решился ничего туда кинуть. Однако мне ничего не стоит и кинуть, если тебе это действительно интересно.

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С, превращая спор о достоинствах С++ и Дельфи в пустопорожнюю болтовню), а алгоритм может разве что "подсказать" нам как не просрать хорошую идею.
Я думаю, что два этих понятия (идея - реализация) паритетны.

Да, насчет протоколов.

Многие способны разработать протокол, так же как многие способны проектировать. Но немногие способны разработать действительно хороший протокол, точно так же как немногие способны действительно хорошо проектировать (см мое мнение насчет профессионализма в предыдущем топе).

Например семейство протоколов IP: TCP/UDP/ICMP/IGMP - пример ужасно плохой разработки протоколов (я думаю, они были разработаны в свое время как внутреннее временное решение) однако проект имеет успех, что лишний раз подтверждает что не только качество влияет на этот самый успех.
Кстати, успех той же 1С вообще ставит в тупик.

2 c127

Тогда уж следовало говорить: "из языков, известных мне и поддерживающих множественное наследование имплементаций только C++ позволил решить....."

Вот золотые слова! (если взглянуть на список языков) :))
Прямо добавить нечего...