Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: расширение области видимости переменной
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
dimka76
May 13 2009, 09:46
Доброго времени суток.

Использую WinAVR-20090313

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

язык Си позволяет обратиться из функции к глобальной переменной, если в этой функции имеется одноименная переменная следующим образом
Код
int i;

void foo(void)
{
  int i, k, e;

  k = i; // i локальная
  e = ::i; // i глобальная

}



у меня компилятор в этом случае выдает ошибку.
может этот оператор расширения области видимости присутствует только в C++ ? Я пробовал в начало файла добавлять следующее определение
Код
#ifndef __cplusplus
#define __cplusplus
#endif


все равно выдается та же ошибка

как мне быть в этом случае?

можно конечно дать разные имена, но хочется разобраться почему компилятор выдает ошибки, если Си предоставляет возможность использования одноименных локальных и глобальных имен.
MrYuran
May 13 2009, 09:59
Даже если определить локальную переменную, совпадающую с глобальной, нормальный компилятор предупреждает "variable shadowed by..." или что-то в этом духе.
Так делать не надо, ибо это источник ошибок.
:: - это точно из плюсов.
И вообще, переменные должны иметь осмысленные имена, а не i,j,k (тем более глобальные)
dimka76
May 13 2009, 10:04
Цитата(MrYuran @ May 13 2009, 13:59) *
:: - это точно из плюсов.


но я же делал #define __cplusplus
а ошибку все равно выдавало


Цитата(MrYuran @ May 13 2009, 13:59) *
И вообще, переменные должны иметь осмысленные имена, а не i,j,k (тем более глобальные)


это я здесь для примера привел
bus16
May 13 2009, 10:34
Цитата(dimka76 @ May 13 2009, 14:04) *
но я же делал #define __cplusplus
а ошибку все равно выдавало

Вероятно надо использовать G++ - скрипт править
Сергей Борщ
May 13 2009, 11:55
Цитата(dimka76 @ May 13 2009, 13:04) *
но я же делал #define __cplusplus
а ошибку все равно выдавало
С тем же успехом можно было написать #define __this_program_works.
Чтобы компилировать в режиме С++ файл должен иметь расширение cpp, а в makefile должно быть прописано правило компиляции .cpp
dimka76
May 13 2009, 12:21
Цитата(Сергей Борщ @ May 13 2009, 15:55) *
С тем же успехом можно было написать #define __this_program_works.
Чтобы компилировать в режиме С++ файл должен иметь расширение cpp, а в makefile должно быть прописано правило компиляции .cpp


если вас не затруднит, не подскажите, что писать в makefile

и еще

например в pgmspace.h есть такое определение
Код
#ifdef __cplusplus
extern "C" {
#endif


значит #define __cplusplus компилятор должен понимать
SysRq
May 13 2009, 12:24
Код
int i;

int get_i(void)
{
  return i;
}

void foo(void)
{
  int i, k, e;

  k = i; // i локальная
  e = get_i(); // i глобальная

}
dimka76
May 13 2009, 12:26
Цитата(SysRq @ May 13 2009, 16:24) *
Код
int i;

int get_i(void)
{
  return i;
}

void foo(void)
{
  int i, k, e;

  k = i; // i локальная
  e = get_i(); // i глобальная

}


можно и так, но громоздко. тогда уж лучше дать разные имена и не городить лишние функции
SysRq
May 13 2009, 12:30
Цитата(dimka76 @ May 13 2009, 16:26) *
тогда уж лучше дать разные имена и не городить лишние функции

Засуньте все глобальные переменные в отдельный namespace, ежели вам так хочется имен одинаковых.
HARMHARM
May 13 2009, 13:45
Цитата(dimka76 @ May 13 2009, 15:21) *
...
значит #define __cplusplus компилятор должен понимать

Этот дефайн как раз компилятор определяет, когда запущен в режиме С++.
У вас причина и следствие перепутались.
Сергей Борщ
May 13 2009, 17:29
Цитата(dimka76 @ May 13 2009, 15:21) *
если вас не затруднит, не подскажите, что писать в makefile
то же самое, что и для файла с расширением .c
Цитата(dimka76 @ May 13 2009, 15:21) *
например в pgmspace.h есть такое определение
Код
#ifdef __cplusplus
extern "C" {
#endif
значит #define __cplusplus компилятор должен понимать
Компилятор не понимает и не может видеть #define. #define - директива препроцессора. Компилятор получает текст, в котором препроцессор уже сделал все текстовые подстановки из #define
sergeeff
May 13 2009, 18:30
Никак не возьму в толк. Какая разница?

1. В "С" программе глобальным и локальным переменным дать разные имена.
2. Перегнать весь проект в С++ (что автор смутно себе представляет) и перед глобальными переменными поставить ::

По любому - чисто правка текста в редакторе.
dimka76
May 14 2009, 04:38
Действительно, я смутно представляю (точнее вообще не представляю) как в WinAVR создавать проекты на С++ и смешаные проекты ( Си + С++).
Использую связку WinAVR + AVRStudio, а там makefile создается автоматически. Пробовал менять расширение файла с *.с на *.С.
Компилятор на :: перестал выдавать ошибки, но начал давать предупреждение на -std=gnu99. Пробовал использовать MFile из пакета WinAVR, но для опиции -std там всего четыре альтернативы и на все компилятор выдает предупреждения при использовании файла программы с расширением *.С.
Непомнящий Евгений
May 14 2009, 06:19
А расширение .cpp не помогает?
amw
May 14 2009, 06:21
Цитата(dimka76 @ May 14 2009, 07:38) *
Пробовал менять расширение файла с *.с на *.С.

Уже говорили - *.cpp
dimka76
May 14 2009, 07:15
Цитата(amw @ May 14 2009, 10:21) *
Уже говорили - *.cpp



..\WinAVR-20090313\doc\avr-libc\avr-libc-user-manual\FAQ.html

Цитата
Can I use C++ on the AVR?
Basically yes, C++ is supported (assuming your compiler has been configured and compiled to support it, of course). Source files ending in .cc, .cpp or .C will automatically cause the compiler frontend to invoke the C++ compiler. Alternatively, the C++ compiler could be explicitly called by the name avr-c++........................................
Непомнящий Евгений
May 14 2009, 08:11
Цитата(dimka76 @ May 14 2009, 08:38) *
Пробовал менять расширение файла с *.с на *.С.
Компилятор на :: перестал выдавать ошибки, но начал давать предупреждение на -std=gnu99.


Дык а что вас изумляет? gnu99 - это, наскока я понимаю, стандарт С99. А вы компилите C++...
dimka76
May 14 2009, 08:18
Цитата(Непомнящий Евгений @ May 14 2009, 12:11) *
Дык а что вас изумляет? gnu99 - это, наскока я понимаю, стандарт С99. А вы компилите C++...


да вобще ничего не изумляет. Вопрос в том, как избавиться от предепреждения?
Непомнящий Евгений
May 14 2009, 09:29
Очевидно - убрать опцию --std=gnu99 для .C файлов smile.gif

Вот как ее убрать - хз, я из авр-студии не компилил...
mdmitry
May 14 2009, 13:02
Забросить студию и собрать проект руками, написав или поправив makefile для Winavr. Есть в комплекте утилита для помощи в написании makefile. Есть документация на русском языке по make. Вообще-то, уже работа с make обсуждалась неоднократно.
В список компилируемых файлов внесите их с правильными расширениями
Код
# List C source files here. (C dependencies are automatically generated.)
SRC =

# List C++ source files here. (C dependencies are automatically generated.)
CPPSRC =

и поправьте опции компилятора для расширения сообщений о компиляции. Можете узнать много нового rolleyes.gif
Сергей Борщ
May 14 2009, 18:33
Цитата(dimka76 @ May 14 2009, 07:38) *
Действительно, я смутно представляю (точнее вообще не представляю) как в WinAVR создавать проекты на С++ и смешаные проекты ( Си + С++).
Но хоть что такое С++ и как оно стыкуется с С вы знаете? Про name mangling и вытекающий из него extern "C" для сишных функций слышали? Иначе лучше вам действительно переименовать локальную переменную.
sergeeff
May 14 2009, 19:08
Вся эта возня с переменными, она для реальной работы или для учебы? По-моему поменять имена у глобальных переменных - дел на 10 минут, а нам задают вопросы третий день.
dimka76
May 15 2009, 05:08
Цитата(Сергей Борщ @ May 14 2009, 22:33) *
Но хоть что такое С++ и как оно стыкуется с С вы знаете? Про name mangling и вытекающий из него extern "C" для сишных функций слышали? Иначе лучше вам действительно переименовать локальную переменную.


Что такое С++ я знаю. Про extern "C" для сишных функций я слышал, но речь идет не о фйнкции. А если вы это к #define __cplusplus, то я думал, что так WinAVR распознает, что прога написана на С++.



Цитата(sergeeff @ May 14 2009, 23:08) *
Вся эта возня с переменными, она для реальной работы или для учебы? По-моему поменять имена у глобальных переменных - дел на 10 минут, а нам задают вопросы третий день.



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

Цитата
а нам задают вопросы третий день.


Но ведь никто никого не принуждает отвечать rolleyes.gif
Сергей Борщ
May 15 2009, 07:10
Цитата(dimka76 @ May 15 2009, 08:08) *
Что такое С++ я знаю.
Я тоже знаю, что такое кардиология. Но это не значит, что могу проводить операции на сердце или даже оказать первую помощь, если (тьфу-тьфу) кому-то станет плохо. По вашим вопросам понятно, что знания у вас если и есть, то поверхостные. Не обижайтесь.
Цитата(dimka76 @ May 15 2009, 08:08) *
Про extern "C" для сишных функций я слышал, но речь идет не о функции. А если вы это к #define __cplusplus,

Нет, это я к тому, что если вы переведете один из файлов проекта на плюсы - то сразу же получите ругань линкера, что из вашего плюсового файла не видны функции из сишных. А из вопроса про #define __cplusplus понятно, что никаких специальных действий для решения этого у вас не предусмотрено и сразу, с наскоку, решить это у вас не получится.
dimka76
May 15 2009, 08:04
Цитата(Сергей Борщ @ May 15 2009, 11:10) *
Не обижайтесь.


Я и не обижаюсь. Про С++ я только читал. На практике не применял.

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


Как я уже выше говорил, я этот файл переводил в плюсы (давал ему расширение .С). Линкер не ругался. Потому, что этот файл не обращается к сишным (без плюсов) функциям. Наоборот, фунции из .с файлов, обращаются к функциям этого файла( которому я давал расширение .С). Но, опять таки, как я уже говорил выше, компилятор выдавал предупреждение на -std=gnu99.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.