Який найкращий спосіб визначити штифт вводу / виводу?


9

Я читаю такі визначення, як

const int ledPin = 9;

а також

#define ledPin 9

Я знаю, що таке визначення, як

int ledPin = 9;

це погана практика, якщо ви не збираєтесь її змінювати (чого зазвичай не хочете), хоча я це бачив кілька разів у програмах Arduino. Який із двох інших є кращим?

Відповіді:


6

#define ledPin 9є кращим. Тим самим int ledPin = 9;ви будете виділяти intпам'ять, значення якої використовується щоразу, коли ви використовуєте ledPin. #defineвідрізняється тим сенсом, що не виділяє пам'ять. пам'яті не називається ledPin. Перш ніж компілювати всі "ledPin", коди в коді (крім рядків) замінюються на 9. Так в основному

digitalWrite(ledPin);

стає

digitalWrite(9);

Переваги #define: Економить пам'ять, і оскільки всі ledPinзамінені на 9 виконання до виконання , це економить час процесора.

Немає значення в малих кодах ...


Чи вбудовані компілятори дійсно такі погані, що вони не роблять постійного складання при використанні const int?
Чуу

1
@chuu, наскільки я знаю, Arduino використовує gcc для avr. Тому його майже слід точно оптимізувати. Відповіді тут не показують особливого розуміння належної практики на C ++
chbaker0,

3
в C ++, const int ledPin = 9;є кращим над 2 іншими варіантами. Це НЕ виділяє пам'ять, за intвинятком випадків, якщо ви десь визначите вказівник на неї, що ніхто б не зробив.
jfpoilpret

Const int виділяє пам'ять @jfpoilpret. #define не займає жодної пам’яті, тому що це лише символічне ім’я виразу, а не ім’я пам’яті…

Перегляньте це посилання cplusplus.com/forum/beginner/28089 і переконайтеся самі. В іншому випадку просто проведіть перевірку за допомогою Arduino IDE: перевірте розмір даних за допомогою const та #define.
jfpoilpret

4

Строго кажучи, #defineпідхід використовуватиме трохи менше пам’яті. Однак різниця зазвичай невелика. Якщо вам потрібно зменшити використання пам'яті, то інші оптимізації, ймовірно, будуть набагато ефективнішими.

Аргументом на користь використання const intє безпека типу . Де б ви не посилалися на цей контактний номер за змінною, ви точно знаєте, який тип даних ви отримуєте. Це може сприяти / перетворюватися неявно або явно кодом, який його використовує, але він повинен вести себе дуже чітко.

Навпаки, значення в a #defineвідкрите для інтерпретації. Переважна більшість часу, ймовірно, взагалі не викличе у вас жодних проблем. Вам просто потрібно бути трохи обережним, якщо у вас є код, який робить припущення про тип або розмір значення.

Особисто я майже завжди віддаю перевагу безпеці типу, якщо у мене немає дуже серйозної потреби в збереженні пам'яті.


Я був у таборі #define, поки не прочитав відповідь Петра. Здається, я знаю, хто буде переробляти код на ці вихідні. ;)
linhartr22

2

Напевно, найкращим способом було б
const uint8_t LED_PIN = 9; // may require to #include <stdint.h>
або
const byte LED_PIN = 9; // with no include necessary
const unsigned char LED_PIN = 9; // similarly
ім'я у великих літери, як згідно загальної практики в С ++ (та інших), називати константи. Це не повинно використовувати жодну оперативну пам’ять сама по собі, а використовувати близько 1 байта програмної пам'яті за використання.
Однак можуть виникнути проблеми, коли число перевищує 127 і розширюється знаками під час просування до більших цілих підписаних чисел (не зовсім впевнене в цьому), хоча це малоймовірно трапиться з номерами штифтів.


-1

Не тільки буде

const int ledPin = 9;

займати оперативну пам’ять, але в цьому випадку буде використовувати більше оперативної пам'яті, ніж потрібно, оскільки digitalWrite(uint8_t, uint8_t)потрібні лише однобайтові аргументи, а int зазвичай два байти (залежно від компілятора, але типово). Зауважте, що ви можете надати буквальному явний тип у #define:

#define ledPin ((int)9) 

хоча в контексті, такому як аргумент функції, де потрібен певний тип (оскільки функція була прототипована належним чином!), вона буде або неявно передана, або отримає повідомлення про помилку, якщо типи не збігаються.


@DrivebyDownvoter, прокоментуєте ви свої причини?
JRobert
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.