Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специальных. Это шестая статья из серии, список предыдущих статей приведен в конце в разделе 7. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Данная статья посвящена объявлению и инициализации переменных.

Переменные являются основой любого языка программирования. В языках со статической типизацией, к которым относится C++, все переменные должны быть объявлены, их тип определяется на стадии компиляции и не может меняться в процессе работы программы. Тип переменных указывается при объявлении явно или выводится компилятором на основе типа инициализирующего выражения.

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

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

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

Недавно я получил по почте от Сэма Джонсона этот вопрос. Вот слегка отредактированное письмо Сэма:

«Возьмём для примера этот код в локальной области видимости функции:

int a;

a = 5;

Многие люди считают, что инициализация происходит в строке 1, потому что веб-сайты наподобие cppreference дают такое определение: "Инициализация переменной предоставляет его начальное значение на момент создания".

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

Можете ли вы сказать, какая строка считается инициализацией?»

Отличный вопрос. На Cppreference написано правильно, и для всех классовых типов ответ прост: объект инициализируется в строке 1 вызовом его стандартного конструктора.

Но (а вы ведь знали, что будет «но») для локального объекта фундаментального встроенного типа наподобие int ответ будет... чуть более сложным. И именно поэтому Сэм задал этот вопрос, ведь он знает, что язык достаточно свободно обращается с инициализацией таких локальных объектов по историческим причинам, имевшим в то время смысл.

Короткий ответ: вполне допустимо говорить, что переменная получает своё исходное значение в строке 2. Но заметьте, что я намеренно не сказал «Объект инициализируется в строке 2», к тому же и код, и этот ответ обходят молчанием более важный вопрос: «Ну ладно, а что, если код между строками 1 и 2 попробует считать значение объекта?»

Статический анализ — это очень мощный инструмент, позволяющий следить за качеством кода. Предлагаем вместе попробовать написать простой Lua анализатор на Java, чтобы понять, как устроены статические анализаторы кода внутри.

Привет! Меня зовут Юля Вакуленко, я дизайнер в AGIMA. Хочу вам рассказать о том, как знания из художественной школы помогают мне с решением рабочих задач.

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

О, таблица merchants2? Да, у нас закончились столбцы в merchants, поэтому мы сделали merchants2.

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

Статья о том, как я во время каникул писал-писал язык для описания конфигураций, да и переборщил с объёмом

Всем салют! Давайте решим задачу "Middle of the Linked List"

Дан указатель head на начало односвязного списка, нужно вернуть средний узел списка.

Если средних узлов два, нужно вернуть второй средний узел.

Если вы никогда не пробовали смотреть как код на C++ разворачивается компилятором в код Assembly – вас ждёт много сюрпризов, причём, не нужно смотреть какой-то замудренный исходный код полный templates или других сложных конструкций: рассмотрите следущий snippet:

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

Ни один процесс разработки программы не проходит без отладки. Современные IDE обеспечивают программиста встроенным отладчиком. Однако бывают ситуации, когда использование IDE для отладки избыточно или невозможно, и тогда на помощь приходят автономные отладчики, один из которых — x64dbg.

Привет, Хабр! Ухудшение работы YouTube стало поистине трагическим событием, которое прибило почти все загрузчики видео, но я нашел легальный способ улучшить ситуацию! Как починить оборудование Google, не привлекая внимание санитаров.

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

Это история о том, как я разочаровался в культовой третьей части и остался в клубе фанатов спорной «четверки». 

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

Главная ошибка была в том, что ты в это вообще ввязался — в этом никаких сомнений.

Ещё когда я впервые взялся проходить курс по C++ несколько лет назад, меня учили, что, если я не предоставлю собственного конструктора, то компилятор сам подберёт ему замену — своего рода конструкторы, действующие по умолчанию. Я решил подробнее в этом разобраться, особенно меня волновали случаи, которые выглядят примерно так:

Эта статья — просто идея, не судите строго.

TLDR: предлагаю рассмотреть хранение исходных кодов программ в некоем бинарном формате вместо голого текста.

Компилятор и IDE

Как примерно работает компилятор: сначала происходит лексический анализ, т.е. разбиение исходного кода на токены. Потом происходит синтаксический анализ — полученные токены объединяются в синтаксическое дерево. Потом семантический анализ: вывод типов данных, проверка видимости переменных, и т.д.

И только потом идут этапы, приводящие в конце концов к появлению исполняемого файла.

Как работает типичная IDE: да точно так же. Лексический анализ, синтаксический анализ, семантический анализ, вывод типов, и всё прочее. Т.е. по сути ребята пишут полкомпилятора, чтобы вы могли получить все современные возможности IDE.

Т.е. сам текст программы нужен только человеку на этапе ввода информации. Потому что ему для понимания происходящего AST-дерево не подойдёт.

Но что если хранить исходный код по-другому?

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

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

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

В этой статье мы рассмотрим графический метод нахождения формул для суммы степеней натурального ряда.