Как часто в реалях используется переопределение? типа #define

Часто :) Это определение, а не переопределение. Тот же Unreal Engine определяет дофига макросов. Ними пользуются для разметки текста, ещё как-то, ...

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

Сишники пишут на плюсах в стиле Си с классами )

Сишники пишут на плюсах в стиле Си с классами )

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

Это понятно, что никто переписывать не будет. Другой вопрос, что если бы начали писать в нынешнее время, то, скорее всего, стали бы писать не на Си

На Rust? Но вообще не уверен, я вот прошёл путь от Си к восторгу от С++ и изучения стандартов. А сейчас свои пет-проекты пишу на снова C. Переписать не настолько больая проблема, Mozilla же начала переписывать на Rust. Не говоря, что переход от С к С++ ввиду совместимости не очень то страшный: просто новый функционал можно запилить на плюсах :)

то-есть С умирает?(

Точно нет, потому что есть embedded. А так в непонятном индексе TUOBI С даже вышел на первое место по популярности, и даже обошёл C++. Так что не уверен... В целом лично мне на C писать приятнее всего

Точно нет, потому что есть embedded. А так в непонятном индексе TUOBI С даже вышел на первое место по популярности, и даже обошёл C++. Так что не уверен... В целом лично мне на C писать приятнее всего

Мало кому в кайф в железе копаться)

Всё относительно. Как по мне, достаточно много. Уж точно, как по мне, повеселее CSS стилей. Ну и...

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

@mustitz чем полезен ооп, и какие трабблы при переходе НА него с процедурного?

Если new не смог выделить память, там будет брошено исключение Bad Alloc )

Есть глобальные грабли, как по мне. Первая — перформанс. Поэтому и появилисть те же колоночные базы, что хранить в обном объекте разнородные данные не кэш френдли. Если говорить про Simula-like ООП, то зачастую 90% кода у нас не будет вызываться никогда, но будет работать код, которые его поддерживает. Особененость крупных фреймвёрков. Мне вот очень нравилось, что во времена, когда PHP был процедурный, то в рекомендацях сервер на Java требовал в два раза больше, в раза мощнее проц и т. п.

Чо перфоманс, колоночные базы. А? Я первый раз слышу, дай вводную статейку скурить пожалуйста

ООП будет полезен тем, что в 90% мест, куда вы будете устраиваться на работу, вам прийдется иметь с ним дело

ИМХО, Simula-like ООП (с таблицами виртуальных функций) инструмент достаточно тонкий, и я часто наблюдал ситуацию из серии «дай дураку стеклянный хуй», большая часть иерархий, которые возникали на проектах в какой-то предметной области, оказывалась мягко говоря не ахти. Хотя, могу припомнить и достаточно удачные реализации, типа Delphi VCL.

Именно в этом я и вижу основную проблему С++. Условно говоря, для решения любой задачи в С++ есть 10 разных способов. Из которых 3 - откровенная херня, 4 - более-менее, 2 хороших и 1 - прям отличный ))

Ну, это же просто - добавить маааленькую новую фичу )))))

Ок спасибо

Кстати, наткнулся на такое описание разных типов СУБД, может для общего образования https://proglib.io/p/11-tipov-sovremennyh-baz-dannyh-kratkie-opisaniya-shemy-i-primery-bd-2020-01-07

Есть глобальные грабли, как по мне. Первая — перформанс. Поэтому и появилисть те же колоночные базы, что хранить в обном объекте разнородные данные не кэш френдли. Если говорить про Simula-like ООП, то зачастую 90% кода у нас не будет вызываться никогда, но будет работать код, которые его поддерживает. Особененость крупных фреймвёрков. Мне вот очень нравилось, что во времена, когда PHP был процедурный, то в рекомендацях сервер на Java требовал в два раза больше, в раза мощнее проц и т. п.

Как то все в одну кучу при чем тут перфоманс ооп и колоночные базы? У всех структур есть своя область применение одна и та же структура может быть как удачной так и не удачной в зависимости от сценария использования. Идея колоночного хранения всегда была на поверхности и никакого ноухау в ней нет всего лишь индексы. Глобальные грабли это когда валят все в одну кучу. Есть у вас куча ненужных полей отрежте их в отдельную таблицу. СУБД как и языки давно уже многопарадигменные.

Привет Игорь)

я ушел тут от армии косили пришел тут какой то новый трешак :)

Хотел у тебя спросить, а ты в какой направлении программист?

программист алкоголик трештолкер %) у меня всегда не такое мнение как у остальных :)

Кто? 😂

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

Понял. Я тут совет дал, что мол нахрен всяких Hr-аров, надо сразу идти к тому человеку, который способен принять решение о приеме тебя на работу. Стоит ли так делать? И вообще кто проверяет резюме?

Почему я настолько "умный", что не могу запустить дебагинг(откладку) в VS?

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

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

Да ладно загибать, Си сложнее С++