Будущее C++ программиста в Windows или переходить ли на Linux
Наблюдая вакансии за последние пару месяцев, вижу, что 95% вакансий для С++, связаны с Linux. Остальное — суппорт приложений, написанных в конце
Leonid Kotov, C++ Software developer
Facebook
Twitter
LinkedIn
flyman
ось воно, майбутнє:
«безбашенний вєдроід»
headlessandroid.blogspot.com
Denis PRO
почему только Линух или Виндовс, есть еще вот jobs.dou.ua/.../vacancies/19375/?from=jd
Mike Gorchak
ТС не хочет: dou.ua/...orums/topic/13969/#714920
это интересно, но еще уже ниши моих доменов. если бы такие вакансии в Киеве попадались чаще — можно было бы повторить материал.
Busted Gipsy
Есть такое мнение, что Rust взлетит. Может стоит переходить на Rust? В Linux там ведь ANSI C, что там делать С++ программисту?
reality_hacker
Может для c++ корпоративный поезд уже уехал, а в линукс c++ еще не приехал?
І не приїде.
В ядрі Торвальвадс їх забанив, туйова хуча ліб на С (є збоченці, що пишуть врапери для ++), а в юзерспейс крім ++ є на чому розвернутися.
А ембедедС++ так і не взлетів.
Вот вот вот, и я о том же. Есть еще некоторые энтузиасты типа PocoProject, но это скорее исключение, чем правило.
На DOU есть Mirantis, у них куча корпоративного™ кода под Linux на C++.
Qt есть, давно, FF/Opera/Chromium. KDE.
Нет мнения, что C++ это светлое будущее. Совсем нет.
minodvesP Vasya
еще есть Nim, Go и D) которые тоже вроде как могут взлететь (особенно Go, ибо гугл).
Я Nim сейчас как раз решил попробовать. Прохожу туториал, описание и фичи языка звучат круто, но не понятен момент с многопоточностью и thread local сборщиком мусора. Мне кажется, у программиста могут возникнуть проблемы с безопасным использованием памяти и синхронизацией между потоками.
Go да, но там опять же с производительностью проблемы судя по тестам сравненительно с Rust/Nim/D (в контексте языка для системного програмирования).
насчет Go — может так и есть насчет производительности. Но я недавно немного его (Go) посмотрел — симпатишный язык как по мне)
Го — это язык с сборщиком мусора, и обедненными возможностями, скорее помесь Си и питона.
Ним, Д уже не взлетели, раст — пока что самый перспективный заменитель ЦПП.
раст — пока что самый перспективный заменитель ЦПП.Судя по количеству depricated проектов на нём, летит он только вниз. Чудовищный язык, как по мне. Дёрнул какие-то мои потаённые струны конструкциями let из бейсика, println из паскаля, идеи из Ada, типизация из фортрана. В той нише, в какой они его позиционируют «Rust is a systems programming language » IMHO не взлетит никогда. Я не вижу ни единого его преимущества, только недостатки. То, что на С/C++ делается уанлайнером, там городятся дикие конструкции из unsafe { } и это systems programming language? Потоки для домохозяек, но никак ни для systems... We don’t need no water, let the motherfucker burn. Burn motherfucker, burn.
Судя по количеству depricated проектов на нём, летит он только вниз.Ну это хипстеры такие, у них запал быстро пропадает, нужно смотреть на динамику — депрекейтнутые против выживших и появившихся.
Ну и стабильной версии языка вроде только 3 месяца стукнуло, еще все только начинается.
Дёрнул какие-то мои потаённые струны конструкциями let из бейсика, println из паскаля, идеи из Ada, типизация из фортрана.Я бы сказал это помесь ML и С++.
Я не вижу ни единого его преимущества, только недостатки.По сравнению с Ц++ более безопасная семантика работы с памятью, нету ада из шаблонов, ну и в Ц++ все больше напихивают и напихивают, а раст имея богатые возможности в тоже время остается языком с достаточно ограниченным количеством фишек. Ну и возможно им удастся построить более [правильную экосистему, пример: cargo.
Потоки для домохозяек, но никак ни для systems...Что не так с потоками?
Что не так с потоками?Они там на уровне stdlib в с++ - т.е. для галочки. Практическое их использование возможно ну разве что при написании HTML5 движка браузера, для чего этот язык и сделали, где нужно очень простое параллельное исполнение кода, но на все остальные особенности многопоточного выполнения кода они не обращают внимание. Нет поддержки TLS, зато ввели какой-то недетерминированную message-passing функциональность между потоками. Вот и получается, fast, safe but dumb language.
thread local storage там есть, кидаться месседжами через каналы сейчас новая модная фишка. А чего еще не хватает?
Дедлоков, недетерминированности и прочих прелестей отладки «непростого» параллельного кода, судя по всему.
На что именно они должны обращать внимание?
И что мешает желающим сесть и написать то, что им надо.
thread local storage там естьДа, снимается замечание — уже есть.
кидаться месседжами через каналы сейчас новая модная фишкаЭтой фишке уже лет
А чем не подходит реализация управления потоками в C++11? Если недостаточно async и futures, то есть низкоуровневые thread и promises. мьютексы, condition variables. Есть также thread_local переменные. Все, что предоставляет win API касательно потоков.
А чем не подходит реализация управления потоками в C++11?Тем что ее можно юзать только из ц++, а не клевого молодежного и хипстерского языка раст.
Уже это тут обсуждали: нет задания размеров стека, приоритетов, affinity mask и многих других вещей.
Go метит в нишу Java приблизительно. Не столько потому, что они так хотят, просто в другую у них уже не получится. И сейчас они последовательно наступают на те грабли, которые Java прошла 10+ лет назад. В плюсах у них нативная компилируемость.
D и Rust это попытки переписать C++ по-человечески.
D через GC изначально, Rust через статический анализ времени жизни.
Nim мог бы подвинуть Python, или возродить нишу (Object) Pascal.
Скриптовый язык с нативной компиляцией.
Ivan
В Rust есть все, чего не хватает в С ИМХО.
P.S. brendan -> laptop -> sticker: pbs.twimg.com/...media/CIboBooWsAIIfFR.jpg
Сергей Свистунов
Не знаю насчет коммерческой разработки, меня это всегда мало интересовало, сам пишу на C++ уже десяток лет, именно под Windows (и не только), и бросать не собираюсь.
Но это не мешает мне также использовать другие технологии и языки. Просто для для конкретной задачи выбираю наиболее подходящий язык.
В принципе, мне абсолютно плевать, что востребовано, а что нет. Главное, что язык живет и развивается. Выходят новые библиотеки и инструменты. И с введением новых стандартов мой интерес к C++ только увеличился. Значит, язык кому-то нужен. Просто задачи реализуемые на С++ стали сложнее. Если вы способны справляться с задачами в новых реалиях — оставайтесь. Если нет — выберите что-то попроще и попопсовее.
Значит, язык кому-то нужен.Он нужен паре десятков корпораций которые на нем пишут свои продукты (МС, гугл, циско, джунипер, американская оборонка, и т.д.), если ты в этих корпах, то да, есть востребованность, если нет, то есть риски с поиском жирной работы.
Windows NT во многих вещах лучше Linux. Архитектура системы безопасности, например, изначально была дискреционная. Потоки в NT были изначально заложены, а не доделаны. Просто при создании Windows учли прошлый опыт. Все верно — раз стандарт выходит на уровне ISO, то язык нужен. Спрашивается — кому именно нужен? Тема как раз и была поднята, чтобы определить наиболее востребованные направления использования C++. Об этом хочется услышать. В частности, интересует С++ разработка корпоративных приложений — реально ли использование обновленного C++ для создания enterprise приложений. Уходить отсюда не хочется по понятным причинам =). Но если уходить, то куда, наверное в смежные области, а не в экстрим.
Мне предлагали писать веб-сервисы на C++ на удаленке в одной американской компании.
docs.google.com/...pm7CzTLzvH74p67y7P2I/edit
И хоть под их требования я в принципе подходил, я отказался. Посчитал, что это для меня тупиковый путь развития.
«XML UML JSP» — Как UML попал в середину, по какой логике — по рифме... Дальше PRC services. Может и есть такое P R C, за всем не уследишь. А я бы не отказался, даже интересно. Только вот есть вероятность финансовой недисциплинированности в разного рода удаленных проектах. А в чем именно тупиковость?
Windows NT во многих вещах лучше Linux.
Интересно, к чему Вы это сказали, если вопроса у предыдущего оратора об этом не было. Но вдвойне интереснее то, что да, во многих вещах лучше, но ни одну из них Вы не назвали, а то, что назвали, никак не является преимуществом.
В частности, интересует С++ разработка корпоративных приложений — реально ли использование обновленного C++ для создания enterprise приложений.
Enterprise это «внутреннее ПО» по Спольски, это коммерческое платное, или какое-то ещё? Термин слишком абстрактный.
Но если уходить, то куда, наверное в смежные области, а не в экстрим.
Экстрим это путевые обходчики или дворники? Второе обычно более хлебное, насколько я знаю.
Из пустого в порожнее — извините, без меня
Сами первый начали, теперь жалуетесь.
я дивлюся на з/пл С++ і хочеться обняти адептів хрестів і плакать
не стоит плакать. выучите плюсы и сможете поднять свою нищенскую з/п до уровня плюсовиков
для тих хто в танку
я дивлюся на з/пл С++....
Де дивитеся? І з чим порівнюєте? Я не для того щоб суперечку почати, просто люблю на графіки і діаграмки дивитися.
я дивлюся тут
jobs.dou.ua/salaries
і порівнюю з жабістами або пітоністами
а ти де?
А дивлюся там де показують :) Ось, наприклад, багато цікавої статистики — stackoverflow.com/...rch/developer-survey-2015. Про гроші там в частині VI.
я покищо в неньці,
а тут так: що добре українцю, то зле буржую
Только что на доу нашел объяву —
...Одеська компанія Augmented Pixels шукає крутого C/C++ девелопера для розробки системи у сфері робототехніки. Зарплата від $4000...
Не знаю что они подразумевают под словом — “крутого”, но з/п очень даже ничего, как для Украины.
You have to perfectly know what is Kalman or particle filters, Bayesian estimation, Monte Carlo localization etc.
думаю, щонайменше менше Ph.D
что они подразумевают под словом — «крутого»,Чтоб не пил, не курил,
И цветы всегда дарил.
В дом зарплату отдавал,
Тёщу мамой называл.
Был к футболу равнодушен,
А в компании не скушен.
И к тому же чтобы он
И красив был, и умён.
Погодите, погодите !
...А знаю !!!
Monte Carlo— это там где многа казино, пальмы и еще спортивные машинки ездят !!!
это там где многа казиновзагалі то одне, і то не сильно велике (якщо оцінювати зал а не будівлю..)
та й пальми там живуть лише завезені, більшість в (відкритому) ботанічному саду ;)
Нет же! Это сигареты и их не только нужно курить, а ещё уметь и находить/стрелять, написано же: Monte Carlo localization.
Да, и в резюме можно написать — знаю фильтры Монте Карло.
Говорил профессор Зайченко — учи фильт калмана
Lyova Zi
Любые попытки предсказывать что либо- неблагодарное дело.
Я попробую описать текущую ситуацию- а фантазировать о будущем предоставлю вам.
С++ очень мощный и сложный и старый язык.
В этом сокрыто его pros and cons
С одной стороны- есть области- где С++ почти в не конкуренции: числодробилки, встраиваемое ПО — новые ЧПУ, прошивки, в финансах- высокочастотный трейдинг, фундаментальные разработки- ОС, браузеры, 3dMax, фотошопы, офисы gis/cad systems,щит и меч — вирусы /антивирусы — это всё сидит на С++
Т.е. как видим- еще очень много ниш в которых- С++ почетно занимает своё место.
а видимое сокращение С++ вакансий связано по моемы мнению с тем, что С++ был вытеснен из областей- где ему не особо было уютно: сайтики, веб, сервисы стартапики, казуалочки под планшетики.
В Украине больших фундаментальных продуктов нет (почти) вот и нет спроса на С++.
В На западе как и в Востоке (Китае, Ю Корее)- сапрос на С++ спецов- довольно высокий. Но в тоже время и требования в спецам астрономические по сравнению с питоном шарпом и жавой.
Вот и выходит- что если С++ дорог и готов тратить уйму усилий просто чтоб быть с С+± то лучше поднять голову и смотреть куда С++ ветер дует.
Знаю что многие бывшие плюсовики со временем переходят в более легкие ниши.
Знаю что многие бывшие плюсовики со временем переходят в более легкие ниши.Слабаки.
Иногда изучение предметной области отнимает больше времени, чем языка. Что бросать, если они в разные стороны расходятся?
С одной стороны — это шутка, с другой даже на дикомцивилизованном западе уже существует знатный перекос в зарплатах для С/C++ разработчиков, меньше народу — больше зарплата. Ситуация и правда приближается к ситуации с коболом, когда в последние деньки кобола разработчики получали просто бешанные зарплаты. Но системное программирование так просто не выкинешь и тут стали готовить больше CC/++ программеров в универах, это уже видно по интернам, которые приходят к нам.
если есть возможность — удаляйте комментарий — мы все так старались...
Тоже — шутка. Какие там деньги. Может это у нас новое поколение преподов просто. Смотрел западный курс по программированию, кажется MTI — так они наоборот со Schema на Python перешли. Правда это начальный курс. Лекции по системному программированию искал и не нашел.
Старое поколение преподов под программированием понимало вообще интересные вещи — пришел на лекцию типа по программированию, а лектор, лет под семдесят, рассказывает как они американские процессоры под микроскопом рассматривали, а потом программировали — создавали матрицу для печати наших, отечественных процессоров.
а есть еще математическое программирование, которое является дисциплиной в математике
но мы отвлеклись :)
а лектор, лет под семдесят, рассказывает как они американские процессоры под микроскопом рассматривали, а потом программировалиХоть так, а у нас у чистых программеров был СТОНХ — системы технологий отраслей народного хозяйства, доменные печи, сплавы и прочая чешуйня только потому что препод человек «хороший» и на пенсии не выживет ему давали часы, причём всем группам подряд, ещё и дифзачёт, чтобы он нём тоже заработал. Доменные печи у программистов, у программистов, КАРЛ!!!
Нестор Иванович
нам на 5м курсе мехмата влепили спецкурс по MS Word
благо преподователь все понимал забил на идеи руководства и разрешал заниматься на парах его норм спецкурсом. Я тогда здорово matlab подтянул
кажется MTIMIT? web.mit.edu/...2014-2015/catalog1415.pdf
Systems
. This area of research aims to discover common principles,
models, metrics, and tools of computer systems, both hardware and
software. Specific research includes compilers, computer architecture and
chip design, operating systems, programming languages, and computer
networks
я для английского смотрел MIT 6.00, только за другой год ocw.mit.edu/...fall-2008/video-lectures
Лекции по системному программированию искал и не нашел.Лекции очень редко бывают, я часто вижу просто презентации на выбранную тему, а всё остальное студент учит дома или по учебнику, который ему выдают. А вот лабы попадаются часто, по ним можно восстановить теорию, если очень хочется.
Как пример: ocw.mit.edu/...em-engineering-fall-2012
Там вместо лекций просто тезисы и ты сам их прорабатываешь. По этим тезисам препод, конечно, рассказывает, но мало, процентов 20% от силы. 80% на домашнее изучение. Лабы там есть.
Операционки никто на питоне никогда не читал понятно, речь видимо шла о классическом computer science курсе, который действительно когда то на схеме читался, потом вроде на джаве, а сейчас на питоне: ocw.mit.edu/...mming-fall-2008/readings
на похожую тему, если хочется смотреть, у МакКузика есть DVD за деньги www.mckusick.com/courses
По мне так с внедрением C++ 11 и 14 жизнь в плюсах стала настолько лучше, что есть смысл возвращаться тем, кто ушел, можно даже сказать, что так комфортно на плюсах ещё не писалось. Внутренние тулзы компании, процессы и стайл гайд тоже играют роль, но в основном качество языка и компиляторов в наше время.
Стало много лучше. Спасибо — добавили в стандартную библиотеку поддержку многопоточности. Но все-таки не хватает, ( в стандартной) кросплатформенной поддержки сети. Типа Asio. Выбор ведь один — сокеты (про TLI молчу). Лет десять назад я еще добавлял в список желаний поддержку баз данных и GUI. Чтобы как в Java — все из коробки. Чтобы перешел на новый проект, а там все знакомое. Но сейчас вижу, что это нереально, учитывая темпы и коллегиальность принятия стандарта. Быстро сделать выбор может только кто-то один. И наверно уже и не нужно — там, где базы данных, там уже другие языки. интерфейсы к БД другие и схема в некоторых начала исчезать. Может такие «уровни» и лучше: стандартная библиотека, буст, другие библиотеки. Протестировали в бусте — пустили в язык. Хотелось бы только , чтобы буст получил более высокий статус.
А о линуксе зашла речь, т.к. C++ похоже актуален для устройств с дефицитом ресурсов, а в такие, похоже, часто ставят бесплатный линукс. Здесь я не совсем уверен — в начале года хотел взять планшет с уже установленной убунтой. На hotline не было такого фильтра. Нашел статьи с обещаниями скоро выпустить. Недавно искал — опять нет. А с Windows в продаже есть. Наверное надо еще различать узкоспециализированное железо и универсальное, ориентированное на юзера.
а у вас є сильні програмісти (мебель перенсти, бутиль з водою в кулер вставити)?
Sergei Epatov
Долгосрочные тренды очень весёлые. Выскажу, осторожно и тезисно, свое субъективное ИМХО по этому поводу.
— Закон Мура еще десять лет назад пошел на спад, дальше будет асимптотически стремиться к остановке.
— Процессоры растут в количество ядер, а не в скорость.
— Текущая производительность процессоров, несмотря на то, что выросла в бешеное количество раз, всё ещё крайне мала для многих классов задач.
— Рост длины и сложности конвейера.
— Нарастающее отставания производительности процессора от пропускной способности памяти и сети.
— Многоуровневые кеши. Когерентность. Атомарность операций. Конвейерная обработка. CPU+GPU.
— Раскладка структур данных в оперативной памяти не менее важна, чем алгоритмы обработки.
— Упрощенные высокоуровневые языки не имеют в своем арсенале необходимых средств для борьбы с перечисленными проблемами.
— Интероперабельность вида «Highlevel <-> C/C++» не всегда приемлемый вариант. Теряется высокая интеграция, совместимость по раскладке структур данных на оперативной памяти, добавляются накладные расходы на переконвертацию туда-обратно, сериализацию-десериализацию и т.д.
— Пропускная способность мобильных сетей уже на пределе. Физику не обманешь. А количество пользователей наоборот будет расти. Соответственно придётся проводить липосакцию и в этих степях.
— Классическое ООП отживает своё: представление данных в виде графа сущностей, связанныx указателями, ужасно ложится на современную оперативную память и кэши.
Учитывая вышеперечисленное, вероятно, через некоторое время с новой силой начётся битва за каждый такт процессора и каждый бит памяти — в растущей конкурентной борьбе при замедляющемся росте производительности железа будут побеждать те, чьи серверные фермы кушают меньше электричества/площади/арендной платы/трафика в расчете на миллиард пользователей, а мобильное ПО вызывает меньше раздражения раскалённой железкой, быстро садящимся аккумулятором и минутными лагами на мобильных сетях. Думаю, в долгосрочной перспективе системное программирование не только никуда не денется, а переживет второе рождение. Возможно, это будет уже не древний C++, а какой-нибудь Rust, Go, Swift или Nim, но даже если так, от интероперабельности с Ц и крестами мы все равно долго никуда не уйдём.
PS. Тупейшая задача парсинга логов. В которой, казалось бы, ничего нового уже не скажешь, всё вылизано и выоптимизировано до чёртиков, и нефиг изобретать новый велосипед. Так вот, небезызвестный в определённых кругах remark ускорил обработку в ~300 раз, переписав код с Ruby на C++ с правильной моделью параллелизма. www.1024cores.net
PPS. К поиску работы здесь и сейчас, равно как и к нынешним реалиям 99% украинского бизнеса, данные соображения, пожалуй, не относятся.
никто не ограничивал «здесь и сейчас». Интересно, что ждет в следующие несколько лет. Как раз, по-моему, разговор начинает идти в правильном направлении.
undefined pointer
переписав код с Ruby на C++да даже если б на Джаве переписали.
вот еще история, на подобной задаче
время обработки было снижено с двух десятков часов до десятка минут
Ruby отличный ЯП для быстрого написания кода, без проектирования.
а вот для эксплуатации написанного...
Думаю, в долгосрочной перспективе системное программирование не только никуда не денется, а переживет второе рождение.Все повторяется, и ничего не повторяется :)
Системное программирование в том виде каком было — уже не вернется.
А вот подход FB HipHop’а, или CoffeeScript, т.е. трансляция кода с ЯП высокого уровня, в код С++, Rust, да, может быть. с — ручной дообраткой критичных мест.
хотя, и это было, лично занимался — трансляцией кода на С в ассемблер, и правкой таких мест.
Долгосрочные тренды очень весёлыеда, вот еще доклад, на указанные вами тенденции
youtu.be/vnymtEeYTjE
Ruslan Teliuk
Отдельное спасибо за линку на remark-а, у него всегда были интересные посты на RSDN. Теперь буду знать где он обитает.
Олексій Пєніє
Есть ещё один сильный вектор роста — количество оперативной и SSD памяти. Даже при текущих процессорных мощностях софту пока не хватает возможностей для полёта. Я более чем уверен, что следующий прыжок будет именно в большую память.
Притом ничего нового разрабатывать не требуется — достаточно просто продолжать прозизводить на том же оборудовании ту же память, и рынок будет её хавать как невменяемый.
Серверов это касается особенно. Согласись, круто разворачивать производительный сервачёк, когда у тебя данные прокешированы практически все.
Я считаю, есть ещё одна «железная» ниша, которая пока не тронута: медленная оперативная память. Которая в разы дешевле стоит, гораздо проще (дешевле) по контроллерам, примерно в 10 раз медленнее обычной оперативки — но тем не менее быстрее SSD, не говоря уже о дисках. При этом обращение к ней ведётся как к обычной оперативе или как к диску — на выбор. А уже сама операционка могла бы оптимизировать размещение, запуская страничный обмен даже в обход CPU. Главная её ценность — количество и дешевизна. Отлично разогнала бы ноутбуки и рабочие компы, существенно снизив требования к дисковой подсистеме и быстрой оперативе. А это даёт ресурс батареям.
Алексанр Слободянюк
текущая разница производительности RAM и SSD на порядок
какой-то вендор или журналист вроде-как рассказал о похожих идеях, такое теоретически возможно в каком-то неопределенном будущем:
Объемы RAM увеличить до масштабов Солид Сторадже
или ИОПС Солид Сторадже увеличить до скорости Оперативки
Я считаю, есть ещё одна «железная» ниша, которая пока не тронута: медленная оперативная память.
Это всё уже есть. Называется, сюрприз, DRAM. Используется именно так, как написано.
Медленней настоящей оперативной памяти (по недоразумению именуемой кешем) порядка на три, и настолько же дешевле.
Промежуточного звена между SSD и DRAM не будет.
Ні, саме звичайна DRAM. Та, якої 4GB+ зараз майже всюди.
Те, що Олексій Пєніє написав, це точно ніша DRAM, якщо подумати.
Дешева, об’ємна, повільна, керується ОС, DMA, дисковий кеш, роль в ноутах.
А оперативна пам’ять у нас зараз на рівні 386, 4..8MB, іноді трошки більше. І вся вона на чипі.
я по контесту зрозумів, що тре щоб була нонволатайл.
А так, таки так, при старті закешував харддиск у оперативку, і насолоджуйся, поки живлення не пропало. Єдине, що тре — механізм підкачки/свопу/шаредмеморі.
А тут більш тема для пісочниць і віртуалізації, і мов з збирачами сміття і динамічною типізацією, і т.п., але хрестовикам від цього ліпше не стане, марні надіі на друге дихання плюсів.
Именно так. Обычная DRAM, но лишённая всех дорогих обвесок дающих высокосоростной интерфейс. Это позволит:
1) Использовать дешёвые технологические линии прошлых поколений.
2) Использовать чипы с дефектами, позволяя программно или в контроллере метить или ремапить сбойные участки — это даст критическое удешевление производства.
3) Низкое энергопотребление, позволяющее сохранять кеш даже на перезагрузках.
4) При наличии аварийного источника энергии — способность отказоустойчиво кешировать запись на обычные диски. Это позволит отказаться от SSD.
5) Свобода масштабирования. В том числе горячая замена, технологии разделяемой памяти, многоядерные процессоры с десятками и сотнями ядер низкой частоты и малого энергопотребления.
6) Прекрасная среда для исполнения виртуальных машин.
7) Разрабатывать и использовать магнитные диски огромного объёма большой геометрии. Память будет компенсировать их низкую скорость поиска участка данных, а большой размер — давать низкую стоимость хранения и высокую линейную скорость данных. Например, жёсткий диск диаметром 2,5 метра, с десятком головок на одной поверхности и внутренней температурой близкой к абсолютному нулю.
Другими словами, есть куда расти даже не задействуя дорогое производство новинок. Достигнутые рубежи себя ещё далеко не исчерпали, есть рынок именно под количественный рост и параллелизм, без роста пиковой скорости.
PS. Память SSD на самом деле очень медленная. Скорость ей даёт параллельное хранение, а достигается это обычной оперативной памятью в контроллере. Со всеми вытекающими узкими местами: промахи по кешу, запись малых порций данных, неравномерный износом, критичные участки способные убить все данные на носителе. Другими словами, это не панацея. При увеличении нагрузки она будет сдыхать очень быстро.
Процессоры растут в количество ядер, а не в скоростьЧто говорит в пользу языков, позволяющих легко распараллелить вычисления. Количесво данных увеличивается быстро и количество ядер не спасет — идут по пути вычислений на гриде. Более востребованными будут средства, предлагающие удобные распределенные вычисления.
Roman Glebov
Насчет руби. Есть еще такой язык Crystal, авторы которого активно вдохновляются синтаксисом руби. Пока что в стадии альфа, но по бенчмаркам выглядит многообещающе:
Oleksandr Golovatyi
Моє імхо таке що питання має бути С++/не-С++, а під яку там ОС доволі фіолетово. Ну хіба що ви щось в ядро тієї ОС дописуєте.
Zakhar Sukhanov
переходи на iOS. как это сделал я. легкий переход и довольно «родственные» языки разработки.
С++ в background для iOS разработчика — очень неплохой плюс и подспорье.
и iOS нонче растет и ширится.
Александр Горбатовский
Автор темы полагает, что для винды презренной уже все программы написаны?
У меня например, план разработок расписан на 10 лет вперед.
Еще нужно осваивать кросс-платформенные приложения. Чтобы работало и на винде и на планшете и на смартфоне и в браузере.
Я говорю о серверных корпоративных приложениях, которые (похоже) создаются сейчас другими средствами. Корпоративные приложения мало касаются планшетов, они думают как бы на гриде успеть вычислить результат до того как через сутки новая порция big data зайдет. Как бы закешировать данные так, чтобы не дергать базу. Кто-то говорил выше, что до сих пор для плюсовиков есть работа в англиях. Непонятно — это суппорт написанного и уходящего или и сейчас по каким-то причинам, например, производительности, создаются на плюсах новые проекты.
Леонид, а кто сказал, что нужно писать только серверные корпоративные приложения?
Полезно иногда менять профиль. Это расширяет кругозор.
anonymous
ХЗ как в Неньке, но на британщине есть много вакансий на С++ для трединга и финансовой сфере.
roman maschak
Більшість з тих вакансій вимагають якийсь досвід з boost
Какие проблемы? Почти все С++ девелоперы юзали его.
і не тільки C++ :)
С boost у меня одна проблема — уговорить лида/менеджера ввести на него зависимость. У них хорошим тоном считается запрещать boost.
Gluttton
уговорить лида/менеджера ввести на него зависимостьА зачем уговаривать? Вам необходим boost для реализации конкретного функционала или Вы притягиваете его в проект «за уши» из-за прикольных фич?
Как-то долго довелось объяснять нужность «прикольных фич» из буста тим-лиду в
Ага, знакомая тема в наших «ведущих конторах». Буст считается почему то слишком мудрённым для среднестатистического программиста. Хотя в той же USA, откуда собственно в основном и заказчики, boost-ом не брезгуют. Парадокс.
Именно. Может не хотят брать ответственность перед заказчиком, когда нет еще зависимости на буст. Был я в проекте, который на оутсорс был отдан уже с зависимостями на буст. Также была в нем библиотека утилит, созданная до распространения буста: мьютексы, смарт поинтеры и т.д. Тим-лид настаивал на библиотеке компании. Я, как программист, конечно хотел буст. Но даже пытаясь поставить себя на место владельца я не отдаю предпочтение доморощенной библиотеке, особенно если уже сломан единообразный подход. С одной стороны сторонники своих библиотек говрорят, что проще изменить реализацию если что. С другой, учитывая смену кадров проще подготовить нового человека, влиться в проект с бустом, т.к. он распространен. Бывают ситуации как на одном из моих последних проектов, который как из затерянного мира — владелец компании сам программирует эту систему лет двадцать и использует MFC. Все — MFC и контейнеры тоже. Так контейнеры еще можно стандартные вставить, но вот CString изменять на string не выгодно, коряво. Единообразие конечно тут есть — отлично. Но вот найти сейчас молодежь и на такой проект сложно. Вообще сложно кого-то найти.
Oleh Korotkov
С требованиями к вакансиям на С++ вообще все очень сложно и тяжело. Если Win то большинство вакансий скорее всего будут в геймдеве и там уже понадобится графика(OpenGL/DirectX).
т.е. похоже надо определиться — что человеку дороже: предметная область и специфика бизнес-приложений или язык. Это касается тех программистов, которые в начале
Volodymyr Nazarenko
Нариаклад,якщо ви глянете на ринок парці С++ в Європі/США, то можна виділити деякі популярні напрямки. В Німеччині С\С++ CAD, OpenGL/VR, QT, Networking (Linux), Мікроконтролери (цих вакансій досить багато). В Англії і США для С++ є багато вакансій фінансових аналітиків, спеціалістів по моделювання, а тaкож ігрових програмістів. Windows зараз в світі в основному на С# це якщо нові продукти, якщо програми написані давно, а випускають тільки нові версії тоді С++.
Networking (Linux)как раз сейчас к этому присматриваюсь, подходит наиболее моему бекграунду. Про Англию и деривативы верно. Не каждый C++ программист годится для микроконтроллеров. говорят там надо иметь некоторые познания в схемотехнике (это кстати не утверждение, я не знаю просто предполагаю, исправьте, если я ошибаюсь). Если человек просидел на деривативах, то ему будет больно первое время в микроконтроллерах.
Ну знати основи мікропроцесорної архітектури, що таке переривання, особливості програмування + завжди пам’ятати про обмежену пам’ять і частоту процесора. Я сам не embended dev., але іноді другу допомагаю з кодом для мікроконтролерів на С++ і скажу, що можна досить швидко опанувати базово, так як там використовується самий простий функціонал мови, але звичайно є свої особливості. А так треба звичайно знати, що таке тригери, як позначаються ті чи інші елементи на схемах. Але я думаю вивчити це не така велика проблема, час якийсь займе, якщо правильно націлитися то можна впоратися. ( Ось посилання на вакансії Embended в Німеччині tinyurl.com/ov8cqoy
В универе это учили, конечно, но боюсь, что сложно будет тягаться с людьми, закончившими факультет электроники. Микрокомпьютеры все-таки не такой экстрим — вроде и производительность и предсказуемость важна, Java позволить себе не могут, но и отгородился в знакомом юзер спейсе.
Кто-то работал в Networking (Linux) проекте — можете описать основную специфику. На что уходит основное время? Я так понял, что тут важна работа со сниферами. Мало внимания прикладному уровню и максимум сетевому. Биты в основном обрабатываются процессором или в голове программиста? На собеседовании отметил отсутствие вопросов по С++ - в основном по С, отсутствие вопросов по паттернам, попросили решить задачу, которую решил рекурсивным обходом дерева — сказали что рекурсия это не есть гуд. И еще были задачи, похожие на те, что я решал будучи школьником на программируемом калькуляторе.
Кто-то работал в Networking (Linux) проекте — можете описать основную специфику. На что уходит основное время?Обычно за время работы нарабатываются пару низкоуровневых классов, отвечающих за работу либо через libsocket, либо через WSA/WSA2 (в основном асинхронные сокеты), а всё остальное неизменно как для винды, так и для линукса. Ведь в винде используется BSD socket API (Berkeley sockets ) :)
Основная специфика, это не бросаться , с головой, в разработку лисапедов, а попытаться найти/заюзать уже готовую сетевую либу, которых под Линух огромное множество (с API на С/С++).
по собеседованиям в Networking Linux проект я так понял, что их совсем не интересует прикладной уровень, и больше всего интересует сетевой (наверно потому, что это верхний в роутерах). Какие сторонние библиотеки они могут использовать, если даже сокеты предполагают работу на прикладном уровне? Я могу ошибаться, но другого использования мне не приходилось встречать. Они все напирают на интенсивное использование сниферов (во всех трех компаниях, так что это отличительная черта). Я присматриваюсь сейчас к таким делам. Что же они там такое делают. Нужна привязка к чему-то знакомому. Может это можно сравнить с дизассемблированием по кропотливости труда? Как-то с этим столкнулся и для меня это очень большое повторение очень простых операций.
Я за многи годы ниже TCP уровня не скатывался, а это транспортный уровень реализуемый на сокетах.
И как там обстоят дела со свякими сниферами не скажу. Но готовых библиотек реализуюших сетевое взаимодействие на основе стандартных сокетов полно.
Какие сторонние библиотеки они могут использовать, если даже сокеты предполагают работу на прикладном уровне?
Сокеты предоставляют транспортный и (raw) сетевой :) Соответственно, «предполагают работу» начиная от транспортного и сеансового.
Они все напирают на интенсивное использование сниферов (во всех трех компаниях, так что это отличительная черта).
Для отладки или для целевого использования? Первое понятно, второе — означает сильную специфику всех.
Может это можно сравнить с дизассемблированием по кропотливости труда?
Нет, сеть это менее рутинно.
Спасибо. Посмотрел пример такого raw использования — www.tenouk.com/Module43a.html
Не вижу особой библиотечной поддержки — в клиентском коде создается структура IP заголовка: struct ipheader. Очень низкоуровневый подход получается. Все-таки Asio реально повышает уровень работы с сокетами. Может это я неудачный пример нашел и есть библиотеки реально упрощающие работу на сетевом уровне. Может кто с ACE работал?
Очень низкоуровневый подход получается.
Блиииин.
Вы можете работать через raw IP, если зачем-то нужно. Но для 99% задач вы не должны этого делать, и, более того, чаще всего не имеете права (потому что ядро разрешает raw ip только при особых правах, которые может давать только рут). Понимаете? Да, адекватно принять DHCP и ответить на него вы иначе не можете, но сколько задач требуют реализации DHCP, а сколько — чего-то поверх TCP (или даже HTTP)?
Все-таки Asio реально повышает уровень работы с сокетами.
При чём тут asio??? Оно вам никак не поможет разобрать или собрать ip пакет в сыром виде с заголовком, это не его задача. Кажется, Вы не понимаете азов. Что оно повышает уровень — там, где это повышение оправдано — да, но оно повышает его над интерфейсом, а не данными, которые по нему гоняются, и не над специфическими настройками задачи (которые всё равно придётся отбирать и ставить руками).
www.tenouk.com/Module43a.html
Между прочим, Вы нашли что-то очень странное. После unsigned char iph_ihl:5, iph_ver:4; можно дальше не читать — видно, что этот код никогда в таком виде не тестировался, и работать он не будет. Учитывая, что Стивенс свои примеры тщательно вылизывал, предполагаю намеренное повреждение. Если этот источник врёт даже в таких банальных мелочах, ему не стоит доверять.
Может это я неудачный пример нашел и есть библиотеки реально упрощающие работу на сетевом уровне. Может кто с ACE работал?
ACE — монстр, в котором заложено почти всё, но по-своему. Так Вы можете таки объяснить, что именно хотите упрощать «на сетевом уровне», учитывая, что по разнообразию задач и методов это целая галактика?
Или Вы, ещё не зная задачу, надеетесь на универсальную пилюлю от всех болезней? Тогда сразу забудьте эту идею.
Постараюсь сохранить невозмутимость — все-таки больше никто не поддерживает сетевую тему. Мы как-будто на разные темы говорим. Прочитайте посты выше — я очертил контекст — существующие вакансии ориентированы НЕ на прикладной уровень, а скорее на сетевой (немного на транспортный). Сужу по удельному весу вопросов на собеседованиях — редко кто описывает проект подробно до выхода на работу и подписания договора о конфеденциальности. Я предположил что интерес к сетевому уровню объясняется тем, что это самый верхний в роутерах(видимо проекты плотно занимаются софтом для роутеров).
Про asio я вспомнил для примера того, как ненужно гибкое API сокетов на C сделали удобным для использования прикладного и транспортного уровня TCP/IP на C++. И хотелось бы узнать, а есть ли что-то подобное для сетевого? Или только такой C подход как в приведенном мной примере. Я пример привел — приведите пожалуйста свой. Раз Вы вспомнили Стивенса, то он пишет, что когда разрабатывали API сокетов, то заложили туда возможность работать не только с TCP/IP, но интересно другое — он также пишет, что многие критикуют эту неиспользуемую универсальность за ненужное усложнение. Итого, в первую очередь интересуют названия библиотек и желательно какой-нибудь источник для дальнейшего изучения, которые на C++ позволяют работать с сетевым уровнем на уровне абстракции, сравнимом с тем, что предлагает asio для верхних уровней стека TCP/IP.
Про asio я вспомнил для примера того, как ненужно гибкое API сокетов на C сделали удобным для использования прикладного и транспортного уровня TCP/IP на C++Особенно прикольно asio использовать на плохих линиях с обрывами связи, с большими задержками по передачи, постоянными реконнектами модемов на выделенных линиях, разными скоростями передач, измеряющимися в бодах, а не мегабитах.
все-таки модемы — не мейнстрим сейчас. Для африканских стран может быть. На сегодняшний день чаще всего речь идет о передаче видео по скоростным, надежным ов линиям.
я про африку без иронии — послушать CNN — так африка самая первая по темпам развития. Просто из того что я нашел у нас, работодатель хочет передавать видео по надежным линиям. И опять таки — вроде как много у них на C написано уже и нужен суппорт. Поэтому даже если выяснится, что на C++ есть отличные библиотеки для написания софта для маршрутизаторов, может оказаться, что их не используют в наших вакансиях и пробить использование нереально. И я не против C — я люблю в свободное время неспешно порешать головоломки разные с маленьким входом и наверное решение будет в стиле C, но когда надо сделать много и быстро, и так, чтобы компилятор мешал сделать неправильно, то С++ лучше.
Хотя смотря что понимать под модемами — и сейчас распространен способ передачи по коаксиалу по протоколу DOCSIS. Относительно таких модемов не знаю про надежность.
У меня сейчас такое. Скорость плавает капитально, но скорее из-за ограниченной полосы пропускания, чем из-за физической линии передачи. Когда гроза и дождь — связь, как правило, ужасная.
Что значит не мейнстрим? Например, у железной дороги большинство удалённых касс хорошо, если подключены по 9600, часто 2400. Бывает что даже такой линии нет, то 9600 CSD по мобильной свзязи. И везде полный спектр проблем с надёжностью канала.
Я кстати сразу про кассы вспомнил, но подумал, что этот сектор не очень привлекательный в смысле ЗП. Есть правда случаи, когда на госзаказе несколько лет сидела известная контора и могла себе позволить платить конкурентные зарплаты, но с каждым потрясением в нашей стране она теряла значительную часть программистов, т.к. замораживала ЗП в гривне. В 2000 я ходил на собеседование в укрзал-цу. Сказали, что должен пройти проверку в особом отделе. Про всех родственников вспомнили. Пока дошел до кабинета, несколько раз расписывался в журналах в разных коридорах. Сказали, что это хороший старт, но больше я туда не ходил.
Может они сейчас не сами разрабатывают, а дают заказ коммерческим конторам. был в такой прошлой осенью, когда курс падать стал. Полчаса доказывали мне, что ЗП не должна быть привязана к СКВ, а зафиксирована при приеме в гривне. И на тот момент это была нормальная величина, но буквально через месяц мне бы пришлось уходить.
Для основателей и ключевых программистов, проработавших годы в конторе госзаказы могут быть интересны. Я же думаю о смене узкой ниши на более просторную.
видимо проекты плотно занимаются софтом для роутеров
Тогда 99%, что там работают через свой транспорт, а не raw sockets. Может быть ядро, может быть специальная ОС.
И хотелось бы узнать, а есть ли что-то подобное для сетевого?
Я думаю, что нет, именно потому, что сетевой уровень слишком специфичен для каждого конкретного применения. Если кто-то и делает, например, TCP/IP стек на C++, то он не выделяет его в виде универсальной библиотеки, параметризуемой под что угодно :)
он пишет, что когда разрабатывали API сокетов, то заложили туда возможность работать не только с TCP/IP, но интересно другое — он также пишет, что многие критикуют эту неиспользуемую универсальность за ненужное усложнение.
Чтобы бессмысленность этой критики стала очевидна, достаточно посмотреть на AF_LOCAL и его широчайшее использование в Unix-системах. С другой стороны, это API сильно хуже, чем TLI/XTI, в ряде применений вроде T/TCP (на BSD sockets оно костыльно, а на XTI реализуется напрямую). Я не знаю, зачем Стивенс вспомнил этих критиков, но конструктива у них нет.
Итого, в первую очередь интересуют названия библиотек и желательно какой-нибудь источник для дальнейшего изучения, которые на C++ позволяют работать с сетевым уровнем на уровне абстракции, сравнимом с тем, что предлагает asio для верхних уровней стека TCP/IP.
Не знаю таких и не буду думать об этом, пока не указано, какая именно функциональность требуется от таких библиотек. Точно так же, как asio рисует свои прокладки для TCP или UDP — это уже конкретные реализации функциональности транспортного уровня с их свойствами — для сетевого уровня должна быть указана задача и протокол реализации. Например, DHCP, IP6 раутинг или что-то другое. И после этого я всё равно уверен, что вы не найдёте готовых, или они будут ужасны.
Євген Лесько
Думаю, однозначно есть смысл и осваивать линуха и юниха, и не забывать Windows. Сам так сделал 13 лет тому, жалею разве что о том, что когда набрал популярность Objective C++, я уже не столько девелопил, сколько руками водил :8) Если Вы внимательно наблюдали вакансии, то увидели наверно устойчивый спрос на Qt — чем не выход?
Еще одна мысль: не ищите в вакансии 100% совпадения со своим опытом. Абсолютно одинаковых проектов не бывает. Что-то можно доучить, что-то есть очень узкой технологией, а бывает, что в вакансию совсем левые требования по копи-пасте попадают :8)
согласен с распространенным на западе мнением: для того чтобы стать опытным программистом нужно 10 лет.Интересно знать первоисточник такого мнения. Нормальная привязка как европейских, так и американских заказчиков, в том числе и по сишке:
Мое личное ИМХО — конечно, много еще зависит от того, на скольки разных проектах побывал девелопер за эти
А сколько людей за 10 лет успевает уйти направо, в BI например, или налево, в менеджмент? сколько технологий за 10 лет меняется? фронтендщики тогда практически все поголовно джуны :8)
Я читал другую статью, но сейчас нашел только эту norvig.com/21-days.html
Но Норвиг тоже уважаемый человек.
Согласен, зависит от области и обстоятельств. Например, такая аналогия — офтальмологом или стоматологом стать проще, чем в других специальностях — уже предметная область.
Спасибо. У меня сложилось впечатление что Норвиг пишет о 10 годах и-или 10.000 часах скорее в смысле «век живи — век учись». Кстате, насчет «правила 10.000 часов» я с небольшими оговорками согласен. Но это и есть в пересчете 5 лет, а не десять :)
не забывать WindowsзабИть на Віндоуз
100% совпадения со своим опытом.ага, прийшов на хрести, а проект поїхав на Жабу, або Пітон
Олексій Пєніє
Не стоит. Рыночная ниша на софт как и прежде сильна. Возможно, ты просто не там ищешь вакансии. И смотри — Windows 10 сейчас будет сильно раскручена, в рекламу планируют вложить мега-бабло. А с каждой новой ОС — есть потребность в новом софте.
Объясняю почему: те кто купил лицензию, переходят не с 8.1 на 10. А часто с XP на 10. Особенно это касается рабочих мест. Многие просто покупают новое железо с новой ОС. Так что потребность на софт возникнет некислая.
Лучше проследи где пишется софт, в том числе по странам. Очень может быть что фирмы попросту не публикуют вакансий дальше своего региона. И совсем уж не редкость, когда вакансии оформлены настолько по-идиотски что не узнаешь там свою. Например, потребуют специалиста с опытом работы в EJRFW не менее 1 года, а по факту окажется что «EJRFW» — это их внутренняя разработка и таких спецов нет вообще.
Я согласен, что ниша относительно узкая. Но тем сильнее скажется всплеск тренда. Ищи трендовый софт, в команду которого хочешь войти. Если софт в тренде, то скорее всего они расширяются.
Serhii Kosyi
Windows 10 станет последним Windows, по заявлению MS.
Потом новая ось, и снова нужно переписать кучу софта на С++ под новую ось? :)
Alexander Nesterenko
Если верить оф. заявлениям, дальше ни не будут выкатывать релизы. Винда будет развиваться динамически, патчами и обновлениями
Цену этим заявлениям можно оценить, задав два вопроса:
1. А как же точно определить версию системы после обновления? Очевидно, что без обновления не обойтись, и точное указание версий основных компонентов будет необходимостью для любой диагностики.
2. Как часто будут выходить эти патчи и обновления? (Ответ — кроме срочных секьюрити фиксов, ничто не изменится от текущего состояния с циклом от пары месяцев до года.)
После этого понятно, что MS выпустила очередной огромный маркетинговый булшит, и меняется только маркетинг — уходят громкие релизы, и вместо этого будут сразу испытывать новинки на пользователях. Версии вместо гордых слов будут называться в стиле 2015C или 10.4.13.2 (где-то обязательно будет такой идентификатор) — точный метод неважен, пока соблюдается правило монотонности нумерации и однолинейного развития. А ещё за этим они маскируют усиленный механизм контроля купленности экземпляра, скрытый через промежуточный слой принудительной обновляемости. В общем, за 20 лет их методы не изменились.
Если последним — тем лучше, больше стабильности по софту и дровам. А вообще я слабо верю, что MS разлюбила деньги. Захочет поднять курс акций, выпустит Windows X++
Oleh Korotkov
Под Win10 вряд ли будут так нужны С++ разработчики, все движется в сторону высокоуровневых языков.
Драйвера на чем писать будут? На С++ перейдут или уже перешли?
Подмножество драйверописателей среди всех разработчиков не такое уж большое. Я сам этими вакансиями не интересовался, но в общем поиске по С++ они не попадались ни разу.
А что задерживало? Я помню начал читать книгу Они, так он пишет, что в Windows очень строгие правила для написания драйверов. Поменялись правила? Книгу Они можно в топку?
Даже если код должен компилироваться C компилятором, все равно ведь можно создать отдельную единицу трансляции на C++, использовать там С++ в полный рост, а связывать модули через extern «C» функции. Просто интересно, что останавливает драйверописателей в Windows от использования C++. бывший мой сотрудник рассказывал, что для Mac они драйвера для принтеров на C++ писали.
Просто интересно, что останавливает драйверописателей в Windows от использования C++Я предполагаю, что попытка написания драйвера на С++, может привести к избыточному использованию конструкторов/деструкторов в разных неявных преобразованиях и т.д. А это вызовет чрезмерное количество вызовов к менеджеру памяти — соответвенно, должна пострадать производительность, для реальных драйверов это критично. Может есть еще какие-то более веские причины.
Александр Колосов
Там вполне можно использовать с++, только упрощенный, надо сторонится виртуальных методов и использовать размещающие перегрузки оператора new. Или писать на с++ в с стиле
Или писать на с++ в с стилеТогда уже проще писать на чистом С.
Там специальный malloc, api шный, может и обычным можно пользоваться, уже плохо помню. Вообще, перед тем как писать драйвер я был скачал примеры с msdn, они обычно подправляют их для каждой новой версии VS, чтобы компилились из коробки. В тех примерах вполне себе плюсанутый код, как уже писали в теме. Я тогда ничего такого свехсложного не делал, нашел похожий пример из SDK и допилил.
Там специальный malloc, api шный, может и обычным можно пользоваться, уже плохо помню.а какой malloc юзает new?
Вы про какой то особый случай, как здесь описан, или взагалі?
Более точно вот что я имел ввиду:
#include <ntddk.h>
//=====================================
void *__cdecl operator new(size_t count)
{
return ExAllocatePoolWithTag(NonPagedPool, count, ’TRCm’);
}
//=====================================
void __cdecl operator delete(void *object)
{
ExFreePoolWithTag(object, ’TRCm’);
}
//=====================================
В msdn так рекомендуют делать
Всю жизнь считал, что в каждом new всегда сидит один и тот же маллок. Главное не перепутать, когда в С++ проекте используют С -библиотеки, если юзаешь new => delete, если malloc =>free
Всю жизнь считал, что в каждом new всегда сидит один и тот же маллок.Ну в общем случае так и есть, но как говорится могут быть ньюансы
согласен, если в С++ после new рубануть по объектам free, да и на gcc еще, долго баг будишь искать.
Та ну как бы 90% либ линуксовых, особенно с сетевой тематикой на чистом С написаны (взять тот же curl), ну а там никаких тебе new/delete.
В с++ каком нибудь новом, как по мне, так большую половину старого функционала и синтаксиса (который еще с С тянется) пора обявлять deprecated.
Я жду того дня, когда C++ компиляторы перестанут позволять #include-ть
Давно пора признать, что C++ это просто другой язык, сделать там нормальный FFI и не любить друг друга в мозги.
Экстерн с позволяет отключить манглинг для компилятор агностик решения. C++ слабо накладывает бинарный стандарт чтобы компилятлры могли оптимизировать.
Если не добавлять свой allocator то new хотя бы на низком уровне, в какой-нибудь фабрике объявить иногда придется
«мультипарадигменное программирование» — автор Коплиен кажется. Топор — универсальная вещь. Хочешь — кашу вари, хочешь дров наламай, хочешь — ко дну пойди. Бензопила Java"Дружба" более дружественная, продуктивная, но не такая универсальная.
на два уровня.
Не менее трёх уровней.
Вызовов free на чужой указатель там тоже нет.
curl.haxx.se/libcurl/c/curl_free.html
(в обратную сторону тот же принцип)
Вопрос не в C++/new/delete, эта грубая ошибка в рамках C.
По поводу долго искать: это покажет первый же запуск valgrind.
В явной форме и с подробностями.
Для
Ну вот я сейчас пишу одну приблуду с самопальным счётчиком ссылок в базовом классе и явным link/unlink в коде. Потому что есть места, сурово критичные по скорости, такие link/unlink замечательно инлайнятся, а shared_ptr даже в сильно оптимизированном режиме это вызов невстраиваемого шаблонного метода с атомарным изменением счётчика, что в сумме становится дороже в десятки раз.
И, что характерно, граблей именно от этого механизма нет, а все найденные лезут совсем из других источников (например, вчерашняя проблема — забыл в одном месте дёрнуть асинхронный коллбэк: чтение БД не было вызвано, а альтернативную ветку потерял).
Явный unlink (наверное то же что и detach, release, etc) может сплоховать в случае исключений. Ваш случай со счетчиком в самом классе возможно подходит для intrusive_ptr. Идея смарт поинтера простая, но была создана масса разновидностей и выжили сильнейшие — определилась группа, которая хорошо взаимодействует друг с другом. Например weak_ptr и shared_ptr. Через пару лет представления о скорости поменяются, а код, содержащий нестандартное решение останется. Не буду спорить — у вас может исключение из правил, особые требования к скорости.
кстати для intrusive_ptr вы сами пишете функции инкремента/декремента и можете не учитывать при желании многопоточность если ее не предвидится.
Явный unlink (наверное то же что и detach, release, etc) может сплоховать в случае исключений.
Знаю, но в плане исключений у меня тут «чужие здесь не ходят».
Ваш случай со счетчиком в самом классе возможно подходит для intrusive_ptr.
Да. Но зачем подключать boost, если нужное уже есть в 10 строк :)
Например weak_ptr и shared_ptr.
Знаю. Пробовал. Вкусно — для менее критичных мест.
Не буду спорить — у вас может исключение из правил, особые требования к скорости.
Увы, да.
может привести кдрайвера уже не тестируют и не оптимизируют?
Тестируют и оптимизируют, но...
если написание драйвера с оптимизацией на С++ требует больше времени, чем написание драйвера на С, вряд-ли в здравом уме не примет решение писать драйвер на С++, экономическая целесообразность и все такое...
а драйвер на Це уже оптимизировать типа не нужно?
Когда в нём в принципе неоткуда взяться соответствующим затратам — да, именно этот вид оптимизации становится не нужен.
Просто интересно, что останавливает драйверописателей в Windows от использования C++. бывший мой сотрудник рассказывал, что для Mac они драйвера для принтеров на C++ писали.В году
Драйвер драйверу рознь, есть которые в пользовательском режиме работают, а есть и в режиме ядра, так вот для последних нет CRT. Не знаю точно, может, с Win 8 появилось. Так что нет там new/delete, std, exceptions... Да и память в драйвере может нужна только невыгружаемая, поэтому будет выделяться специальными методами, в общем, там другое «окружение».
А мультимедийные потоки на чем кодить? Мне вчера, например, мой друган предложил видео маттинг (замена заднего фона ) в потоке писать на JS. Пришлось огорчить, захват кадра и его обработка за 40 мс ну никак не натянуть. Хотя, может кто пробовал?
Драйвера/фильтры для виртуальных эмуляторов пишутся на низком уровне. А спрос на них немеренный.
Сегодня прислали мне гуловскую статистику, каким операционками юзера юзают наш сайт за последние 6 месяцев. Вышло такое
— Win7 — 62.9%
— XP — 22%
— 8 (не 8.1) — 14.4%
-Vista — 0.5%
— итд
А я, наивный, хотел поддержку ХР шашкой рубануть с проги в пользу 10 винды. Хрен! — кормит она нас и долго кормить будет. Короче Винда — форевер, а сишники при ней!
потребность в новом софте для новой версии Windows может быть интересна разработчикам десктоп приложений (или мобильных, от меня это далеко). Я наблюдал за товарищами под Mac OS, когда они ожидали гигантского перехода на Lion и не момню как называется — на репозиторий для приложений. Так вот для древнейшего десктоп-приложения этот гигантский переход закончился тем, что убрали пару «опасных» API функций.
С виндой не так всё просто. Винда делает всё на свете, чтобы юзер не обновлял старую до новой, а ставил с нуля. Таким образом, полагаю, дерьмовые «дывелоперс» страхуются от ошибок совместимости. В Майкрософт настолько всё плохо, что они даже ошибки не снабжают текстовым пояснением. Пишут «не удалось сделать бла-бла-бла», но что именно не удалось — ни малейшего намёка.
Потому пользователи винды очень сильно подсажены на качественный софт. Разработчики кода вынуждены со своей стороны обходить туеву хучу мелких проблем винды, дабы предоставить юзеру что-то вменяемое. Так, они уже научились не пользоваться реестром — винда с завидной жестокостью «автоматически» его гробит, если у самой случился баг. С другой стороны, пользователю вообще мало понятно, что творит софт и как — виндовые юзеры более глупые. А это значит большой спрос на софт, который делает их действия просто, без лишних движений.
Кроме всего прочего, винда по-прежнему любимая корпоративная платформа. Фирмы ну очень медленно меняют свои предпочтения. А это значит приличную нишу именно в корпоративном секторе. Хотя там и скучно.
Ністєрпєл...
> Винда делает всё на свете, чтобы юзер не обновлял старую до новой, а ставил с нуля.
Штое? Більше ніж вінда оновлення з версії до версії жодна система не підтримує навіть в половину.
> Таким образом, полагаю, дерьмовые “дывелоперс” страхуются от ошибок совместимости.
Які саме “ошибки совместимости” маєте на увазі?
> В Майкрософт настолько всё плохо, что они даже ошибки не снабжают текстовым пояснением.
І знову: штое? Які помилки? Яким текстовим поясненням?
> Пишут “не удалось сделать бла-бла-бла”, но что именно не удалось — ни малейшего намёка.
Хто пише, де пишуть? До того ж “намек” прямо в вашому реченні і написано: бла-бла-бла, от його саме і не вдалося.
> Разработчики кода вынуждены со своей стороны обходить туеву хучу мелких проблем винды
Наприклад?
> Так, они уже научились не пользоваться реестром — винда с завидной жестокостью “автоматически” его гробит, если у самой случился баг.
Лолшто? Проблема з реєстром в тому що його не так просто переносити з конфігурації в конфігурацію рядовому користувачу. Тому і існують “портабельні” версії різного софта які свої настройки пишить поруч з бінарніками щоб їх можна було на флешці носити. Якщо ви звісно про це.
> виндовые юзеры более глупые.
Ага, прям от з пруфлінків які ви привели це і видно.
> А это значит большой спрос на софт, который делает их действия просто, без лишних движений.
Мені такий софт хотілося б мати на будь-якій системі, вінда там чи не вінда.
> Кроме всего прочего, винда по-прежнему любимая корпоративная платформа.
Заговор?
> Фирмы ну очень медленно меняют свои предпочтения.
Може це якось пов’язано з тими можливостями уніфіковано керувати політиками і конфігураціями “корпоративної платформи”?
Пишут «не удалось сделать бла-бла-бла», но что именно не удалось — ни малейшего намёка.
Кстати, я понял, как им это удаётся, когда был поставлен в рамки, когда ты можешь вернуть максимум шмогла/нешмогла (даже errno по сравнению с этим было прогрессом). И, как ни странно, это было лучше, чем вообще падать без объяснения:)
Вот то, что у них очень длинный цикл обработки реакции пользователя, хуже, потому что и приводит к такому эффекту, что подобные данные диагностики остаётся единственным на годы.
Очень много хороших языков, но предлагаю все же сохранять рамки темы, т.е. предполагая, что обязательное условие задачки — C++. В багаже есть еще пара языков, на базовом уровне, например, Java. Но предположим, человек остался в С++.
Mike Gorchak
преимущественно серверное ПОСерверное ПО — это не окошки рисовать, будет гораздо проще перейти, принципы все те же, API немного другое. Опять же, я не знаю, использовали ли вы windows специфику или всё пряталось за библиотеками, если второе, то даже переучиваться не надо. Почти.
Вопрос — стоит ли переходить. Понятно ведь, что на пару лет производительность упадет. Было бы ради чего.
на пару лето_О
всё настолько плохо? обычно на освоение новых технологий тратят до 3х месяцев, учитывая что язык вы уже знаете
освоение и уровень эксперта — разные вещи. Чтобы откалибровать шкалу я скажу что согласен с распространенным на западе мнением: для того чтобы стать опытным программистом нужно 10 лет.
Юрій Ярош
Опыт временем мерить бесполезно.
А зачем вам быть экспертом во всех технологиях? Либы это дело приходящее. На одном проекте — одни, на другом — другие.
Я бы не ставил вопрос ребром. Рассматривайте это как шаг в сторону, а не переход. Серверный С++ программист под Windows как по мне звучит довольно узко. Стоит ли? Я бы попробовал всё, где встречается С++, чтобы расширить свои возможности. Ну и пары лет не будет, возможно вы в линуксе будете плавать какое-то время, но, максимум, через год для вас будет всё равно где работать и под чём писать.
Было бы ради чего.Так уже по вашим же словам осталось 5% вакансий.
Спасибо. Это, очень полезная оценка сроков. Согласен, что программу минимум удастся выполнить до года. Моя оценка означала срок перетаскивания всех имеющихся знаний из Windows в Linux, включая опыт сетевого администрирования(т.е. когда производительность станет равной). Я прикидывал следующим образом, сроки брал из книжек, т.к. сам не преподавал и не руководил и своей статистики нет. Петзольд оценивает освоение Win API (для окошек) в среднем 6 месяцев. Win API для объектов ядра, управление памятью, IPC, синхронизация потоков — отображаем в POSIX — еще пару месяцев. Круглинский оценивает освоение обертки MFC еще в шесть. Отображаем например в Qt. Дон Бокс тоже в шесть месяцев оценивает освоение COM. Точнее говорит, что через шесть вы сможете создать что-то что работает. COM отобразим на Corba. Итого уже >полтора года. Но вроде Corba напрямую не особо сейчас используется и без этого можно жить хотя жаль — на технологии подобной COM + ATL можно быстро на плюсах создать сетевое приложение.
и база данных будет скорее всего не MS SQL Server и не T-SQL
Я недавно следить за этим начал — может это временное явление. Может результат общего снижения активности. А может и то, что случилось с программистами Visual Basic 6 и Delphi.
А может С++ в бизнес-приложениях ожидает то же, что Cobol. Было бы неплохо.
по-моему, кобол живет только там, где софт работает с доисторических времен, и его накладно переписывать (а новый софт на коболе думаю вряд ли счас пишут, может разве что одна-две конторы на весь мир + какие-то бородатые дядьки, которые на нем пишут с тех времен, когда кобол был в тренде). Т.е. кобол по большому счету умер, как мне кажется.
Поэтому, если ожидаешь, что С++ ждет судьба кобола, то наверное в таком случае лучше учить еще какой-нить язык, на всякий пожарный...
по разному было: и свои низкоуровневые обертки на Win API писались и чужие использовались. Тут есть еще момент, раз уж коснулись деталей. там где сейчас ищут Linux C++ программиста, там часто проект для встроенной системы, ограниченной в ресурсах аппаратуры. И часто С++ используется в стиле C или частично модули на чистом C присутствуют. И это значит, что придется отказаться от так называемого Modern C++.
И часто С++ используется в стиле Cк сожалению, данное сильно зависит от:
1. навыков/адекватности лида
2. тухлости кода
3. тухлости компилятора
под новый проект можно выбить C++11/14/1z, т.к. два последних пункта пропадают
Тут есть еще момент, раз уж коснулись деталей. там где сейчас ищут Linux C++ программиста, там часто проект для встроенной системы, ограниченной в ресурсах аппаратуры.Там скорее ищут С, а рекрутер просто не делает разницы между С и С++.
И часто С++ используется в стиле C или частично модули на чистом C присутствуют. И это значит, что придется отказаться от так называемого Modern C++.Ну и что? Это принципиальная позиция? Если нет, то надо заводит pet-project и пилить его ради своего удовольствия, а на работе делать работу. За пределами Украины я практически не вижу Modern C++ вообще, все накладывают какие-то ограничения.
Вот, пару вакансий с большой зарплатой для примера (чтобы знать, что нужно там, ведь часто оттуда спускают к нам):
jobview.monster.ca/...672857.aspx?jobPosition=5 — Core skills for this role will include real-time, embedded software development.
jobview.monster.ca/...24920.aspx?jobPosition=12 — они тут целое шоу устроили и никого не нашли на эту должность.
jobview.monster.ca/...25688.aspx?jobPosition=13 — тоже никого не нашли, хотя зарплаты у них высокие.
jobview.monster.ca/...62936.aspx?jobPosition=17 — чисто для виндовс, но требуют ещё кучу разного виндового типа C#.
Вот этот вопрос, насчет C, меня больше других интересовал. Это не надуманная проблема. Это просто другой язык, очень низкоуровневый, в котором нет даже стандартной библиотеки контейнеров. Я работал в таком проекте и было неприятно, когда рещая задачу предметной области, параллельно приходится устранять баг в самописном списке. А на С++ сейчас можно писать почти также легко как на Java, если можно подтягивать любые библиотеки.
Интересно почему ищут программистов на C? Может это объясняется просто легаси кодом, как тут уже упоминалось.
Все ведь повторяется. десктопы прошли путь от очень ограниченных по ресурсам, до современных машин с избытком ресурсов. C сменился на C++ и потом на Java/С#.
Современные микрокомпьютеры по пороизводительности не уступают десктопам пятнадцатилетней давности. Логично использование C++, т.к. он снижает сложность.
Я работал в таком проекте и было неприятно, когда рещая задачу предметной области, параллельно приходится устранять баг в самописном списке. А на С++ сейчас можно писать почти также легко как на Java, если можно подтягивать любые библиотеки.
Не насилуйте себя. Пишите на Java. Можно даже под Линукс.
наверное минус такого подхода — это фактически стать мидлом на какое-то время. Формально могут взять и сеньором. Интересно как долго будешь терять в ЗП.
Java мидддлы получают сравнимо с C++ сеньёрами. :)
Вот этот вопрос, насчет C, меня больше других интересовал. Это не надуманная проблема. Это просто другой язык, очень низкоуровневый, в котором нет даже стандартной библиотеки контейнеров.Я всегда рассматривал C++ в отрые от STL и boost. Может потому что начинал давно и стандартная библиотека в Turbo C++ 1.0 вызывала бы сейчас гомерический хохот.
Я работал в таком проекте и было неприятно, когда рещая задачу предметной области, параллельно приходится устранять баг в самописном списке.Я списки не писал со времён универовских лаб, ибо для С я использую: BSD queues: svnweb.freebsd.org/...s/sys/queue.h?view=markup одно время тягал хедер из проекта в проект, а сейчас уже все ОС поддерживают это как стандартное, с определёнными ньюансами, чего-то нет, что-то есть дополнительно и т.п.
А на С++ сейчас можно писать почти также легко как на Java, если можно подтягивать любые библиотеки.Если требования к проекту такие, что остаются С с классами, то почему бы не поискать чистых С программеров. В западном мире чистых С программеров ну наверное 3/4 среди всех С/C++. Это у нас почему-то все С++. Я тоже С учил спустя пяток лет после С++, было тяжко.
Интересно почему ищут программистов на C?
Современные микрокомпьютеры по пороизводительности не уступают десктопам пятнадцатилетней давности. Логично использование C++, т.к. он снижает сложность.Опять же смотря где. Сплошь и рядом в embedded используют OpenCV, она написана на С++, но тем не менее её вызывают из С кода. Да и дело не в сложности, а в предсказуемости, в С++ со стандартной библиотекой (причём от разных производителей) код получается слабопредсказуем.
ибо для С я использую: BSD queues
Кстати, они уже давно рядом такого же стиля RB-деревья сложили:) только там всё в макросы не укладывается, надо рядом сложить инстанциацию для конкретного целевого типа.
Может потому что начинал давно и стандартная библиотека в Turbo C++ 1.0 вызывала бы сейчас гомерический хохот.
О да. Хотя списки в ней уже были:) Вообще, самое смешное, что там было — это политика реаллокации (грубо говоря, если вылезли за пределы N, требовать realloc не на 4+N*2 или N*1.618, а на N+10). Всё остальное — нормально объяснимое и законное детство, а вот именно это разумом не понять. Но в большинстве случаев и тогда проходило.
Вот этот вопрос, насчет C, меня больше других интересовал. Это не надуманная проблема. Это просто другой язык, очень низкоуровневый, в котором нет даже стандартной библиотеки контейнеров.ужос-ужос
Я работал в таком проекте и было неприятно, когда рещая задачу предметной области, параллельно приходится устранять баг в самописном списке.а навіщо було велосипедити?
Интересно почему ищут программистов на C?взагаліто, туйова хуча бібліотек написана на простому тупому Ц
А на С++ сейчас можно писать почти также легко как на Java, если можно подтягивать любые библиотеки.може тоді кразе зразу на Жабі, аби не мучитися?
Логично использование C++, т.к. он снижает сложность.ти впевнений?
як на мене зменшує складність правильна архітектура, використання готових бібліотек і їх АРІ та скриптів
ужос-ужос
а навіщо було велосипедити?большинство C проектов уже существуют и пользоваться приходится тем, что уже есть в проекте. Могли бы в 1999 и добавить какую-нибудь бесплатную библиотеку из тех, что получше в качестве стандартной — раз уж
хуча бібліотек написана на простому тупому Ц.
впевнений?сори, но продолжать здесь диспут про C против C++ в контексте снижения сложности не буду, т.к. выяснение целесообразности использования ООП в другой теме.
Євген Козлов
а че там с рынком? ни становится ли (сильно) нишевым, как Перл или Асм?
топикстартер вон, ниже обозначил приоритеты:
приоритет — оставаться на плаву: это и ЗП и возможность найти новую работу без особых проблем.мне-то кажется, что с этим все сложнее и сложнее, но я валенок в этой области.
а че там с рынком? ни становится ли (сильно) нишевым, как Перл или Асм?Он уже давно нишевый.
Євген Козлов
в чем вопрос? будут ли вакансии разработки _нового ПО под windows на С++_? да, будут.
будет ли их много? нет, навряд ли. на этом сайте 57 вакансий по С++(это без уточнения платформы) и 153 по C#(именно так, а не более обширный сегмент «.Net»).
решить за тебя можешь только ты сам. в зависимости от приоритетов.
даже по опыту не понятно: обобщенное «серверное ПО под Windows» — достаточно туманно звучит.
приоритет — оставаться на плаву: это и ЗП и возможность найти новую работу без особых проблем.
По поводу C#: 1) на DOU встречал статистику, согласно которой предложение по C# не отстает от спроса. 2) С нуля наверное не стоит учить C++, но для тех, кто уже вложил время, возможно, уже не стоит расставаться с плюсами.
не, ну, вы говорите про «че-то серверное писать».
на С++ есть, кроме эмбеда, и всякие алгоритмические штуки. но к серверу не имеющие отношения. ну, не знаю, медицинские проекты, например.
Медицинские, из того что представлены у нас это графика, OpenGL, насколько мне известно
я вообще из другого мира, так что ничего конкретного не скажу.
но на глаза попадается, ага.
в Softserve минимум несколько проектов на С++ есть, но там по безопасности шо-то.
опять же, вакансии Hola бередят душу намеками на хитрые задачи, критичные к скорости.
но что еще есть — прямо сразу не скажу.
выложитесь на Джинни, посмотрите отклики, что ли.
Да и его тоже стоит выучить, так как OpenGL — часто единственное что держит С и С++ за пределами embedded и серверного ПО. Есть чисто алгоритмические типа OpenCV и компания, но нужно уметь полученные и обработанные данные визуализировать. OpenCL тоже стоит изучить, многим он нужен.
Это хорошо что Вы за такую многогранность интересов. Иногда ведь натыкаешься на критику резюме, где человек многостаночник. Якобы не следует человек специализации, кидается из стороны в сторону.
Сейчас для С++ программиста считается хорошим тоном знать Qt, если нужно GUI и OpenGL, если надо умень визуализировать данные. Я бы не назвал это многостаночностью, скорее необходимый минимум.
211 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів