Как программировать на С++, не делая из него другого языка?

Што

Изобрести машину времени, вернуться в 2004, писать как все пишут.

Или выкинуть ++ из С++.

Как писать на «С++» в стиле «С с классами»?

Лучше никак. Говно получается обычно.

без внедрения зависимостей и всяких ORM

Это-то тут причем? Как будто код на C++, который использует fmtlib или Boost.MultiIndex, внезапно перестает быть кодом на C++.

А вообще, как минимум, нужно забить на то, что кто-то считает «настоящим C++», а что таковым кем-то не считается.

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

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

Rust?

Писал один комментатор из всех. Да и ТС так и не потрудился нормально описать задачу, нахрена ему там Dependency injection и базы данных. Как будто какой-то курсач по программированию делает.

Без нормальной задачи и нормального её описания ни на вопросы того ТСа, ни, тем более, на твой ответить нельзя

Освоить С++ целиком, хотя бы до C++14. Чтобы не возникало потребности притащить некоторые фишки, получившие популярность в других языках, потому что проблемы, которые они решают, в С++ решаются другим способом.

(без внедрения зависимостей и всяких ORM и т.д???)

Будь мужиком! Напиши их сам!

Вам виднее.

Я уже и с C++ как-то приноровился. Но я в рамках больших команд (когда над кодом работает больше 50 человек) и не работаю.

Но я в рамках больших команд (когда над кодом работает больше 50 человек) и не работаю.

В рамках больших команд, когда над одним кодом работает столько народу, вообще ничего не работает.

http://www.intelib.org/intro.html

АЭС строят несколько тысяч человек одновременно и всё получается. Нужен полный проект и архитектор.

АЭС строят несколько тысяч человек одновременно и всё получается. Нужен полный проект и архитектор.

Ты ещё скажи, что с полным проектом и архитектором твоя мама родила тебя через три дня, а не через девять месяцев.

С++ для того и создавался, чтобы писать абстракции нормально. Из классического ANSI C++ можно сделать что угодно. Например, Croco сделал InteLib, которая позволяет писать на C++ как на Лиспе.

Вынашивание детей хорошо параллелится. 90 мам родят 90 детей за 9 месяцев при должной организации. То есть в среднем одного ребёнка за 3 дня.

Вынашивание детей хорошо параллелится. 90 мам родят 90 детей за 9 месяцев при должной организации. То есть в среднем одного ребёнка за 3 дня.

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

Ну ты сравнил Строителей и сраных кодеришек.

Положить один кирпич быстрее не получится никак. Положить стену из 5000 кирпичей можно быстрее вдесятером, чем в одиночку. В программировании должно быть так же: вдесятером быстрее, чем в одиночку.

Положить один кирпич быстрее не получится никак. Положить стену из 5000 кирпичей можно быстрее вдесятером, чем в одиночку. В программировании должно быть так же: вдесятером быстрее, чем в одиночку.

Иди читай «Мифический человеко-месяц» до полного просветления.

ох, чувак, никто на самом деле не знает что это за стиль такой, даже автор, настолько это необъятное и не консистентное чудище

Нужен полный проект и архитектор.

Что делать если в наличии только полный архитектор?

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

Дело не в С++, дел в том что это твои «внедрения» эти прочие модные слова на самом деле представляют из себя околокодерскую графоманию и не нужны.

Так ведь через три дня и есть (на всякий случай обращу твоё внимание что ты не указал точку отсчёта и вероятно считаешь от другой даты).

Так аналогии правильные выше - если надо написать 1000 программ то это можно распараллелить на 1000 программистов с почти нулевым оверхедом. Тут больше проблема где столько найти одновременно (хороших).

Интересная тема.

Чем же?

По сабжу: просто взять и писать на этом вашем C++.

Освоить С++ целиком, хотя бы до C++14. Чтобы не возникало потребности притащить некоторые фишки, получившие популярность в других языках, потому что проблемы, которые они решают, в С++ решаются другим способом.

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

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

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

Поэтому забудьте про несуществующие каноны и используйте инструмент как вам удобно. Конечно же, если вы называете C++ языком программирования, и DI и ORM будут абсолютно «в стиле C++» на все 100%.

Запросто, но для этого нужен лид который сможет декомпозировать задачу и задизайнить интерфейсы, после этого действительно можно работать на 100% параллельно. Только если в кирпичеложестве лидом быть все хотят, потому что это более простая, высокооплачиваемая и уважаемая работа, но в программировании наоборот - чтобы спроектировать систему учтя все требования, и предвосхитив требования неозвученные или их изменения, нужна куча сил и колоссальный опыт, при этом не всегда это ценится, в отличие от разноабочего Васи, который заимплементил f(int x, string b) -> string с готовым набором тестов.

Сам придумал, сам опроверг, красавчик.

Dependency injection это подход в ООП. Язык тут ортогонален. Если язык позволяет, то и DI на нем можно нативно реализовать. Пиши DI на плюсах, если нужно конечно) и не майся дурью))

В C++ нет единого стиля. Вот, ты спроси себя, хочешь ты, чтобы в твоем коде кидались исключения? И сразу два стиля программирования получаются. Где-то еще на идиомах можно попытаться усидеть сразу на двух стульях, но в целом, это будет очень непросто. Причем, люди просто недопонимают, почему в проектах на Qt рискованно кидать исключения. Ну да, ладно!

С другой стороны, вот те же идиомы есть. Книжки вон умные написаны. Наверное, какой-никакой стиль все же есть, но в исходниках до сих пор встречаются сигнатуры функций в стиле Кернига и Ритчи времен первого издания… Так что, чем старее язык, тем больше в нем стилей. Я бы так сказал.

Да, и вообще, не забивай себе голову такой ерундой. Как программируется, так и программируй! Копируй стили из книжек умных, хороших библиотек. Учись по хорошим примерам, но больше на алгоритмы напирай, на их сложность, трудоемкость. Стиль - это далеко не самое главное. Важнее, работает твой код или нет!

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

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

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

Так ведь через три дня и есть (на всякий случай обращу твоё внимание что ты не указал точку отсчёта и вероятно считаешь от другой даты).

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

Во-первых, это ты отсчитываешь, не надо за всех говорить.

Во-вторых,

Ты ещё скажи, что с полным проектом и архитектором твоя мама родила тебя через три дня,

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

Вполне разумная точка отсчёта.

Для программиста на C++, разве что. У вас всё не как у людей!

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

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

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

Основное правило написания кода на плюсах

Неслушать всяких там фанатиков одного правильного способа, т.к. язык официально «мультипарадигменный», а фанатики должны страдать.

DI в C++ можно, только выглядит оно по-другому.

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

АЭС строят несколько тысяч человек одновременно и всё получается. Нужен полный проект и архитектор.

Строительство энергоблока 3 началось в 2005 году. Коммерческая эксплуатация, первоначально запланированная на май 2009 года,[4][5] началась 1 мая 2023 года.[6]

Королевского пути нет, но плохонький путь есть.

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

Никак, плюсы - дергунчик для шизофреников

Там какой-то сок мозга. Начиная с этого вот di::make<>

Там ничего не понятно, потому что объяснение начинается не с вопроса «зачем эта хрень нужна», а с вопроса «как эта хрень работает». Но если дочитать до FAQ, то всё должно встать на свои места.

шаблоном

станет короче и понятнее

Только во влажных мечтах плюсовиков.

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

Хвататься за питолет нужно когда тебе начинают затирать про «сиплюсплюс».

DI это когда тебе нужно из экземпляра класса A обращаться к экземпляру класса B, и для этого ты, вместо реализации внутри A логики получения нужного экземпляра B (что обычно сводится к выковыриванию свойств какого-нибудь глобального или thread-local синглтона), передаёшь ссылку на экземпляр B в конструктор A. Всё. Предельно тупой и универсальный паттерн, от языка ни с какого боку не зависящий.

Как программировать на С++, не делая из него другого языка?

Если не программировать на С++, то вопрос решится автоматически.

люди просто недопонимают, почему в проектах на Qt рискованно кидать исключения.

Нелюди говорят:

Qt использует механизм сигналов и слотов, который может привести к проблемам при обработке исключений. Если исключение выбрасывается в слоте, оно может быть необработанным, если сигнал был отправлен из другого потока. Qt использует механизм автоматического управления памятью через умные указатели (smart pointers), такие как QSharedPointer и QScopedPointer. Эти умные указатели автоматически удаляют объекты, когда они больше не нужны, но они не могут корректно обработать исключения, которые могут возникнуть в деструкторах.
Когда исключение выбрасывается из деструктора, оно может привести к двойному удалению объекта, что может вызвать неопределённое поведение программы. Это связано с тем, что умные указатели могут попытаться удалить объект, который уже был удалён в результате исключения.

А почему на самом деле?