Check Levi9 best QA positions to Backbase team!
×Закрыть

Разные пути в С++, какой путь выбрать?

В данный момент устроиться на позицию Junior Developer очень тяжело, а если выбор среды обитания С++ то это практически невозможно ибо нужен опыт или очень хорошие знания. Но также проблема прокачать skills состоит в том что направлений несколько и даже больше, если (допустим) на Java это мир Android и Enterprise то есть их по сути два и можно спокойно определиться, а у .NET (C#) вообще 90% случаев это ASP.NET, когда с «плюсами» это :
1)Embedded
2)Game Developing
3)Desktop (MFC, Qt)
4)Low-level Dev (не Embedded даже близко как некоторые считают)
5)Серверные приложения (Хоть это и странно но я встречал такое под *nix)

— Это разные направления, по мимо того что сам С++ огромен и сложен, иногда кажется что он просто избыточен и слишком запутан да страшен, а также думается что он просто изжил своё в этом WEB-мире при том что на Windows его успешно заменяет C# в настольных приложениях и утилитах а также в Unity3D это основной язык. Иногда хочется переучится на что-нибуть иное, более перспективное и простое но я потратил 8 месяцев на его упорное изучение и хочу выбрать ПЕРСПЕКТИВНОЕ направление !
Из моих выводов (судя с вакансий по Украине) Game Developing — очень не плохо набирает обороты особенно казуальные и «смартфонные» игры, а там конечно могу ошибаться, но на то и вы есть, по этому подскажите по своему опыту, что делать? Куда податься? Хочу на работу и немного денег на хлеб (можно без масла).

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
5)Серверные приложения (Хоть это и странно но я встречал такое под *nix)
странно с какой именно стороны?

Тренинг центр глобала собирается набирать новую C++ группу, если у вас есть родственники, знакомые, друзья, которые хотят освоить C++ и пройти интервью, форвардните им линку:
docs.google.com/...gm6KlE/viewform

Пожалуйста, не нужно спамить все топики сообщением об этим тренинге.

К сожалению на ДОУ стоит защита и все топики заспамить не получилось ;)

Ну разве я не прав когда утверждаю что до уровня первого собеседования в какой-либо компании__ «С++» учиться дольше чем «Java» ?

Капитанская шапка сегодня вручается вам.

Да я же ничтожное быдло, куда мне до шапочки то, да ещё и капитанской ...

Мені цікаво, як адеппети вічно живого і переспективного С++ закривають очі на той факт, що в мобільних платформах С++ не дуже велкам.
В Андроїді там якийсь обрізок, що тягне на С+, ане С++.
Ядро на С, app на Java.
В iOS там Objective С ( хоча є місце для С++ із Qt).
Теж думаю що перевага віддається зв"язці С — ядро, Objective С — прикладны програми.

Як на мене, в мобайлі С++ іде боком.

ой :) да кому нужен ваш блэкберри ос :)
вроде ж можно на с++ и под андроид и под айос писать

могли би ще здехлий Simbian привести, там теж С++ та Qt

ББ не мертв. Ща пишу под плейбук, параллельно его пользую. И я вам скажу авторитетно, что андроид и иос делает глубокий минет с проглотом. То же самое они делают и по отношению к винде фон. Единтсвенное, в чем выигрыш — в количестве приложений, но эргономика и юзабилити у масс платформ хуже.

Я вот тоже юзал плейбук некоторое время — глюк на глюке, какие такие проглоты?

всё это чудесно, вот только плейбук не продавался должным образом. и RIM переживает самые лучшие времена.

Те що С++ ще живий, ніхто не заперечує, але те що він «перспективний», в цьому я маю дуже великі сумніви.
Так як доля мобайлу росте і буде рости, а ББ і Сімбіан — мають відносно малу долю.
Як ти уявляєш, скільки тих джедаїв, і хто ж буде г0вн0кодити всякий шлак?

Так що хом"ячки перемагають і вибирають зовсім не С++.

пока все нормально, акции выросли очень сильно, на 600 миллионов увеличился кэш за последний квартал.

цитата по вашей сслыке

Although RIM’s over all subscriber base has declined from quarter to quarter, RIM will be unveiling its next generation operating system, BlackBerry 10, on January 30, 2013. The company also claims that beta trials of BlackBerry Enterprise Service 10 are underway at more than 120 enterprises including 64 Fortune 500 companies.

RIM expects that the timing of the BlackBerry 10 launch event for January 30, 2013 could impact sales of current BlackBerry 7 products as some customers may defer purchasing decisions and wait for BlackBerry 10 devices.

Я поигрался новой осью, особо не впечатлило. Кроме того, те кто сейчас разрабатывают под ББ скорее всего перестанут это делать :)

неважною, мне непонянет ваш месседж:

в мобайлі С++ іде боком.

как раз во всем мобайле С,C++ и используется. даже Виндовс Фон8 разродились.

Наскільки я розбираюся в бізнесі, time to market один з основних чинників — «косо — криво, лиш би живо».
Якщо продукт «вистрілює», т потім серйозні дядьки хоч на асембері його допиляють, не те що на С++.
WP8, прост має таку фічу — хочеш пиляй С++.

А основна розробка на С#, чи не так?

надо писать на Джава, потому что С++ устарел и нинужен

"
В данный момент устроиться на позицию Junior Office Manager очень тяжело, а если выбор среды обитания английский язык, то это практически невозможно ибо нужен опыт или очень хорошие знания.
...

но я потратил 8 месяцев на его упорное изучение и хочу выбрать ПЕРСПЕКТИВНОЕ направление !

(facepalm)

Насчёт C++ server services сказано как-то странно. Есть масса случаев когда C++ - отличный вариант для таких вещей. Если нужно обрабатывать какое-то приличное количество событий и объектов на сервере то кроме C++ ничего вменяемого для Linux наверное нет:

a) память на миллионы мелких объектов и скорость обработки отсеивают всё скриптовое и java;
b) C не рассматривается из-за отсутствия ООП; прикладные области бывают достаточно сложными и C со своими структурами и указателями на функции тормозит разработку;

с) libstdc++, boost — великолепная основа по базовым компонентам, алгоритмам, структурам.

У меня лет 10 опыта реазизаций подобных вещей — network services, data processing services, event processing. Где возможно использую perl, python. Лучше C++ для high performance пока не встречал.

Насчёт C++ server services сказано как-то странно. Есть масса случаев когда C++ - отличный вариант для таких вещей. Если нужно обрабатывать какое-то приличное количество событий и объектов на сервере то кроме C++ ничего вменяемого для Linux наверное нет:

a) память на миллионы мелких объектов и скорость обработки отсеивают всё скриптовое и java;

Как показывает практика в гонке nosql баз данных, важна не только абстрактная row производительность но и возможность быстро эксперементировать c алгоритмами, и С++ здесь представляется не в лучшей красе сливая джаве.

Как показывает практика если кто-то лучше знает язык X то кому-то кажется что на языке X проще писать. Я например так думаю по поводу C++. Для прототипов, как мне кажется, удобней использовать perl/python, нежели чем довольно ограниченную по выразительности java (опять же, как мне кажется; ymmv).
Скорость обработки и размеры по памяти, с другой стороны, от «кажется» не зависят и java подходит разве что до определённого уровня потребностей по производительности и компактности представления данных.
Ещё момент — я не испрльзую nosql ни в одном из этих проектов. Все необходимые структуры данных организованы в памяти одного (довольно мультипоточного) процесса.

Можно попробывать поднятся над уровнем собственных предпочтений и посмотреть обьективные характеристики языков. А характеристики говорят следующее:
— у джава лучше toolchain, это и ИДЕ, и менеджмент зависимостей, и простое достижение кроссплатформенности, continuous integration, мониторинг, профайлинг, семплинг, анализ хипдампов в продакшне
— у джава больше либ и реализаций для разработки сложных мультипоточных приложений и сложных структур данных
— джава программисту почти не надо химичить с памятью. У с++ тоже есть выход в юзании всяких shared&smart pointers, но это сразу убивает производительность(она становится хуже джавовской) и увеличивает потребление памяти до уровня джавовского
— у джава в разы богаче экосистема либ

Все это делает джава программистов в разы продуктивнее при разработки нагруженных бекендов, о чем и свидетельствует рынок nosql, джава продукты легко заруливают c++ аналоги

и вообще у джава код в джва раза меньше занимает на диске!

Можно попробовать опуститься с небес и заценить следующие мысли:
— java как язык довольно убогая — сравни с C++, perl.
— наличие хорошего редактора — сомнительый критерий для выбора языка и компонент для разработки системы
— количество либ для разработки сететвых и мультипоточных систем лидирует скорее всего C++, но это не критерий — ты ведь будешь использовать всего одну, и она должна быть ооочень хорошей. Лучшие из того что есть в C++ и java на данный момент наверняка находятся на примерно одном уровне => это не критерий.
— работа с памятью в java быстрее чем в C++ ? Ты это сам придумал? Потестируй.
— насчёт экосистемы либ тоже здорово придумано. Я тут у себя в fedora linux если сделаю rpm -qa то увижу пару тысяч пакетов программ и библиотек, написанных на C/C++ и покрывающих функционала больше чем я могу представить.

— на java у меня тут работает vuze — отличный пример «шустрейшей» программы. Прорисовка gui-компонент в ней разве что не скрин-скроллится — и на том спасибо!

Всё это делает толпы java-программистов не более чем просто толпой java-программистов — со своей нишей, заблуждениями, системой beliefs и тд.

А для того чем я занимаюсь java совершенно не подходит:
a) она МЕДЛЕННАЯ в сравнении с аналогичными по сложности алгоритмами и подходами на C++.
b) жрёт МАССУ памяти по сравнению с аналогичными стратегиями выделения памяти и размещения объектов в C++.

c) Лично мне на java просто неприятно писать программы — синтаксис языка слишком ограничен.

java как язык довольно убогая

ти серйозно?

Лично мне на java просто неприятно писать программы — синтаксис языка слишком ограничен.

залізобетонний аргумент

— java как язык довольно убогая — сравни с C++, perl.

Она не убогая, она просто в другой точке баланса между предсказуемостью и читабельностью и перегруженностью фичами

— наличие хорошего редактора — сомнительый критерий для выбора языка и компонент для разработки системы

Почему, ИДЕ дает много плюшек которые сильно повышают продукривность при разработке большых и сложных систем

— количество либ для разработки сететвых и мультипоточных систем лидирует скорее всего C++, но это не критерий — ты ведь будешь использовать всего одну, и она должна быть ооочень хорошей.

Почему одну? Для разных задач много разных либ

Лучшие из того что есть в C++ и java на данный момент наверняка находятся на примерно одном уровне => это не критерий.

Это неправда, начать хотя бы с того что в стандартной библиотеке джава в пакетах java.concurrent & java.util намного больше стандартных и консистентных компонент на все случае жизни.

В с++ тебе нужно прикручивать кучу каких то слабостыкующихся компонентов, а для многих задач попросту нету ничего. Например типичная задача — асинхронный обработчик сообщений с пулом потоков и fork-join-ом на неблокирующих сокетах, в джаве есть либы где все работает из коробки, а в ц++ нужно велосипедить и велосипедить.

работа с памятью в java быстрее чем в C++ ? Ты это сам придумал? Потестируй.

Вот почитай: blogs.microsoft.co.il/...t-pointers.aspx

асчёт экосистемы либ тоже здорово придумано. Я тут у себя в fedora linux если сделаю rpm -qa то увижу пару тысяч пакетов программ и библиотек, написанных на C/C++ и покрывающих функционала больше чем я могу представить.

Из них 90% это какие то хелловорлды с которыми ты постоянно будешь ловить сюрпризы

на java у меня тут работает vuze — отличный пример «шустрейшей» программы. Прорисовка gui-компонент в ней разве что не скрин-скроллится — и на том спасибо!

Мы все еще о серверсайд?

она МЕДЛЕННАЯ в сравнении с аналогичными по сложности алгоритмами и подходами на C++.

Не критично, как я уже сказал инфраструктура и легкость экспериментирования с алгоритмами оказывается намного важнее

b) жрёт МАССУ памяти по сравнению с аналогичными стратегиями выделения памяти и размещения объектов в C++.

Жрет, но для кеширования есть уже много экономных out of heap кешей, а для короткоживущих обьектов память не так важна

c) Лично мне на java просто неприятно писать программы — синтаксис языка слишком ограничен.

К счастью твоя личная неприязнь на положение вещей не влияет

Всё это делает толпы java-программистов не более чем просто толпой java-программистов — со своей нишей, заблуждениями, системой beliefs и тд.

И только с++ уникальные и справедливые

&blockquote; Она не убогая, она просто в другой точке баланса между предсказуемостью и читабельностью и перегруженностью фичами

Ага, точка баланса java в этом срезе называется «убогая», «невыразительная».

>Почему, ИДЕ дает много плюшек которые сильно повышают продукривность при разработке большых и сложных систем

Потому что плюшки во время разработки не дают производительность во время исполнения, сколько бы ты их ни ел.

>Вот почитай: blogs.microsoft.co.il/...t-pointers.aspx

Какой-то еврей не до конца понял что такое shared_ptr etc и написал жалобную статью об этом. Ни слова о java. WTF?

>Из них 90% это какие то хелловорлды с которыми ты постоянно будешь ловить сюрпризы

С 96-го использую эти helloworld-ы как desktop-систему, сюрпризов как-то поменьше чем с windows/macosx. Так чтобы тебе было понятней — софта на java для десктопов на порядки меньше чем на C/C++. Соответственно и библиотек и средств для разработки больше, возможно на порядок-другой.

> Мы все еще о серверсайд?

А это тебе был пример по скорости работы java. Она чисто визуально медленней чем что либо написанное коряво на C/C++. Сейчас я ещё тут ps сделаю.. 5gb virtual / 277mb real. 25 минут CPU usage за 5 часов uptime. Это на каких-то 30 торрентов. Можно сказать ресурсов не ест, кстати очень популярный проект на java. Разработчики наверное очень любят плюшки редактора, но как видишь на качестве программы это сказывается довольно существенно.

>Не критично, как я уже сказал инфраструктура и легкость экспериментирования с алгоритмами оказывается намного важнее

Для этого есть perl, python. И ещё свора всяких скриптовых языков. Зачем себя ограничивать тормознутой и убогой java ? Воспользуйся тормознутым и богатейшим по синтаксису перлом! Хочешь библитоек? Так чтобы java стало страшно? Воспользуйся cpan.org.

>Жрет, но для кеширования есть уже много экономных out of heap кешей, а для короткоживущих обьектов память не так важна

Ага, эти кеши тоже написаны на C. В моём случае тут как-то посложней будет — обьекты все умные, любят таймеры, зависимости между собой, параллельную обработку, вспомогательные потоки для всяких интенсивных подзадач и тд. Не могу я взять сериализовать что-то такое и впихнуть в memcached (C!).

>К счастью твоя личная неприязнь на положение вещей не >влияет

Я думаю ты имел в виду свои личные положения вещей. Обратное тоже верно.

>И только с++ уникальные и справедливые

Ни в коем случае.

ИДЕ

— MS Visual Studio top1 IDE, гугл поможет

менеджмент зависимостей

— MSBuild

простое достижение кроссплатформенности

msvc + gcc + boost

continuous integration

CruiseControl, CruiseControl.NET, TeamCity

мониторинг, профайлинг, семплинг

dbghelp, BoundsChecker

анализ хипдампов в продакшне

это что, дебаг на продакшен окружениях, когда пользователи транзакции проводят )

— у джава больше либ и реализаций для разработки сложных мультипоточных приложений и сложных структур данных

boost, GitHUB, плюс все наследие С библиотек.

— джава программисту почти не надо химичить с памятью. У с++ тоже есть выход в юзании всяких shared&smart pointers, но это сразу убивает производительность(она становится хуже джавовской) и увеличивает потребление памяти до уровня джавовского

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

Между делом «shared» подмножество «smart pointers».

Оттолкнемся от высококлассной промышленной библиотеки boost. Ограничимся, для простоты одним типом: boost::shared_ptr:
* просто реализует идиому RAII, накладные расходы в виде счётчика ссылок минимальны shared_ptr
* boost::enable_shared_from_this интеграция счётчика в любой объект, такое себе псевдо-интрузивное поведение
* make_shared/allocate_shared позволяет размещать объект и счётчик в единожды выделенном блоке памяти.
* потенциальная дефрагментация, вызываемая частыми созданияvb shared_ptr, решается назначением отдельного аллокатора из той же библиотеки(small object allocators), если проблема имеет место быть.

Соль добавляется по вкусу в зависимости от требований системы.

Не зная броду, не лейте воду.

Все это делает джава программистов в разы продуктивнее при разработки нагруженных бекендов

Я Вас умоляю, я полтора года проработал рядом с такой командой. Единственный плюс, что патчить можно со скоростью мысли.
Система легла, дебажимcя час, потом за 10 минут готов фикс (линковать то ничего не надо, только синтаксис чекнули), зип архив, инпак на энваримент — прямо по живому, никакой процедуры развёртывания.

В таком случае — да, продуктивность просто зашкаливает, фиксим по 200 своих же багов в день )

MS Visual Studio top1 IDE, гугл поможет

MSBuild

msvc + gcc + boost

CruiseControl, CruiseControl.NET, TeamCity

Мне тоже импонируют продукты МС в этом вопросе, но там выше вроде речь шла про сервера на линукс.

то что, дебаг на продакшен окружениях, когда пользователи транзакции проводят )

В джаве это можно делать вполне безопасно, мне очень эта тема нравится

boost, GitHUB, плюс все наследие С библиотек.

Это абстракции, я там привел пример с обработчиком сообщений, как ты такое будешь делать на с++?

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

Вот например есть такой бенчмарк: flyingfrogblog.blogspot.com/...lower-than.html

ГЦ у жабы производительней чем у окамла по ряду причин

Между делом «shared» подмножество «smart pointers».
Оттолкнемся от высококлассной промышленной библиотеки boost. Ограничимся, для простоты одним типом: boost::shared_ptr:
* просто реализует идиому RAII, накладные расходы в виде счётчика ссылок минимальны shared_ptr
* boost::enable_shared_from_this интеграция счётчика в любой объект, такое себе псевдо-интрузивное поведение
* make_shared/allocate_shared позволяет размещать объект и счётчик в единожды выделенном блоке памяти.
* потенциальная дефрагментация, вызываемая частыми созданияvb shared_ptr, решается назначением отдельного аллокатора из той же библиотеки(small object allocators), если проблема имеет место быть.
Соль добавляется по вкусу в зависимости от требований системы.

Не зная броду, не лейте воду.

И какой вывод в контексте сравнения?

Я Вас умоляю, я полтора года проработал рядом с такой командой. Единственный плюс, что патчить можно со скоростью мысли.
Система легла, дебажимcя час, потом за 10 минут готов фикс (линковать то ничего не надо, только синтаксис чекнули), зип архив, инпак на энваримент — прямо по живому, никакой процедуры развёртывания.

В таком случае — да, продуктивность просто зашкаливает, фиксим по 200 своих же багов в день

И это тоже, но есть еще и другие факторы которые я частично расскрыл уже

Мне тоже импонируют продукты МС в этом вопросе, но там выше вроде речь шла про сервера на линукс.

cmake

Это абстракции, я там привел пример с обработчиком сообщений, как ты такое будешь делать на с++?

boost::thread, boost::signal, boost::signal2

Вот например есть такой бенчмарк:

We already have C++ code that solves the n-queens problem using logic programming with a variety of different allocation strategies. Adding another version of our benchmark using Boost’s shared_ptr

что там за код внутри их «n-queens» это надо ещё посмотреть.

Я как-то портировал игру с XBox на PC,
так вот такой кака-фрагмент
for(......)
{
char* c = new char[4096];
...
delete[] c;
}

просто летал на XBox, там шина как Амазонка, а вот на РС всё ушло в сад из за не эффективной работы с памятью и её дефрагментации.

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

И какой вывод в контексте сравнения?

Что в С++ нет проблемы с управлением памятью, её утечками и эффективностью, есть кривые запястья.

cmake

Не смеши мои тапочки, ему до мавена и прочих грейдлов, ну ты понял.

boost::thread, boost::signal, boost::signal2

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

We already have C++ code that solves the n-queens problem using logic programming with a variety of different allocation strategies. Adding another version of our benchmark using Boost’s shared_ptr

что там за код внутри их «n-queens» это надо ещё посмотреть.

Там в коментах есть много обсуждений и кода, вкратце после убирания копирования shared ptr и передаче его по ссылке и убирании потокобезопасности(оба действа уже явный читинг) получилось всего в 2.5 раза медленнее тормозного окамла.

Что в С++ нет проблемы с управлением памятью, её утечками и эффективностью, есть кривые запястья.

пока что бенчмарки говорят об обратном

Не смеши мои тапочки, ему до мавена и прочих грейдлов, ну ты понял.

Это тоже самое что говорить, что Perforce(Maven) лучше чем Git(cmake/msbuild). Каждому своё )

получилось всего в 2.5 раза медленнее тормозного окамла

Вопрос не в хаках, а в том на на каком коде тестируется, какая реализация берется за основу

это
for(......)
{
char* c = new char[4096];
...
delete[] c;

}

и это
char* c = new char[4096];
for(......)
{
...
}
delete[] c;

эквивалентно с точки зрения алгоритма и результата, но далеко не одно и тоже с точки зрения использования памяти как ресурса.

Этот бэнчмарк, сравнивает реализацию сборщика мусора в окамла и поведение памяти как ресурса в чьей-то конкретной программе «n-queens». И не более того.

Это тоже самое что говорить, что Perforce(Maven) лучше чем Git(cmake/msbuild). Каждому своё )

Ну обьективно же cmake сливает мавену, без всяких оговорок

Этот бэнчмарк, сравнивает реализацию сборщика мусора в окамла и поведение памяти как ресурса в чьей-то конкретной программе «n-queens». И не более того.

Та нет, вполне себе проливает свет на тормознутость shared pointers, приведи другой бенчмарк где они заруливают garbage collector.

Скорость работы аллокатора и gc в java — urban myth, известная ещё с 90х. Или толковый бенчмарк в студию, или перестань постить ложь.

С одной стороны — reality check — на java эффективных программ просто нет (i.e. аналоги на C/C++ эффективней), с другой — попытки доказать обратное наталкиваются на реальность и это воодит головной мозг java-иста в замешательство. Результат — странные сравнения яблок с апельсинами, например — cmake и maven.

Скорость работы аллокатора и gc в java — urban myth, известная ещё с 90х. Или толковый бенчмарк в студию, или перестань постить ложь.

Еще раз, я уже привел бенчмарк, чем конкретно он не понравился?

С одной стороны — reality check — на java эффективных программ просто нет (i.e. аналоги на C/C++ эффективней), с другой — попытки доказать обратное наталкиваются на реальность и это воодит головной мозг java-иста в замешательство.

бла-бла-бла, пол ecomerce серверсайда в мире на джава, куча банковского ПО, а вот с++ оттуда да, поперли.

бла-бла-бла, пол ecomerce серверсайда в мире на джава, куча банковского ПО, а вот с++ оттуда да, поперли.

Но там есть две вещи:
— трейдинговые системы таки еще на С++

— ушли в сторону джава потому что для простого индусского парня джава плиже

— трейдинговые системы таки еще на С++

Ну есть же заезженные контрпримеры: martinfowler.com/...icles/lmax.html

— ушли в сторону джава потому что для простого индусского парня джава плиже

По тем же причинам джава позволяет и бородатоми хакеру сосредоточится на задаче а не воевать с инфраструктурой

Ну есть же заезженные контрпримеры: martinfowler.com/...icles/lmax.html

от туда же
One was to write custom implementations of the java collections that were designed to be cache-friendly and careful with garbage
...
However when you are trying to process millions of transactions per second with minimum jitter, a GC pause becomes a problem.
...

However when you are trying to process millions of transactions per second with minimum jitter, a GC pause becomes a problem.

т.е. там где обычный сишник думает только о процессоре, им приходится думать за gc и jit — что бы скормить им то, что потом (может быть удачно) пойдет процессору.

это тоже самое как если бы в пшп пришлось бы всегда учитывать что
$i—
считается медленнее, чем

—$i

т.е. там где обычный сишник думает только о процессоре, им приходится думать за gc и jit — что бы скормить им то, что потом (может быть удачно) пойдет процессору.

Неправда, цппшнику тоже нужно будет нехило думать о памяти в таких условиях. В джава как бороться с gc уже тема изученная, есть и GCs которые делают все без пауз(azule) или с минимальными паузами(cms), есть и пулы обьектов и escape analysis что бы все это делать.

Почитай как hft программируют, там 80% запрещено использовать и тоже пилят кучу своих велосипедов.

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

да. но ему проще — у него все в руках напрямую

Что именно напрямую?

В таких задачах что в джаве преалоцируют а потом реюзают память что в с++, разницы нету

ну незнаю, если в java можно создать новый обьект в памяти, где сидит другой (ну не знаю, самый простой случай — в строке чет поменять), то это классно

я думал в этом случае всегда память уйдет в gc

Для того что ты написал есть простой масив чаров.
Ну и с чего ты взял что GC это плохо? В джава в эту тему инвестировано огромное количество ресурсов, которые позволили достичь результатов для которых в ц++ нужно писать много нетривиального кода.

Например джава не отдает память операционке, а реализует свои механизмы менеджмента памяти, т.е. на каждый new нету никаких syscalls, у каждого потока в джаве своя локальная куча, что позволяет достичь намного лучшей locality для кешей проца, и уменьшает количество преодолений барьера памяти что легко может дать прирост производительности на ровном месте в сотни раз. Что бы сделать такой же алокатор на с++ нужно что бы он очень тесно общался с внутренностями библиотеки тредов. Плюс нетривиально отслеживать когда переменная все таки становится доступной вне треда и надо ее переводить из локальной кучи в глобальную. Есть еще куча других оптимизаций которые есть в джаве изкаробки а для ц++ нужно инвестировать месяцы кропотливой работы и быть профессором для достижения аналогичного результата.

Для того что ты написал есть простой масив чаров.

я примерно представляю как выглядит хай-лоад код на java :)

Ну и с чего ты взял что GC это плохо?

gc не плохо. особенно если есть возможность отключить gc, сделать что-то быстрое, и «отпустить» гц на волю :)

в принципе я более менее нормально с гц работал и на .net и на php. надо просто помнить о нем, ибо программист лучше знает когда и что освобождать

Например джава не отдает память операционке, а реализует свои механизмы менеджмента памяти, т.е. на каждый new нету никаких syscalls

несистемный аллокатор — иметь отдельный хип — это дефолтная фича с\c++, что бы выделить память напрямую у системы надо явно попросить.

у каждого потока в джаве своя локальная куча, что позволяет достичь намного лучшей locality для кешей проца, и уменьшает количество преодолений барьера памяти что легко может дать прирост производительности на ровном месте в сотни раз. Что бы сделать такой же алокатор на с++ нужно что бы он очень тесно общался с внутренностями библиотеки тредов.

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

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

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

если функция закончит свое выполнение, значит обьект на стеке уже не нужен, ваш ко

кстати, я вот вспоминаю что в си мире можно подобрать подходящий аллокатор (для бинарника, если уж ломит указывать напрямую), выбрав, что важнее — скорость или память, есть всякие локфри аллокаторы, которые я так понимаю на уровне реализации создают все тот же локальный хип для потока (процессора)

если функция закончит свое выполнение, значит обьект на стеке уже не нужен, ваш ко

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

кстати, я вот вспоминаю что в си мире можно подобрать подходящий аллокатор (для бинарника, если уж ломит указывать напрямую), выбрав, что важнее — скорость или память, есть всякие локфри аллокаторы, которые я так понимаю на уровне реализации создают все тот же локальный хип для потока (процессора)

Можно наконфигурировать кучу глючных костылей, кто-ж спорит. Вопрос зачем если в джаве уже все вылизано и стабильно и проверенно временем

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

я о том, что в си есть масса разных возможностей , а не один наименьший общий делить.

Можно наконфигурировать кучу глючных костылей, кто-ж спорит.

дык это сделано как опция коммандной строки. мне ли говорить сколько опций у java ?

Вопрос зачем если в джаве уже все вылизано и стабильно и проверенно временем

вы говорите про silver bullet ? ок.
но в моем понимании java старается получить скорость за счет памяти. а это не всегда самое оптимальное решение

кому будет интересна супер-пупер оптимизация хипа, если он будет черпаться из свопа

я о том, что в си есть масса разных возможностей , а не один наименьший общий делить.

А про то что в таких случаях можно выделять место на стеке ты ошибся? КО оказался фейковый а в джаве решают реальные а не самовыдуманные проблемы?

дык это сделано как опция коммандной строки.

Опцию командной строки для алокатора с локальными кучами под поток в студию

мне ли говорить сколько опций у java ?
В джава тоже есть много опций, я даже некоторые тут упоминал.

Ну и зачем много опций если дефолтные настройки удовлетворяют 99% случаев?

вы говорите про silver bullet ? ок.
но в моем понимании java старается получить скорость за счет памяти. а это не всегда самое оптимальное решение

кому будет интересна супер-пупер оптимизация хипа, если он будет черпаться из свопа

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

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

А про то что в таких случаях можно выделять место на стеке ты ошибся?

нет. просто привел самый простейший пример, который инженеры java решили только кувыркаясь через голову

Опцию командной строки для алокатора с локальными кучами под поток в студию

LD_PRELOAD="/usr/lib/libtcmalloc.so"

Я уж не говорю что какой нибудь пыхпых потребляет ее в разы больше, и ниче, ты ж кодируешь.

даже какой нить пых-пых поспокойнее в этом смысле

benchmarksgame.alioth.debian.org/...=java&lang2=php

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

на реальном проекте, когда памяти не хватает, лишний десяток гигабайт памяти обычно «добавляют» новым сервером, так что не все так просто

нет. просто привел самый простейший пример, который инженеры java решили только кувыркаясь через голову

Ты не привел никаких примеров, в джаве обьекты замечательно выделяются на стеке, читать про escape analysis. Это не отменяет того что локальные кучи нужны когда выделить на стеке не получается как в примере который я привел.

LD_PRELOAD=«/usr/lib/libtcm

О, как все запущено, tcmalloc это не реализация локальных куч, это локальный кеш для большой кучи что бы уменьшить лок контеншн между потоками. Потом там обьекты все равно перемещаются в большую кучу.

даже какой нить пых-пых поспокойнее в этом смысле

benchmarksgame.alioth.debia

В очередной раз отсылаю к изучению матчасти по поводу того чем отличается инкрементальный gc в пэхопе от того что в джаве.

на реальном проекте, когда памяти не хватает, лишний десяток гигабайт памяти обычно «добавляют» новым сервером, так что не все так просто

Ну да, а в чем непростота добавления сервака в второе десятилетие 21-го века то? Вот у меня это одна команда.

О, как все запущено, tcmalloc это не реализация локальных куч, это локальный кеш для большой кучи что бы уменьшить лок контеншн между потоками. Потом там обьекты все равно перемещаются в большую кучу.

ну там для каждого потока выделяется свой блок, что собственно и является локальным хипом, не ?

Ну да, а в чем непростота добавления сервака в второе десятилетие 21-го века то?

деньги

ну там для каждого потока выделяется свой блок, что собственно и является локальным хипом, не ?

не, выделенный блок памяти это еще не куча представь себе

деньги

Ну вот практика и показывает что выбрать джаву где не нужно писать кучу кода для ручного управления памятью оказывается дешевле чем ц++, пусть и проигрывая немного по памяти и переплачивая опять же не так уж много за сервера

программист лучше знает когда и что освобождать

я це, думаю, занесу в меморіс

Еще раз, я уже привел бенчмарк, чем конкретно он не понравился?

опять, сорок пять )
Для того о чём тут идёт спор, человечество уже давно придумало решение — статистика называется.
Чтобы о чём-то говорить с определённой долей уверенности необходимо иметь результаты для так называемой репрезентативной выборки.

Чтобы сказать: С++ гавно, нужно взять некоторое множество систем (например 100), которое покрывает интересующий Вас сегмент, и провести на нём испытания.

Другими словами: пример никогда не может быть доказательством, пример всегда только лишь иллюстрация.

Та нет, пример наглядное доказательство что shared pointers сасутнипадецки

всегда есть другая сторона медали.
— java хуже тюнится под производительность там где надо выжать все
— java больше жрет памяти, что иногда очень важно

benchmarksgame.alioth.debian.org/...are-fastest.php

Это все правда, вопрос насколько такой проигрыш критичен по сравнению с выигрышем?

лично я отказался от java-based иде в пользу vim в том числе из-за соображений скорости (иначе даже мысли не возникло бы искать замену)
на работе переписали один сервис с java на nodejs — оно хоть стало стабильно и шустро работать (тут, конечно, много разных моментов, но java сервис неоднократно пытались «починить» разные люди, но вот не шло)

и да это все мои личные частности, но все-же

почти не надо химичить с памятью

я просто не в курсе про джаву, разве кроме GC программер как-то управляет там памятью?

Подозреваю, что есть стронги и софты, или что-то похожее, но нет никаких ретейнов и релизов?

Нету, химичить можно на уровне -
— прятать обьекты от GC в каком то off heap сторадже
— тюнить и менять GC

— использовать escape analysis что бы выделять память на стеке

еще одну проблему вспомнил — java не очень устойчива против reverse-engineering, т.е. в областях, где продаются бинарники — это неприемлемо

Есть и всякие обфускаторы и компиллеры в нативный код для джавы

ну обфускаторы безполезны, разве что всю jre заобфускировать.

Базы данных — это не единственные вещи, с которыми работают серверные системы. На сервере так же могут выполняться довольно сложные вычислительные задачи, далеко не все из этих задач можно решить вовремя и в полном объеме на Java, в сравнении с возможностями, предоставляемыми языком С++.

Ну расскажи про такие задачи пожалуйста

HipHop for PHP isn’t technically a compiler itself. Rather it is a source code transformer. HipHop programmatically transforms your PHP source code into highly optimized C++ and then uses g++ to compile it

HipHop for PHP

После этого

...However, C++ is already far too large for anyone to understand it all perfectly...

но коментс )

Они переходят на jvm не потому что С++ плох, а потому что они его не понимают. Ну ок )))

Это ты высосал из пальца, это было личное мнение автора статьи а не коментарий инженера фейсбука.

Ну и да, это распространенное мнение что с++ перегружен фичами.

Это ты высосал из пальца, это было личное мнение автора статьи а не коментарий инженера фейсбука.

ваще там автор статьи из факта, что инженеры facebook посетили конфу, высосал из пальца что они заменяют hiphop.

с тем же успехом можно сказать что фейсбучек юзает какие-то жавовские вещи и зашли посмотреть на новую вм

Они походу вообще свою ВМ написали в результате: www.infoq.com/...cebook-HHVM-JIT

а то я не в курсе :)

в январе-феврале начнем переводить свою инфраструктуру

Моделирование сложных систем, обработка графической и звуковой информации и т. д..

Обработка аудио видео это Ок, тут традиционно джаву не применяют.

А wtf моделирование сложных систем?

C не рассматривается из-за отсутствия ООП;

ти серйозно?

Почему не хотите попробовать Objectiv C ?

Здесь может быть только два пути, это :

1) Java
2) C#

Зачем ломать голову и тратить время на ужасный С++, всёравно зат*рахаетесь и бросите ибо уже задаёте такой вопрос. Если бы вам он был так интересен вы бы не спрашивали : чё делать дальше ? Потому что если бы вы его любили как родной инструмент вы бы колупались в нём до последнего и зубрили всё что с ним связано ! С++ очень очень страшный, запутанный, сложный, не красивый, захламленный язык ! Он просто по природе своей ужасен !!! Это очень скользкая дорожка, так как через 2 года его изучения вы будете либо вменяемым разработчиком либо потратите время зря и можете умереть от жалости к себе ! C# - очень хорош и даже более, он зашибенный, после «плюсов» он как новый мерседес (и к стати мерседес купить можно быстрее и легче зная C# или Java чем С++) ! Java — мне она показалась редким говнищем после C# и только через 60 дней перечитывая Хорстманна и Эккеля я понял что не такое оно уже и д*ерьмо, а ещё через месяц даже понравилась но тут дело вкуса, хотя явно это всё намного лучше С++ ....

ха ха прикольно «страшниый и ужасный С++» :)

template < typename T, date_t D >
class dr_evil
{
void kill_all();
public:
void destroy() { kill_all(); collider::start(); }

};

dr_evil<earth, make_date(21,12,2012)> dre;

dre.destroy();

В GameDev’е даже на джуниора надо знать кучу всего. У меня такое впечатление, что в гейм дев компаниях даже уборщицу спрашивают про 3д математику, алгоритмы, железо, гапи и всякую лоу левел всячину. Думаю, в эмбеддед так же. Если взять всякий казуальный\мобильный геймдев, то там днем с огнем не сыщешь С++ вакансии — в основном Юнити\говнококос.
Про десктопный дев даже и не знаю, что можно сказать... Я не знаю ни одной компании, которая бы выпускала свой софт. Потому это скорее всего унылый аутсорс\багфикс какого-то древнего говна мамонта.
Вакансий на сервер под плюсами вообще не видел. Сомневаюсь, что будет широкий выбор для перехода.

А вы в своем Crytek разве не под десктоп пишете?

Про геймдев я говорил отдельно. Crytek помимо десктопов еще и под консоли с мобильниками пишут.
З.Ы. К сожалению, он, Crytek, не мой. Я там только работаю.

А ты хочеш казуальные игры на CryEngine писать чтоли?

ШОК!!!11 СЕНСАЦИЯ!!11! www.fibble.com казуальная игра на CryEngine

На плюсах в Украине сейчас делается достаточно большое количество мелких и средних интересных проектов. Это очень бывает пресловутое «банковское ПО», так что хороших вакансий для опытного разработчика хватает.

Вот еще news.finance.ua/...12/08/29/286519

— Qt и embedded — если связался с одним, то, скорее всего, будет и второе, и лоу-левел за одно.
— Сервер сайд — да, бывает такое, народ лепит какую-то корпоративную ахинею с темплейтпами восьмерной вложенности, под которой мейнфреймы ложатся... (по слухам)
— Game-dev — мало платят (тоже по слухам)...
— MFC ыз дэд, бейби.

:)

Qt-проекты очень часто бывают только под десктоп и даже только под Windows, например.

Qt-проекты очень часто бывают только под десктоп и даже только под Windows, например.
Да. Но после смены двух-трёх Qt-проектов легко обнаружить себя конфигурирующим ядро.

Ага, и ковыряющим Buildroot или Yocto :)

— Game-dev — мало платят (тоже по слухам)...

Правда, скоро на собеседования буду ходить с молоточком. Как только затянут: «геймдеееввв, это же интерееееестно, зачем вам столько денег?» Молоточком по переносице тюк

А вы еще предлагаете вам разрешить огнестрел носить :-)

1)Embedded

4)Low-level Dev (не Embedded даже близко как некоторые считают)

На самом деле Embedded включает в себя Low-level Dev полностью.

Да ладно, а когда пацаны копающиеся во внутренностях баз данных оптимизируют всякие векторные операции это тоже embedded или не low level? Или тоже самое для HFT например?

Да ладно, а когда пацаны копающиеся во внутренностях баз данных оптимизируют всякие векторные операции это тоже embedded или не low level? Или тоже самое для HFT например?
И где тут low level?

Берешь красную пилюлю — остаешься в Стране Чудес, а я покажу тебе насколько глубока кроличья нора.©

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

хотя mobile game dev наверное неплох с точки зрения поиска прямых заказчиков, ну или можно относительно легко перепрыгнуть на apple и все такое

Разные пути в С++, какой путь выбрать

ПЕРСПЕКТИВНОЕ направление

С і Java — lingua franca, їми тре володіти, а С++ то для динозаврів.

В данный момент устроиться на позицию Junior Developer очень тяжело, а если выбор среды обитания С++ то это практически невозможно ибо нужен опыт или очень хорошие знания.

Я бачу ситуацію ти прекрасно розумієш, то нащо тобі плюси?

Иногда хочется переучится на что-нибуть иное, более перспективное и простое но я потратил 8 месяцев на его упорное изучение и хочу выбрать ПЕРСПЕКТИВНОЕ направление !

Зроби це раз, така ситуція буде повторюватися постійно і не бійся починати з нуля у чомусь новому.

Попробую скомпоновать для Вас грешное с праведным.

По поводу выбора языка. Тут все как в жизни: «у Вас может быть много женщин, но всю жизнь Вы будете по-настоящему любить только одну». Если плюсы Вас прут (как впрочем и меня), то смело выбирайте это направление, такая «любовь» позволит не перепрыгивать с технологии на технологию при малейших колебаниях на рынке. Ну и как советуют гуру: «занимайся тем, что нравится» и конечно, «меню можно и нужно смотреть» )

Любая ИТ технология требует постоянного самообразования. Плюсы не исключение, а даже такой себе флагман.
8 месяцев?!?!?!?

В своё время я трижды перечитывал Александреску и только после этого мог сказать, что я точно понимаю, что автор имел ввиду. В этом направлении лучше не питать иллюзий, С++11 уже почти на всех экрана страны )

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

GlobalLogic/AVID
+ Top employer, офис/страховка/...

— Maintenance, сильно не разгонишься

Epam/Barcap, Epam/UBS
+ Top employer, офис/страховка/...
— Maintenance

Прикладной домен — финансы. Для кого-то может быть плюсом, для кого-то минусом.

Luxoft/UBS

Аналогично Epam/Barcap, Epam/UBS

Luxoft/AMD

+ Top employer, офис/страховка/..., Разработка новых продуктов, сильная техническая база

Ubisoft, Crytek
+ Фаново, нет сильных ограничений на «велосипеды»

— Компенсация

Viewdle

+ Погоны Гугла, Очень сильный С++ и математика.

update:
Samsung
+ R&D, почти как геймдев

— Компенсация

Materialise, Materialise Dental
+ Хороший коллектив, серьёзная математика(3D, графы) на плюсах

— Компенсация

еще бы добавил Samsung, при желании можно и интересным чем-то позаниматься, и разным.

Влад, а почему отсутствие ограничений на велосипеды — это плюс? В юбисофте каждый джун имеет за честь написать свой «оптимизированный» STL? :)

он малий грає в Rayman (я так розумію by Ubisoft), нарікань нема

Антон, я имел ввиду немного другое. Как раз переписывать STL можно только в ситуации крайней необходимости и во время кризиса среднего возраста (senior23+10), раньше нельзя )

ТС начинает карьеру и в этот период возможность набить своих шишек также важна как и хороший лид, который может направлять в нужное русло.
Поэтому «некоторая» свобода «велосипедности» даже для junior-а должна быть.

А вот Александреску. он сильно помог Вам? Я не троллю, просто интересно)

Вы же понимаете, что нельзя просто так оценить вклад какой-то отдельной книги или статьи. Невозможно выделить знания полученные из книги Александреску от книг Страуструпа, Саттера, Мейерса, Майерса, Джосаттиса, Вандервуда, Таненбаума, Рихтера, GoF, ...
Тут я троллю немного )

Если серьёзно, то безусловно — да. Это был отличный базис для погружения в boost::mpl. Конечно лучше перед Александреску прочитать «Шаблоны С++. Справочник разработчика». У меня получилось наоборот, так что потерял прилично времени.

* Базовые концепции, такие как Loki::Int2Type и Loki::Type2Type и списки типов. Без них просто никуда и в бусте они не видны, даже если начинать с рефмануала.
* Использование стратегий, потом GoF воспринимается не как нечто академическое, а как реальный кладезь.
* Мультиметоды, как пример пограничной зоны, которая не доступна в языке прямо из коробки.
* Концепции языка D воспринимаются естественно и как хороший компромисс.
* ...

И кстати, у меня есть отличный лакмус, когда я встречаю резюме синьора 1989 года рождения, у которого написано: MPL, Loki, c boost-ом с первого класса вместе.

Я просто прошу назвать аналоги для Loki::Int2Type и Loki::Type2Type из буста )

Конечно лучше перед Александреску прочитать «Шаблоны С++. Справочник разработчика». У меня получилось наоборот, так что потерял прилично времени.

У меня вышло точно так же. Я просто применения многих из перечисленных концепций видел довольно редко, хотя я не так много всего видел пока (я 90 года рождения).

По моим субъективным наблюдениям C++ потихоньку возвращает себе популярность. Я сужу по количеству вакансий в рассылках и внутри компании, фриланс проектов и поступающих предложений.

Я плотно подсел на Qt и весьма доволен. Сейчас занимаюсь разработкой для BlackBerry 10, но уже в следующем году Digia обещает официальную поддержку iOS и Android. При желании смогу уйти обратно на десктопы, хотя мобильный рынок более перспективен.

Embedded и gamedev, по-моему, наиболее интересные направления, после мобильной разработки. Серверную разработку никогда не пробовал, думаю, что в основном это сервера онлайн-игр или какие-то финансовые приложения. По embedded Linux нередки вакансии, но там уже больше C и редко C++.

Новичку я бы рекомендовал податься во фриланс, но это уже личные предпочтения. Недавно Luxoft рассылал что-то на тему порекомендуйте Junior C++, значит вакансии тоже должны быть.

фриланс для новичка еще и на плюсах?

вы, должно быть, шутите...

Отнюдь, всё зависит от способности к самообучению и желания, по-моему... Я в отечественный аутсорс из фриланса пошёл чисто из любопытства, изнутри посмотреть на то, о чём все говорят.

Платят, embedded linux видел даже $4k+, но чистый C, а не плюсы.

так хто ж в ядро з плюсами лізе?

Ого, это где так? У меня сложилось впечатление, что в среднем предлагают 1500-2000 у.е.

Да уже 2 конторы такое присылали, но т.к. я о разработке для ядра имею очень поверхностное представление, то соответствие реальности неизвестно.

...С++ огромен и сложен, иногда кажется что он просто избыточен и слишком запутан да страшен, а также думается что он просто изжил своё в этом WEB-мире

Надемеся, что еще не изжил. Вот постоянные вакансии jobs.dou.ua/.../vacancies/1553, постоянно берем trainee. Не Game Developing, но все серьезно.

---Один-три года опыта работы с языком C++.--- Судя с вакансии

— Это не особо похоже на уровень

trainee

Вы не поняли — в платной вакансии на ДОУ — требования опыта — это не вакансия стажера. А вакансии «treinee» мы публикуем на собственном сайте. И как все это происходит для стажеров там тоже описано.

Целых 8 месяцев? Это даже не смешно. Я, к примеру, потратил 2 года в школе на Паскаль. Мне что ли до пенсии на нём писать? Бросать то жалко!

Это разные направления, по мимо того что сам С++ огромен и сложен, иногда кажется что он просто избыточен и слишком запутан да страшен, а также думается что он просто изжил своё в этом WEB-мире при том что на Windows его успешно заменяет C# в настольных приложениях и утилитах а также в Unity3D это основной язык. Иногда хочется переучится на что-нибуть иное, более перспективное и простое но я потратил 8 месяцев на его упорное изучение и хочу выбрать ПЕРСПЕКТИВНОЕ направление !

Все правильно, учи джаву, если вовремя не перестроишься, потратишь безсмысленно намного больше чем 8 месяцев.

стоит ли плюсы изучать для «первого» языка? более менее знаю паскаль

нужно начать с С#, а потом всю жизнь боятся С++ :)

С выводами, что С++ «изжил свое» лучше не торопится,
вся серьезная софтина написана на нем и еще многие
годы будет писаться именно на нем. И альтернативы

пока нет.

Не в том дело какой язык учить — без хлеба не останетесь

в любом случае.

еще многие
годы будет писаться именно на нем. И альтернативы
пока нет.
==========

Амінь і Алілуя! (3 рази)

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

В игрострое математика сплошная и не слабая ...

А Джуниор так вообще будет работать за чебурек !!!

Насколько меньше чем не в геймдеве ?

Тут много зависит от движка. Даже XNA реализует процентов восемдесят нужной математики.

Подписаться на комментарии