LINUX.ORG.RU
ФорумTalks

C++ для Си-программиста

 , ,


1

7

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

Перемещено tailgunner из development

а оно тебе надо?

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от anonymous

А вообще читай за раст уже. Хватит плодить говнокод на плюсах.

Правильно-правильно. Нужно больше ржавого говнокодазолота.

slackwarrior ★★★★★
()
Ответ на: комментарий от kawaii_neko

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

Ты ведь троллишь? Или правда так думаешь? К сожалению или счастью, но на плюсах начинают и новые проекты. [Пруфов не будет.]

DarkEld3r ★★★★★
()
Ответ на: комментарий от kawaii_neko

Сынок

Ой-фсе... В продакшын коде светлое будущее настает не так быстро. Никому не нужно что-то модное-танцевальное только потому что оно модное, но из него еще не выловили всех блох (это не жабоскрипт, где работать можно только в том, с чего уже вся хипстота убежала с визгом «оно дохлое, не обновлялось полгода!» (а лучше vanilla.js и plain.js ничего нет :)) Независимо от предпочтений йезыков, молоток, который в руке изменяется точно никому не нужен.

slackwarrior ★★★★★
()
Ответ на: комментарий от chimera19

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

А ты для пруфа готов все тестами заново покрыть (не будем о грустном) — ок, ты готов зарплату свою поставить за 12 лет, что ничо не сломается в проде после переписывания в модном стиле всего напластования человеко-лет? Манагер не разрешает, потому что ему заказчика надо убедить, а не просто стрелки на тебя перевести — «вот его в тазик с цементом» :)

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от DarkEld3r

Почему?

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

Deleted
()
Ответ на: комментарий от Deleted

Реальный код на ржавчине получается перегруженным конструкциями, в которых запутаться проще, чем даже в плюсовом коде.

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от kawaii_neko

в 17-м стандарте не будет ни сокетов, ни файберов

Средствами самого языка никак нельзя сделать? Обязательно ждать пока в std запихают?

Hertz ★★★★★
()
Ответ на: комментарий от Deleted

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

slackwarrior ★★★★★
()
Ответ на: комментарий от Kroz

Поведай, что же такого страшного в endl, то должно призвать всех срочно отказать от него?

std::endl не только переводит строку, но и сбрасывает буферы, поэтому, если нужно только вставить перенос строки, то эффективнее использовать << "\n" вместо std::endl.

chimera19
()
Ответ на: комментарий от i36_zubov

что плохого в том, чтоб писать на С++ как на С с классами?

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

Кому нужно программировать, так и поступает, но так срач на 10+ страниц не создать.

chimera19
()
Ответ на: комментарий от chimera19

По делу — это ты выше понтанулся что проблем никаких :) Да и пруф нужен не мне, а менеджеру, который тебе «нидает что-то менять» под свою ответственность — у тебя-то никакой пока, да? :)

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

По делу — это ты выше понтанулся что проблем никаких

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

chimera19
()
Ответ на: комментарий от chimera19

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

Начались прохладные истории из серии «в идеальном мире» :)

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

Ты тупо не в теме, как это работает :) У коммерческой конторы нет цели сделать офигенно круто (т.е. можно — но это рассматриваетс под углом «кост-эффектив», т.е. соотношения усилий и выхлопа, причем не в долгосрочной перспективе, и даже не в пределах человеческой жизни, а несколько раньше, особенно если контора вышла на IPO и выхлоп надо делить с акционерами). Т.к. контора и команда «NOT YOUR PERSONAL ARMY», менеджер обязательно согласует с заказчиком бюджет этой всей лабуды — и если будет где-то рядом охапка «сеньеров за еду», как ты рассказываешь (ну или страдальцев «комплексом морской пехоты: настоящие программисты во сне и отдыхе не нуждаются — нахер выходные, чо» (обычно у нормальных людей это проходит где-то годам к 30, у семейных — намного раньше :)), заказчик радостно одобрит эту вакханалию, звезды совпадут и планета наскочит на небесную ось после чего всем будет пофиг — то ок. А нет — так нет :) Нет бюджета — нет работы.

slackwarrior ★★★★★
()
Ответ на: комментарий от chimera19

В результате разработка станет очень медленной и очень дорогой (чем-то ведь нужно компенсировать необходимость оставаться в проекте)

"-- Папа! Я за месяц закрыл то несчастное дело, из-за которого ты таскался с клиентом по судам 20 лет!

 — Сынок, видишь ли... Наша юридическая контора, дом, автомобиль, загородное поместье, твое образование и т.д. были оплачены благодаря «тому несчастному делу». Я то уже пожил свое... Но... ты уже большой мальчик — пора тебе узнать страшную правду про деда Мороза и усвоить важный жизненный урок." (с)

Как-то так. Но это работающий бизнес-план, чего бы там клиентам не дули в уши про «быстро, качественно, нидорага». Качество дешевым вообще не бывает. А когда кроилово начинается — менеджеры, дезориентированные CI/DI с автотестами, которые напишут программисты, радостно спиливают с команды «жырок» типа отдельных спецов по QA и перфомансу — заменяя их, например, «нашими экспертами из компетенси центров, за отдельную плату» (которую клиент обломается платить). И вуаля :) Души прекрасные порывы там и не ночевали :) Не нравится — вперед, основывать свою контору с «кровоточащим краем инноваций и бест практисами», чо.

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

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

chimera19
()
Ответ на: комментарий от chimera19

Я в курсе. И, если только программа не должна выдавать N тысяч строк в секунду, ничего страшного в этом не вижу; скорее только плюсы.

Kroz ★★★★★
()
Ответ на: комментарий от chimera19

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

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

Такой разработчик из описанной тобой конторы свалит при первой возможности.

Ага. На остров с пальмой, где работать вообще не надо (можно числиться «CEO и кофаундером» стартапа, но лучше — стартапхапа... И не в ИТ, а в оффшорных хедж-фондах :) Кокосы сами падают. И горячие мулатки по кустам валяются. Только успевай...

Лично наблюдал этих с шилом в жеппе, «не усижу три года на одном месте» — возвращаются, отбив амбиции о чугунную же... лезобетонную бзсхднст реальности или уходят в управдомы, если профессией ошиблись. Один вот риальни думал, что в нефтянке ему с ойтишного ПМства сразу дадут чем-то рулить, без профильного образования — ну да... Дадут. Буровой в Уренгое.

Сразу после разнорабочих и через мастера глубокого бурения :)

Ушел к конкурентам «у них перспективы»... Потом вернулся с остановившимисе глазме (ПМом не стал), на ступеньку выше прежней (которую тут уже все миновали), наверное поняв жызнь :) (И таких было не один — а все которые «я нитакой как все»).

slackwarrior ★★★★★
()
Ответ на: комментарий от chimera19

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

slackwarrior ★★★★★
()
Ответ на: комментарий от DarkEld3r

К сожалению или счастью, но на плюсах начинают и новые проекты

Новые проекты много на чем начинают, даже на хаскеле. Кодовая база на C++ выходит из под контроля очень быстро. Это, наверное, самый плохой после lisp-а язык для поддержки: всякий так и норовит присунуть маргинальных библиотек, да прилепить невпопад какой-нибудь модный паттерн.

kawaii_neko ★★★★
()
Ответ на: комментарий от Hertz

Средствами самого языка никак нельзя сделать? Обязательно ждать пока в std запихают?

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

kawaii_neko ★★★★
()
Ответ на: комментарий от kawaii_neko

Это, наверное, самый плохой после lisp-а язык для поддержки: всякий так и норовит присунуть маргинальных библиотек, да прилепить невпопад какой-нибудь модный паттерн.

Это вы, наверное, еще с JavaScript-ом дел не имели...

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

eao197 ★★★★★
()
Ответ на: комментарий от RazrFalcon

Ну и на засыпку: любой прикладной софт сложнее блокнота. Хотя и они на плюсах

В последнее время они всё чаще на node.js. И любой прикладной софт уже тоже на нем всё чаще пишут. Скайп вот новый, как пример.

Loki13 ★★★★★
()
Ответ на: комментарий от Loki13

В последнее время они всё чаще на node.js.

Довелось попользоваться StarUML, который на node.js. Как только UML-диаграмма чуть посложнее, так ощутимые лаги при выполнении действий. Так что, может разработчикам StarUML использовать node.js было проще. А вот пользователям сего творения от этого только хуже.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

ощутимые лаги при выполнении действий

Ну так да, я же с сарказмом писал. Так то блокнот(atom.io) тормозящий на 4-х ядерном i5 и 4Гб памяти это за гранью уже.

Loki13 ★★★★★
()
Ответ на: комментарий от Loki13

Сарказм-сарказмом, но хайп вокруг Electron-а в частности и разработке десктопных приложений на базе Web-технологий же не на пустом месте возникает :(

eao197 ★★★★★
()
Ответ на: комментарий от kawaii_neko

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

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

Кстати, в плюсах с «маргинальными библиотеками», в некотором роде, даже «проще». В смысле, если каждого, кто библиотеку подключить хочет, тыкать в необходимость сборки на разных платформах, то использоваться будет самое необходимое.

DarkEld3r ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.