Я правда хочу разобраться.



Не означает ли эта запись, что внутри функции мы работаем с адресами переменных?

Это (в C++) означает, что переменная передана по ссылке. То есть, любые изменения её внутри функции изменяют оригинальную переменную извне. Внутри функции (с точки зрения синтаксиса) с этими переменными работать нужно ровно так же, как если бы они были переданы просто по значению.

P.S.

Спойлер

Код:

#include <iostream>

using namespace std;

void swap_c_style(int a, int b)
{
    int r = a;
    a = b;
    b = r;
}

void swap_c_pointer_style (int *a, int *b)
{
    int r = *a;
    *a = *b;
    *b = r;
}

void swap_cpp_style(int &a, int &b)
{
    int r = a;
    a = b;
    b = r;
}

int main()
{
    int x, y;

    x = 2; y = 3;
    swap_c_style(x, y);
    cout << "x: " << x << ", y: " << y << endl;

    x = 2; y = 3;
    swap_c_pointer_style(&x, &y);
    cout << "x: " << x << ", y: " << y << endl;

    x = 2; y = 3;
    swap_cpp_style(x, y);
    cout << "x: " << x << ", y: " << y << endl;

    return 0;
}

Вывод:

Код:

x: 2, y: 3
x: 3, y: 2
x: 3, y: 2

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

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Как создать и подключить .h и .с файлы? Как правильно?
Создаю timer8.c с реализацие функции, и создаю timer8.h с обьявлением функции. Кидаю в одну папку с main.cpp файлом.
В main в начале пишу:


В timer8.h обьявляю:


В timer8.c пишу:


Как итог "undefined reference to `Timer0Init()'". Если в .h файле добавить "#include "timer8.c"" то ошибки нет. Но это же идеологически не правильно.
Пишу в AtmelStudio7.
Как правильно делать?

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

правильно:
1. не делать проекты без необходимости с исходниками одновременно С++ и С
2. добавлять исходники в проект средствами IDE

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

1. Этого, наверное, мало. Нужно добавить исполняемый файл в проект.
2. Объявление в .cpp-файлах внешних функций, находящихся в .c-файлах нужно делать через обрамление в extern "C"{}

Т.е. это нормально-правильно, что если в майне есть инклюд .h файла, то .cpp автоматом к нему не подтягивается? Надо обязательно средствами IDE добавлять, а не из main или добавленных к main файлов. Далать "#include "timer8.cpp"" - вроде как не правильно?

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

Есть IDE, которые всё подряд из папки компилят, но это как-то нефеншуйно.

Отнюдь. Только не всё подряд, а определённые типы файлов. Вон FeCat-у именно так и хотелось бы.)

Я правильно понимаю, что если появилась необходимость подключить к проекту "C++" файлы "C", то делаем так:
extern "C"{
#include "timer8.h"
};
Файл timer8.c добавится в проект "C++"(через IDE) как "C".
Аналогично можно делать вставки кода не на языке "файла".

Не добавится он в проект. Его нужно самому добавлять, ручками. Чтобы он отображался в дереве проекта.
Как это делается конкретно в вашем IDE - не в курсе. Погуглите.

Нет... Есть IDE, которые сканируют каталог и всё, что там найдено считают файлами проекта и подвергают компиляции. Типичный пример - IDE Momentics в QNX 6.3 (на базе Eclipse вроде она).



Но, кстати, очень удобно. В отличие от Visual Studio с логическими папками (которые ещё создать надо ручками), проектом очень просто управлять - создал папки и скопировал файлы и попросил пересканировать.
А вот есть всякие Keil, которые сами чего-то там из CMSIS и HAL компилируют из исходников, но в проекте этих файлов исходников не отображается (или я не в курсе, как его заставить их показать). Вот это неудобно.

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

Тупо подключать и компилировать все .c файлы из каталога - плохая идея. Компилятору следут передавать только нужные файлы.

Почему - ответ простой. Если у меня в проекте поддерживается, например, 20 разных контроллеров дисплея, а собираю я под какой-то конкретный, то компилировать 19 ненужных файлов нет смысла.

да, Eclipse CDT по умолчанию именно так и делает: всё, что в папке проекта, считает компилируемыми файлами. однако, легко можно исключить любой файл и даже папку целиком из этого списка.как правило, в IDE это решается при помощи конфигурации разных target-ов, и в упомянутой мною Eclipse именно так.

Наоборот, удобней в любой заголовочный файл C в начало поставить

, а в конец:



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

Надо в cи файле написать #Include "timer8.h"

Огромное спасибо ответившим. Вроде в голове прояснилось.

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