Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: глобальная переменная в DLL  (Прочитано 16685 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« : 16-09-2011 06:29 » 

в коде DLL, в глобальной области объявлены две переменные

Код:
int i1=0;
static int i2=0;

в чём будет заключаться различие , на что повлияет static ?
Записан

Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 16-09-2011 07:11 » 

на что повлияет static ?

На компоновку объектного модуля. При статической компоновке символ не попадает в таблицу имен модуля. Следовательно, обращение к переменной i2 возможно только в пределах модуля, в котором определена эта переменная.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #2 : 16-09-2011 07:55 » 

Dale, знаю, что эти правила приняты в Си. А на C++ они тоже распространяются?
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #3 : 16-09-2011 08:26 » 

Dale, то есть, по сути, это защита от экспорта и всё ?
Записан

RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4 : 16-09-2011 09:00 » new

Да, Леш, но на уровне исходного модуля, а не исполняемого. Также функции, объявленные как static, не экспортируются за пределы модуля и отсутствуют в таблице символов объектного файла. Соотв., в исполняемый модуль они тоже не попадают.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 16-09-2011 09:06 » 

Dale, знаю, что эти правила приняты в Си. А на C++ они тоже распространяются?

Да, поскольку корректная программа на C является корректной программой на C++ (почти всегда, за исключением нескольких тонких моментов, на которые случайно нарваться довольно трудно, нужно специально постараться).

Dale, то есть, по сути, это защита от экспорта и всё ?

Боюсь, я не вполне понимаю, что есть "экспорт" в данном контексте. Скажем так, это определение переменной с областью видимости в пределах файла. Если в каком-то другом исходном файле тоже будет объявление
Код:
static int i2=0;
, то это будет другая переменная, не имеющая к нашей никакого отношения.

Вообще, если речь идет о Visual C++ (судя по названию раздела), то это шаг назад в сторону C без плюсов. В языке, где есть возможность объявить классы и пользоваться инкапсуляцией, такие трюки странны (хотя синтаксис языка допускает, конечно, и ошибки компиляции не будет).
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #6 : 16-09-2011 09:20 » 

Dale, да, можно и в класс или namespace засунуть, в принципе. Интересовало именно поведение static вне класса (и внутри namespace, кстати, тоже).
Записан

Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #7 : 16-09-2011 09:29 » 

Dale, да, можно и в класс или namespace засунуть, в принципе.

Это намного корректнее. В C переменная со статической компоновкой - мера вынужденная, единственный способ хоть как-то имитировать инкапсуляцию. А когда есть настоящая инкапсуляция, нужно просто ей воспользоваться.

Интересовало именно поведение static вне класса (и внутри namespace, кстати, тоже).

Кстати, один из многих косяков, за которые Страуструпу следовало бы хорошего ремня всыпать. Мало ему было того, что слово static в C имеет два совершенно различных смысла в зависимости от контекста, так он еще и третий смысл придумал внутри класса, не имеющий ничего общего с теми двумя. Как будто в английском слов мало...
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #8 : 16-09-2011 09:44 » 

>>static в C имеет два совершенно различных смысла в зависимости от контекста,

какие такие два ?
Записан

Вад
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #9 : 16-09-2011 09:53 » 

Алексей1153++, второй - это, очевидно, статические переменные в теле функций. Там они задают уже не ограничение на экспорт, а "локальную глобальность" самой переменной, существование её экземпляра в единственном числе на всём протяжении работы программы, с инициализацией при первом обращении.

Код: (C)
void foo()
{
    static int i = 0;
    ++i;
    printf("%d\n", i);
}

int main() {
    foo();
    foo();
    return 0;
}
вывод будет:
1
2
« Последнее редактирование: 16-09-2011 09:58 от Вад » Записан
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #10 : 16-09-2011 10:03 » 

всё, сосчитал ) Даже 4 уже

1) static функция - без this
2) static мембер - один на все экземпляры
3) static переменная в функции - не реинициализируется меняется между вызовами
4) static в ::  - видимость в пределах файла реализации

а ещё

5) static в namespace --- ?
« Последнее редактирование: 16-09-2011 10:05 от Алексей1153++ » Записан

PredatorAlpha
Помогающий

us
Offline Offline

« Ответ #11 : 16-09-2011 10:27 » 

Кстати, один из многих косяков, за которые Страуструпу следовало бы хорошего ремня всыпать. Мало ему было того, что слово static в C имеет два совершенно различных смысла в зависимости от контекста, так он еще и третий смысл придумал внутри класса, не имеющий ничего общего с теми двумя. Как будто в английском слов мало...
Немного не согласен. Каждое новое ключевое слово ему приходилось в дебатах отвоёвывать. Почитай его "Дизайн и эволюция С++".

Цитата: Алексей1153++
всё, сосчитал ) Даже 4 уже
Ещё применимо к функции внутри с-файла.. Но это расширение п.4.
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #12 : 16-09-2011 11:26 » 

какие такие два ?
Алексей1153++, второй - это, очевидно, статические переменные в теле функций.

Верно. Первое применение static в C - статическая компоновка (переменная вне тела функции или функция доступны в пределах файла). Второе - статическая переменная в теле функции, сохраняющая значение между вызовами.

В C++ добавляется еще и третье значение - статические члены класса, не принадлежащие экземпляру класса.

Все три понятия совершенно различны по смыслу. Обозначение их одним ключевым словом без какой-либо объективной необходимости несколько напоминает лексикон планеты Плюк из галактики Кин-Дза-Дза, где большинство понятий выражались одним словом "ку".

Немного не согласен. Каждое новое ключевое слово ему приходилось в дебатах отвоёвывать. Почитай его "Дизайн и эволюция С++".

Не факт, что в эти дебаты вообще следовало встревать. Хейлсберг не встрял - и в результате имеем в C# ряд довольно логичных понятий вроде interface, abstract и delegate вместо невразумительных "чисто виртуальных" функций и низкоуровневых указателей на функции. А то бы ему насоветовали...

Нам же самим потом читать этот код, компилятору совершенно пофиг, что половина слов в программе - "ку". Вместо прозрачного текста в итоге получается натуральное кю (извиняюсь за свой чатланский).
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
PredatorAlpha
Помогающий

us
Offline Offline

« Ответ #13 : 16-09-2011 11:39 » 

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

Цитата
Хейлсберг не встрял - и в результате имеем в C# ряд довольно логичных понятий
Оно то да. Но там уже накомпен опыт по плюсам и Делфи, что надо, что удобно и т.п. Плюсы - это совсем другая эпоха.

Нам же самим потом читать этот код, компилятору совершенно пофиг, что половина слов в программе - "ку". Вместо прозрачного текста в итоге получается натуральное кю (извиняюсь за свой чатланский).
Ко всему мерзавец-человек привыкает.... (С)
« Последнее редактирование: 16-09-2011 11:44 от PredatorAlpha » Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines