Вопросы по С/С++ (СИ)

[VladislavS]

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

[OKF]

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

[FeCat]

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

[Аlex]

[uquote="FeCat",url="/forum/viewtopic.php?p=3617127#p3617127"]Файл timer8.c добавится в проект "C++"(через IDE) как "C".[/uquote]Не добавится он в проект. Его нужно самому добавлять, ручками. Чтобы он отображался в дереве проекта.
Как это делается конкретно в вашем IDE - не в курсе. Погуглите.

[da-nie]

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

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

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

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

[Аlex]

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

[WiseLord]

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

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

[ARV]

на базе Eclipse вроде она

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

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

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

[ПростоНуб]

[uquote="FeCat",url="/forum/viewtopic.php?p=3617127#p3617127"]то делаем так:
extern "C"{
#include "timer8.h"
};[/uquote]
Наоборот, удобней в любой заголовочный файл C в начало поставить

Код: Выделить всё

#ifdef __cplusplus
extern "C" {
#endif

, а в конец:

Код: Выделить всё

#ifdef __cplusplus
}
#endif

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

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

[Psych]

[uquote="FeCat",url="/forum/viewtopic.php?p=3617072#p3617072"]Если в .h файле добавить "#include "timer8.c"" то ошибки нет. Но это же идеологически не правильно.
Пишу в AtmelStudio7.
Как правильно делать?[/uquote]
Надо в cи файле написать #Include "timer8.h"

[FeCat]

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

[arkhnchul]

[uquote="WiseLord",url="/forum/viewtopic.php?p=3617201#p3617201"]Тупо подключать и компилировать все .c файлы из каталога - плохая идея.[/uquote]на самом деле, это очень удобно - заметно упрощается makefile и вообще управление проектом. Не хочешь, чтобы файл компилировался - просто не клади его в этот каталог

[WiseLord]

Ну... разбрасывание .c файлов по разным каталогам тоже не упрощает Makefile.

Честно говоря, я и сам в своих проектах часто использую маску по расширению .c, чтобы не переусложнять Makefile. Но всё-таки "в душе" считаю это не совсем правильным.

[da-nie]

Но всё-таки "в душе" считаю это не совсем правильным.

А напрасно. Когда количество файлов модулей подойдёт к тысяче, вам очень пригодится именно маска (поясню - речь не о микроконтроллерах, где такое вряд ли возможно, речь о программном обеспечении для PC).

[WiseLord]

В больших проектах уже работают другие системы сборки типа autotools, cmake, qmake и прочие, генерирующие Makefile.

[ПростоНуб]

Не обязательно. У меня есть проекты с сотнями исходных файлов, благополучно собирающиеся обычным GNU make. Необходимость в autotools/cmake возникает только на кроссплатформенных проектах, где действительно нужна автоконфигурация.
Для МК тоже бывают проекты с огромным количеством исходников. Другое дело, что бОльшая часть этих исходников является ресурсными файлами, а не кодом. Например, для каждого клиента можно выбрать свои фонты, иконки, сообщения, фоновый рисунок и логотип. В AT24C256 много ресурсов можно прошить )

[FeCat]

Как в .h файле в обьявлении класса обьявить массив указателей на методы этого-же класса?
Если делаю так:

Спойлер

.h

Код: Выделить всё

#ifndef __SENSORCONF_H__
#define __SENSORCONF_H__

#include <avr/io.h>

class SensorConf
{
	//variables
	public:
	public:
	int Alarm_1_TemperatureVal;
	unsigned char MenuN;	// номер функцию меню
	void menu_1(void);
	void menu_2(void);
	void menu_3(void);
	void menu_4(void);
	void menu_5(void);
	void menu_6(void);
	void menu_7(void);
	void menu_8(void);
	void menu_0(void);
	
	void (SensorConf::*Menu[10])(void);    //  ТУТ ЗАТЫК
	
	static unsigned char Sensor_Namber;
	
	void menu_start(void);
	
	protected:
	private:

	//functions
	public:
	SensorConf();
}; //SensorConf

#endif //__SENSORCONF_H__

.cpp

Код: Выделить всё

#include "SensorConf.h"

	void SensorConf::menu_1(void){};
	void SensorConf::menu_2(void){};
	void SensorConf::menu_3(void){};
	void SensorConf::menu_4(void){};
	void SensorConf::menu_5(void){};
	void SensorConf::menu_6(void){};
	void SensorConf::menu_7(void){};
	void SensorConf::menu_8(void){};
	void SensorConf::menu_0(void){};

	void (SensorConf::*Menu[10])(void) = {
		&SensorConf::menu_0,
		&SensorConf::menu_1,
		&SensorConf::menu_2,
		&SensorConf::menu_3,
		&SensorConf::menu_4,
		&SensorConf::menu_5,
		&SensorConf::menu_6,
		&SensorConf::menu_7,
		&SensorConf::menu_8,
		&SensorConf::menu_0	};
	
	void SensorConf::menu_start(void)
	{
		(this->*Menu[MenuN])();
	};

	SensorConf::SensorConf()
	{
		MenuN = 1;
		Alarm_1_TemperatureVal = 24;
	};

То при вызове "menu_start" микроконтроллер уходит с брос, судя по отладке массив "Menu" заполнен нулями.
Если в хедере закомментировать "void (SensorConf::*Menu[10])(void);" то работает нормально. Как так то?

[da-nie]

void (SensorConf::*Menu[10])(void) = {
&SensorConf::menu_0,
&SensorConf::menu_1,
&SensorConf::menu_2,
&SensorConf::menu_3,
&SensorConf::menu_4,
&SensorConf::menu_5,
&SensorConf::menu_6,
&SensorConf::menu_7,
&SensorConf::menu_8,
&SensorConf::menu_0 };

Такая инициализация работает вне класса? Хм.

Вообще-то, очень не рекомендую делать указатели на функции класса. На то есть вот какие причины.

[Reflector]

[uquote="FeCat",url="/forum/viewtopic.php?p=3629388#p3629388"]Как в .h файле в обьявлении класса обьявить массив указателей на методы этого-же класса?[/uquote]

Код: Выделить всё

class SensorConf
{
public:
	using FP = void(SensorConf::*)();
	FP Menu[10] = { &SensorConf::menu_1, &SensorConf::menu_2, ... };
	uint8_t MenuN;
	static uint8_t SensorNumber;

	void menu_1();
	void menu_2();
	...

	void menu_start() { (this->*Menu[MenuN])(); }
};

[FeCat]

[uquote="da-nie",url="/forum/viewtopic.php?p=3629399#p3629399"]Вообще-то, очень не рекомендую делать указатели на функции класса. На то есть вот какие причины.[/uquote]
Это не для средних любительских умов )).

Reflector
Спасибо! Это работает.