По сути массив это не более чем упорядоченный набор элементов. Динамический массив это просто массив с НЕ статическим размером. Абстрактно это абсолютно одинаковые вещи. Если у тебя стоит задача найти например сумму элементов ты итерируешься по массиву и считаешь сумму. Неважно статический он или динамический. Вектор это абстрактно массив. Понимать то, что под ним лежит динамический массив надо. Уметь работать с сырыми динамическими массивами при этом уже не надо. Точно так же как и для того чтобы пользоваться std::sin не надо уметь раскладывать тригонометрические формулы в ряды (а они реализлваны именно так).
Базовая математика не меняется уже веками. Программирование сейчас и 12 лет назад отличается суперсильно. Про базовые знания, как я писал выше, надо понимать что такое массив абстрактно и как он себя ведет. Уже давно нет потребности в умении вручную выделять память для работы с массивом. Я не спорю, что более глубокие знания это хорошо. Но я и писал выше, что сейчас стоит сначала изучать реализации массивов в виде std::vector и std::array, а потом уже добавить к своим знаниям понимание того как вектор создает себя на куче, как он меняет свое capacity и чем capacity отличается от size. Другое дело в том, что сейчас не то чтобы нет потребности в ручном управлении памятью - это плохая практика.
P.S. Да, всякое программирование микроконтроллеров, работа напрямую с памятью и т.д. требует этого. Но для этого есть С, вся идея С++ заключается в уходе от опасных и костыльных методов решения проблем в С к пускай и чуть более медленным, но куда более безопасным, гибким и удобным методом решения проблем на С++. Как говорил Линус Торвальдс С стоит использовать как минимум для того, чтобы с проектом работали только люди которые лезут реально очень глубоко. Вот только он пишет ядро ОС, а не системные приложения... В промышленном коде С++ итак дает слишком много поводов отстрелить себе ногу чтобы лезть глубже и уведичивать шанс угробить все нехваткой знаний (поэтому кстати много где и переходят на условную джаву - чтобы не то что меньше работать с памятью, а не работать вообще). Сырые массивы новичкам нанесут только вред. В 2021 в первую очередь скорость надо увеличивать крастой архитектуры, а уж потом, обладая тучей знаний все еще сомнительным переходом на более низкий уровень. И это знание действительно суперполезно для человека который хочет стать программистом через пару лет.
LPSTR и подобные есть только в винапи. Это был твой "супер"аргумент в пользу актуальности char*.
Я начинал учить плюсы на стандарте 03 года, пока std::string был плохим вариантом. Поверь, я знаю про что говорю. Я писал на большем количестве разных ассемблеров (GAS, MASM, NASM), чем ты представляешь сколько их существует. Для меня int 80h это флешбэк к системным прерываниям, ты, если думаешь что с винапи не может быть реально странных проблем, следовательно даже не знаешь что такое системное прерывание (хуевая пародия на абсолютно дурацкое следствие, надеюсь ты поймешь).
const char* и char* это в первую очередь указатели. Первый константный, другой нет (ака по первому указателю память read-only, по второму - свободный доступ). Возможно ты хотел узнать знаю ли я, что написав
const char* str = "Hello!" str будет хранится в отдельной рид онли секции оперативной памяти после запуска? Или может ты хотел узнать чем отличается их ПРЕДСТАВЛЕНИЕ в памяти(ничем)? В любом случае стоит формировать вопрос точнее. Да и вообще у меня под профилем есть ссылка на мой гитхаб, где есть вещи для которых нужно понимание куда более сложных вещей, зачем очевидные вопросы?
В памяти то все одно, это верно. Но ТСу например хочется хранить строку (т.е. для него char* это в первую очередь cstring, а не массив 8мибитных элементов), а не байты, как в чит сфере.
Найди мне
хоть один метод, который принимает указатель на память как производную от char, а не как производную от void. Попробуй писать гуи на винапи и познаешь всю его боль. Слава богу есть Qt, которые использует основную фичу плюсов в виде ООП и работа с ним куда проще и веселее(и я говорю про все еще только писать код руками, никакие Qt Designerы которые позволяют создавать гуи тягая кнопочки я не рассматриваю), чем сишные подходы винапи.
Если ты начнешь везде тыкать свои ифы с проверкой на переполнение массива, то у тебя получится ужасный код, да и скорость ту самую сырых массивов ты теряешь. "Освободи память, когда она станет не нужна". Точно блять. "Если нет дома - купи". По твоему зря составители стандартов зря придумывали умные указатели и еще несколько раз потом их меняли? Конечно можно добиться кода без багов на С - куча дебага и проверок. Вот только если раньше это стоило того, то сейчас можно позволить потерять немного в скорости работы, зато сэкономить на нервах в случаях крупных крашей и времени программистов и тестеров. А с сишными массивами есть еще куча приколов когда оно вроде как и тесты проходит, и работает хорошо, но стоит поменять что-то в совсем другом месте или перенести код на другую машину как начнуться краши.
2021 год на дворе, пора переставать юзать сишные штуки в плюсах, когда есть актуальные аналоги.
