C++ с полного нуля спустя месяц

Примерно месяц назад я решил освоить программирование и выбрал для этого C++. Основные занятия продолжаю по книге Стауструпа «Программирование. Принципы и практика использования C++».

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

Однако, я считаю это плюсом, т.к. наталкивает на материал из других источников (например, чтобы разобраться с циклами, я прорешал пару десятков задач из другой книги и только после этого решето Эратосфена вылилось в готовый код).

Желания бросить не возникало, но убедился, что выбор основной книги верен для моего уровня подготовки на данный момент с позиции методологии (все же думаю, есть специальная литература, по которой надо шлифовать правильность архитектуры программ и позволяющая улучшить «красоту» кода). Я сравнил подачу изученного материала Страуструпом с подходом авторов в книгах:

Джесс Либерти «Освой Cpp самостоятельно за 21 день»
Харви М. Дейтел, Пол Дж. Дейтел — «Как программировать на C++»
Шилдт Г. — «Самоучитель C++»

Хотя, в поисках идеи вложенных массивов я запоем прочитал тематические главы из всех упомянутых книг и Страуструп Б. «Язык Программирования С++».

К Visual Studio 2013 я поставил Visual Assist, к которому быстро привык. Другие среды программирования буду щупать позже, т.к. Visual Studio устраивает полностью. Главное, освоившись с азами, я понимаю, что впереди море интересного: классы, шаблоны, наследование и прочее.

P. S. По поводу конкретно C++ и сетевых холиваров о перегруженности его «отвлекающим» функционалом, сказать пока ничего не могу, однако заметил, отличия в подаче материала Страуструпом и другими авторами в книгах по C++ для новичков. У Страуструпа какие-либо абстракции языка гармонично вытекают из предварительно поданной базы, остальные упомянутые книги я к данному моменту воспринимаю как гораздо менее связанный набор описаний аспектов языка.
  • +3
  • 09 февраля 2014, 22:32
  • habl

Комментарии (61)

RSS свернуть / развернуть
Кто пробовал студию в качестве среды для создания программ для микроконтролеров?
0
зачем граблями волосы расчесывать?
+1
Грабли и расчёска это два принципиально разных инструмента. Студия же как и eclipse среда для программирования.
Меня интересует количество граблей при прикручивании сборки и отладки проектов для МК под VS. После просмотра презентации по Visual Assistant захотелось попробовать. И не надо рассказывать о прожорливости студии и тому подобное. Ресурсы ПК можно обновить, это не дорого. А вот мое время для меня гораздо ценнее. Посему хочу оценить сколько проблем будет при настройке сборки и отладки, и насколько стабильно и предсказуемо это будет работать. У Eclipse своих глюков море.
0
Вот и меня тот же вопрос сильно волнует(я чуть ниже спрашивал уже). Ибо MSVS моя родная среда разработки — было бы крайне удобно пользоваться привычным инструментом при embedded разработке.
0
Насколько я знаю, толковой привязки GCC к студии нет. Тот же uni работал через мейкфайлы, используя студию, по сути, только как пролдвинутый редактор кода.
Хотя чисто теоретически — можно разработать набор плагинов для полноценного подключения GCC к студии — примерно как это сделано в AVR Studio 5 / Atmel Studio 6. Вроде даже не так уж сложно — такие языки, как RemObjects Chrome (ныне Delphi Prism), Nemerle или GPCP неплохо интегрировались в студию даже несмотря на то, что совсем не похожи на С.
Вообще, нужно гуглить, и если ничего не нагуглится — то, возможно, изучать документаци на MSVS и писать требуемые плагины самому.
И не надо рассказывать о прожорливости студии и тому подобное. Ресурсы ПК можно обновить, это не дорого. А вот мое время для меня гораздо ценнее.
Хоть один разумный человек, понимающий что его ресурсы куда ценнее машинных)
0
uni использует MSVS для МК.
0
Спасибо за подсказку! Постараюсь расспросить что да как :)
0
Если что то интересное разузнаете — поделитесь :)
0
Брожение по форумам подтвердило мои опасения — пока лучше Eclipse ничего нету. Хорошо это или плохо — я не знаю. Слишком много граблей при попытке использовать Visual Studio для разработки под МК.
У меня пока хорошо работает Eclipse+IAR. Пробовал Em::blocks — послевкусие странное, надо будет поглубже разобраться.
0
Сорри за некропост, но уже более двух лет использую MSVS(сейчас уже 13.0) для программирования на AVR. Из граблей вижу только(что пришлось сделать):
1. Генератор мейкфайлов. По сути программка которая по шаблону генерила бы мейкфайл вставляя вместо «ключей» нужные параметры переданные через командную строку(типа MCU или F_CPU)
2. Выходной синтаксис GCC и MSBuild несколько отличается, поэтому чтобы иметь возможность навигации по ошибкам выданным компилятором, то можно написать программку которая преобразует выход компилятора GCC в формат принимаемый студией.

После этого создаём в VS проект на основе мейкфайла, в качестве команды запуска вызываем генератор мейкфайлов, запускаем make и скармливаем это всё «перекодировщику» (make all 2>&1 | gcc_filter.exe)
И наслаждаемся. Даже никакие плагины не нужны. Студия кстати очень хорошо подхватывает родные библиотеки avr, работает и поиск и навигация.
0
Поделился бы программами.
Есть, кстати, коммерческие биндинги GCC к MSVS. Сделанные «по правилам», т… в виде плагинов к студии
0
Не очень хочется распространяться, потому как могут возникать баги, а я не гарантирую что смогу их править в ближайшее время после репорта. Но в принципе можно. Куда и как скинуть? Правда придётся писать инструкцию, на что у меня в данный момент нет времени, но за пару недель думаю оформить смогу.
0
дней* а не недель, конечно же.
0
Напиши топик и пристегни к нему. Желательно с сырками.
А лучше залей сорцы на гитхаб, а бинарники туда же в релизы.
0
Ух, какие хитрые:)
Топик писать не хочется. Могу дать документацию, исходники и файлы, а если есть желание топик сами напишете:)
0
Ну напиши топик «для галочки» с приаттаченными архивами сырков, доков и бинарников.
В качестве текста можешь туда свой же каммент скопипастить чудь подправленный.
0
Ладно, фиг с вами, один чёрт надо будет писать доки для внутреннего использования. На следующей неделе попробую что-нибудь оформить. Сюда кину ссылку по готовности.
0
Буду ждать)
0
Я использовал MSVS для AVR. Сейчас пришёл к выводу что удобней Eclipse + GCC.
PS Atmel на базе VisualStudio сделал IDE для AVR/AVR32/Cortex-M
0
Вы имеете в виду Atmel Studio 6.1?
Если да — вот у меня вопрос — а есть ли возможность использовать ее для сборки и заливки скажем в STM32?
Вопрос конечно несколько наивен и ответ скорее всего будет «нет» в простом случае и «да» в случае «а сменить клапан ДВС через выхлопную трубу» (в смысле слишком много граблей при прикручивании компилятора к MSBuild и того хлеще отладчика). В общем вопрос скорее к тем, кто пробовал нечто подобное.
0
Возможно программировать МК в .NET. Тоже неплохой изврат.
А вообще можно писать С++ на МК в любой среде, где можно задать свой компилятор и переназначить стандартные библиотеки.
0
Про .NET Micro я слышал и даже немного щупал. В принципе удобно, особенно если всю жизнь просидел на .NET. Однако для встраиваемых систем слишко высоки накладные расходы ресурсов для CLR. Помигать светиком на F4DISCOVERY — можно. А использовать как платформу для серии я бы не стал.
0
Вы имеете в виду Atmel Studio 6.1?
Да
Если да — вот у меня вопрос — а есть ли возможность использовать ее для сборки и заливки скажем в STM32?
Ээ… makefile проекты оно поддерживает — так что можно конечно…
«а сменить клапан ДВС через выхлопную трубу»
типа то и выйдет — не стоит этим заниматься.
в смысле слишком много граблей при прикручивании компилятора к MSBuild
MSBuild там роде как нету.
того хлеще отладчика
С этим вообще думаю труба — отадчики под ател тольо поддержаны — хотя всё возможно…
Лучше Эклипс пробуйте — он не хуже как редактор (MSVS несколько деградировала) и отладчик с JLink и регистрами периферии прикрутить можно без проблем. С STLink сложнее — но это я не пробовал, но тоже реально (смотрите про openOCD + texane)
0
MSBuild там роде как нету.
Эмм… ну как бы он обязан там быть по определению — это ведь родная система сборки MS. Другое дело что в AS6.1 оно может быть неустановленно по умолчанию — но никто не запрещает его добавить.

Лучше Эклипс пробуйте — он не хуже как редактор (MSVS несколько деградировала) и отладчик с JLink и регистрами периферии прикрутить можно без проблем. С STLink сложнее — но это я не пробовал, но тоже реально (смотрите про openOCD + texane)
Эклипс как раз пробовал — не смог свыкнуться с _другой_ IDE. Для меня он показался сверх неудобным и убогим (хотя быть может уже что то изменилось) по сравнению с MSVS.

Меня вот как раз интересует есть ли у кого реальный опыт прикручивания скажем GCC к студии и отладчика под STM32 (как самому популярному)?
+1
Эклипс как раз пробовал — не смог свыкнуться с _другой_ IDE.
Ничего там особо другого нет. Настриваете key binding как в VS и почти не отличишь.
Меня вот как раз интересует есть ли у кого реальный опыт прикручивания скажем GCC к студии и отладчика под STM32
Опыт есть — у этих. Но это ж know how — они за это деньги получают.
отладчика под STM32 (как самому популярному)
Под STM32 разные есть отладчики — Jlink, Ulink, STLink. Вам какой?
0
Вообще говоря, AS6 сделана на GCC и поддерживает ARM. Я полагаю, что если покопаться в потрохах (библиотечная поддержка, программы тулчейна — в частности, серверы GDB, различные конфиги, описывающие камни) — то можно и подружить AS6 c STM32. Правда, AS6 я еще не щупал, а вот AS5 разочаровывает — те части, что написаны атмелом изрядно косы.
0
… вроде CrossWorks снована на MSVS, но она платная
0
electronix.ru/forum/index.php?showtopic=102359 Может кому-нибудь интерсен будет IAR+MSVS.
0
Я только и пишу проги в студии. Начинал с 4й версии. Потом на 5ую перешел. Когда появилась 6я, пересел на нее. Так и пишу сейчас на 6й, ничего другого и не хочу. Так а тебя что именно интересует?
0
Речь о MSVS вообще-то, а не AVRStudio. MSVS 4-6 — знатная древность, хотя 6-я у меня есть)
0
для stm32 советую попробовать Em blocks ее тут и на хабре уже озвучивали, но она обновилась, добавили удобный визард для создания проектов под stm32, в том числе и под самые новые камни(stm32f429,stm32f030...) есть пример для новой stm32f429i-disco(подточенный для em blocks) вот, последний я пробовал запускать-работает, но сильно в среду не вникал, будет время разобраться — на нее перейду полностью если косяков не будет. Описание использованных лицензий среда скачивается без регистраций и ограничений, размер чуть больше 40 мегабайт
0
Забыл написать, дебагер встроен, после установки ничего допиливать не надо, поставил, запустил, сделал проект визардом, пиши и отлаживай…
0
Видел я этот em::blocks. Идея хорошая, но до юзабилити того же кокоса еще пилить да пилить. Хотя бы сделали подключение библиотек по щелчку мышки и поддержку большего числа отладчиков. Пока что это продвинутый блокнот с компилятором.
0
Пока что это продвинутый блокнот с компилятором.
И makefile project там трудно сделать…
Но кстати отладка там работает…
0
из отладчиков в последней jlink и stlink, библиотеки вручную не подключал, просто пока дальше запуска примера не пошел, проект со стандартными библиотеками собирается визардом(ничего вручную подключать не нужно)
0
SPL добавили только в последней версии — у меня стояла 1.4.2 и там даже точную модель камня нельзя было. К кокосовскому разнообразию либок под множество камней, а так же платформонезависимых (в основном херовых, но как примеры годятся) еще далеко.
0
Я сам не против заиметь нормальное IDE вместо остоебенившего эклипса, так что идея правильная. Но пока что это «кривоногий и хромой», полуничейный опенсорс.
0
С++ для микроконтроллеров, не нужно же, есть Си ^_^
0
Расскажи это neiver 'у.
+1
Ну, там чувак, ваще фанат ))
0
Фанатство тут ни при чем. Просто отличное владение инструментом.
+3
Это конечно всё здорово: ООП, шаблоны, умные указатели, но как это всё сказывается на размере программы? Да и разумно ли делать систему классов там, где вполне хватит несколько структур? Я так понимаю, это уже врос просто вкуса.
+1
neiver же демонстрирует — эффективность по крайней мере не уступает С, а во многих случаях С++ позволяет эффективно делать то, что на С сделать нельзя.
Хотя, конечно, применение С++ в эмбеде требует хорошего им владения. Не зря про С говорилось, что он подобен ножу мясника, к С++ это применимо в еще большей степени, и сделать на нем кровавое месиво вместо программы — раз плюнуть.
Да и разумно ли делать систему классов там, где вполне хватит несколько структур?
По большому счету классы и структуры — практически одно и то же. В том же С++ разница между ними как между указателями и массивами в С.
+2
Это конечно всё здорово: ООП, шаблоны, умные указатели, но как это всё сказывается на размере программы?
Положительно. И на качестве кода тоже. С некоторыми усилиями можно делать вещи, которые на обычном С не получаются.
Да и разумно ли делать систему классов там, где вполне хватит несколько структур?
Система классов вовсе не обязательная вещь. Так же как умные указатели. Как и любой другой инструмент, С++ в эмбеддед программировании нужно применять с умом.
+3
Положительно. И на качестве кода тоже. С некоторыми усилиями можно делать вещи, которые на обычном С не получаются.
Это смотря что с чем сравнивать, инструмент удобен для тех задач, для которых он предназначен(или где ему нашли достойное применение). Большой гвоздь можно забить и молотком и кувалдой, да вот только сапожные гвозди не кувалдой вбивают (не, ну можно конечно найти несколько мастеров, которые могут и кувалдой быстро и качественно все сделать в лучшем виде), да и костыли в шпалы тоже не молотком заколачивают… Я к тому клоню, что у каждого свои заморочки, и при достаточно хорошем владении чем либо, можно это применять там, где применяют только мастера, знающие как это будет работать и как в случае необходимости все исправить, не сделав хуже, но не дай бог чтобы туда залез кто неграмотный… поддержка кода… мать ее…
0
Вот для С++ с шаблонами в эмбеддеде и нашли достойное применение — писать читаемый и эффективный код. Да, сами либы писать могуть не многие, но пользоваться ими могут практически все. Причем делать это проще, удобнее и более поддерживаемо, чем код писанный, например, на SPL. Собственно, ровно та же ситуация, что и с C++ STL — пользоваться ею легко, но если залезть в пузо, то там сам черт ногу сломит и понять, как и что там работает, может далеко не каждый. Из этих соображений любые телодвижения по написанию универсальных кросс-контроллерных либ должны категорически приветствоваться.
+3
 Большой гвоздь можно забить и молотком и кувалдой, да вот только сапожные гвозди не кувалдой вбивают
У Вас некорректная аналогия.

Ели уж сравнивать ЯП с ручным инструментом — то ЯП это, скорее, не конкретный инструмент, а набор инструментов, который доступен разработчику. Такая себе коробка с ручным инструментом.
Язык С — это (согласно аналогии) «Универсальный комплект домашнего мастера». Отличный набор инструментов, есть все необходимое.
Язык С++ — это «Расширенный комплект домашнего мастера» куда помимо базовых инструментов входят некоторые более продвинутые. Возможно Вам ассортимент инструментов в комплекте покажется избыточным, но никто не заставляет вас пользоваться сразу всеми инструментами из «расширенного» комплекта.

Так и в данном случае с ЯП — я могу писать на С++ используя только подмножество средств С. Но, если мне нужно, я всегда могу воспользоваться «более продвинутыми» инструментами, которые предоставляет С++. Главное — уметь этими инструментами правильно пользоваться и понимать специфику их применения на МК.
+2
Перечитал свой комментарий — я перестарался с аналогиями :)

Давайте так: ели С — это «молоток», то С++ — это «кувалда», которую дают в комплекте с «молотком». Но сам «молоток» у вас не отбирают.

Итого — (при использовании С++) всегда есть выбор: использовать только «молоток», либо связку «молоток» + (при необходимости) «кувалда».
0
Недавно со мной произошла интересная (скорее даже поучительная) история.
Брат попросил сделать блок управления правИльно-отрезным станком. Сама задача элементарная донельзя — отмерить нужное количество выравненной проволоки и отрубить — справится даже tiny13. Сложность в конфигурировании заданий для станка. Кроме всяких калибровок, диагностики и т.п. оператор должен иметь возможность задать “программу” из набора шагов вида “отрезать X прутов длиной Y см”.
Технически это тоже легко. Сложно сделать, чтобы это все было удобно оператору.
Рассмотрев несколько вариантов, пришли к тому, что лучше всего иметь TFT экран с тачем.

Ну а дальше дело техники — за вечер была написана микро библиотечка для ГУИ (при ее максимальной простоте получилось довольно гибко и удобно в использовании), еще за пару вечеров реализована задача, ради которой все и затевалось.

Делалось все на отладочной плате с довольно жирным контроллером и кучей другого фарша, но с пониманием, что в финальном устройсве будет контроллер попроще.
Когда все было готово, ради спортивного интереса решил упихнуть все это дело в STM8S003F (8Kb Flash 1Kb RAM 16 ног). Единственная проблема — мало рама, а в первоначальном варианте библиотеки каждый элемент гуи ел довольно много. Решил чуть поменять реализацию.

В общем, в последующие дни библиотека переписывалась еще пару раз и, в итоге, при том же объеме ГУИ, все поместилось в порядка шестисот байт рама.
К чему я все это… Посмотрев получившийся код, я увидел, что чтобы ужаться в маленький объем флэша, я, по сути, реализовал на Cи систему классов C++. Только, если бы изначало делал все на C++, то половину работы, как минимум, сделал бы компилятор. А так пришлось все вручную.

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

P.S. А блок управления я все-таки сделал на чуть более жирном контроллере :(
Хотя самая ресурсоемкая часть ГУИ поместилась полностью — все же не хватило буквально пару килобайт,. Из имеющихся восьми только шрифт + стартап съедает 3. Чтобы поместиться в оставшиеся 5 нужно было еще раз более существенно прорефакторить подход (хотя все-равно не уверен что дожал бы), а времени уже не было — подходил дедлайн.
+2
У Страуструпа какие-либо абстракции языка гармонично вытекают из предварительно поданной базы, остальные упомянутые книги я к данному моменту воспринимаю как гораздо менее связанный набор описаний аспектов языка.

Он один из авторов данного языка программирования — идиология языка в подаче от разработчика — его врядли кто-то переплюнет :)

Спасибо что поделились. Респект, добро пожаловать.
0
По-моему Страуструп все же единственный автор данного языка, без учета библиотек шаблонов и прочего.
0
Дельное замечание, кстати…
0
По-моему Страуструп все же единственный автор данного язык

Я бы сказал, что он автор изначальной концепции и идеолог данного языка.
Современный стандарт С++ взят под контроль ANSI/ISO. И современный стандарт продвинулся намного дальше изначальной концепции.

Но это, безусловно, не уменьшает роль Страуструпа в становлении языка. И его книгу «The C++ Programming Language» я считаю «Книгой Книг» для данного ЯП. Ее, однозначно, стоить изучить (если Вам интересен данный ЯП). Несмотря на то, что вряд ли ее будут переиздавать в связи с введением нового стандарта, этих ваших автовыведений типов и прочего анонимного кода :)
0
Он же и его главный враг, IMHO. C++ с его подачи точился как язык прикладного программирования широкого назначения (при этом потребности системного программирования были забыты либо проигнорированы). Но жизнь показала, что такое позиционирование ошибочно, в прикладном программировании прочно закрепились языки типа жабы и шарпа, плюсы остались в довольно узкой нише. В итоге, там где он реально был бы наиболее востребован (критичные к ресурсам задачи, в том числе ембеддед), С++ может предложить только отдельные (хотя и весьма полезные) возможности (типа шаблонов). Все остальные низкоуровневые возможности остались на уровне С и зачастую требуют привлечения компиляторо-зависимых решений, что усложняет сопровождение и портирование на другие платформы. Ситуация отчасти смягчается наличием gcc, но это достижение не самого языка, а конкретного компилятора.
0
Ну, вообще-то, жаба и шарп моложе чем С++, и до них он был одним из основных языков в прикладном программировании. Да и сейчас жаба не слишком популярна в прикладном програмировании — ну, по крайней мере в том, что можно скачать и поставить.
0
С# моложе, жаба почти ровесница (96-й год, стандарт С++ появился в 98-м, до этого в плюсах был полный разброд и шатание среди компиляторостроителей). Что касается софта, то львиная его доля это софт, который делатеся конторами для себя (либо им его кто-то пишет) + всевозможные веб-решения + последние годы добавился софт для мобильных девайсов. Все перечисленное это что угодно, кроме плюсов (за очень редким исключением). Да и среди софта, который можно скачать и поставить тоже жаба попадается, хотя и гораздо реже. Скажем, Media Composer писан на жабе (кроме кодеков).
0
стандарт С++ появился в 98-м, до этого в плюсах был полный разброд и шатание среди компиляторостроителей
Разброд был, но язык уже использовался, так что я бы не назвал появление стандарта началом С++.
Что касается софта, то львиная его доля это соф
Ну, это все скрыто где-то в недрах компаний, так что не слишком много инфы снаружи о том, что там, что и на чем пишет. Я говорил о том, что распространяется, и там основном был С++ до прихода дотнета. Да и в тех задачах, о которых говоришь ты, ява сравнительно свежий язык, до нее много кто побывал. В России, например, внутренний софт нередко клепался на Delphi.
Да и среди софта, который можно скачать и поставить тоже жаба попадается, хотя и гораздо реже.
О чем я и говорю — попадается, но очень редко. А это тоже прикладной софт и подавляющая часть его на плюсах.
0
Разброд был, но язык уже использовался, так что я бы не назвал появление стандарта началом С++.
Я и не называл. Я имел в виду, что в промышленное прикладное программирование массово он двинулся именно с появлением стандарта. Так же как жаба двинулась примерно с появлением версии 1.4 (2002-й год). У С++ просто не было времени, что бы закрепиться и захватить эту нишу.
Ну, это все скрыто где-то в недрах компаний, так что не слишком много инфы снаружи о том, что там, что и на чем пишет.
Я, как бы, эту кухню знаю не по наслышке.
Да и в тех задачах, о которых говоришь ты, ява сравнительно свежий язык, до нее много кто побывал. В России, например, внутренний софт нередко клепался на Delphi.
«Сравнительно свежий» это примерно 10-12 лет в in house софте, 8-10 в веб софте. В мобильном софте очень активное внедрение пошло вместе с андроидом (хотя и Java ME тоже была заметна в этой нише). Впрочем, напомню, что речь не о жабе, а о С++ и его нише. В том же прикладном софте для мобильных девайсов его для массовых платформ нет вообще: андроид=жаба, айос=обжектив-С, винда=С#.
О чем я и говорю — попадается, но очень редко. А это тоже прикладной софт и подавляющая часть его на плюсах.
Только доля этого софта в прикладном программировании в целом весьма не велика.
0
Я имел в виду, что в промышленное прикладное программирование массово он двинулся именно с появлением стандарта.
Ну как сказать, 1998-й — это уже MSVC6, а оно и в более ранних версиях активно использовалось для прикладного программирования. Или ты опять про «заменить кобол»?
Я, как бы, эту кухню знаю не по наслышке.
Но, возможно, только на примере тех компаний, где работал, я ж не знаю.
«Сравнительно свежий» это примерно 10-12 лет в in house софте, 8-10 в веб софте.
Ну да, я о том же. Но С++ раза в два старше как минимум. В веб-софте да, ява популярна (По крайней мере в той области, которая мне близка — игровые серверы).
Ну а в мобильном софте выбора и нет. Хотя андроид — это Java+C++, там, где нужна максимальная производительность (кодеки видеоплееров, игры, etc) на яве только интерфейс или лаунчер, все остальное С++. Вот J2ME — ява без вариантов.
Еще некогда мобильный софт был под WinCE, это тоже С++.
Только доля этого софта в прикладном программировании в целом весьма не велика.
Ну уж не знаю, насколько велика, но для большинства людей это единственный прикладной софт, о котором они вообще в курсе. Да и у меня до вих пор именно с этим понятие прикладного софта ассоциируется.
0
Ну как сказать, 1998-й — это уже MSVC6, а оно и в более ранних версиях активно использовалось для прикладного программирования. Или ты опять про «заменить кобол»?
Не только. Кстати, там еще VB не хило выступает.
0
теперь вам пора взяться за Boost.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.