Это (в 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
Последний раз редактировалось WiseLord Пн апр 15, 2019 12:21:47, всего редактировалось 2 раз(а).
Не означает ли эта запись, что внутри функции мы работаем с адресами переменных?
Означает. Мы передаём константные адреса переменных, по которым работаем с самими переменными внутри функции. Единственные, на мой взгляд, отличия от указателей - синтаксис и константность.
Как создать и подключить .h и .с файлы? Как правильно? Создаю timer8.c с реализацие функции, и создаю timer8.h с обьявлением функции. Кидаю в одну папку с main.cpp файлом. В main в начале пишу:
Код:
#include "timer8.h"
Timer0Init(); // Timer0Init - обьявлен в timer8.h, и реализован в timer8.c
while(1) {
}
В timer8.h обьявляю:
Код:
#ifndef __timer8_h__ #define __timer8_h__
void Timer0Init(void);
#endif
В timer8.c пишу:
Код:
void Timer0Init(void) { реализация Timer0Init }
Как итог "undefined reference to `Timer0Init()'". Если в .h файле добавить "#include "timer8.c"" то ошибки нет. Но это же идеологически не правильно. Пишу в AtmelStudio7. Как правильно делать?
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Карма: 90
Рейтинг сообщений: 1289
Зарегистрирован: Чт мар 18, 2010 23:09:57 Сообщений: 4510 Откуда: Планета Земля
Рейтинг сообщения:1 Медали: 1
FeCat писал(а):
Кидаю в одну папку с main.cpp файлом.
1. Этого, наверное, мало. Нужно добавить исполняемый файл в проект. 2. Объявление в .cpp-файлах внешних функций, находящихся в .c-файлах нужно делать через обрамление в extern "C"{}
Т.е. это нормально-правильно, что если в майне есть инклюд .h файла, то .cpp автоматом к нему не подтягивается? Надо обязательно средствами IDE добавлять, а не из main или добавленных к main файлов. Далать "#include "timer8.cpp"" - вроде как не правильно?
Я правильно понимаю, что если появилась необходимость подключить к проекту "C++" файлы "C", то делаем так: extern "C"{ #include "timer8.h" }; Файл timer8.c добавится в проект "C++"(через IDE) как "C". Аналогично можно делать вставки кода не на языке "файла".
Файл timer8.c добавится в проект "C++"(через IDE) как "C".
Не добавится он в проект. Его нужно самому добавлять, ручками. Чтобы он отображался в дереве проекта. Как это делается конкретно в вашем IDE - не в курсе. Погуглите.
В любой IDE нужно добавлять ручками исходные файлы в проект.
Нет... Есть IDE, которые сканируют каталог и всё, что там найдено считают файлами проекта и подвергают компиляции. Типичный пример - IDE Momentics в QNX 6.3 (на базе Eclipse вроде она).
Цитата:
Есть IDE, которые всё подряд из папки компилят, но это как-то нефеншуйно.
Но, кстати, очень удобно. В отличие от Visual Studio с логическими папками (которые ещё создать надо ручками), проектом очень просто управлять - создал папки и скопировал файлы и попросил пересканировать. А вот есть всякие Keil, которые сами чего-то там из CMSIS и HAL компилируют из исходников, но в проекте этих файлов исходников не отображается (или я не в курсе, как его заставить их показать). Вот это неудобно.
Карма: 90
Рейтинг сообщений: 1289
Зарегистрирован: Чт мар 18, 2010 23:09:57 Сообщений: 4510 Откуда: Планета Земля
Рейтинг сообщения:0 Медали: 1
Удобство - дело сугубо индивидуальное. Вам удобно - другим нет... В любом случае, нужно сделать так, чтобы файлы появились в дереве проекта. А каким образом это сделать - зависит от конкретной IDE. Просто подкинуть файлы в папку, в большинстве случаев, не достаточно. По этому - гуглим...
Тупо подключать и компилировать все .c файлы из каталога - плохая идея. Компилятору следут передавать только нужные файлы.
Почему - ответ простой. Если у меня в проекте поддерживается, например, 20 разных контроллеров дисплея, а собираю я под какой-то конкретный, то компилировать 19 ненужных файлов нет смысла.
да, Eclipse CDT по умолчанию именно так и делает: всё, что в папке проекта, считает компилируемыми файлами. однако, легко можно исключить любой файл и даже папку целиком из этого списка.
WiseLord писал(а):
Если у меня в проекте поддерживается, например, 20 разных контроллеров дисплея, а собираю я под какой-то конкретный, то компилировать 19 ненужных файлов нет смысла
как правило, в IDE это решается при помощи конфигурации разных target-ов, и в упомянутой мною Eclipse именно так.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Наоборот, удобней в любой заголовочный файл C в начало поставить
Код:
#ifdef __cplusplus extern "C" { #endif
, а в конец:
Код:
#ifdef __cplusplus } #endif
WiseLord писал(а):
Тупо подключать и компилировать все .c файлы из каталога - плохая идея.
По разному бывает. Я часто настраиваю makefile именно таким образом. А вот все условно включаемое размещаю в соответствующих поддиректориях, нередко даже с симлинками. Тогда настройка на конкретную сборку вызывает подключение еще одной или нескольких поддиректорий (или конкретных файлов). В сложных сборках, когда этих самых исходных файлов десяток видов, а людей, работающих над проектом не мало, удобней минимально трогать общий makefile. С/С++ иходники еще ничего. А вот когда ворох мелких ресурсных файлов, причем взаимосвязанных, задолбаешься постоянно makefile мержить.
Тупо подключать и компилировать все .c файлы из каталога - плохая идея.
на самом деле, это очень удобно - заметно упрощается makefile и вообще управление проектом. Не хочешь, чтобы файл компилировался - просто не клади его в этот каталог
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 33
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения